This is one of the benefits of golang. You compile it into a binary and copy just the binary into your scratch container. Maybe it is 20MB in size.
apt-get update && apt-get upgrade
rinse, repeat.
Secondly, all this cargo-culting around small containers is fine if you are cramming resources. I am not.
The reality is that my projects and many others are really, really over-provisioned. Looking at my graphs right now, I am on the front page of HN and my server load is still only 20%.
You can do this exactly the same in alpine, with "apk update" and "apk add".
"Secondly, all this cargo-culting around small containers is fine if you are cramming resources. I am not."
The default docker python image is 885MB. python:buster-slim is 114MB which is much more reasonable. Even if you're not "cramming resources", pushing 885MB vs 115MB vs 20MB across the wire does add up over time.
In my case, we do quickly iterate and pull docker images so it does make a difference for my colleagues if the image is 30MB vs 500MB. Even if we're all on gigabit internet.
"Cargo culting" implies doing it without knowing why we're doing it. The benefits of reducing the size of docker images is apparent to everyone, although there are diminishing returns. With dive[0] it is very easy to figure out where the waste is.
"The reality is that my projects and many others are really, really over-provisioned. Looking at my graphs right now, I am on the front page of HN and my server load is still only 20%. "
Optimizing docker images has nothing to do with being over-provisioned.
I will concede that it's very different as a solo developer vs even a small team.
Push new versions of one of those to 50 machines, versus the other.
You don't have to watch security lists for vulnerabilities.
You don't have to scan your docker containers because the dockerfile is 4 lines long.
You don't have to worry about a coworker adding a bad tool to your production container.
That frees up cognitive load to write your code.
Note: I am an infrastructure engineer for a small SaaS that builds and runs production.
> You don't have to watch security lists for vulnerabilities.
These two statements are incompatible. You have fewer things to watch but you’re definitely still going to track your dependencies. Static linking still means you have to do that, and nobody else can do it for you.
I am more concerned about pulling in Linux binaries that are full of vulnerabilities.
Alpine is subtly different for python builds:
* It uses musl-c. It's not glibc, it's different. Not necessarily better or worse.
* You can't use manylinux1 wheels with alpine, so if you've got python/c extensions, you're going to be building them instead of installing upstream binaries. So cue the need for a dev toolchain, and a much longer install time.
And once you have all that, you're running a different version in dev/prod, which is one of those things that docker is supposed to be good at fixing.