Document Docker build for cross platform images (e.g build on macOS and deploy to amd64)

[devraj]

At Anomaly we primarily use macOS for development and as Apple moves to Apple Silicon the development environments are moving to arm based CPUs, but most of our deployments are still under amd64 (Intel or AMD based CPUs).

This has caused issues in the past, this should be documented properly and possibly even be made into a Task endpoint

docker build --platform=linux/amd64 -t "anomalyhq/accacia-server:0.2.0" -f Dockerfile .

[devraj]

I came across this issue yesterday, I was building fine and then was unable to this week with the no match error messages showing up when it tried to export the image

------
 > exporting to image:
------
ERROR: failed to solve: no match for platform in manifest sha256:30c8...: not found`

I tried almost everything that I could find around the web including what has been mentioned in this ticket.

I am on an Apple Silicon M2 machine and my deployment targer is linux/amd64

Eventually I came across this article Faster Multi-Platform Builds: Dockerfile Cross-Compilation Guide which outlines that buildx is the way to go when support multiple architectures and mentions Graviton2 CPUs on AWS.

I also saw that Moby was updates in v4.19 of Docker desktop

Eventually this is what worked for me.

docker buildx build --platform=linux/amd64,linux/arm64 --push -t "ghcr.io/anomaly/app-server:0.7.0" -f Dockerfile.prod .

Note the --push flag that pushes the built images to ghcr

Hope this helps someone out there struggling with the same issue.

See also M1 mac: docker build allows platform "amd64" but docker run can't find images unless platform is "linux/amd64" where I have left this comment, that issue also references containerd-integration: cannot interact with images that don't have the default platform

[devraj]

Reopening until this is merged into documentation.

[devraj]

This Stackoverflow post highlights the use of the --entrypoint flag to mount a shell in interactive mode, which overrides the default entrypoint.

docker run -it --entrypoint sh image_name

This was very useful when debugging why the labs server image worked in development using compose but failed to work when I built and published the image to the Github container repository.