Change-to/Provide Alpine

[andrerom]

As many other official images have moved to provide alpine flavor already it would be great if mysql, mariadb and postgres did the same. But these images using debian packages probably makes that easier said than done.

[yosifkit]

Yeah, mariadb, mysql, and percona use Debian packages that are provided by upstream directly, so I think it is unwise that we provide something that they do not support.

[tanji]

I can have a look at Alpine support, will circulate this internally and let you know.

[aXe1]

There are unofficial packages (maintained by Natanael Copa, Alpine creator, AFAIK). I agree, that it's less preferable than using official package, but there are also examples of popular images, that even compile needed software. See official nginx image, for example. I think it would be great to have a choice whether to use less officially supported Alpine-based image, or not.

[yosifkit]

I think this comment is our current response. ie, we want to be sure that upstream supports running it on Alpine Linux.

I am especially hesitant with regards to the non-glibc: musl-libc, since it has caused issues in the past.

[mordant23]

@yosifkit's position is understandable. The ironic thing is that the only available MySQL package in alpine is MariaDB. The official MySQL images use oraclelinux. That makes MariaDB the best candidate for the an alpine based image for MySQL when you just need a MySQL drop in.

I created a quick and dirty alpine MariaDB image for local development and found the spin up time for local development drop to less than a second versus over 15 seconds for the Percona image using debian. The caveat is the time savings may be due to the lack of proper initialization.

[zyrill]

+1 for alpine image. All my other images are based on alpine, it's just so much more ressource efficient. I think having an "official" image without "inofficial" support is still preferable to using the image of somebody that you have to check every time. In other words: educating users that the image might misbehave and declaring it "unsupported" but still providing it is preferable to the users wandering off to some completely unofficial build with all the related security issues. It's a matter of trust IMHO.

[skwashd]

Does MariaDB providing a knowledge base article about how to build for Alpine change anything?

[zyrill]

@skwashd Yes and no: it's cool to not have to start from scratch so it's highly appreciated to have the docu but it doesn't solve the security issue I mentioned: yeah, I can build a script myself but the governance that even an unsupported official build has means it's much easier to put an image into production if it's endorsed by the original devs. The reasoning is as follows: if we use MariaDB, we trust the devs or checked the source ourselves and we trust their releases so we don't need to check every new version as vigorously. This saves resources and makes deployment processes so much easier.

[csandanov]

Meanwhile feel free to use alpine-based https://github.com/wodby/mariadb, 10.1 and 10.2 versions.

[tianon]

Just to re-summarize the current position here:

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).

[J0WI]

How about https://pkgs.alpinelinux.org/packages?name=mariadb&branch=v3.7?

[skwashd]

@J0WI that is what I use when I need mariadb in a project. Official docker images are built using upstream tarballs.

I often find it is better to use the alpine base image and apk add whatever I need. Not only does it build faster, it results in smaller images.

[616b2f]

Any news on that?

[J0WI]

@tianon would you accept a PR that uses the prebuilt package by Alpine Linux?
It cannot be build from source directly, Alpine Linux uses various patches to fix compatibility with musl libc.

[daveisfera]

Installing the prebuilt package from Alpine Linux means that it will be tied to the version that's available there, so updates and fixes can't happen without it happening in Alpine first. I'd recommend that the build happen in the container and the necessary patches be applied as part of the build.

Here's an example of that happening with RethinkDB: rethinkdb/rethinkdb-dockerfiles#32 (comment)

[J0WI]

I think the discussion on openjdk:8-alpine was about the same. But manual patching every new version is not practicable (and we may have to wait for Alpine to submit a patch anyway).
In your example it seems that you only need one patch for LibreSSL compatibility. But you also built for only one architectures. Official images are built for many architectures and MariaDB has more complex patches for Alpine.

[maenujem]

I think providing a build that works with Alpine (and then with Docker, which then should not be a big issue) is more a matter for MariaDB in the first place (upstream for musl libc) and for Alpine OS in the second place (packages), as it is a lot of continuous work and requires also good knowledge of Alpine. That work could be re-used by everyone using the db with Alpine, not only for Docker, and thus could have bigger support and maybe/hopefully become (almost) official supported build for Alpine.

As already mentioned by others before, there are regularly updated / maintained builds for Alpine: https://wiki.alpinelinux.org/wiki/MariaDB and https://pkgs.alpinelinux.org/packages?name=mariadb&branch=edge

[daveisfera]

The problem with using the pre-built binaries from Alpine is that you're locked into a single version and locked into the updates that they do.

[J0WI]

That's true, but you can easily contribute upstream to https://github.com/alpinelinux/aports/tree/master/main/mariadb
Alpine Linux currently supports MariaDB 10.1, 10.2 and soon 10.3 (depending on release branches).

[yosifkit]

Alpine Linux has "bug fixes" support for 3.7 + 3.8 (and "security only" for 3.5 + 3.6) and is basically always behind the releases available from MariaDB, so it would not provide the same experience that the Ubuntu images provide.

• Alpine 3.5, 3.6, and 3.7 have MariaDB 10.1.32; latest from MariaDB apt packages is 10.1.37
• Alpine 3.8 has MariaDb 10.2.19; latest from MariaDB apt packages is 10.2.21

