It looks like the images published to dockerhub have the wrong arch, all images are build for amd64 not arm64. I would assume a bug in you build & publish pipeline. Can somebody fix that?
Regards
Hello @dragonchaser
You are correct that some of the arm64 docker images for drone appear as amd64 images. I was curious about this as well.
It turns out that many of drone projects (plugins, extensions, runners) consist of just a single binary in the docker image. This is a bit of a “trick” when building Docker images, even though they appear as linux/amd64, the binary inside the image is linux/arm64, so it will work on that platform.
I agree the release pipelines for these projects should be updated so that they appear as the appropriate architecture, I will mention this to the team.
Yeah one should not do this there is fallout to such approaches:
For example I use netcat for healtchecks
nc -z 127.0.0.1 3000|| exit 1
This does not work with that construct on arm64. Thanks for taking care of this.
Can you describe your use case? Is there a nc binary in an image that is the wrong architecture? I just want to make sure I understand.
I am running drone on docker-swarm. I am using netcat as health check, as described above, to verify that port 3000 is open.
This works fine for the amd64 runners, but fails on arm64. It is also somewhat hard to track down, since I can not attach to the console of the running containers, running /bin/sh works on amd64 but not on arch. I am assuming a wrong arch there as-well.
Ok thanks. Can you clarify, is nc being run from within the drone container or from a different location? Thanks again
Nc is run from within the container.
Got it, now I understand, thanks!
1 Like
Drone builds all images on amd64 (using cross-compiling) and then we push a manifest file to assign the correct os and architecture to those the images. We have done it this way for years without issue. It appears something changed on the registry side, and docker is no longer respecting the os and architecture defined in the manifest. See the screenshot from Dockerhub from a few months ago (correct) and a few weeks ago (incorrect).
Before DockerHub Change:
After DockerHub Change:
The good news is we have a relatively simple solution. The docker build command added support for the –platform flag so that we can force a specific os and architecture. The docker plugin should be updated to accept platform in the settings section. This would require a code change and release to the Docker plugin.
- name: amd64
image: plugins/docker
settings:
repo: drone/drone-runner-docker
auto_tag: true
auto_tag_suffix: linux-arm64
dockerfile: docker/Dockerfile.linux.arm64
+ platform: linux/arm64
username:
from_secret: docker_username
password:
from_secret: docker_password
Once the plugin supports platform we can update the pipeline definition for affected images (as shown above) and ensure the platform is being set.
This does not really help me, this is not about enforcing the build arch for the pipeline but having the proper arch on the deployment to interact with the runner container.
The build results itself are fine…
You described the problem as “It looks like the images published to dockerhub have the wrong arch”. The enhancement that I proposed for the Docker plugin helps us publish the image with the correct architecture tags, which would solve the problem you described in your initial post.
Ahh ok, sorry misunderstanding on my behalf, I thought you meant this as a solution for my pipeline.