Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Orphaned Docker Layers in CLI with docker-compose #2387

Open
5 tasks done
davies-a opened this issue Nov 11, 2024 · 0 comments
Open
5 tasks done

Orphaned Docker Layers in CLI with docker-compose #2387

davies-a opened this issue Nov 11, 2024 · 0 comments
Assignees

Comments

@davies-a
Copy link

Checked other resources

  • I added a very descriptive title to this issue.
  • I searched the LangGraph/LangChain documentation with the integrated search.
  • I used the GitHub search to find a similar question and didn't find it.
  • I am sure that this is a bug in LangGraph/LangChain rather than my code.
  • I am sure this is better as an issue rather than a GitHub discussion, since this is a LangGraph bug and not a design question.

Example Code

# langgraph.json
{
  "docker_compose_file": "configs/default.docker-compose.yml",
  "graphs": {
    "chat_response": "./app/graphs/chat_response.py:graph",
  },
  "env": ".env",
  "python_version": "3.12",
  "dependencies": ["."]
}

Error Message and Stack Trace (if applicable)

No response

Description

Hey, Apologies if you don't consider this a bug, it's in that grey area where devex performance issues cause degredation that could be considered either. But sorry if this is in the wrong place!

We're encountering an issue when using langgraph up --watch with the above langgraph.json.

Essentially the compiled dockerfile lines produced by the CLI in this region create an uncacheable layer in faux_pkgs_str, meaning that the subsequent pip installs can't use the docker build cache. That then means that if you are repetitively saving, you can easily balloon the HD space usage dramatically. I've had quite a few instances where it's exhausted the 50GB volume assigned to my docker VM and the postgres sidecar no longer inserts records. I ended up tearing down regularly and using docker builder prune about once a day on my development machine, meaning we lost traces etc.

In our instance, we've resorted to creating a static pyproject.toml file and a static docker-compose.yml using what the CLI creates; however this is a potential maintenance headache long-term.

It appears that the package name isn't used for anything outside the install and is the only dynamic content; as such I'd suggest swapping to a static pyproject.toml file that can be added to the container, so that docker can cache it.

Very happy to open a PR if it would help, but wanted to make the observation/issue report first to gather your thoughts!

System Info

❯ python -m langchain_core.sys_info

System Information

OS: Darwin
OS Version: Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6030
Python Version: 3.12.3 (v3.12.3:f6650f9ad7, Apr 9 2024, 08:18:47) [Clang 13.0.0 (clang-1300.0.29.30)]

Package Information

langchain_core: 0.3.8
langchain: 0.3.1
langchain_community: 0.3.1
langsmith: 0.1.130
langchain_anthropic: 0.2.1
langchain_aws: 0.2.1
langchain_groq: 0.2.0
langchain_openai: 0.2.1
langchain_text_splitters: 0.3.0
langgraph: 0.2.34

Optional packages not installed

langserve

Other Dependencies

aiohttp: 3.10.8
anthropic: 0.34.2
async-timeout: Installed. No version info available.
boto3: 1.35.32
dataclasses-json: 0.6.7
defusedxml: 0.7.1
groq: 0.11.0
httpx: 0.27.2
jsonpatch: 1.33
langgraph-checkpoint: 2.0.0
numpy: 1.26.4
openai: 1.51.0
orjson: 3.10.7
packaging: 24.1
pydantic: 2.9.2
pydantic-settings: 2.5.2
PyYAML: 6.0.2
requests: 2.32.3
requests-toolbelt: 1.0.0
SQLAlchemy: 2.0.35
tenacity: 8.5.0
tiktoken: 0.7.0
typing-extensions: 4.12.2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants