buildpack-deps:jessie over debian:jessie

[retrohacker]

What advantage does this offer? From what I can see, most of the packages installed on top of debian:jessie in buildpack-deps:micro and buildpack-deps aren't dependencies of our project.

[retrohacker]

// CC @pesho

[pesho]

@wblankenship That's the difference between the main and the -slim variants. The -slim one is based on debian:jessie, but has to apt-get more stuff. It results in smaller image overall, but creates a larger delta on each build. The buildpack-deps base indeed contains lots of stuff we don't need, but it's a common base for all official docker images, so will probably get pulled in anyway in most deployments.

[retrohacker]

Ah, I see. That does make sense. 😄

[rvagg]

so will probably get pulled in anyway in most deployments

IMO this is a Docker fable, the majority of deployments with Docker are going to be relatively homogeneous

[pesho]

IMO this is a Docker fable, the majority of deployments with Docker are going to be relatively homogeneous

Could be, we can't know for sure. But that's not the only factor. The -slim variant has a pretty big delta over debian:jessie - currently ~250MB. This will be pulled every time the image is updated. The default variant pulls the big buildpack-deps:jessie once, but afterwards each delta is only ~27MB.

It's true that buidpack-deps is unnecessarily big. The best option would probably be to create our own base image on top of debian. Not sure if it's worth the maintenance effort though.

[retrohacker]

The best option would probably be to create our own base image on top of debian

Wouldn't this be no different than what we are doing now, just moving a layer to another image? The only advantage that buildpack-deps:jessie gives is that there is a chance that many images on a host will share that as a common base. Nobody would share our base so I don't see the benefit.

[pesho]

Wouldn't this be no different than what we are doing now, just moving a layer to another image?

Not completely (assuming you mean the -slim variant). If you run apt-get update && apt-get install ... the packages that we need twice in a row, you'll get different layers, with different hashes, even though the packages will be the same. Making that a fixed image would save a lot of useless re-downloading.

But then of course we'd need to maintain that base image, taking care to update it each time there's a security fix in curl/python/git or the debian base... not worth the effort IMO.