4 ms·

> their new arch breaks docker builds I’ve seen this complaint quite a bit on HN, and I don’t really understand it. Apple helped Docker port over to arm64 on t

by easton 4y ago

> their new arch breaks docker builds I’ve seen this complaint quite a bit on HN, and I don’t really understand it. Apple helped Docker port over to arm64 on the Mac (which was one of the first pieces of software to use the new fancy hypervisor APIs), and it’s been working for over a year now. If your docker images can’t build on arm64, I don’t really understand how Apple or Docker can make that any easier. Most of the popular images have arm64 builds now, the only holdout I know of is MySQL due to Oracle being Oracle. If you’re building your own images, GitHub Actions and many other CI providers have had ARM64 agents for a long time (and you can build arm Docker images in QEMU super easy on GHA if you need hosted agents). There’s not much of an excuse anymore, and since arm instances are cheaper on some public clouds, you should be making sure your stuff runs on arm64 now. Especially if it’s a typical Node/.NET/Java/Ruby/Python app, they’ve been arm native for years.

heywoodlh 4y ago
> you can build arm Docker images in QEMU super easy on GHA if you need hosted agents Yeah, you nailed it: it's fairly trivial to create cross architecture images -- my preferred tool is Docker's buildx plugin[1]. I have an M1 Mac, Raspberry Pi 4 running 64 bit Ubuntu Server and multiple x86_64 bit machines. I try to exclusively use Docker images that are cross-architecture. When they are not cross-architecture I usually just build the project's Dockerfile using the Docker Buildx Github Action[2]. The majority of the time most projects' stock Dockerfile works on all architectures. The few times they don't work are usually when a Dockerfile grabs an x86_64 binary and downloads it. I feel like that is bad practice so I usually just write my own Dockerfile when I encounter that. A recent image I did this with was Gitleaks[3] (link goes to my Github Action). I will say I have found that while most projects usually compile well on all platforms, if I ever do run into issues it is usually on 32 bit ARM. [1] https://docs.docker.com/buildx/working-with-buildx/ https://docs.docker.com/buildx/working-with-buildx/ [2] https://github.com/docker/setup-buildx-action https://github.com/docker/setup-buildx-action [3] https://github.com/heywoodlh/actions/blob/master/.github/workflows/gitleaks-buildx.yml https://github.com/heywoodlh/actions/blob/master/.github/wor...
johannes1234321 4y ago
> the only holdout I know of is MySQL due to Oracle being Oracle. I am (partially) responsible at the MySQL team for Docker images. I however don't use Mac myself. The only thing I am aware of is that for 8.0.28 we were a little late with ARM images due to technical issues, but that should be resolved. But mind there are different sets of container images: `mysql` is maintained by Docker, Inc. where we only have limited influence and `mysql/mysql-server` which is maintained by us. I see for instance https://hub.docker.com/layers/mysql-server/mysql/mysql-server/latest-aarch64/images/sha256-bcb56714933157b2bb203408b6b5e292559d8b8a42d4e3acb8514ae783225e13?context=explore https://hub.docker.com/layers/mysql-server/mysql/mysql-serve... Any specific issue with that? I'd then work with the involved teams to get it resolved. (Preferebly issues via bugs.mysql.com, but I'll check responses here as well)
- easton 4y ago
  I thought “mysql” was y’all. Sorry! I'll have to remember in the future to use "mysql/mysql-server". I just remember that GitHub issue for "mysql" being open forever.
smeagull 4y ago
You've certainly painted a sunny picture of arm adoption that I'm simply not seeing. One of the advantages of docker is that you can have systems lock their versions. So our project using say, Neo4J, uses a particular version of it. Not necessarily one with an arm build. This creates predictable and repeatable builds. So now either we upgrade dependencies out of our expected cycle, or we abandon macs as our development machines. A decent number of us wanted Linux anyway. This is a cost that Apple foisted on us. > since arm instances are cheaper on some public clouds, you should be making sure your stuff runs on arm64 now. Some instances might be cheaper, therefore we have to adopt it now? I think the cost/benefit analysis you're performing here is ignoring development costs. Are you a project manager of some kind? > they’ve been arm native for years. The native libraries and tools that make them worthwhile are not. Really it only takes a single component to ruin everything.
- easton 4y ago
  I’m not a PM, but I’ve been in the room during those conversations. Granted, I’ve never had to rely on a ton of native extensions (at least in a business context, personal stuff for sure). It’s just like any other dependency. Sometimes you can afford to freeze on a single version until the end of the project, but most of the time projects I’ve been on will regularly upgrade the third party stuff we rely on if for no other reason than security, with things like arm64 support coming along for the ride. We usually prefer to be able to get help with our issues faster than our tickets getting closed with “fixed in new version update”, of course weighing that against breaking API changes or what have you.

by easton 4y ago

heywoodlh 4y ago

> you can build arm Docker images in QEMU super easy on GHA if you need hosted agents Yeah, you nailed it: it's fairly trivial to create cross architecture images -- my preferred tool is Docker's buildx plugin[1]. I have an M1 Mac, Raspberry Pi 4 running 64 bit Ubuntu Server and multiple x86_64 bit machines. I try to exclusively use Docker images that are cross-architecture. When they are not cross-architecture I usually just build the project's Dockerfile using the Docker Buildx Github Action[2]. The majority of the time most projects' stock Dockerfile works on all architectures. The few times they don't work are usually when a Dockerfile grabs an x86_64 binary and downloads it. I feel like that is bad practice so I usually just write my own Dockerfile when I encounter that. A recent image I did this with was Gitleaks[3] (link goes to my Github Action). I will say I have found that while most projects usually compile well on all platforms, if I ever do run into issues it is usually on 32 bit ARM. [1] https://docs.docker.com/buildx/working-with-buildx/ https://docs.docker.com/buildx/working-with-buildx/ [2] https://github.com/docker/setup-buildx-action https://github.com/docker/setup-buildx-action [3] https://github.com/heywoodlh/actions/blob/master/.github/workflows/gitleaks-buildx.yml https://github.com/heywoodlh/actions/blob/master/.github/wor...

johannes1234321 4y ago

> the only holdout I know of is MySQL due to Oracle being Oracle. I am (partially) responsible at the MySQL team for Docker images. I however don't use Mac myself. The only thing I am aware of is that for 8.0.28 we were a little late with ARM images due to technical issues, but that should be resolved. But mind there are different sets of container images: `mysql` is maintained by Docker, Inc. where we only have limited influence and `mysql/mysql-server` which is maintained by us. I see for instance https://hub.docker.com/layers/mysql-server/mysql/mysql-server/latest-aarch64/images/sha256-bcb56714933157b2bb203408b6b5e292559d8b8a42d4e3acb8514ae783225e13?context=explore https://hub.docker.com/layers/mysql-server/mysql/mysql-serve... Any specific issue with that? I'd then work with the involved teams to get it resolved. (Preferebly issues via bugs.mysql.com, but I'll check responses here as well)

easton 4y ago
I thought “mysql” was y’all. Sorry! I'll have to remember in the future to use "mysql/mysql-server". I just remember that GitHub issue for "mysql" being open forever.

smeagull 4y ago

You've certainly painted a sunny picture of arm adoption that I'm simply not seeing. One of the advantages of docker is that you can have systems lock their versions. So our project using say, Neo4J, uses a particular version of it. Not necessarily one with an arm build. This creates predictable and repeatable builds. So now either we upgrade dependencies out of our expected cycle, or we abandon macs as our development machines. A decent number of us wanted Linux anyway. This is a cost that Apple foisted on us. > since arm instances are cheaper on some public clouds, you should be making sure your stuff runs on arm64 now. Some instances might be cheaper, therefore we have to adopt it now? I think the cost/benefit analysis you're performing here is ignoring development costs. Are you a project manager of some kind? > they’ve been arm native for years. The native libraries and tools that make them worthwhile are not. Really it only takes a single component to ruin everything.

easton 4y ago
I’m not a PM, but I’ve been in the room during those conversations. Granted, I’ve never had to rely on a ton of native extensions (at least in a business context, personal stuff for sure). It’s just like any other dependency. Sometimes you can afford to freeze on a single version until the end of the project, but most of the time projects I’ve been on will regularly upgrade the third party stuff we rely on if for no other reason than security, with things like arm64 support coming along for the ride. We usually prefer to be able to get help with our issues faster than our tickets getting closed with “fixed in new version update”, of course weighing that against breaking API changes or what have you.