This gist is meant to explain why Alpine Linux is being dropped from support for Docker images for both Kumiko, and Akari. When choosing the base image for Docker for Kumiko and Akari, Alpine Linux was first used. (first introduced to me by Ellie). Alpine's main selling point is simple: smaller image sizes, and better security. But Alpine comes with a catch. Alpine Linux uses musl (different implementation of the C stdlib for Linux) and busybox, while distros like Debian, Ubuntu, Arch, etc all use glibc and coreutils (GNU Core Utilities). Often times this doesn't play well with Python, and any languages that extensively use C/C++.
One of the biggest issues why I've decided to move away from Alpine Linux is the insane build times that it takes. On average, Debian-based images for Kumiko often only take 3-4 minutes, while for Alpine-based images, it will take around 20-25 minutes. Each commit triggers the workflow to rebuild and re-tag the Alpine tags for Kumiko, and soon it gets annoying.
For example, the build times for Alpine take around 20 mins. Compared with Debian, which takes around 2-4 mins. This is also with caching enabled on GitHub Actions.
TD;LR: Standard PyPI wheels do not work on Alpine (mostly)
If you have looked at the actions running, you will notice that on Debian, it is downloading wheels compiled for the ManyLinux format. So what is ManyLinux? ManyLinux is a standard (PEP 600) to distribute binary Python packages on Linux. Each package is packaged into a wheel, which is what gets installed and gets unzipped once you are installing. Now most manylinux packages are packaged against glibc (with orjson and ormsgpack using Maturin to build). If you have a package that only provides manylinux wheels, the other option is to look for a musl version of it. If there isn't a musl version of it, then it just compiles from source. What takes most of the time when the Docker image is being built is compiling from source, which some packages like orjson, ormsgpack, and more, will need to have Rust installed to compile. Kumiko depends on a ton of libs built in C/C++, Cython, and Rust, which when you have like 10-14 libs building that way, building the Docker image takes more time since it needs to compile all of those libs from source. The compilation time adds up, and at the end, it takes like 20-25 minutes to build. This was also the primary issue on why Rin was actually getting slower build times on Alpine Linux as well (since Rin depends on Numpy, which does not offer musl wheels to this day).
Another good example, since these are mostly libs that requires Rust and C/C++ libraries.
As of now, there has not been any tested or general issues for Kumiko yet, so this might not apply.
- A user found that their Python app ran much slower on Alpine. Node.js running on Alpine Linux images are about 15% slower then Debian images. Python images often will have a performance decrease of 35% when using Alpine Linux.
- DNS connections and lookups have been pretty fishy. Uptime Kuma deprecated Alpine support for this exact reason.
- Alpine by default has a smaller default stack size for threads, which actually lead to memory issues
- Literally no list of security flaws (CVE) maintained for Alpine. The closest is alpine-secdb, which is already deprecated.
- Chances of extremely obscure bugs. This is because Musl uses a different malloc, different libm, and different implementations of the C stdlib.
Due to these issues, Kumiko, and by extension, Akari will finally drop Alpine Linux support. It literally has become a frustration for me to wait 25 mins to get an Alpine version of Kumiko. The overhead size won't really matter in the long run, since 100MB of difference is not too much for the end user. The Alpine Dockerfiles will still be available, but not in the same repo as Kumiko or Akari will be in.