Added support for multi-arch building of Operator image

[tobiasoort]

Adds multi-arch support in the Camel-K Operator docker image.

• Parameterized (defaults to amd64 + arm64)
• Uses the ubi-quarkus-mandrel-builder-image base instead of the ubi-quarkus-mandrel one

Fixes #1238 ; This should allow the Operator image to run natively on Apple Sillicon and other arm64 based processors.

Release Note

Camel-K Operator Container Image is now available in multi-arch flavour; support for linux/amd64 and linux/arm64.

[tadayosi]

Sorry for asking this naive question, as I'm not the expert on this part of code.

Why do we need to also make make images multi-arch even though we already have make images-arch which obviously builds images for multi-arch?
https://camel.apache.org/camel-k/next/configuration/multi-architecture.html

I'm sure I'm missing something important but please tell me so that I can understand.

[tobiasoort]

Why do we need to also make make images multi-arch even though we already have make images-arch which obviously builds images for multi-arch?

A couple of reasons! First of all, because 'it is the way'. Users expect dockerimages to be multi-arch and not ponder about what arch their system/cluster is on. Even the upstream containers like ubi-quarkus-mandrel-builder-image do this. So they don't need to read docs pages and do local builds, they can just use the regular image and it will 'just work'.

Second, because it allows you to think about the pipeline and not about specific arch builds. This also means that this multi-arch image would get pushed to dockerhub, 'business as usual'. Again, it will 'just work', for devs and for users.

Third: the multi-arch build depends on graalvm instead of quarkus (

camel-k/build/Dockerfile.arch

Line 16 in 3be0ab8

FROM --platform=$BUILDPLATFORM ghcr.io/graalvm/graalvm-ce:ol8-java11-22.1.0

) because the right upstream image 'just for arm64' isnt there. This puts a split in the project dependencies and can cause weird issues downstream that are hard to reproduce.

My suggestion would be to remove the 'images-arch' after this PR. It was a good way to get all the plumbing in place, but with official docker support for multi-arch and also upstream support from quarkus, we don't need that 'fork in the road' anymore.

[tobiasoort]

One test failed, due to:

operator_test.go:102: 
Expected
[3114](https://github.com/apache/camel-k/actions/runs/3567995319/jobs/6001875342#step:4:3256)
              <string>: 
[3115](https://github.com/apache/camel-k/actions/runs/3567995319/jobs/6001875342#step:4:3257)
          to equal
[3116](https://github.com/apache/camel-k/actions/runs/3567995319/jobs/6001875342#step:4:3258)
              <string>: \"\"

I'm pretty sure that's a bug in that test with some escaping gone awry.

[christophd]

FYI #3804 is related to this. The Camel K images stopped working for me because of the multi-arch changes made before. For me the wrong kamel CLI binary has been added to the image on MacOS aarch64.

[christophd]

don't get me wrong this is not related to changes in this PR in particular but to multi-arch build in general

[tobiasoort]

FYI #3804 is related to this. The Camel K images stopped working for me because of the multi-arch changes made before. For me the wrong kamel CLI binary has been added to the image on MacOS aarch64.

don't get me wrong this is not related to changes in this PR in particular but to multi-arch build in general

Yep, quite possible. I can check out the Camel CLI build (this is the Operator) after this! Would love to help out over there. Edit: I see you already did that! Do we have collissions? If not it sounds like these two PRs together are really helpful for ARM64 users.

[github-actions]

This PR has been automatically marked as stale due to 90 days of inactivity.
It will be closed if no further activity occurs within 15 days.
If you think that’s incorrect or the issue should never stale, please simply write any comment.
Thanks for your contributions!