ensure we built images using both x64 and aarch64 architecture

[ssbarnea]

As aarch64 architecture is becoming more popular every day, we should ensure that we built multi-platform images, so everyone can make use of them.

See https://github.com/docker/build-push-action/blob/master/docs/advanced/multi-platform.md for
a potential solution to this issue.

• Ensure https://quay.io/repository/ansible/python-base also includes arm64 architecture
• Ensure https://quay.io/repository/ansible/ansible-builder also include arm64 architecture
• Enable ansible-builder to perform multi-platform builds using docker buildx
• Adapt creator-ee pipelines to build and publish both architectures

Depends-On: ansible/ansible-runner#1046
Depends-On: ansible/ansible-builder#373

[webknjaz]

I implemented this for pylibssh in the past, happy to do the same here.

[ziegenberg]

Would now be a good time to work on this?

[ssbarnea]

@ziegenberg Obviously! you have my support. I just did not know how to do it with GHA.

[ssbarnea]

@mattclay @nitzmahone As I seen the work on new container building at https://github.com/ansible/base-test-container lets have a talk so we can decide what is the easiest path for @ansible/devtools team to build and publish multiple architectures for for creator-ee.

[kmf]

@ssbarnea do you need help updating the GitHub workflow?

[ssbarnea]

@kmf What needs to be done is bit more complex but if you can link to an existing GHA workflow which builds and publishes a dual-arch container, it could clearly help with this task.

[nitzmahone]

We're already doing this with all the ansible-test containers using containmint so the builds are happening on real aarch64 hardware instead of hella slow emulation. It's a little harder to do securely from GHA because the GHA secret stuff is a lot jankier than AZP and there's no Core CI GHA job support, so you need to keep the ansible-core-ci key secret. Take a look at https://github.com/ansible/default-test-container/blob/main/azure-pipelines.yml - it's pretty trivial.

[nitzmahone]

... and as for builder and EEs, once the vanilla base image support is done, builder itself shouldn't need any special support to do non-x86 containers (though there might be a couple minor convenience things like build arch arg passthrus to the underlying container runtime if someone is configured for foreign arch emulated builds or whatever).

[kmf]

@shanemcd mentioned this pull request @ssbarnea

ansible/receptor#652

[nitzmahone]

That's using emulated builds though. It looks like an arch-native release build on creator-ee takes ~10min, and IME emulation adds a 5-15x wall-clock penalty. Let's split the difference and call it 10x- that means an emulated aarch64 build would take 100min to complete. This isn't my project, but if it were, that would be completely unacceptable 😆 . At first blush it doesn't seem like there's a lot of practical use today for EEs that aren't x86_64 or aarch64, and both of those have commodity ephemeral compute instances readily available, so emulation is unnecessary. But again, not my project, do what you want...

[ssbarnea]

I sorted the performance issue by creating a creator-base container which installs all RPMs (including binary wheels). That is the heavy one and we now have a job that updates that base container container weekly.

pip install runs quite fast, even with QEMU virtualization, so no problem here.

Since yesterday with 0.9.3 release, we do have multi-arch containes.