> Nobody who built containers before Docker came along shipped an operating system in the image. Now we have gigabytes of Ubuntu alongside nginx thanks to Docker. Cool.
First: I believe shipping the entire distro in each container was in fact the most common use of containers before Docker, since openvz/vserver/lxc were focused on "mini-servers" (to this day you can still rent openvz-based vps). So I think your statement is incorrect.
I also think your (eternal?) anger might be misplaced. Yes, today most people who use Docker build containers with unnecessary distro bits in them. But before Docker, 99% of them didn't build containers at all, and struggled with non-repeatable deployments and dependency hell. Even better, now all these people use a standardized Dockerfile which can be changed and improved over time - for example to move away from a heavyweight distro like fedora or ubuntu, to something like alpine or even more minimalistic.
Incidentay, we have hired Natanael Copa, the awesome creator of Alpine Linux and are in the process of switching the Docker official image library from ubuntu to Alpine. You can help us with pull requests to https://github.com/docker-library if you want :)
Even one such pull request could go a long way to promoting smaller containers, since those images have been downloaded over half a billion times.
>... to move away from a heavyweight distro like fedora or ubuntu, to something like alpine or even more minimalistic.
The distro package management is one of the biggest reasons why people still stick with heavyweight distros like Ubuntu.
This is why DockerSlim  was created (at one of the Docker hack days, by the way :-)) It lets you use heavyweight distros as-is eliminating everything you don't need. You get the best of both worlds where you don't have to change your process and you still get small images (7, 10, 20 and even 30 times smaller than the original).
 - http://dockersl.im
It is safe for use in production :)
And if you are using 3rd party Docker images Alpine won't help :)
Docker has regressed the container term completely and irreversibly. I'm glad you're switching to Alpine (and kudos on spinning a negative comment like a top), but you skipped over that I said static builds, as in: the container doesn't carry hundreds of files to support a full Linux distribution with the weight of legacy support atop it. A container should be one binary. Dependencies are one thing, and yes, they often have to ship in the image. I don't find /sbin/init or /etc/nsswitch.conf when I open up JARs built by the average CI, though, so what the hell are they doing in Docker containers? Now the term is so blown out that my comment alone is probably causing crossed eyes and tilted heads among readers, because nobody really knows what a container is any more.
You know this opinion exists, too, because certain folks have reminded you numerous times in the political theater that containerization has become behind the scenes. Also largely thanks to Docker. (Not solely. Largely.)
`FROM scratch` should have been the default. Come on. You know it just as much as I do, Solomon. Imagine if you had shipped a build chain to automate the same dependency work that Google did to build containers, instead of just dumping ubuntu-minimal into a container so dynamic linking and such works and finally trapping us in a hell where Alpine is seen as better.
Disclaimer: I work at Docker on unikernels. You might like this approach to containers.
But we call [0.0, 1.0] the same thing now, so the tooling has to support all cases, and now just pulling a Docker image down might cost me gigabytes of network transfer that I don't need to spend. Combined with the HTTP-strong architecture, Docker encourages fat containers but then falls apart on them at higher sizes because of the HTTP mechanics.
Example: I need to ship about 1 TB of static data alongside my app in a separate container. Try that in Docker. The answer will invariably be Docker not being designed for that, but I thought Docker encouraged the jail-style fat container case? What happens when the jail you're renting out because that's a container too actually uses a bunch of space and you try to `docker commit` into whatever you're managing your containers?
You shouldn't be using containers for that, but features of Docker encourage it, and thinking fat like that has numerous pitfalls. (My example is borne from reality: I watched Docker wash out from a team in two days once they tried to commit a 100+ GB container. I assume the docs guided them there.)
And many folks don't, because the amount of unreadability from having to concat 20 statements in a && fashion to cut down layer size gets out of hand. This leads to folks then having to use scripts to clean the layers, which leads to reuse in things like Packer, which leads to even more problems when the base image changes culturally.
I'd also argue the that it's a matter of familiarity. Every time we change the base image culturally, we have to retool for a different method of making the things in it (apt/dnf/yum -> apk), so while large distro images are bad, they're familiar and predictable (with a mature package set and releases) to what we're used to doing on servers.
Or folks use another tool to abstract that (like Ansible or Chef), which brings us right back to not using Dockerfile.