7 ms·
Is there really a reason to use Alpine anymore? There's RedHat's UBI-minimal/micro and Ubuntu has a minimal image. Especially with Alpine's DNS weirdness in K8s
by stuff4ben 4y ago
Is there really a reason to use Alpine anymore? There's RedHat's UBI-minimal/micro and Ubuntu has a minimal image. Especially with Alpine's DNS weirdness in K8s environments. I feel the whole "Debian/Ubuntu bloatedness" (from the blog) is so last decade nowadays.
- rediculous400 4y agoI still believe there are some (i agree not many) reasons to still use Alpine Linux. The obvious is the small size i think still maybe even smaller than Ubuntu. But more importantly the security, it focuses on security with features such as stack-smashing protection, address space layout randomization, and a hardened kernel. And isn't performance still decent for being lightweight and fast? And of course the package management apk manager. Isn't it smaller package repository than other distributions still?
- klooney 4y agoRedHat also does a ton of hardening (ASLR since 2004), and they employ the people that wrote most of the implementations. They've historically been quite good and fast with security updates, and are one of the vendors that gets the inside track on security embargoes. They're also really slow and stable, which is nice for boring plumbing.
- sebazzz 4y agoHow much of these security hardening matters in a container?
- blueflow 4y agoAn application running in a container is still an application running in userspace, so the hardening applies as normal.
- csdvrx 4y ago> Is there really a reason to use Alpine anymore? There are already many reasons. As cosmopolitan advances, there will be even more: think about what you could do with a set of binaries that would run anywhere. That'll happen way sooner with a muslc based distribution than with any other libc, and there aren't many muslc distributions as popular as alpine (except Void): https://wiki.musl-libc.org/projects-using-musl.html https://wiki.musl-libc.org/projects-using-musl.html
- viraptor 4y agoWhat could you do? Normally we deploy to a known environment with a chosen OS. Unless I'm a distributor of closed source software, why should I be interested in cosmopolitan?
- blueflow 4y agoBoth RedHat and Ubuntu made some user-hostile decisions in the past, thats why i ended up using Alpine for Server and Laptop. So far i haven't found enough reason to migrate back. Plus, a smaller resource footprint reduces resource pressure and improves application speed. Alpine is still leading in that.
- tristor 4y agoWe are actively working on migrating away from Ubuntu minimized images towards Alpine, because Ubuntu makes significant changes every major release that break basic expectations on the system around packaging, networking, service management and other aspects that affect lower-level system software. If your app is run inside of an app server proxied through a web server, you probably don't care that much about the underlying OS changes. If your app is system-level, underlying OS changes are a significant maintenance cost that greatly increases friction and reduces feature velocity. Alpine's environmental stability and tiny security footprint make it ideal for system software that is being containerized.
- kdjfjxidj 4y agoreally feel you will benefit more from undertanding containers (i.e. processes) correctly instead of rebuilding and evaluating different bundles of pseudo OS to wrap your programs
- tristor 4y agoI am very certain that my understanding of containers is correct. I have been working deeply with containerization techniques on Linux since well before the creation of Docker, including on the (then) largest containerized production systems in the world. I've also spoken extensively at major technical conferences on the topic. I've sat on technical committees evaluating containerization techniques, both privately (inside a company) and publicly (as part of open projects). I'm quite assured of my knowledge on the topic, but am always open to new information. If you have something specific you think you know that is related to my exact application where I am mistaken, please inform me, and I'll give it all due consideration. I suspect you don't, since you also don't know my exact application for doing this, so it seems a bit presumption to have the response that you did.
- yjftsjthsd-h 4y agoWhat does understanding containers have to do with choice of base image?
- pella 4y ago
- skovati 4y agoFWIW, musl has implemented DNS-over-TCP recently [1], so future Alpine releases shouldn't have DNS issues in k8s anymore. [1] https://gitlab.alpinelinux.org/alpine/tsc/-/issues/43#note_295556 https://gitlab.alpinelinux.org/alpine/tsc/-/issues/43#note_2...
- schemescape 4y agoHow big is the minimal install for non-Alpine distributions? Other than Puppy Linux and Alpine, every “minimal” distro I’ve tried has been annoyingly huge.
- tristor 4y agoTo Canonical's credit, minimal Ubuntu is pretty small, unfortunately it bloats quickly when you start installing packages for dependencies. Minimal Ubuntu clocks in around 30MB, comparable Alpine images are around 5MB, both are significantly smaller than a typical distro installation. Packaged our software on Ubuntu takes 400MB and around 45MB on Alpine, so the base image for minimal Ubuntu is 6x larger than Alpine and the packaged image is nearly 10x larger than Alpine.
- stuff4ben 4y agoThe latest UBI9-based version of ubi-micro is 24.3MB on disk. Still a bit bigger than Alpine's 7.05MB on disk. In my case, it's not enough to notice and anything under 100MB is perfectly fine.
- pella 4y agoYou might even want to look at the minideb[1] based bitnami images if extension is less important. for example postgres: https://github.com/bitnami/containers/tree/main/bitnami/postgresql https://github.com/bitnami/containers/tree/main/bitnami/post... - bitnami/postgresql:15 bb50064c650b 275MB ( postgis included! ) - postgres:15-alpine 6a35e2c987a6 243MB - postgres:15-bullseye 2bb008a38e7c 379MB [1] https://github.com/bitnami/minideb https://github.com/bitnami/minideb However, it is sometimes a good idea to benchmark the speed of different images, as sometimes a significant speed loss is possible. for example: alpine and bitnami images optimized for size. If reliability and support is important then the official debian based images are the way to go. ( --> postgres:15-bullseye )
- dboreham 4y agoI wish Alpine didn't exist because it's been quite a time sink for my team in terms things that are randomly different from mainstream Linux, and things that end up not being supported at all. We often have to fork projects just to add a Debian image so it's usable in our deployment context.
- yjftsjthsd-h 4y ago> There's RedHat's UBI-minimal/micro and Ubuntu has a minimal image. Neither of those is as minimal as Alpine, and both are tied to companies that I view as having acted against my interests in the past.
- ttfkam 4y agoI switched to debian-slim a while ago and never looked back. The base may be bigger than Alpine, but not significantly after packages and frameworks are loaded. node:lts-slim is 75MB node:lts-alpine is 50MB Yes, 50% larger, but also has glibc for greater compatibility and can even be faster at runtime. I know Python containers tend to be faster on Debian than Alpine. So is 25MB really worth it? Especially when that 25MB is shared between multiple containers?
- MuffinFlavored 4y agoWhat's different between debian:bullseye-slim and debian:bullsye (assuming you are talking about https://hub.docker.com/_/debian https://hub.docker.com/_/debian) let me try to answer/research this question myself to find the answer/go on this journey: takes me to non slim: https://github.com/debuerreotype/docker-debian-artifacts/tree/dist-amd64/bullseye https://github.com/debuerreotype/docker-debian-artifacts/tre... slim: https://github.com/debuerreotype/docker-debian-artifacts/tree/dist-amd64/bullseye/slim https://github.com/debuerreotype/docker-debian-artifacts/tre... https://github.com/debuerreotype/docker-debian-artifacts/blob/dist-amd64/bullseye/slim/rootfs.manifest https://github.com/debuerreotype/docker-debian-artifacts/blo... versus https://github.com/debuerreotype/docker-debian-artifacts/blob/dist-amd64/bullseye/rootfs.manifest https://github.com/debuerreotype/docker-debian-artifacts/blo... two files are identical so at a quick glance i have no clue what is going into rootfs.tar.xz that makes one slim and one not go to google: https://stackoverflow.com/questions/59794891/how-does-debian-differ-from-debian-slim https://stackoverflow.com/questions/59794891/how-does-debian...
- ttfkam 4y agoFrom the hub page regarding -slim: > These tags are an experiment in providing a slimmer base (removing some extra files that are normally not necessary within containers, such as man pages and documentation), and are definitely subject to change.
- Gordonjcp 4y ago> Is there really a reason to use Alpine anymore? No glibc cruft. No systemd cruft. Still Linux though.
- ddevault 4y agoAlpine is small, stable, and built by professionals with a purpose in mind. I would not consider running anything else in production, and I run it on all of my devices -- servers, workstations, laptops, phone, SoCs, even my TV runs Alpine. It's an excellent distro and one of the few that I feel can fit entirely in my head.
- thinking001001 4y agoDepends if you're running Python or not (or an equivalent scripting language with OS dependencies i.e. Ruby, PHP, Perl)