The docker registry is bursting at the seams. At the time of this writing, a search for "node" gets just under 1000 hits. How does one choose?

What constitutes a good docker image?

This is a subjective matter, but I have some criteria for a docker image that I consider good:

  • working. Some examples:

    • an Android SDK image should be able to compile a project without first applying updates to the container.
    • a MySQL container should expose a way to bootstrap the server with a database and user.
  • minimal. The beauty of containers is the ability to sandbox an application (if not for security, then to avoid clutter on the host file system). Whereas I could install node.js on my host system or pollute it with a Java Development Kit, I would rather pay a slight premium in disk space or performance to keep them cordoned off from the rest of my files. With that said, it is obviously preferable that these penalties be as small as possible. The docker image should serve its purpose, having exactly what's necessary for it to function but nothing else. Following this principle, the image is more extensible and has fewer things that can break.

  • whitebox. In the case of docker images, this means having a published Dockerfile. That way I can evaluate what went into creating the image and tinker with it if I want to.

Unfortunately the docker registry does not make it easy to discover "good" images or even to judge any particular image. It's often a matter of docker pull <...> and then wondering why the 10 megabyte node binary needs 10 file system layers and, ultimately, a 700 megabyte virtual environment.

Building good docker images

Because there is no consensus on "good" docker images, and because the barrier to entry for adding images to the docker registry is very low, the situation is straight out of xkcd #927: everybody just does his or her own thing. The introduction of "official" language-specific docker development environments is a good start. I was happy to see that some of my pet practices (listed below) showed up in those images. However, the "thousand node images" situation probably won't improve much until the docker registry works on its discovery and evaluation mechanisms.

