Dockerfile for ARA
apollo13 opened this issue · 7 comments
What is the idea ?
I'd love to provide an optimized Dockerfile for ARA that can be easily built (and preferably also shipped to dockerhub during releases). What would improve:
- No dev deps in the image (EDIT:// Correction there are no dev deps in the image, that was an oversight from me)
- Properly collected static files
- Easier building (buildah.sh files are still somewhat niche and not supported anywhere)
What do you think? I can provide the Dockerfile if wanted :)
Is what you're talking about different from these?
https://ara.readthedocs.io/en/latest/container-images.html
There is already a discussion about the future handling of docker files here: #352
Hi @apollo13,
Properly collected static files
I've been meaning to test and benchmark using collected static files without whitenoise.
I am curious about the overhead. Have you figured something that works ?
Easier building (buildah.sh files are still somewhat niche and not supported anywhere)
I have a personal preference for buildah (and podman) but that doesn't mean we can't have a Dockerfile and there is no need need to argue about which is easier :p
My time is limited and I don't generally use Docker but I don't mind if you would like to contribute one and help maintain it. Please feel free to send a PR.
Unless you had something specific in mind, the Dockerfile can live next to the bash script and there's already a playbook to build, test and publish the container images. We can update them to support Docker where necessary.
I realized just now there are some Zuul assumptions in them so I'll send a PR to make that easier to run locally but in the meantime it looks like this recorded on the demo: https://demo.recordsansible.org/playbooks/3728.html
The idea is that there's a bash script for each image tag -- so far these have been buildah commands but it could very well be Docker build . -t ara-pi:with_dockerfile or something.
There is already a discussion about the future handling of docker files here: #352
@hille721 there are relations between that issue and this one but for me they are fundamentally about different things -- this one is about contributing a Dockerfile and the other one is about creating image tags for versions.
They are not mutually exclusive and I still have opinions about versioned tags.
I will revisit that issue sometime in the future.
I am curious about the overhead. Have you figured something that works ?
Well collecting static files would mean that static files would be brotli compressed and sent out with proper caching headers etc…
but that doesn't mean we can't have a Dockerfile and there is no need need to argue about which is easier :p
Given that a Dockerfile/Containerfile (I am happy to name it Containerfile btw) is buildable by podman as well as docker I am wondering if in the longrun consolidating to one file might not make more sense (maintainance wise). But either way I will submit a Dockerfile and you let me know how you like it…
Well collecting static files would mean that static files would be brotli compressed and sent out with proper caching headers etc…
Right, what I mean to say is that currently static files are served by the django backend via whitenoise and as a result does not /need/ to be collected.
Now, ara doesn't have a lot of static assets but I assume there is a non-zero overhead to doing that vs collecting files and exclusively serving them through a web server in front.
Given that a Dockerfile/Containerfile (I am happy to name it Containerfile btw) is buildable by podman as well as docker I am wondering if in the longrun consolidating to one file might not make more sense (maintainance wise). But either way I will submit a Dockerfile and you let me know how you like it…
Containerfile is fine ¯\(ツ)/¯
There tends to be subtle enough differences or edge cases between buildah/podman and docker but generally, it works both ways, yes. We can try it.
I think we will eventually want to settle on keeping at least one approach with buildah and one with Docker because the intent is two-fold: yes, providing images is cool but good documented examples for educational purposes such that people can build their own images easily is great.