Live data from Hacker News

Building Good Docker Images

jonathan.bergknoff.com

1–10 of 70 posts

Re: Building Good Docker Images

#2
Google takes this a step further and creates single binary containers with the minimal OS bits needed [1, 2]. Personally, I think this is where we need to be headed vs running a full blown ubuntu/debian/centos OS inside the container. Three benefits, 1) no OS to manage eg. no apt-get update or configuration management, 2) container has less of an attack surface (think shellshock -- the container does not have bash, wget, curl, etc), 3) they are lightweight. The issue is that, how you do we (container creators) know the dependency tree for the app? Sure this might be easier for Go binaries, but what about complex apps like rails and mysql? It is a major pain to figure this out, so we just use an OS, and it takes all the thinking out of it.

Kelsey Hightower actually published something on this topic called "Building Docker Images for Static Go Binaries" [3].

[1] https://registry.hub.docker.com/u/google/nodejs-hello/

[2] https://github.com/thockin/serve_hostname

[3] https://medium.com/@kelseyhightower/optimizing-docker-images...

Re: Building Good Docker Images

#4
"Pin package versions" -- yes. One of the things that has been bugging me about Docker is that if you begin every Dockerfile with an `apt-get -y update`, you never know what you're going to end up with.

On the other hand, pinning every package that you install would end up being pretty verbose.

Re: Building Good Docker Images

#5
post #4

"Pin package versions" -- yes. One of the things that has been bugging me about Docker is that if you begin every Dockerfile with an `apt-get -y update`, you never know what you're going to end up with. On the other hand, pinning every package that you install would end up being pretty verbose.

Why do an update if you prefer your packages to be pinned?

Re: Building Good Docker Images

#6
post #4

"Pin package versions" -- yes. One of the things that has been bugging me about Docker is that if you begin every Dockerfile with an `apt-get -y update`, you never know what you're going to end up with. On the other hand, pinning every package that you install would end up being pretty verbose.

If you need to pin all your packages then it probably makes more sense to just have your own software package "layer" that imports your pinned base with the packages that are required.

Re: Building Good Docker Images

#7
post #5
post #4

"Pin package versions" -- yes. One of the things that has been bugging me about Docker is that if you begin every Dockerfile with an `apt-get -y update`, you never know what you're going to end up with. On the other hand, pinning every package that you install would end up being pretty verbose.

Why do an update if you prefer your packages to be pinned?

Depending on what your base image is, the pinned versions you want to install may not be available.

Re: Building Good Docker Images

#8
post #4

"Pin package versions" -- yes. One of the things that has been bugging me about Docker is that if you begin every Dockerfile with an `apt-get -y update`, you never know what you're going to end up with. On the other hand, pinning every package that you install would end up being pretty verbose.

If you need to pin all your packages then it probably makes more sense to just have your own software package "layer" that imports your pinned base with the packages that are required.

Many organizations are actually doing this.

Re: Building Good Docker Images

#9
Lately we've been using shell scripts to do a lot of boiler-plate container preparation. We copy that script in and run it at the beginning of the container build. The nice thing about doing things this way is that you keep your Dockerfile a little cleaner, you end up with less layers, and that layer will only rebuild if you change the source file.

Re: Building Good Docker Images

#10

Google takes this a step further and creates single binary containers with the minimal OS bits needed [1, 2]. Personally, I think this is where we need to be headed vs running a full blown ubuntu/debian/centos OS inside the container. Three benefits, 1) no OS to manage eg. no apt-get update or configuration management, 2) container has less of an attack surface (think shellshock -- the container does not have bash, w…

Interesting this approach of building single binary containers.

I think that would be like packr [1] for Java, already discussed here [2]. I wonder if there is something like this for other languages/platforms like python/ruby/node.

[1] https://github.com/libgdx/packr

[2] https://news.ycombinator.com/item?id=7696564

Post reply on HN