Even the development branch lags as well:

• Alpine Edge has MariaDB 10.3.11; latest from MariaDB apt packages is 10.3.12

We strive to provide images that are as close to upstream (MariaDB) recommendations as possible, and I don't think the Alpine packages meet that. So I am against providing images that use the packages provided by Alpine.

Users are free to improve upon and make their own images that use the Alpine packages:

FROM alpine:x.x
RUN apk add --no-cache mariadb
# entrypoint script??
CMD xxx

[vndroid]

Why do you have to use the official repository to build the image? Some software supports the Alpine. And it doesn't use the official repository to install. Why not release this sort of the image? There must be no need to say more about the reasons of use Alpine based.

[achton]

I don't know...

10.4.12 was packaged for Alpine on January 29th (v3.11), 1 day after the official release. The official Docker image (this one) was released on February 16th. Even the image from MariaDB Corporation is still at 10.4.10, which is a release from 2019-11-08. So I'm not sure the release timing argument is valid any longer :-)

Most providers add a "disclaimer" to their Alpine variants to the effect of "The main caveat to note is that it does use musl libc instead of glibc and friends, so certain software might run into issues depending on the depth of their libc requirements."

[yosifkit]

The 10.4.12 image was updated is this repo on the 28th (c895fa5) and the image update was merged on the 29th (docker-library/official-images#7366).

Regardless of the great work made by the Alpine maintainers package, we still will not use it here; Alpine Linux is not a target that the MariaDB upstream build packages for (https://mariadb.com/kb/en/deprecation-policy/).

---

We had left this issue open in the hope that MariaDB upstream was working internally to test/add Alpine linux, but since the contact we had no longer works there, we have no insight to their process. Since it has been 4 years since they were supposedly working on it, it is probably not actively happening.

Let them know this is something desired by their community on their bug tracker. Vote for the open issue at https://jira.mariadb.org/browse/MDEV-18462.

Closing in favor of upstream bug MDEV-18462 ⬆️

[J0WI]

See also https://jira.mariadb.org/browse/TODO-2238 for CI with musl libc.

[grooverdan]

TODO-2238 moved to https://jira.mariadb.org/browse/MDBF-244 for public visibility

[McLotos]

Some news about mariadb alpine image?

[grooverdan]

I'm still waiting on people to describe what the driver is for alpine? Is it the only possible implementation? #343 has some thoughts around size if that was the requirement. It also says why we're no going to jump into something that isn't currently in the CI of MariaDB currently.

So please, can you tell me why its important?

[McLotos]

@grooverdan Alpine is the smallest Linux distrib. Everyone switched to it a long time ago, but when using mariadb containers,we also have to pull up Ubuntu because there is no version of Mariadb-alpine: latest
Look at php-fpm, nginx, composer projects:
https://hub.docker.com/_/composer
https://hub.docker.com/_/php
https://hub.docker.com/_/nginx
https://hub.docker.com/_/alpine

[McLotos]

@grooverdan? Is there an approximate date of mariadb:alpine release?

[grooverdan]

@grooverdan Alpine is the smallest Linux distrib.

As calculated in #343 (comment) if size was the main requirement there are ways of getting much smaller than it - probably ~60M. Alpine, like what docker.io/linuxserver/mariadb:alpine uses is 25% smaller (though their ubuntu is bigger so Alpine isn't the only aspect).

Why is size such an important requirement?

Because the base OS alone is a rather small part of the mariadb image so its not making that much difference.

Everyone switched to it a long time ago, but when using mariadb containers,we also have to pull up Ubuntu because there is no version of Mariadb-alpine: latest

Also note the reasons not use use alpine - #343 (comment)

@grooverdan? Is there an approximate date of mariadb:alpine release?

It won't until its in the CI of the mariadb-server (MDEV-18462) which is rather full in terms of hardware usage currently.

It also won't happen without a requirement that is more substantial than "Everyone switched to it" and some consideration to performance.

In the mean time there is https://fleet.linuxserver.io/image?name=linuxserver/mariadb

[grooverdan]

Also why is a size requirement important when a basic database's datadir will quickly exceed the size of the container image?

[russnes]

Looking forward to this (if it eventually arrives!). I'm sad to see the issue closed, however I understand and respect the complexities involved.

For the record it might be interesting to note that for example the default nginx package on docker.io is 138 MB whilst nginx:alpine is 24.5 MB.

[grooverdan]

I don't buy the size argument and no-one has put in a meaningful case to show why its important. A basic MariaDB data directory makes both of these sizes insignificant.

Alpine will never arrive unless a meaningful, thought out, justification happens. Quasi emotive states don't help and they certainly don't help when we get alpine/musl bugs like https://jira.mariadb.org/browse/MDEV-24756.

In the mean time, the FAQ stands - https://github.com/MariaDB/mariadb-docker#why-dont-you-provide-an-alpine-based-image .

[russnes]

To your point on the size argument I personally run mariadb servers that have data directories smaller than the current image size. On some small footprint projects a few hundred megabytes can really count and change the project from being viable to too costly. However I think you're right that there are many cases where it doesn't matter.

Anyways I completely understand that it is not a priority, I just wanted to show my interest.