4 ms·

I said "built containers." Not rented a VM which happens to be run atop container-style virt. Since Docker is positioned toward the former, not the latter, but

I said "built containers." Not rented a VM which happens to be run atop container-style virt. Since Docker is positioned toward the former, not the latter, but due to your company origins and history ends up looking like the latter, thereby training a generation of developers that /etc/hosts and shells belong in production artifact containers, my anger is correctly placed. 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.

justincormack 11y ago
Almost no containers have /sbin/init in. An alpine container has little in it. But C applications do generally require some files, eg config. Docker does encourage people to put as little as possible in, but alas there are still people who shell out as they do not have libraries do do what they need yet... including Java programmers. Disclaimer: I work at Docker on unikernels. You might like this approach to containers.
- jsmthrowaway 11y ago
  You don't even need unikernels, and as much as I loathe myself for saying it, I find myself agreeing with a few of Cantrill's points regarding unikernels in prod. Not all of them, and I think it's worth exploring, but there's a spectrum here: on one end, unikernel app containers, and on the other full jails. The Google approach with minimal containers that still act Unixy and Posixy but carry very little distribution overhead is somewhere around 0.1 on the spectrum. 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.)

justincormack 11y ago

Almost no containers have /sbin/init in. An alpine container has little in it. But C applications do generally require some files, eg config. Docker does encourage people to put as little as possible in, but alas there are still people who shell out as they do not have libraries do do what they need yet... including Java programmers. Disclaimer: I work at Docker on unikernels. You might like this approach to containers.

jsmthrowaway 11y ago
You don't even need unikernels, and as much as I loathe myself for saying it, I find myself agreeing with a few of Cantrill's points regarding unikernels in prod. Not all of them, and I think it's worth exploring, but there's a spectrum here: on one end, unikernel app containers, and on the other full jails. The Google approach with minimal containers that still act Unixy and Posixy but carry very little distribution overhead is somewhere around 0.1 on the spectrum. 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.)