grafana-toolbox / grafanimate

Animate timeseries data with Grafana.
https://community.panodata.org/t/grafanimate/205
GNU Affero General Public License v3.0
47 stars 6 forks source link

Add Dockerfile #21

Closed intermittentnrg closed 1 year ago

intermittentnrg commented 1 year ago

A work in progress submitted for any feedback.

Since some animations take some time to render, especially with --exposure-time, and before I added #19, I thought I will run it as container from pipeline.

You may notice I don't usually write python. Submitted for early feedback.

Also it should build container from github actions and push image to github container registry.

intermittentnrg commented 1 year ago

Added GH actions workflow to build amd64 and arm64 images and push to github container registry for current repo

Docker images can be seen here https://github.com/intermittentnrg/grafanimate/pkgs/container/grafanimate

Build from workflow here: https://github.com/intermittentnrg/grafanimate/pull/3/checks

amotl commented 1 year ago

Hi again,

I've cherry-picked your Dockerfile into GH-24, and added our well-known recipe about OCI->GHCR publishing to it, following your intentions.

With kind regards, Andreas.

intermittentnrg commented 1 year ago

Yes I used https://github.com/docker/build-push-action instructions and examples also, but went with parallel github worker per platform per example here https://docs.docker.com/build/ci/github-actions/multi-platform/#distribute-build-across-multiple-runners. Building arm64 images with qemu can be very slow, but seems not to be an issue for grafanimate.

Also if you have any suggestions on the Dockerfile it would be great. It's a first attempt. Should maybe switch to from ubuntu to alpine for base image...

amotl commented 1 year ago

Hi again,

Also if you have any suggestions on the Dockerfile it would be great. It's a first attempt. Should maybe switch to from ubuntu to alpine for base image...

I already started to build upon your proposal on behalf of GH-24. We discourage Alpine-based images, due to subtle differences compared to glibc. Specifically when running a huge software stack including Firefox, this is even more important.

With kind regards, Andreas.

intermittentnrg commented 1 year ago

There is a alpine package for firefox available though. https://wiki.alpinelinux.org/wiki/Firefox

I try to use alpine if possible and have used it for python applications in production environment without issues.

amotl commented 1 year ago

We love the musl project, and it is becoming more mature every day. Still, we didn't regain enough trust, and don't bother too much about it. There are a few more pointers on this discussion - admitted, it's already from a few years ago ;].

Other than potential differences between musl and glibc, the package management is also different than Debian, so we would need to re-learn, or maintain a different stack. It is not worth the time for us, we are clearly on the Debian side of "maintenance convenience and peace of mind", optimizing for re-using well-established recipes across all the projects we maintain.

intermittentnrg commented 1 year ago

It's basically just apk add firefox-esr instead of apt install firefox-esr`. But yeah we can discuss this later. Might add a Dockerfile.alpine later tho and see how it goes...

amotl commented 1 year ago

It's basically just apk add firefox-esr instead of apt install firefox-esr.

It is not about this specific recipe. It is about that we want to use the same kinds of recipes across many projects, and need to keep a reasonably universal setup to keep our sanity. Thanks for your understanding ;].

amotl commented 1 year ago

GH-24 has been merged, therefore I am closing this. Thanks for all the fish.