With that said, here are the Dockerfile practices which I've settled on as best. I am no expert (I don't think anybody is at this early point in docker's lifetime), so discussion and feedback are welcome.

  • Base images off of debian

    At the time of this writing, ubuntu:14.04 is 195 MB while debian:wheezy is 85 MB, but the extra hundred megabytes of Ubuntu doesn't buy you anything of value (that I'm aware of). In some extreme cases, it may even be possible to base your image off of 2 MB busybox. This is probably only practical with a statically linked binary. An example of a busybox-based docker image is progrium/logspout (link) which clocks in at a respectable 14 MB.

  • Don't install build tools without good reason

    Build tools take up a lot of space, and building from source is often slow. If you're just installing somebody else's software, it's usually not necessary to build from source and it should be avoided. For instance, it is not necessary to install python, gcc, etc. to get the latest version of node.js up and running on a Debian host. There is a binary tarball available on the node.js downloads page. Similarly, redis can be installed through the package manager.

    There are at least a few good reasons to have build tools:

    • 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.

    In the second case, think really hard about whether you should be doing that. In the third case, I suggest installing the build tools in another "npm installer" image, based on the minimal node.js image.

  • Don't leave temporary files lying around

    The following Dockerfile results in an image size of 109 MB:

    FROM debian:wheezy
    RUN apt-get update && apt-get install -y wget
    RUN wget http://cachefly.cachefly.net/10mb.test
    RUN rm 10mb.test

    On the other hand, this seemingly-equivalent Dockerfile results in an image size of 99 MB:

    FROM debian:wheezy
    RUN apt-get update && apt-get install -y wget
    RUN wget http://cachefly.cachefly.net/10mb.test && rm 10mb.test

    Thus it seems that if you leave a file on disk between steps in your Dockerfile, the space will not be reclaimed when you delete the file. It is also often possible to avoid a temporary file entirely, just piping output between commands. For instance,

    wget -O - http://nodejs.org/dist/v0.10.32/node-v0.10.32-linux-x64.tar.gz | tar zxf -

    will extract the tarball without putting it on the file system.

  • Clean up after the package manager

    If you run apt-get update in setting up your container, it populates /var/lib/apt/lists/ with data that's not needed once the image is finalized. You can safely clear out that directory to save a few megabytes.

    This Dockerfile generates a 99 MB image:

    FROM debian:wheezy
    RUN apt-get update && apt-get install -y wget

    while this one generates a 90 MB image:

    FROM debian:wheezy
    RUN apt-get update && apt-get install -y wget && rm -rf /var/lib/apt/lists/*
  • Pin package versions

    While a docker image is immutable (and that's great), a Dockerfile is not guaranteed to produce the same output when run at different times. The problem, of course, is external state, and we have little control over it. It's best to minimize the impact of external state on your Dockerfile to the extent that it's possible. One simple way to do that is to pin package versions when updating through a package manager. Here's an example of how to do that:

    # apt-get update
    # apt-cache showpkg redis-server
    Package: redis-server
    Versions:
    2:2.4.14-1
    ... # apt-get install redis-server=2:2.4.14-1

    We can hope, but there is no guarantee, that the package repositories will still serve this version a year from now. However, it's undeniably valuable to explicitly show what version of the software your image depends on.

  • Combine commands

    If you have a sequence of related commands, it is best to chain them into one RUN command. This makes for a more meaningful build cache (logically grouped steps are lumped into one cache step) and keeps the number of file system layers down (I consider this generally desirable but I don't know that it's objectively better).

    Backslashes \ help you out here for readability:

    RUN apt-get update && \
    apt-get install -y \
    wget=1.13.4-3+deb7u1 \
    ca-certificates=20130119 \
    ...
  • Use environment variables to avoid repeating yourself

    This is a trick I picked up from reading the Dockerfile (link) of the "official" node.js docker image. As an aside, thisDockerfile is great. My only criticism is that it sits on top of a huge buildpack-deps (link) image, with all sorts of things I don't want or need.

    You can define environment variables with ENV and then reference them in subsequent RUN commands. Below, I've paraphrased an excerpt from the linked Dockerfile:

    ENV NODE_VERSION 0.10.32
    
    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"

This article is being discussed further in this Hacker News post.

转自http://jonathan.bergknoff.com/journal/building-good-docker-images

Building good docker images的更多相关文章

  1. Error when Building GPU docker image for caffe: Unsupported gpu architecture 'compute_60'

    issue: Error when Building GPU docker image for caffe: Unsupported gpu architecture 'compute_60' rea ...

  2. 在Linux和Windows的Docker容器中运行ASP.NET Core

    (此文章同时发表在本人微信公众号"dotNET每日精华文章",欢迎右边二维码来关注.) 译者序:其实过去这周我都在研究这方面的内容,结果周末有事没有来得及总结为文章,Scott H ...

  3. Docker Resources

    Menu Main Resources Books Websites Documents Archives Community Blogs Personal Blogs Videos Related ...

  4. Docker容器中运行ASP.NET Core

    在Linux和Windows的Docker容器中运行ASP.NET Core 译者序:其实过去这周我都在研究这方面的内容,结果周末有事没有来得及总结为文章,Scott Hanselman就捷足先登了. ...

  5. 为Go程序创建最小的Docker Image

    本文将会介绍如何使用docker打包一个golang编写的应用程序,最终的产物就是一个makefile文件,可别小瞧这短短几行代码,涉及的知识点可不少,接下来我们就仔细剖析一下吧. FROM gola ...

  6. kubernetes 实战6_命令_Share Process Namespace between Containers in a Pod&Translate a Docker Compose File to Kubernetes Resources

    Share Process Namespace between Containers in a Pod how to configure process namespace sharing for a ...

  7. Docker容器学习与分享10

    Docker容器向外提供服务 用分享04中的Nginx服务来试一下. 不过这次我直接用Nginx镜像创建容器,先下载Nginx镜像. [root@promote ~]# docker search n ...

  8. Docker的基本使用(部署python项目)

    今天开始利用docker来部署项目,当然,首先,需要安装好Docker,这个在我的上篇中写了 一.准备项目 我写的是一个爬取某ppt网站的代码,就一个ppt1.py是爬虫,然后,ppts是存放下载的p ...

  9. AspNetCore容器化(Docker)部署(一) —— 入门

    一.docker注册安装 Windows Docker Desktop https://www.docker.com/products/docker-desktop Linux Docker CE h ...

随机推荐

  1. 黑马----JAVA迭代器详解

    JAVA迭代器详解 1.Interable.Iterator和ListIterator 1)迭代器生成接口Interable,用于生成一个具体迭代器 public interface Iterable ...

  2. oracle实现split函数功能

    转载: http://blog.csdn.net/jojo52013145/article/details/6758279在实际的应用中,为了让PL/SQL 函数返回数据的多个行,必须通过返回一个 R ...

  3. Android中proc/meminfo的详解(原)

    今天在写到获取手机可用内存空间的总大小的时候,通过下面的方法去获取的时候,发现该方法最低支持的版本是16,这显然是不可取的. public static long getTotalSpace(Cont ...

  4. 深入解析Javascript中this关键字的使用

    深入解析Javascript中面向对象编程中的this关键字 在Javascript中this关键字代表函数运行时,自动生成的一个内部对象,只能在函数内部使用.比如: function TestFun ...

  5. svn客户端命令

    记几个常用的命令. 首次拉仓库时,先要进行检出(url可以带端口号): svn checkout http://svn.example.com:9834/repos svn checkout file ...

  6. linux命令行将已有项目提交到github

    之前用git是在windows下用git的图形化界面进行操作的,这次有一个写了几天的小项目想提交到git上,linux命令行下面没有图形化的界面,所以全部需要git命令来操作. 实践之后,主要是下面几 ...

  7. The long way

    转眼毕业一年多了,经历的好复杂,从PHP转到了C++,回到了老本行. 虽然PHPDE各种框架已经很熟了,但是仍然感觉这不是我想要的. 回到C++,才发现这才是自己的方向,心也跟着静了下来. 但是莫名的 ...

  8. matlab列优先与高维矩阵重构 及 CNN 逐层可视化 on Matlab

    由于matlab在列化a(:)以及reshape(a)等操作中是列优先的,所以要重构出新的高维度矩阵,通常要把reshape和permute结合起来使用. 先到 http://caffe.berkel ...

  9. C#产生不重复随机数

    static int GetRandomSeed( ) { byte[] bytes = new byte[4]; System.Security.Cryptography.RNGCryptoServ ...

  10. java hook

    linux下 hook的触发,需要 发送信号为15. 后续补充具体内容.