[duped]

Memory is not cheap in the cloud nor is bandwidth, so optimizing for image/container size is quite cost effective.

Also every headache I've had with musl libc is because glibc is insane, not because there is a problem with musl. It should be trivial to swap out your standard library, as that is the entire point of dynamic loading. Yet you cannot actually swap out the dynamic library that nearly every program on your system will need, because it's not actually a library.

[hinkley]

People often forget that bandwidth is time. A significant fraction of redeploy time for me is docker images, and that's using alpine base images. It would be (was) far worse with something else.

[dharmab]

If you are optimizing for image size, Alpine is not the best choice. For example, Distroless (https://github.com/GoogleContainerTools/distroless) has options 50% smaller than Alpine.

[hinkley]

My other options seem to be to use more Google software or more RedHat software and both of those have been in the doghouse for some time.

I’d be more likely to use CoreOS as at least I can claim peer pressure, and potential layer savings.

[sofixa]

That's why the best option is scratch containers, they have pretty much nothing outside of the stuff you add in manually (like your binaries).

[hinkley]

I’m not fucking around with a container that doesn’t have a package manager in it. apk does a pretty good job of not being populated with hot garbage.

[dharmab]

Generally with scratch images you build in a less weird environment, then copy your application's files into a scratch image.

https://docs.docker.com/build/guide/multi-stage/

[sofixa]

You don't need a package manager in your production container, you need one for the dependencies to build your artifact (in previous stages) which gets passed on, on it's own, statically compiled, to the empty container.

[hinkley]

And I need a tool chain for inspecting a sick container trying to figure out why CPU jumped 25% for no apparent reason.

Also some programming languages, you can’t really populate the app’s dependencies without a bunch of its dependencies. And the only way to split the difference means you have to memorize every file that gets created during the build/install process to be sure you don’t miss anything airlifting them from one container to another.

All of which amounts to me becoming the package manager. Which gets much less fun the more containers you have running in prod.

I generally respect the curation that alpine does. Not too old, not too bleeding edge.

[dharmab]

> And I need a tool chain for inspecting a sick container trying to figure out why CPU jumped 25% for no apparent reason.

You can attach a debugging container with your tools temporarily: https://kubernetes.io/docs/concepts/workloads/pods/ephemeral...