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

11–20 of 70 posts

Re: Building Good Docker Images

#11

Post by bradleyland »

Curious if the sizes quoted Debian netinst vs Ubuntu server, or a standard Debian install vs Ubuntu server? We base all our installs (regular VMs, not Docker) off of Debian netinst because we get to choose exactly what goes on to the server.

Re: Building Good Docker Images

#13

Post by pmahoney »

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…

> how you do we (container creators) know the dependency tree for the app

Nix package manager [1] offers a potential means to know the complete dependency tree. If you're not familiar, a nix expression to build a package takes a set of inputs (specific binary packages of, e.g., make, gcc, bash, libc, libxml2) and produces a binary output (depending only on the inputs). The run-time dependencies can be a smaller set than the build-time dependencies and are deduced by observing shared library linking for example.

I've been using it (outside Docker) for various Ruby apps, and I can't say it's been easy, but a large part of the pain has been Rubygems' inability to encode dependencies on C-libraries (e.g. libxml-ruby depends on libxml2).

There have been attempts at provisioning Docker containers with Nix [2]

Of course, if you are using Nix, some part of Docker's isolation becomes redundant (Nix isolates multiple version of things on the filesystem using plain-old-directories, so it's trivial to run ten different versions of Ruby side-by-side, for example).

[1] http://nixos.org/nix/ [2] http://zef.me/6049/nix-docker/

Re: Building Good Docker Images

#14

Post by esteth »

labianchin wrote: post #10
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…

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

You might want to look into nix and nix-docker.

Nix is a package management system which knows the full (yes completely full) transitive dependency tree of every package it installs, so you can have an absolutely minimal set of software in your container if you use nix-docker.

Because it's already doing version isolation in the package manager, you can also mount the software from the host into a shim container, which is more the "nix way" of doing things.

Re: Building Good Docker Images

#16

Post by zokier »

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 issues I propose two-phased building of Docker image. First you setup a regular Docker image based on Debian or whatnot which contains all the tools you need to build/setup the application. Then inside that container you build the final image based on empty image (eg http://docs.docker.com/articles/baseimages/#creating-a-simpl... ), adding only the files that are really needed at runtime.

Re: Building Good Docker Images

#18

Post by jared314 »

zokier wrote: 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…

I propose a third layer: Integration with an application checkpoint library, like CRIU[1], to snapshot the running container. CRIU already supports snapshots of docker containers[2], just not correctly restoring them.

[1] http://criu.org/

[2] http://criu.org/Docker

Re: Building Good Docker Images

#19

Post by 23david »

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/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

Re: Building Good Docker Images

#20

Post by 23david »

banmeagainplz wrote: post #15

This patch is essential for creating minimal, best images with Docker. https://github.com/docker/docker/pull/8021

I hope nested build functionality get merged soon. From reading the last proposal minutes, I wasn't sure if it's been shelved for later?

https://github.com/docker/irc-minutes/blob/master/docker-dev...

It'll replace a bunch of unnecessary shell scripts that are currently required to get similar functionality working.

Post reply on HN