Building good docker images

本文涉及的产品
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
简介:

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"
    
    本文转自feisky博客园博客,原文链接:http://www.cnblogs.com/feisky/p/4062983.html,如需转载请自行联系原作者
    
相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore &nbsp; &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
1月前
|
缓存 测试技术 持续交付
docker desktop 搜索不到images
【2月更文挑战第23天】
181 0
|
3月前
|
Docker 容器
Docker-删除untagged docker images
Docker-删除untagged docker images
35 0
|
9月前
|
Docker 容器
25-Docker-常用命令详解-docker images
25-Docker-常用命令详解-docker images
|
10月前
|
Docker 容器
docker中命令docker images
docker中命令docker images
|
11月前
|
Docker 容器
Docker Review - docker images 常用命令
Docker Review - docker images 常用命令
51 0
|
Docker 容器
Docker(7)- docker images 命令详解
Docker(7)- docker images 命令详解
164 0
Docker(7)- docker images 命令详解
|
Docker 容器
删除docker images的正确姿势
删除docker images的正确姿势
|
Ubuntu Linux 应用服务中间件
|
Ubuntu Docker 容器
Docker images
Docker   images   介绍:      docker  images 是docker 的三大组件之一   docker把下载好的镜像上传到docker本地镜像仓库中,如果本地镜像仓库中不存在需要用到的镜像,docker会从一个镜像库中去下载所需镜像,默认的公共仓库是Docker HUB。
2010 0