Hacker News new | ask | show | jobs
by tyingq 1903 days ago
"Choosing a base image can be quite daunting. I’m always a fan of Alpine Linux for my application containers, so that’s what I chose."

Just be aware that means the musl libc, which is often fine, but not always. Software that expects glibc can crash or have unpredictable behavior. The JVM is a good example, unless you get a JVM that was originally built against musl.

And sometimes also issues with busybox, where it differs from other implementations of the same tools.

2 comments

Case in point: "Using Alpine can make Python Docker builds 50× slower", https://pythonspeed.com/articles/alpine-docker-python/
That article should be titled, “Most Python packages do not upload an Alpine-compatible wheel to PyPI.”

If you know where to find Alpine-compatible wheels, or host your own, Alpine has no build-speed penalty.

Where do you find Alpine-compatible wheels? Many ones uploaded to PyPI aren't, because e.g. both GitHub actions [0] and Azure pipelines [1] don't have Alpine images. Is it reasonable to expect maintainers of small, open-source libraries to write and maintain their own Alpine runners?

I guess if you know your company's workflow depends on Alpine, you can build and cache them yourself. But the wider community doesn't benefit from that.

[0] https://docs.github.com/en/actions/using-github-hosted-runne...

[1] https://docs.microsoft.com/en-us/azure/devops/pipelines/agen...

I was not aware of prior work so I maintain Alpine wheels for packages I use personally in a GitHub org.

https://github.com/alpine-wheels/index

Besides my own needs, only one other person has requested additional packages, which I was happy to add. Maintenance is minimal, mostly just approving pull requests created by Dependabot.

That's pretty slick! Thanks
Exactly zero packages upload Alpine-compatible wheels to PyPI.

The manylinux specification assumes glibc, so there is no valid distribution format which would allow the publication of non-glibc wheels.

However there is an in-progress PEP to support it: https://www.python.org/dev/peps/pep-0656/

I've used alpine images for python in production and not run into any of these issues. The key is to know how to use multistage builds to cache layers.
Yeah, this is why I use debian slim as an image for most projects unless I'm prioritizing small size. Its small and popular enough that a lot of other images already use it and chances are that you dont have to redownload it.