Hacker News Reader

Comment by paxys | Hacker News Reader

While such articles are usually helpful, I'd caution that making individual image sizes as small as possible shouldn't really be your goal.

As a simple example - if you have 100 unique images in your system, having an image size of 1 GB each where 99% of it is derived from a common layer is going to be a lot smaller overall than "optimizing" the size down to 100 MB each but taking away the base layers.

View on HN

In my experience you 100 unique images might still have different base images. So you end up with too many layers. Especially with interpreted languages those python, ruby or node runtimes add up quickly

Also depending on usecase (e.g running a CI system) you might end up with high storage costs (caching) or high bandwidth costs (no caching)

Depending where your datacenter is, coworkers with slow connections might suffer as well. Hey, let’s just download 12GB of my everylanguage-and-Tex:latest every workday.

But I agree, docker golfing to have minimal images is not always needed, but don’t let your images grow like a wildfire. They are part of your architecture.

A standardization for base images, OS etc. is just something that has to be enforced at the organization level.

But if you do that you're giving up all public images. It makes sense in a large organization but there are plenty of other use cases for Docker.

You don't have to give up public images. Here's a simple example rule - production images should all be built on Ubuntu:18.04. (With a large enough maintenance team this can change to - you must use one of these 8 images with the standard runtime stacks preconfigured).

Teams still have the flexibility of using whatever they want during the build stage, and it takes away the ambiguity of them having to decide between different OS flavors, versions, slim/Alpine, building from scratch or whatever else. In 99% of cases there will be no functional difference between them anyways, and this rule reduces the overhead of having to track down and manage an infinite number of permutations from an operations side.

If you are using public images, then you are already giving up on optimizing image sizes anyways.

But if you are making a public image you are doing your users a favor by minimizing the size.

Using a trendy small base image doesn't make the intermediate layers any smaller.

What you're describing is what cloud native buildpacks are intended to solve: sensible, efficient, auto-updateable OCI images. I worked on them for a while and it just hardened my heart against Dockerfiles.

It's starting to feel like this is a lost battle though. People have decided that Dockerfiles are "the kubernetes way", even though it exposes developers to details they just shouldn't need to care about.

Add anything on top, and it is no longer "vanilla kubernetes". Never mind that means everyone roles their own Rube Goldberg build process, and somehow that is ok...

I don't feel like it's a lost battle at all. Folks are fanning out and learning that all of this is harder than it looks, with the exception of enterprise, where it's harder than it looks squared.

I suspect folks will become attracted to the simplicity and performance of buildpacks. They make whole classes of headache vanish.

I guess on this one I'm optimistic.

Almost every CI setup completely breaks that assumption since layers are not cached efficiently among job runners.

Reply on news.ycombinator.com