Docs/docker best practices #9542
Conversation
This ensures to use the correct python executable. Using `run` simply uses `sys.prefix` with a bin suffix, which is not necessarily the currently used python executable. E.g. when linking a specific python version to a custom directory, using `sys.prefix` may point to the wrong python version: * /usr/bin/python2.7 * /usr/bin/python3.6 * /usr/bin/python is a symlink to 2.7 * /usr/bin/local/python (or any other location) is a symlink to 3.6 which shadows the former symlink `sys.prefix` is `/usr` in this case, which is correct, but the `python` executable there points to the wrong version. `run_pip` in the env fixes this already by using `sys.executable`, see https://github.com/python-poetry/poetry/blob/develop/poetry/utils/env.py#L964 This should be used in the executor as well.
radoering
force-pushed
the
docs/docker-best-practices
branch
from
d12242c to
5500497
Compare
|
Deploy preview for website ready! ✅ Preview Built with commit 21ec55e. |
…idebar by the framework
radoering
left a comment
radoering
left a comment
There was a problem hiding this comment.
Some first feedback.
One general point: I am wondering why the project itself is not copied (after poetry install)? It feels like the examples stop halfway through.
…a/poetry into docs/docker-best-practices
…tall --no-root' Edit Dockerfile as suggested in - python-poetry#9542 (comment) - python-poetry#9542 (comment)
Edit Dockerfile as suggested in - python-poetry#9542 (comment)
|
I wonder if we could make a repo in our org to store those examples instead of putting them here. @radoering what do you think? |
We could. Do you propose to only put the |
|
There are some things that irk me in this. But first, is this something we are considering putting into the docs? I agree with Secrus that the example code etc should either be inline in doc or in a separate repo. I personally think we should not need to be the care takers of that, as that is out of scope for Poetry as a project. |
|
|
||
| # Install the dependencies and clear the cache afterwards. | ||
| # This may save some MBs. | ||
| RUN poetry install --no-root && rm -rf $POETRY_CACHE_DIR |
There was a problem hiding this comment.
I wonder if rm -rf $POETRY_CACHE_DIR is necessary since this is the builder stage, that shouldn't (?) be present in the output image at all
There was a problem hiding this comment.
Having the rm -rf $POETRY_CACHE_DIR should keep the intermediate stage smaller - impacting how much storage space it uses.
With bigger dependencies (pytorch) the cache impact is notable.
There was a problem hiding this comment.
Why not using:
RUN --mount=type=cache,target=/opt/.cache \
poetry install
This allows saving poetry package cache in local docker builder, which can be reused later. And it is not included into final image.
| @@ -0,0 +1,36 @@ | |||
| FROM python:3.11-slim as builder | |||
There was a problem hiding this comment.
Consider using python:3.11-alpine instead (124MB vs 48.3MB for python 3.12)
There was a problem hiding this comment.
Thank you very much for sharing this suggestion. In fact Alpine may be great for a “the lightest poetry image” version.
In general, I would not recommend Alpine, since it does not seem the best in terms of security and stability (see e.g. https://pythonspeed.com/articles/alpine-docker-python/).
Please feel free to share if you have different thoughts.
There was a problem hiding this comment.
That's interesting. No, I don't have any other argument other than "I've heard alpine small", and the image size comparison I shared earlier.
I'm not sure why you mention security though ? I didn't see anything related to that in your article
There was a problem hiding this comment.
You are right.
My answer comes from some rules of thumb like:
prefer debian for stability, prefer slim for smallness, use alpine when you want something just essential, but consider that you will have to compile everything yourself, with possible errors.
Anyway, it was enough to search on docker hub, to compare for example on python 3.11:
| image | Main CVEs | compressed size |
|---|---|---|
| python:3.11-slim-bookworm | 1 H | ~46MB |
| python:3.11-alpine3.21 | 1 H | ~20MB |
So I would say that from the security point of view there are no particular concerns. Finally, alpine team also state that they care about safety :) .
Thank you again
9 participants
Init Docker Best Practices documentation
Resolves: Discussion #1879
This PR is intended to begin the section on Docker Best Practices in Documentation.
It will serve as a collection point for all best practices (BPs) that will be recommended.
Hopefully, BPs, in order to be included and accepted here, will have to be accompanied by a concrete example that reproduces and demonstrates their effectiveness and by due references where possible.
The following contributions are proposed in this PR:
docs/docker-best-practices.md. Introduction file and list of best practices.docker-examples/. Folder with practical examples to get you started. This already comes with two examples, also referenced in the docker-best-practices.md.