-
Notifications
You must be signed in to change notification settings - Fork 1
chore: optimize dockerfile #61
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
base: main
Are you sure you want to change the base?
Conversation
@gastonva could you share the a size difference between the previous docker image size and new one. Also, I'd like to see the output of docker scout |
I suppose that for this particular template, the optimizations are not that significant. In the SCJ project, we managed to reduce the image size from around 2.8GB to 1.9GB. I'm not an expert in Docker, but my assumption is that the larger the original image size, the more impactful these optimizations become, and possibly others as well. Not sure if this PR makes sense anymore, you tell me. |
Changes look good to me, I was just curious about the final results. |
Type of change
Description of the change
In a recent project, we discovered that our Docker image was unnecessarily large and somewhat inefficient, so we implemented a few improvements.
The first change involved optimizing layer handling and cache usage. Every instruction in a
Dockerfile
creates a layer that Docker automatically caches. When we copied the entire project in one step, any change to any file would invalidate the cache and trigger a full rebuild. However, package installation does not need to be repeated if dependencies haven’t changed. To take advantage of layer caching, we split the copy step into two: first we copy only thepyproject.toml
anduv.lock
files and install dependencies, and then we copy the rest of the project. This allows Docker to reuse the cached dependency layer whenever those files remain unchanged.We also reduced the APT footprint by skipping recommended packages and installing only the ones we actually need.
Finally, we could add even more caching by using BuildKit via docker buildx. Enabling BuildKit in a devcontainer requires installing or configuring docker buildx on the host, which may complicate the developer workflow, but we can discuss whether the benefits outweigh the extra setup.
Related PRs
N/A