经验之谈:八种Docker容器开发模式

4. The Test In A Different Environment containers

　　我喜欢Docker的一个原因，是它可以让我在不同的环境中测试我的代码。例如，当我升级Ruby编译器到1.9时，我可以生成一个Dockerfile，派生一个1.8的环境。

FROM vidarh/devbase
RUN apt-get update
RUN apt-get -y install ruby1.8 git ruby1.8-dev

　　当然你可以用rbenv等达到类似的效果。但我总是觉得这些工具很讨厌，因为我喜欢尽可能多地用distro-packages部署，不仅仅是因为如果这项工作的顺利进行，能使其他人更容易地使用我的代码。

　　当拥有一个Docker容器，我需要一个不同的环境时，我仅需要“docker run”一下，几分钟便能很好的解决这个问题。

　　当然，我也可以使用虚拟机来达到目的，但使用Docker更省时间。

5. The Build Container

　　这些天我写的代码大部分都是解释性语言，但还是有一些代价高昂的“build”步骤，我并不愿意每次都去执行它们。

　　一个例子是为Ruby应用程序运行“bundler”。Bundler 为Rubygems更新被缓存的依赖，并且需要时间来运行一个更大的app。

　　经常需要在应用程序运行时不必要的依赖项。例如安装依赖本地扩展gems的通常还需要很多包——通常没有记录——通过添加所有build-essential和它的依赖项就轻松启动。同时，你可以预先让bundler做所有的工作，我真的不想在主机环境中运行它，因为这可能与我部署的容器不兼容。

　　一个解决方案是创建一个build容器。如果依赖项不同的话，你可以创建分别的Dockerfile，或者你可以重用主app Dockerfile以及重写命令运行你所需的build commands。Dockerfile如下：

FROM myapp
RUN apt-get update
RUN apt-get install -y build-essential [assorted dev packages for libraries]
VOLUME ["/build"]
WORKDIR /build
CMD ["bundler", "install","--path","vendor","--standalone"]

　　然后每当有依赖更新时，都可以运行上面的代码，同时将build/source目录挂载在容器的"/build"路径下。

6. The Installation Container

　　这不是我擅长的，但是真的值得提及。优秀的nsenter和docker-enter工具在安装时有一个选项，对于现在流行的curl | bash模式是一个很大的进步，它通过提供一个Docker容器实现“Build Container”模式。

　　这是Dockerfile的最后部分，下载并构建一个nsenter的合适版本：

ADD installer /installer
CMD /installer

“installer”如下：

#!/bin/sh
if mountpoint -q /target; then
       echo "Installing nsenter to /target"
       cp /nsenter /target
       echo "Installing docker-enter to /target"
       cp /docker-enter /target
else
       echo "/target is not a mountpoint."
       echo "You can either:"
       echo "- re-run this container with -v /usr/local/bin:/target"
       echo "- extract the nsenter binary (located at /nsenter)"
fi

　　虽然可能还有恶意攻击者试图利用容器潜在的特权升级问题，但是attack surface至少显著变小。

　　这种模式能吸引大多数人，是因为这种模式能避免开发人员在安装脚本时偶尔犯的非常危险的错误。

7. The Default-Service-In-A-Box Containers

　　当我认真对待一个app，并且相对快速的准备一个合适的容器来处理数据库等，对于这些项目，我觉得难能可贵的是已经有一系列的“基本的”基础设施容器，只做适当的调整就可以满足我的需求。

　　当然你也可以通过“docker run”得到“主要的”部分，在Docker索引里有诸多替代品，但我喜欢首先检查它们，找出如何处理数据，然后我将修改版本添加到自己的“library”。

　　例如Beanstalkd：

FROM debian:wheezy
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get -q update
RUN apt-get -y install build-essential
ADD <a href="http://github.com/kr/beanstalkd/archive/v1.9.tar.gz">http://github.com/kr/beanstalkd/archive/v1.9.tar.gz</a> /tmp/
RUN cd /tmp && tar zxvf v1.9.tar.gz
RUN cd /tmp/beanstalkd-1.9/ && make
RUN cp /tmp/beanstalkd-1.9/beanstalkd /usr/local/bin/
EXPOSE 11300
CMD ["/usr/local/bin/beanstalkd","-n"]

8. The Infrastructure / Glue Containers

　　许多这些模式专注于开发环境（这意味着有production 环境有待讨论），但有一个大类别缺失：

　　容器其目的是将你的环境组合起来成为一个整体，这是目前为止对我来说有待进一步研究的领域，但我将提到一个特殊的例子：

　　为了轻松地访问我的容器，我有一个小的haproxy容器。我有一个通配符DNS条目指向我的主服务器，和一个iptable入口开放访问我的haproxy容器。Dockerfile没什么特别的：

FROM debian:wheezy
ADD wheezy-backports.list /etc/apt/sources.list.d/
RUN apt-get update
RUN apt-get -y install haproxy
ADD haproxy.cfg /etc/haproxy/haproxy.cfg
CMD ["haproxy", "-db", "-f", "/etc/haproxy/haproxy.cfg"]
EXPOSE 80
EXPOSE 443

　　这里有趣的是haproxy.cfg

backend test
    acl authok http_auth(adminusers)
    http-request auth realm Hokstad if !authok
    server s1 192.168.0.44:8084

　　如果我想要特别一点，我会部署类似 AirBnB's Synapse ，但这已经超出了我的需求。

　　在工作时扩大容器的规模，目的是让部署应用程序简单便捷，就像我正在过渡到一个完整的面向Docker的私有云系统。

原文链接： Eight Docker Development Patterns （编译/魏伟 审校/周小璐）