Add Alpine variant

[J0WI]

No description provided.

[tianon]

#53 is still very relevant -- what's changed since that was closed? 😕

(See also https://jira.mariadb.org/browse/MDEV-18462, where upstream seems still committed to not officially supporting Alpine Linux.)

[J0WI]

Various patches have been accepted upstream including some specifically for Alpine Linux. It builds now without any additional patches.

[tianon]

Specifically, from #53 (comment):

For us to move forward with Alpine variants of MariaDB within this repo, we either need upstream to start releasing explicit, supported Alpine builds of MariaDB (which would be ideal), or we need their blessing to create variants of this image which build MariaDB from source (attempting to match the compilation options of the Debian/Ubuntu-based images as closely as possible, which is going to be a slight challenge).

[julienfritsch44]

I suggest the MDEV is watched and once it's done then a new PR would make sense. Letting this PR open whereas the related MDEV is not done, doesn't help. Is that acceptable?

[J0WI]

Isn't this PR kind of fixing https://jira.mariadb.org/browse/MDEV-18462?

[grooverdan]

Isn't this PR kind of fixing https://jira.mariadb.org/browse/MDEV-18462?

Its kind of forcing it into production without a CI testing process behind it.

As far as I can tell, the main driver is size.

Linux server does an alpine distribution of:

docker.io/linuxserver/mariadb alpine a2ca1767a30f 6 days ago 294 MB
docker.io/linuxserver/mariadb latest 4af007939310 6 days ago 357 MB

latest being a bionic base, so these are still smaller than the ones from here:

docker.io/library/mariadb 10.5 992bce5ed710 6 days ago 407 MB

And from alpine itself, its a rather small component of this:

docker.io/library/alpine latest 6dbb9cc54074 2 weeks ago 5.88 MB

Compared to the ubuntu sizes:

docker.io/library/ubuntu focal 7e0aa2d69a15 7 days ago 75.1 MB
docker.io/library/ubuntu bionic 4eb8f7c43909 7 days ago 65.5 MB

If ubi was used as a base ( https://github.com/grooverdan/ubi-mariadb ) I get:

localhost/ubi-mariadb 10.5.9 e63d31d3b847 24 seconds ago 579 MB
registry.access.redhat.com/ubi7/ubi latest 899998a87be7 10 days ago 216 MB
registry.access.redhat.com/ubi7/ubi-minimal latest 67ea4d7eac18 10 days ago 83.2 MB
registry.access.redhat.com/ubi8/ubi-minimal latest 332744c1854d 2 weeks ago 105 MB
registry.access.redhat.com/ubi8/ubi latest 613e5da7a934 2 weeks ago 213 MB
registry.access.redhat.com/ubi8 latest 613e5da7a934 2 weeks ago 213 MB

Looking the packages installed here there are a large number of unneeded large pages, glib2, perl, python3, systemd, gnupg, file-libs so there's a significant amount of room to improve.

As a comparison point, MariaDB does do a (mostly) statically linked tar.gz files

https://downloads.mariadb.org/mariadb/10.5.9/#os_group=linux_generic of 343.6 MB which in uncompressed from can go from 1.2G to 60M with brutal pruning of client programs, test suites, stripping of executables.

On size alone, taking a tar and adding busybox as a base image to handle the entrypoint might be the smallest possible:

docker.io/library/busybox 1.33-musl 1f8bca985304 3 weeks ago 1.65 MB
docker.io/library/busybox 1.33-glibc 1b8593d457ef 3 weeks ago 5.44 MB

So on size, Alpine + a staticly linked (all but musl-libc) tar.gz based image will probably be the second smallest reasonably achievable. A ubi-minimal based one would be about third (with added benefits of using existing tar.gz, Red Hat support etc, unclear if/how it would be on dockerhub however - docker-library/official-images#9445).

Has anyone done performance tests of musl mariadb vs glibc mariadb?

Are there any other driving requirements that has led to an alpine approach?

[grooverdan]

@J0WI any other requirements that lead this Alpine PR? Are the alternatives suggested acceptable? There's vague hint in #53 that consistency of base images enables adding of apk usage on top of it.

I'm not totally against Alpine, but if there's a way to meet its requirements in a supported (CI + generally better tested) way and satisfy other users as well with less effort I'm definitely going to favour that approach.

[J0WI]

The Debian/Ubuntu packages are missing a lot of platforms. Building MariaDB on Alpine from source would enable more platforms.

some references:

• More arches (ppc64le + arm64v8) and ubuntu #184, Please build cross architecture images #204, Not working on RPI4 #335
• https://github.com/docker-library/official-images/blob/a84d874673f46404dc6f5f59258a182db7241633/library/mariadb#L13
• https://github.com/docker-library/official-images/blob/a84d874673f46404dc6f5f59258a182db7241633/library/alpine#L17
• https://github.com/docker-library/official-images/blob/a84d874673f46404dc6f5f59258a182db7241633/library/debian#L48
• https://github.com/docker-library/official-images/blob/a84d874673f46404dc6f5f59258a182db7241633/library/ubuntu#L33
• https://github.com/docker-library/official-images#architectures-other-than-amd64
• https://pkgs.alpinelinux.org/packages?name=mariadb&branch=edge

[grooverdan]

Thanks @J0WI. You've probably noticed me pushing for ppc64le support where upstream support existed back in #154.

Adding architectures ends up in the same case as adding muslc, its hardly sane to do it without a CI process behind it, or some hardware available for testing if things go wrong.

s390x support has been requested in MDEV-23155 and with IBM providing access its something that could be done.

arm32v7 might be something to consider but at the moment without hardware debugging them is hard - MDEV-24756.

i386 accidentally dropped off support in the way debian got packages, and no-one noticed or complained about the dropping of support.

arm32v6 is probably too old.

mips64le could be something to aim to support, its range of optional extensions is a bit daunting from a packaging/coding point of view. MariaDB/server#1805 has some options that might enable its support.

[J0WI]

I think the older arm32 platforms are mostly relevant for Pi users. Postgres supports all of them. MariaDB packages are available in the distro repos but not on Docker.

[grooverdan]

I think the older arm32 platforms are mostly relevant for Pi users.

Noted.

Postgres supports all of them.

Yes it seems to be based on the Debian disto packaging but more importantly - https://www.postgresql.org/docs/current/supported-platforms.html list them as supported which matches their build farm.

MariaDB packages are available in the distro repos but not on Docker.

Yes, and arch dependent bugs linger https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=mariadb-10.5 .

I'd rather users ask for support in architecture/platform X than to try to over-deliver beyond a reasonably tested codebase. Unlike Debian we don't have an upstream to offload the problem to.

[tianon]

I wouldn't suggest losing much sleep over armel and sh4 bugs, but ppc64le having issues definitely interesting. 😅

[tymonx]

Please notice some Alpine caveats

In my experiences:

• one of major issues with Alpine images is DNS. I have recently added support for the Galera replication that can be used in container clusters like Docker Compose, Docker Swarm and others. All of them heavy relay on DNS and hostnames to achieve no-machine aware (cloud, high-availability)
• the musl library is used in embedded. It is slower than glibc in many cases. For example simple standard C function strlen is heavy optimized in the glibc library. It uses many optimization tricks to find number of characters in string as fast as possible
• the glibc wrapper for the musl library is not perfect. Some glibc applications behaving strangely, crashes randomly or never run. It is sometimes better to rebuild source code and add direct support for the musl library (with testing if everything still works)

For small images is better to use the Distroless. It includes glibc (gcr.io/distroless/base-debian10), it is based on the Debian distro, is more secure, it has less security surface attacks than other base images.

[grooverdan]

Please notice some Alpine caveats

In my experiences:

Thanks for sharing.

* one of major issues with Alpine images is DNS. I have recently added support for the Galera replication that can be used in container clusters like Docker Compose, Docker Swarm and others. All of them heavy relay on DNS and hostnames to achieve no-machine aware (cloud, high-availability)

Glad --skip-name-resolve is default however.

* the `musl` library is used in embedded. It is slower than `glibc` in many cases. For example simple standard C function `strlen` is heavy optimized in the `glibc` library. It uses many optimization tricks to find number of characters in string as fast as possible

The common libc functions I've seen in MariaDB performance profiles are memcpy and memcmp who's simple muslc implementation (memcmp) doesn't correspond the the more optimized version in libc (however the compiler seem to do a fairly verbose transform - I looked with objdump -d /lib/ld-musl-x86_64.so.1 | fgrep -A 150 '<memcmp>:').

* the `glibc` wrapper for the `musl` library is not perfect. Some glibc applications behaving strangely, crashes randomly or never run. It is sometimes better to rebuild source code and add direct support for the `musl` library (with testing if everything still works)

[tymonx]

The common libc functions I've seen in MariaDB performance profiles are memcpy and memcmp who's simple muslc implementation (memcmp) doesn't correspond the the more optimized version in libc

I would also notice that functions like memcpy and others are part of built-in gcc functions. Generic glibc functions are replaced with more optimized architecture aware version (in assembler) of these functions like for example memmove-vec-unaligned-erms.S

[grooverdan]

recent example on why we're not jumping to support musl/armv7 without a backing CI in place.

I did search JIRA for armv7 based issues, and with the exception of distro maintainers reporting failing unit tests (rather than user reported issues), there did appear to be a small number of users.

[grooverdan]

@J0WI apart from forking your own entrypoint this looked pretty decent from a container point of view.

Bases on reliability backed up by recent bugs like MDEV-24756 shows how badly things can go with no easy resolution because of alpine/musl/arm32v7.

So I'm closing this. I've added the FAQ to the README at the top level. Based on which requirement comes first I or someone else may open this back up later.