The following issues demonstrate and explain this more succinctly and have been ongoing for almost a year.
Simply put, the issue is as follows.
This issue is, I assume, because Balena is forked from Docker and doesn’t yet support the latest features and has yet to pull in the MULTI-ARCH stuff from Docker so there is no support for automatically pulling images from the docker hub with the correct architecture.
If I have a Dockerfile.template and I use balena push appname, the following has to be present in my Dockerfile.
--platform=linux/arm/v7
Else, the build will fail.
However, if I push to a local device, for example balena push 10.0.100.1 then the same will not occur. I do not need to specify the architecture.
If --platform=linux/arm/v7 is specified however, then the local build will fail, as the local docker daemon running on the device does not support the --platform command, since it is more up to date than the Balena build server. Therefore I can only use one approach. I have been using the Balena build server ever since, since building locally is not an option due to this inconsistency.
Thank you for pointing out this inconsistency and linking the two CLI issues. I have created a third CLI issue to make sure that this problem is captured in the balena-cli repository as well:
I agree that this is an issue that needs attention and a proper solution.
In terms of a workaround (in an attempt “to be helpful today”), would it be an option for you to include the image’s sha256 hash in the FROM line? I have recently answered another forum thread whether it was reported that FROM nginx:1.17.1-alpine was selecting the incorrect image architecture (amd64 instead of arm64v8), and a successful workaround was to include the sha256 hash for the correct architecture as follows:
FROM nginx:1.17.1-alpine@sha256:ba0713e56ea1d0ce7aad766529dda12c2e47e1fcb2b6ee0079ada8c575873c3a
See more details in the following comment, including how to find the sha256 hash in Docker Hub:
The obvious downside of this workaround is that including the sha256 hash makes it harder (extra work) to update the base image (it won’t update automatically), and makes it harder (impossible) to have a single Dockerfile that works with multiple architectures.
The proper/best solution is probably for the balena CLI to implement support for image manifests. I don’t have an ETA to share at the moment, but this is issue has high priority in the CLI project / repository. Thanks again for raising it.
Wow, I did not know that you could provide that to the FROM directive. What a great solution, this works for now. This is fine, since I would not want to use :latest in any circumstance at all anyway, so I can just add a comment to make it human readable as to what the version actually is and why SHA256 is being used. You’ve described it much more clearly, I only have intuition to go on as my knowledge of Docker is not as deep.
