- Tue 29 July 2025
- server admin
- Gaige B. Paulsen
- #server admin, #docker, #gitlab
As described previously, we run predominantly SmartOS systems at our data center and that includes using them to run docker in some cases, to quite good effect.
A few years ago, multiplatform images started to appear in the docker space, providing the ability to have (mostly) linux arm64 and x86-64 images with the same tag. With the advent of more powerful ARM systems, especially the M-series processors from Apple, these had started to take hold, but weren't yet pervasive.
Back in SmartOS-land, the docker ability isn't exactly neglected, but it's an uncommonly-used feature on a niche operating system. The general functioning of docker on the platform is solid (surprisingly so, given all of what it's doing), but the tools haven't needed to evolve much.
Now, I may be assigning a causality to a coincidence here, but at WWDC25, Apple announced that the ARM transition was nearly complete and so the support for Intel CPUs would be removed from macOS 27. Moreover, Apple announced that Rosetta 2 would be "significantly scaled back" in macOS 28+. Suddenly, there were releases of more multi-platform images into the ecosystem, and in particular, the fine folks at GitLab released 18.2.x versions with multi-platform images... and there's the root of our story here: SmartOS did not play well with multiplatform images.
To be clear, multiplatform images are a registry construct, the actual images are still a manifest and a list of image overlay layers. However, with the advent of multiplatform images, there's a new index type that returns an uber-manifest that lists the manifests for multiple platforms.
Unfortunately, the imgadm
client for SmartOS didn't understand these
multiplatform images and thus wouldn't pull them correctly. Now, I think
that I've established my bona fides as not including substantial
prowess with Javascript, and unfortunately for my open-source contributing
self, the imgadm
command is written in Node. I rolled up my sleves
and made a PR
for the node-based client in SmartOS. Although the PR isn't yet accepted,
the problem is fixed in 20250724T001011Z of SmartOS and that's great.
In the mean time, we're still qualifying this version and I need to get some images that are currently multiplatform, so I decided to set up docker-registry on one of the k8s clusters (limiting access) and then mirror just the x86-64 versions in the local registry until we can do the upgrade.
On the Mac:
# inspect the imsage
docker manifest inspect gitlab/gitlab-ee:18.2.1-ee.0
# get just the linux/amd64 image
docker pull --platform linux/amd64 gitlab/gitlab-ee:18.2.1-ee.0
# retag for our repo
docker image tag gitlab/gitlab-ee:18.2.1-ee.0 XXX/gitlab/gitlab-ee:18.2.1-ee.0
# and push to our repo
docker push XXX/gitlab/gitlab-ee:18.2.1-ee.0
This worked and I'm now in business temporarily until I'm able to get the upgraded version of SmartOS in place.