16 comments

[ 6.1 ms ] story [ 53.1 ms ] thread
I was always under the impression that Docker had support for having different architectures under the same tag, and that the client would pull the image that matches the client's architecture, ala most package managers. Is that not the case?
Yes, but only if the publisher publishes images with that architecture.
That is exactly the point of the post. MySQL has no image built for the arm64 architecture even if docker provides a way to provide it for the same tag.

This post is focused on MySQL but you have other images with the same issue.

We basically had to fork the official Dockerfile for 5.7, switch to ubuntu-provided packages and change the debconf options + some tzdata problems to work around this.

For 8.0 there are some arm64 images already on Docker Hub, just the oraclelinux variant.

Lack of good "official" ARM image support in some key places is something the Docker on Raspberry Pi community have had to deal with for some time. I'm hopeful that more people add ARM builds to their publishing processes for their container images now Apple have introduced a huge number of developers to "desktop ARM" for want of better name. There are some tricks (QEMU etc) that allow you to build your ARM container images on any existing x86 build infra you are already using too:

https://www.docker.com/blog/multi-arch-images/

Ability to use cheaper ARM based VPS instances are another reason to really want this too.

Oracle provides "official" (meaning, built by the MySQL team at Oracle) ARM images for MySQL 8 at https://hub.docker.com/r/mysql/mysql-server/tags and has for quite some time.

Historically there weren't any ARM builds over at https://hub.docker.com/_/mysql?tab=tags , which (if I understand correctly) are "official" in a totally different way (these namespace-less images are maintained by Docker Inc?) ... it seems as of the most recent MySQL release (8.0.28) they've started supplying ARM builds with the "-oracle" tag though.

Thanks for pointing to the mysql/mysql-server images. We (I'm working on those at the MySQL/Oracle team) are maintaining those along with the other MySQL components.

Difference to Docker's isn't huge. Our builds are built upon Oracle Linux (which shouldn't have much impact, but relevant for customers to have a fully supported stack), have minor difference in available flags (we for isntance have the "initialize only" mode which temrinates after setting up the data dir which is useful in Kubernetes init containers and similar places) etc.

Our images are also available via container-registry.oracle.com which can be useful, if you run into rate limitations on dockerhub (there you'll also find Enterprise Edition in case you care about that)

I'm open for feature requests etc.

Thank you for maintaining these images!

One question, on the topic of ARM builds actually: I just noticed on Docker Hub that tags mysql/mysql-server:8.0 and mysql/mysql-server:8.0.28 actually lack ARM builds at the moment, is this known/intentional?

On my m1 mac, when I try to use either mysql/mysql-server:8.0 or mysql/mysql-server:8.0.28, I'm actually getting an amd64 image... it is working but is presumably emulated through qemu, which is not ideal.

There's an ARM build for mysql/mysql-server:latest, which I would expect should also be the same as 8.0.28, but its image digest differs from 8.0 / 8.0.28 even for amd64. A bit confusing...

Hi, I have to check that. I know we had a small issue in the .28 release of the arm images, but I assumed that was solved.
Thanks for sharing this docker image. Sound a great option as well.

It has been added to the blog post! Thanks again for the contribution!

mariadb is available in ARM and a drop-in replacement for mysql..
Well that was true until mariadb 10.1 <-> mysql 5.6. Now they diverge too much to assume this.
It's a full-on fork, it hasn't been a drop-in replacement for many years now. MySQL and MariaDB each have many features that the other lacks.
Sorry if this is dumb - I’ve only done a tiny amount of docker stuff - my understanding is that docker images were essentially build scripts, so if the container being built doesn’t have raw assembly these things would just work?

Or is the problem the base image being used for a given dockerfile are typically cpu specific?