Add aarch64 docker image

[iexos]

The official docker image matrixdotorg/synapse only works with x86_64. I successfully started the docker file on my aarch64 machine by simply changing the images from docker.io/python to docker.io/arm64v8/python in the Dockerfile.

Please provide this prebuilt as well :)

[richvdh]

that would mean finding an aarch64 box to build on...

[iexos]

It should not be too hard to use QEMU to build foreign architectures:
https://ownyourbits.com/2018/06/27/running-and-building-arm-docker-containers-in-x86/
I can also try to set this up, however I am not familiar with the matrix CI system.

[hawkowl]

atleastfornow.net is on aarch64 right now, and I've come up with a docker image using nix that might work... needs a bit more cleaning up, though.

[GrimKriegor]

If a multiarch pipeline is ever created, please consider also including the armhf architecture.

Its a prevalent architecture, used in systems such as the official Raspberry Pi OS (regardless of SoC architecture) and a bunch of libre and mainlined chips like the Allwinner A20.

I believe Docker Hub's official images have started becoming multi-arch a while ago, so keeping the parent image docker.io/python and building it for armhf and aarch64 should probably suffice.

Thank you for your time.

[soyflourbread]

There are aarch64 and armhf server providers such as Scaleway. It should be extremely easy to build the docker image on them and provide prebuilt images.

[Starbix]

I've opened a PR that adds support for multi-arch images: #7397

[maquis196]

Like @Starbix, i have a branch similar that produces multi-arch images on circleci but using the new debian base image. The issue is still the compilation of the wheels. Takes 95ish minutes on my branch to build amd64, arm64 and arm/v7 docker images. The pip install only seems to install amd64 binaries. So unless im missing something we have 3.5 options I can think of;

1. Accept the 90 odd minute build time
   2a. Split the pipeline up so that the amd64 image is produced immediately and uploaded and the rest take their time. Not sure if dockerhub would accept them all as the same, so might be a non-starter.
   2b. If 2a can't work, a separate tag for arm images? - I dislike this personally.
2. Work out a nice way of pre-compiling these arm wheels, perhaps as a permanent docker image we can overlay on the build pipeline so that step is instant.

FTR, 3 is my favourite choice, but more moving parts isn't always good, I've seen online precompiled wheels via sites such as - https://www.piwheels.org/ but that might not even work here.

I'm quite eager to get multi-arch images ready, so happy to help with this.

[richvdh]

do you know why the pip install does not install wheels for the arm builds?

[maquis196]

i believe they dont have precompiled arm versions in the regular pip repo, hence the existence of the above piwheels site. We can also rule out 2a above as well, amd64 image made in 3mins flat, replaced by the 2 arm images 90mins later.

One other option is cross compiling the arm wheels, but i need to figure out a nice way of getting the arm versions of python on the host to target, not sure multilib debian had that in mind. Compiling it from scratch probably not a good time saver either.

[richvdh]

i believe they dont have precompiled arm versions in the regular pip repo, hence the existence of the above piwheels site

ah right.

We can also rule out 2a above as well, amd64 image made in 3mins flat, replaced by the 2 arm images 90mins later.

could we upload the amd64 image when it's ready, and then upload it again along with the other two?

[maquis196]

Funny, I have thought this too, the only potential issue being people with say something like watchtower where it will restart twice in 90mins every latest tag which is far from ideal. So if the docker tag doesnt change we might get away with it? let me test that.

[maquis196]

I think we have a winner @richvdh...

https://hub.docker.com/repository/docker/maquis196/synapse/tags?page=1

Same docker run, test_latest was to make sure the original tag was saved, both are 27aff868e811 so end users wont notice they way its getting updated. I'll whip up the PR for you now

edit - in case the files are updated by more testing -

https://photos.app.goo.gl/H5neqBM1HcEHfUdD6

[maquis196]

ive raised #7921 which is similar to the above PR, but made it easier to specify which archs we want on which job, and the build dependencies in the builder docker image, now that were on debian.

[richvdh]

We can also rule out 2a above as well, amd64 image made in 3mins flat, replaced by the 2 arm images 90mins later.

I'll note that according to https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/, this does not appear to be the case if one is careful about how one labels the images, and then builds a separate manifest (see 'The hard way with docker manifest'). However, building the amd64 image twice is probably fine.

[richvdh]

fixed by #7921