Most of the time, knowing what an error means can get you to the solution right away but when the error message is not descriptive enough, finding a solution can take a lot of time. While I didn’t spend days with this issue thanks to this article, I do want to share my current workaround since it doesn’t involve buildx
but instead, using GitHub actions and deploying to EKS.
I am exploring my development environment in a new 14-inch MacBook Pro with Apple Silicon (M1 Max) and part of my workflow required to test a docker image to later deploy it in an EKS cluster.
Docker has a page about Docker Desktop for Apple Silicon here that you should read.
My workflow back on Intel was:
- Pull the code from GitHub
- Use or create the Dockerfile
- Perform a Docker build
- Run the image locally, test everything works
- Push the image to ECR
- Deploy the image un EKS with a Kubernetes Deployment and an Ingress object.
In my workflow, the Kubernetes pod was not starting.
$ kubectl logs my-pod-name-6cdbb74df6-jjdwr -n <NAMESPACE>
standard_init_linux.go:219: exec user process caused: exec format error
After this, I would typically create a GitHub Action and just get out of the manual steps, but with this new laptop my new process looks like this:
- Pull the code from GitHub
- Use or create the Dockerfile
- Perform a Docker build
- Run the image locally, test everything works
- Create the Github Action, it builds the Docker image, pushes it to ECR and does the Kubernetes deployment.
The good: I think in the long term this makes my work more focused on getting things to work directly in the cluster.
The bad: Testing the image locally doesn’t really tell me if it’s going to work on the cluster, because there are in different architectures.
The article I mentioned in the beggining does have the laternative of using buildx
which I’m pretty sure it can work but there is some outdated intructions so I shall come back to try to build x86_64
images in the M1.