3 ms·

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 p

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.

jacques_chester 7y ago
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.
- cpitman 7y ago
  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...
  - jacques_chester 7y ago
    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.
paxys 7y ago
A standardization for base images, OS etc. is just something that has to be enforced at the organization level.
- wmf 7y ago
  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.
  - cpitman 7y ago
    If you are using public images, then you are already giving up on optimizing image sizes anyways.
    - wmf 7y ago
      But if you are making a public image you are doing your users a favor by minimizing the size.
  - paxys 7y ago
    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.

jacques_chester 7y ago

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.

cpitman 7y ago
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...
- jacques_chester 7y ago
  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.

paxys 7y ago

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

wmf 7y ago
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.
- cpitman 7y ago
  If you are using public images, then you are already giving up on optimizing image sizes anyways.
  - wmf 7y ago
    But if you are making a public image you are doing your users a favor by minimizing the size.
- paxys 7y ago
  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.