ansible-community / ara

ARA Records Ansible and makes it easier to understand and troubleshoot.
https://ara.recordsansible.org
GNU General Public License v3.0
1.84k stars 170 forks source link

Dockerfile for ARA #455

Open apollo13 opened 1 year ago

apollo13 commented 1 year ago

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:

What do you think? I can provide the Dockerfile if wanted :)

erik-overdahl commented 1 year ago

Is what you're talking about different from these? https://ara.readthedocs.io/en/latest/container-images.html

apollo13 commented 1 year ago

Yes, I'd like to have a common tooling for building the image. I do not want to figure out how I can shove buildah into my ci pipeline. So any improvement I'd be able to offer would be towards a Dockerfile/Containerfile that one can build with docker, podman and kaniko among others

On Thu, Nov 3, 2022, at 19:50, erik-overdahl wrote:

Is what you're talking about different from these? https://ara.readthedocs.io/en/latest/container-images.html

— Reply to this email directly, view it on GitHub https://github.com/ansible-community/ara/issues/455#issuecomment-1302534117, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAT5C5W6JBXX3MIRQTQSP3WGQCQDANCNFSM6AAAAAARV4LPMU. You are receiving this because you authored the thread.Message ID: @.***>

hille721 commented 1 year ago

There is already a discussion about the future handling of docker files here: https://github.com/ansible-community/ara/issues/352

dmsimard commented 1 year ago

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.

dmsimard commented 1 year ago

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.

apollo13 commented 1 year ago

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…

dmsimard commented 1 year ago

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.