Provide Camunda Platform Docker artifacts for arm64 architectures/M1 Apple machines

[ThorbenLindhauer]

This issue was imported from JIRA:

Field	Value
JIRA Link	CAM-14301
Reporter	@toco-cam
Has restricted visibility comments	true

---

User Story (Required on creation):
As a Software Engineer, I want to be able to use Camunda Docker containers to develop on arm64 architectures/my Mac with an M1 processor.

Functional Requirements (Required before implementation):

• In addition to the images for linux/amd64 architecture, we provide our Docker images also for the linux/arm64 architecture
• The new images have the same functionality as the existing ones

Technical requirements

• The CI covers the new images

Limitations of Scope (Optional):
 
Hints (Optional):

• https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/
• feat(arch): arm64 image docker-camunda-bpm-platform#214

Links:

• is related to https://jira.camunda.com/browse/SUPPORT-12659
• is related to https://jira.camunda.com/browse/SUPPORT-13282
• is related to https://jira.camunda.com/browse/SUPPORT-13965

Breakdown

• Define arm64 builds for docker-camunda-bpm-platform actions
  • feat(docker): add arm64 build docker-camunda-bpm-platform#237
• Define arm64 builds for the release jenkins jobs
  • Move the build to GHA & trigger workflow via REST API
  • Update release guides accordingly
• Define arm64 builds for the QA Docker EE images

[ThorbenLindhauer]

This comment was imported from JIRA and written by user @koevskinikola

---

Notes:

• A similar issue was raised in the docker-camunda-bpm-platform repository: https://github.com/camunda/docker-camunda-bpm-platform/issues/205
• It is possible to run the current Camunda Docker images on an M1 MacBook with the --platform linux/amd64 argument. For example:

docker run -d --platform linux/amd64 --name camunda -p 8080:8080 camunda/camunda-bpm-platform:latest

[ThorbenLindhauer]

This comment was imported from JIRA and written by user @ThorbenLindhauer

---

Related Zeebe issue that could give some hints for implementation: camunda/zeebe#6155

[danielkelemen]

EE docker-qa https://github.com/camunda/camunda-bpm-platform-ee/pull/750

• Updated docker-maven-plugin version to latest v0.40.2
  • buildx support was added in 0.40.0
• In the build step, the plugin can only build and load the native image: Source
  • This is the normal with docker buildx as local docker cannot hold multi-platform images.
  • It's fine for QA images to only test the amd64 version.

Release master https://github.com/camunda/jenkins-job-dsl-seed-jobs/pull/380

• Added arm64 emulator support using tonistiigi/binfmt (same image as in docker/setup-qemu-action).
• Added multi-platform build support using docker buildx.

docker-camunda-bpm-platform camunda/docker-camunda-bpm-platform#237

Ideas

• Build images normally with platform tags (-arm64, -amd64) -> test them -> create multi-platform images with docker manifest from the previously built images.
  • Pros:
    • Simple workflow
    • No double builds -> quicker workflow
  • Cons:
    • manifest is an experimental command!
    • Manifest creation would require all the images to be pushed already
• Build images for testing and then build again the multi-platform images and push
  • Pros:
    • No experimental commands, buildx is stable and designed this way
  • Cons:
    • Double builds -> slower workflow (we can use gha cache)

Implementation

• Decided to use the 2nd option.
• Added docker/setup-qemu-action step for emulating arm64.
• Added crazy-max/ghaction-github-runtime step so buildx can use the gha cache, it needs two runtime variables for that which this action exposes internally.
• Added docker/setup-buildx-action to build and later build+push the images.
• Created a separate publish job that runs for every distros. It uses similar actions as the build.
• Adapted the pipeline and release scripts.

[danielkelemen]

Due to the lack of native arm runners I had to adjust a few timeouts and retries both for jenkins and github:

• increased test polling retries to 80 (from 20)
• increased jenkins docker ce/ee timeout to 60 minutes (from 15)

We might need to adjust these values later even more if we notice they are too low, emulation is extremely slow.

It's definitely recommended to switch to native runners once they are available (https://github.com/camunda/team-infrastructure/issues/63) and to move the docker jobs to github actions as well so they can use said runnners.

[danielkelemen]

Dev2QA:

• QA Images
  • Multi-platform images are the ones where there is a little folder icon next to the artifact hash.
  • https://registry.camunda.cloud/harbor/projects/6/repositories/weblogic14r1/artifacts-tab
  • https://registry.camunda.cloud/harbor/projects/6/repositories/websphere9/artifacts-tab
• CE Images
  • Multi-platform images are the ones where under OS/ARCH both amd and arm are listed
  • https://hub.docker.com/r/camunda/camunda-bpm-platform/tags
• EE Images
  • They will be available after the nightly build, they are marked the same way as for QA.
  • https://registry.camunda.cloud/harbor/projects/2/repositories/camunda-bpm-platform-ee/artifacts-tab
• Run a specific platform version:
  docker run --rm -p 8080:8080 --platform linux/amd64 camunda/camunda-bpm-platform:wildfly-SNAPSHOT
docker run --rm -p 8080:8080 --platform linux/arm64 camunda/camunda-bpm-platform:wildfly-SNAPSHOT
  • Heads up: if you ran amd64 and then run without the platform parameter, docker won't automatically download the arm64 platform version.
• Check the downloaded image architecture:
  docker inspect camunda/camunda-bpm-platform:wildfly-SNAPSHOT | grep "Architecture" -A2

[gbetances089]

Tested thanks to the Dev2QA and Daniel's help, will write a testing guide for images for reference which could be use for this type of tickets.