Live data from Hacker News

Building Good Docker Images

jonathan.bergknoff.com

31–40 of 70 posts

Re: Building Good Docker Images

#31
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.

Depends on which Debian I believe, but Ubuntu doesn't update their package versions beyond security fixes within a single distro version.

So you'll generally want those fixes, unless they really broke something, which I'd guess would be somewhat rare.

Re: Building Good Docker Images

#32
post #19

One additional tip for readability is to replace the && with set -e at the top of any RUN commands that combine more than one command. before: RUN curl -SLO "http://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-x64.tar.gz" \ && tar -xzf "node-v$NODE_VERSION-linux-x64.tar.gz" -C /usr/local --strip-components=1 \ && rm "node-v$NODE_VERSION-linux-x64.tar.gz" after: RUN set -e; \ curl -SLO "http://nodejs.org/d…

Hmm, needs additional semi-colons.

Re: Building Good Docker Images

#33
post #21

The author mentions a good image is a "whitebox" if it publishes its Dockerfile on the Hub. Unfortunately this isn't really enough; many (even most) Dockerfiles depend on scripts and data files which aren't hosted on the Hub. I would suggest the only truly whitebox images are the ones that can be recreated from github (or similar) repositories.

You're right that a published Dockerfile isn't enough to really know what went into the image, but I think it's the closest thing we have at the moment. I would love to see some tools for building truly minimal docker images from scratch.

Re: Building Good Docker Images

#34

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…

Perhaps I'm missing something, but I don't see how [1] can be used to create "single binary containers with the minimal OS bits needed"? It is from https://registry.hub.docker.com/u/google/nodejs/dockerfile/ and uses the full Debian stack that you discuss including apt-get etc.

I've heard whisperings on the wind of research being done with respect to monitoring what files a Docker container uses, and then removing everything that the container doesn't need to run the app. I agree that this is the future- I shouldn't have apt-get, curl, etc. taking up space in my final image if I don't need them - but how do you tell a "good" file from a "bad" one? (Just thinking out loud here - what if my app depends on imagemagick, libffmpeg etc.?) Nix looks pretty cool I suppose.

Re: Building Good Docker Images

#35
Docker images are like if some high school kids decided to sell mass-produced beer. Instead of writing down a recipe with the ingredients, measurements, temperatures, elevation, times, and distributor-sourced quality-assured materials, the kids go to random stores and buy whatever they think they need to make beer in huuuuge quantities. They make huge batches of beer so that they won't need to make it again for months or years. Then the next time they brew a batch, the beer tastes completely different, they say, "Oh, we might need to write some of this stuff down, and make sure it was the same as last time."

Re: Building Good Docker Images

#36
post #16

This gave me an (probably non-novel) idea: "double-layered" Docker image creation. One thing that rubs me the wrong way is how Docker images contain stuff like apt (and all the related supporting stuff) when they don't really need them (at runtime). On the other hand you need to install/compile/setup the environment somewhere, and relying on the host system would break any hopes of reproducibility. To reconcile these…

The problem with this is when you introduce applications with arbitrary dependencies. If your language can spit out a binary which is truly statically compiled, like Go, a Makefile or simple shell script such as https://github.com/nathanleclaire/sfserver/blob/master/build... will do you just fine, but if your app is Ruby or Javascript, requires dynamic linking, etc. the task just got a lot harder.

I'd love to see more research in the area.

Re: Building Good Docker Images

#38

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…

Perhaps I'm missing something, but I don't see how [1] can be used to create "single binary containers with the minimal OS bits needed"? It is from https://registry.hub.docker.com/u/google/nodejs/dockerfile/ and uses the full Debian stack that you discuss including apt-get etc. I've heard whisperings on the wind of research being done with respect to monitoring what files a Docker container uses, and then removing ev…

[deleted]

Re: Building Good Docker Images

#39
I think this is a case where gentoo can really shine. Although tooling might not be there just yet, the linux meta distribution allows you to build a strict set of dependencies based on what you need and nothing else. There's already been pretty successful attempts at this, such as https://github.com/edannenberg/gentoo-bb (63mb custom nginx sound ok to you?) or https://github.com/wking/dockerfile.

edit: To elaborate for people not very familiar with gentoo; it solves what a lot of the discussion in this thread seems to be about - having complete control of the dependency chain based on how you choose to build your software. Using nginx as an example, enabling mod_security would pull and build its own dependencies (which also can be limited based on its compiler options). Strip man pages? Done. Change libc library? No problem (if the packages support it).

The work that needs to be done is expanding the toolset to a point where you say "I want this in docker, plx" and anything else (dependencies disregarded) basically goes out the window. The current attempts builds upon a small set of packages for convenience then removes "safe" stuff. When time allows, I'd like to be much more aggressive in terms of what's considered safe. :edit

I'm personally also very interested in progrium's work with bundling busybox with opkg (https://github.com/progrium/busybox), but still think that docker containers should not be built from within - which why cross compiling from gentoo to create a minimal docker image is the way to go.

Re: Building Good Docker Images

#40

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…

Perhaps I'm missing something, but I don't see how [1] can be used to create "single binary containers with the minimal OS bits needed"? It is from https://registry.hub.docker.com/u/google/nodejs/dockerfile/ and uses the full Debian stack that you discuss including apt-get etc. I've heard whisperings on the wind of research being done with respect to monitoring what files a Docker container uses, and then removing ev…

I wrote https://github.com/jwilder/docker-squash to remove things that I know I don't need in the final image such as curl, wget, temp files, various packages, etc..

I've managed to get most images to basically the size of the base image + my app.

This process is sort of the reverse of building a single binary and adding it to a minimal image. I like that approach but it's not always straightforward w/ some applications.

Post reply on HN