docker image publishing #6
Conversation
| @@ -0,0 +1,34 @@ | |||
| ARG PYTHON_VERSION=3.12 | |||
| FROM python:${PYTHON_VERSION}-alpine AS builder | |||
There was a problem hiding this comment.
nitpick: I don't like using alpine variants of images, unless using static builds like go binaries (even then I prefer distroless images).
I had to deal with a lot of headaches due to some libraries sometimes not working under alpine. Though, I don't know the recent scene as I have not used alpine images for a long time.
There was a problem hiding this comment.
For actively developed project this is true, but for dockerized CLIs alpine is has additional benefits, since its twice as small, which is reflected in bootup speed. There is some argument for security as well (less security alerts due less of stuff included by default).
There was a problem hiding this comment.
One thing worth noting, is project using this template can always replace this Dockerfile if for some reason alpine proves a non-starter. And then it could even be added as another option to cookiecutter if that becomes a common need.
Right now for two projects were I expect this dockerfile to be used alpine will do better.
...}/# COOKIECUTTER{% if cookiecutter.docker_image == "y" %}Dockerfile# COOKIECUTTER{% endif %}
Outdated
Show resolved
Hide resolved
| RUN pdm build -d /tmp/wheelhouse | ||
|
|
||
| RUN pip install --no-cache-dir -r /tmp/requirements.txt | ||
| RUN pip install --no-cache-dir /tmp/wheelhouse/*.whl | ||
|
|
||
| FROM python:${PYTHON_VERSION}-alpine | ||
|
|
||
| COPY --from=builder /usr/local/lib/python${PYTHON_VERSION%.*}/site-packages /usr/local/lib/python${PYTHON_VERSION%.*}/site-packages | ||
| COPY --from=builder /usr/local/bin /usr/local/bin |
There was a problem hiding this comment.
Instead of copying the os level (in container) site-packages, I'd prefer to set-up a venv in the builder, install the dependencies there, copy the whole venv in the final stage. It keeps the app dependencies totally separate from container-global packages.
There was a problem hiding this comment.
there is no point of doing venv "container" inside already containerized system (there is no expectation of anything other than the installed app to be installed on it, so there are no extra "global" packages), it would also significantly increase the image size - which as mentioned in other comment - while not affecting typical apps much, for CLI is problematic
There was a problem hiding this comment.
I think right now we use venv in django cookiecutter, but AFAIK only reason for that is that we went and used pdm in different fashion than I did here, and it has no ability to work without venv other than using some rejected-PEP implementation. Also for django apps they are that heavy that we simply care much less about the extra megabytes added with venv.
Since this is targeted towards CLI, priorities are different.
| with: | ||
| context: . | ||
| file: ./Dockerfile | ||
| platforms: linux/amd64,linux/arm64 |
There was a problem hiding this comment.
question: doesn't multi-arch builds require qemu? The docs says:
If you want support for more platforms, you can use QEMU with the Docker Setup QEMU action.
But I couldn't find for which platforms you need qemu 🤷♂️
There was a problem hiding this comment.
Only thing I can say to that is that I tested this workflow and it correctly built images for these archs on default GHA runner
No description provided.