In my experience, "slim" Debian images (like `python:slim`) aren't significantly larger than Alpine-based ones, but save lots of time and headache when something assumes glibc and breaks (or, worse - subtly breaks) with musl (or doesn't have a binary distribution for musl so every time image's built you have to build from source).
Also, I'm not sure what are the benefits going `FROM alpine` and installing nginx, than just starting `FROM nginx:alpine`. The latter has benefit of a more straightforward update logic when a new nginx version is released - `docker build` will "just" detect this. It won't notice that Alpine repos have an upgrade, though, and will reuse cached layers for `RUN apk install nginx`.
> In my experience, "slim" Debian images (like `python:slim`) aren't significantly larger than Alpine-based ones, but save lots of time and headache.
I came to pretty much the same conclusion too.
For years I was using Alpine but as of about a year ago I've been going with Debian Slim and haven't looked back.
I'd much rather have the confidence of using Debian inside of my images than save 100MB on a base image (which is about what it is in a real web project with lots of dependencies).
In my experience, the difference is sometimes even less than 100MiB (which is quite a lot). For the current ("real-world") project I'm working on, it's about 25MiB - something like 325MiB for Alpine and 350MiB for slim Debian base images.
Either way, it's not 1.12GiB I was getting with a fat `FROM python:3` base image.
Exactly. The author considers the fact they the official images are built from source as a negative. Though that’s what allows them to actually generate updated images.
They mention trust of who’s building the images, which is valid, but then using `apk install nginx` means you still have to trust that package maintained. It’s really just moving trust from Docker to Alpine.
It’s fair that it’s a reduction of entities that need be trusted since they are using Alpine as their operating system already, however they are still running Docker binaries...
It’s pretty neat to be able to say they don’t use Docker Hub for anything, but it doesn’t seem to offer any advantage.
Nah, that would require going completely `FROM scratch`. Otherwise that won't be true as `alpine` base image is still hosted on Docker Hub: https://hub.docker.com/_/alpine
Oh that is excellent news, thanks for the tip! I spent a bit of time trying to get Alpine working for a Python application with a relatively complicated set of dependencies, and Alpine was really not cooperative so I think I gave up and went with a fat image. I'll try it again with slim.
Also, I'm not sure what are the benefits going `FROM alpine` and installing nginx, than just starting `FROM nginx:alpine`. The latter has benefit of a more straightforward update logic when a new nginx version is released - `docker build` will "just" detect this. It won't notice that Alpine repos have an upgrade, though, and will reuse cached layers for `RUN apk install nginx`.
Just saying.