Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building Good Docker Images

jonathan.bergknoff.com

Post reply on HN
Print view View original

41–50 of 70 posts

Re: Building Good Docker Images

#41

Post by thockingoog »

WestCoastJustin wrote: post #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, w…

There's another gotcha in super-small images - things like "docker exec" will not work because there's nothing to exec. SSH-to-container becomes impossible.

I think there's got to be a middle-ground - small (maybe O(tens of MB) max) but full-featured enough to have a simple shell and the ability to get debug tools.

How small of a debian or fedora image could we get if we REALLY tried? 50 MB? 30 MB?

Re: Building Good Docker Images

#42

Post by WestCoastJustin »

thockingoog wrote: post #41
WestCoastJustin wrote: post #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, w…

There's another gotcha in super-small images - things like "docker exec" will not work because there's nothing to exec. SSH-to-container becomes impossible. I think there's got to be a middle-ground - small (maybe O(tens of MB) max) but full-featured enough to have a simple shell and the ability to get debug tools. How small of a debian or fedora image could we get if we REALLY tried? 50 MB? 30 MB?

I thought there was a way to enter a namespace (googled this as I write the comment). Basically you have your shell and debug bits outside the container and make it appear as if it was inside it via nsenter [1]. I have not tested this, but will do that in a second. This might correct the situation you are thinking of.

    +--------------------+
    | docker container   |
    |  w/ static bin     |
    |
[1] http://www.kevssite.com/2014/08/05/console-access-into-a-run...

Re: Building Good Docker Images

#43

Post by mnarayan01 »

23david wrote: 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…

Why?

Re: Building Good Docker Images

#44

Post by ajdecon »

I really think there are no good reasons to include build tools in a docker image. The author lists three possible reasons:

- you need a specific version (e.g. redis is pretty old in the Debian repositories).

- you need to compile with specific options.

- you will need to npm install (or equivalent) some modules which compile to binary.

But you can avoid all of these by building your own DEB/RPM packages and installing those into the container.

This might make the container less "whitebox", in that the Dockerfile no longer contains the full steps to reproduce the built image from public sources. But having an internal package repository makes a lot of sense, and not just for building small Docker images. Keeping your own package repository helps make your server builds more reproducible in general, and provides clean mechanisms for performing updates on your own software as well as third-party packages.

(edited for formatting)

Re: Building Good Docker Images

#45

Post by deeviant »

Is minimizing the size of a docker image really the top priority?

I would hold that making docker images easy to use, transparent as possible, reliable, versatile and easy to use (did I mention that already? oops) are far more important priorities.

Admittedly, I use docker primarily for development/testing purposes and my use-cases are a bit different than the average production use-case, however, having a large toolbox easily accessible for me to use (yes, including the ability to ssh into the docker container) is invaluable to me.

I may be missing something here, but racing to make docker images "as small as possible" feels like a bit of premature optimisation.

Re: Building Good Docker Images

#46

Post by [deleted] »

zenlikethat wrote: post #34
WestCoastJustin wrote: post #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, 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

#47

Post by 23david »

digisign wrote: post #32
23david wrote: 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.

where?

I was trying to use the example given... Here's another, smaller example:

  # install wget without artifacts
  RUN set -e; \
    apt-get update; \
    apt-get install -y wget; \
    apt-get clean; \
    rm -rf /var/lib/apt/lists/*

Re: Building Good Docker Images

#48

Post by WestCoastJustin »

zenlikethat wrote: post #34
WestCoastJustin wrote: post #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, 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…

Sorry, here's the one I was thinking of: https://registry.hub.docker.com/u/google/cadvisor/ However, I just broke apart that image, and it is using busybox. I swear this was standalone though. I'm going to dig through the layers to see if/when this changed.

Re: Building Good Docker Images

#49

Post by e12e »

23david wrote: post #47
digisign wrote: post #32

Earlier quoted context omitted.

Hmm, needs additional semi-colons.

where? I was trying to use the example given... Here's another, smaller example: # install wget without artifacts RUN set -e; \ apt-get update; \ apt-get install -y wget; \ apt-get clean; \ rm -rf /var/lib/apt/lists/*

I think parent meant you trade two &&s for one ;.

Personally I also don't think the meaning is as clear, and you now need to maintain the top line if you cut'n'paste. I suppose it's a matter of taste.

Re: Building Good Docker Images

#50

Post by aye »

ajdecon wrote: post #44

I really think there are no good reasons to include build tools in a docker image. The author lists three possible reasons: - you need a specific version (e.g. redis is pretty old in the Debian repositories). - you need to compile with specific options. - you will need to npm install (or equivalent) some modules which compile to binary. But you can avoid all of these by building your own DEB/RPM packages and installi…

I wish I could upvote this a few times.
Post reply on HN