Add arm64 docker image for grafana/oncall

[vadimkerr]

When running the following command from README.md: docker-compose --env-file .env_hobby -f docker-compose.yml up --build -d, uWSGI fails to start on my M1 Mac.

uWSGI logs:

[uWSGI] getting INI configuration from uwsgi.ini
[log-encoder] registered format ${strftime:%Y-%m-%d %H:%M:%S} ${msgnl}
2022-06-15 08:06:33 *** Starting uWSGI 2.0.20 (64bit) on [Wed Jun 15 08:06:33 2022] ***
2022-06-15 08:06:33 compiled with version: 11.2.1 20220219 on 14 June 2022 18:16:43
2022-06-15 08:06:33 os: Linux-5.10.104-linuxkit #1 SMP PREEMPT Thu Mar 17 17:05:54 UTC 2022
2022-06-15 08:06:33 nodename: cfcc13d1c266
2022-06-15 08:06:33 machine: x86_64
2022-06-15 08:06:33 clock source: unix
2022-06-15 08:06:33 pcre jit disabled
2022-06-15 08:06:33 detected number of CPU cores: 4
2022-06-15 08:06:33 current working directory: /etc/app
2022-06-15 08:06:33 writing pidfile to /tmp/project-master.pid
2022-06-15 08:06:33 detected binary path: /usr/local/bin/uwsgi
2022-06-15 08:06:33 uWSGI running as root, you can use --uid/--gid/--chroot options
2022-06-15 08:06:33 setgid() to 2000
2022-06-15 08:06:33 setuid() to 1000
2022-06-15 08:06:33 chdir() to /etc/app
2022-06-15 08:06:33 your memory page size is 4096 bytes
2022-06-15 08:06:33 detected max file descriptor number: 1048576
2022-06-15 08:06:33 lock engine: pthread robust mutexes
2022-06-15 08:06:33 unable to set PTHREAD_PRIO_INHERIT

When building the grafana/oncall image manually on my machine and using it in the docker-compose file, all works as expected. My proposal is to add a docker image for arm64 to DockerHub, so the instruction works for Apple Silicon/arm64 users.

[iskhakov]

Agree, let's add another env variable, that use can configure during docker-compose up, to use arm64 image and add the ci job to build such an image

[Matvey-Kuk]

I like it. @vadimkerr will you take it?

[vadimkerr]

@Matvey-Kuk yes, assigned it to myself.

[tziokioa]

Hello team

same issue still occurs. any update ?

[Matvey-Kuk]

@tziokioa it's in our short-term backlog

[tziokioa]

Thank you Matvey :) thank you all for the great work - just wanted to know the status :)

[tommyjcarpenter]

I do not use this repo, but I'm chiming in to say this is the closest issue I've found on the web to mine! I have an alpine bsed image that runs UWSGI. I can run that docker image in Ubuntu fine (docker installed on ubuntu). However, when I run this image on my M1 Mac using Docker For Mac, I get the exact same error as above.

Do any of you have an idea as to what can be done for that? I was thinking to see if I can swap out the docker engine backend for a VM running in Ubuntu, which is how Docker for Mac used to work, but now it uses its own hypervisor.

Again sorry to come here uninvited, but we share the same issue!

[smety]

HI, i have same problem, do you know when it will be fixed?

[scubbo]

let's add another env variable, that use can configure during docker-compose up, to use arm64 image

I'm still a novice with Kubernetes, so apologies if this is a stupid question, but - would that also enable setting a similar variable for the Helm chart to make it usable on arm64? (I strongly suspect that the answer is "yes", but it never hurts to check!). If not - would this be an appropriate place to request/track that, or should I start a new issue?

[vadimkerr]

arm64 image has been added to DockerHub and is available starting from version v1.0.29.

@iskhakov I think we don't need any additional env variables since platform selection is handled by docker, so building & pushing an image on arm64 host is enough to resolve the issue.

The problem with PTHREAD_PRIO_INHERIT is gone after updating to the latest image v1.0.29, so I'm closing this issue.

[scubbo]

Update: My bad - it wasn't a problem with grafana/oncall itself, but with the mysql images, which:

• explicitly request platform: linux/x86_64 rather than just linux
• request image mysql rather than arm64v8/mysql

I made those changes, and the docker-compose file starts up with no problems.

Thanks again for making this available!

You can ignore the original below...

---

Hmm, still no luck. I followed the instructions for a hobby setup, which resulted in unhealthy containers for celery, oncall_db_migration, and engine - that is, all the containers that use the grafana/oncall image. docker logs shows repeated standard_init_linux.go:219: exec user process caused: exec format error, which I've found is generally a sign of architecture-incompatible images. This happens both when using image: grafana/oncall and image: grafana/oncall:v1.0.29. I've also tried explicitly setting platform: linux/arm64 or ...arm64/v8 (as per here) on those containers; with no effect.

docker run grafana/oncall (or ...:v1.0.29) seem to start up alright (well - there are some stacktraces in there, but at least it starts execution rather printing exec format error.

Docker does seem to be able to see the arm64 images:

docker manifest inspect grafana/oncall | jq '.manifests[].platform.architecture'
"amd64"
"arm64"

I recognize that this is a slight scope-creep of the request (you've made the image available, job done!) - but if someone could advise me on how to fetch the platform-appropriate image with docker-compose, it would be helpful not only to me but to anyone else who discovers this issue in the future. (I promise to update the docs in gratitude!)