← Back to context

Comment by wmwragg

6 months ago

Yes that was my first thought as well, and as the images aren't designed to be run on a mac specifically, like a native app might be, there is no expectation for the developers to create a native apple silicon version. This is going to be a pretty major issue for a lot of developers

Case in point - Microsoft's SQL Server docker image, which is x86-only with no hint of ever being released as an aarch64 image.

I run that image (and a bunch of others) on my M3 dev machine in OrbStack, which I think provides the best docker and/or kubernetes container host experience on macOS.

I’ve worked in DevOps and companies I’ve worked for put the effort in when M1 came out, and now local images work fine. I honestly doubt it will have a huge impact. ARM instances on AWS, for example, are much cheaper, so there’s already lots of incentive to support ARM builds of images

  • In our small shop, I definitely made sure all of our containers supported aarch64 when die M1 hit the scene. I'm a Linux + Thinkpad guy myself, but now that I've got an x13s, even I am running the aarch64 versions!

  • It has a huge impact if you need to run the exact same container as in production. This kills Macs in those shops. And there are more than you might think.

Apple Silicon is ARM64 which is supported by Linux and Docker.

  • But Docker images don't necessarily have ARM64 support. If you are exclusively targeting x64 servers, it rarely makes sense to support both ARM64 and AMD64 platforms for development environment/tests, especially if the product/app is non-trivial.

    • Every port I've done to a new hardware or software platform has shaken loose at least a handful of bugs or assumptions that were well worth ironing out. And in the case of a port to Apple Silicon, you get a very fast development environment at the end of it. This library also helped with 90% of the work:

      https://github.com/DLTcollab/sse2neon

    • Or, if you just want to create multi-arch images for your project, on your Mac...so that your non-Mac customers can use them.

  • Parent doesn't want to merely run ARM64 Linux/Docker images. They want to run Intel images. Lots of reasons for that, from upstream Docker images not available to ARM64, to specific corporate setups you want to replicate as close as possible, or who aren't portable to ARM64 without huge effort.

  • I'm aware, I use ARM images all the time, I was trying to indicate that the usual refrain that the developers have had years to migrate their software to apple silicon, doesn't really apply to docker images. It's only the increase in use of ARM elsewhere (possibly driven by the great performance of macs running apple silicon) which has driven any migration of docker images to have ARM versions

  • Yeah but many people are using x86-64 Docker images because they deploy on x86-64. Maybe ARM clouds will be more common by that time.

    • Yep, this is another reason I've needed the use of x86-64 images, as although they should be technically the same when rebuilt for ARM, they aren't always, so using the same architecture image which is run in production, will sometimes catch edge case bugs the ARM version doesn't. Admittedly it's not common, but I have had it happen. Obviously there is also the argument that the x86-64 image is being translated, so isn't the same as production anyway, but I've found that to have far less bugs than the different architecture

      1 reply →

  • That's not really the point though right? It means that pulling and using containers that are destined for x86 will require also building arm64 versions. Good news is buildx has the ability to build arm64 on x86, bad news is people will need to double up their build steps, or move to arm in production.

    • W/o rossetta i can't build x86_64 images anymore. Today i can setup OrbStack amd64 linux and build native amd64 images on my mac to put on my servers.

      1 reply →