文档介绍：八种最常见 Docker 开发模式
Docker 已迅速成为本人最喜欢的基础工具之一，以便构建可重复软件 产品，从而带来尽可能静态的服务器环境。
我在本文中将概述我在使用Docker的过程中开始反复出现的几种模 式。我不指望它们会带来多oot
# 针对 Graphivz 整合
RUN apt-get update
RUN apt-get -y install graphviz xsltproc imagemag
ick
USER vidarh
WORKDIR /home/vidarh/src/repos/hokstad-com
ENTRYPOINT bundle exec rackup -p 8080
因为它们从共享软件库获取代码，而且基于共享的基础容器，当我添 加/修改/删除依赖项时，这些容器通常可以极其迅速地重建，我觉得 这很重要，以便确保我没有忍不住采用疏忽未记录依赖项的变通方法 即便如此，肯定有些方面是我想改进的。尽管上述基础容器是轻量级， 但它们肯定不止这样：这些容器中的大多数内容仍然未使用。由于
Docker采用写时拷贝（copy-on-write履盖，这不会导致庞大开销，但
确实仍意味着我并没有真正体现最基本需求，也没有尽可能减少攻击 或出错风险（我倒不是很担心这些特定情况的攻击风险，因为我的博 客并不在“实时”版本中含有任何重要状态。）。
开发工具容器
这对像我们这些喜欢依靠通过ssh连接至屏幕会话来编写代码的人来 说可能最有吸引力，而对IDE人群来说不太有吸引力;但对我来，上述 方案的一个好处就是，它让我可以将编辑和测试执行部分代码与运行 开发中的应用程序分离开来。
过去开发系统方面很烦人的问题之一是，开发及生产依赖项与开发工 具依赖项很容易混在一起。你可以试着将它们分开来，但除非这些设 置真正做到了分离开来，否则很容易建立未记录依赖项。
在过去，我花了几周对应用程序的依赖项进行“反向工程”后，总算 搞清楚了这个问题。由于开发环境、测试和初始原型部署环境混在一 起，这个应用程序积累了各种各样的未记录依赖项。
虽然有很多方法可以解决这个问题：只要确保你进行定期的测试部署， 结合上述模式，但我还是有一种个人很喜欢的解决方案，因为它可以 从根本上防止问题出现：
我有一个单独的容器含有Emacs安装环境，还有我喜欢随时可用的其 他各种工具。我仍试图保持精简，但问题是，我的屏幕会话可以驻留 在这个容器中，结合我那台笔记本电脑上设置的
“autossh”，几乎 总是有一条连接与容器相连，那样我就可以编辑与我的其他开发容器 “实时”共享的代码。
在这个容器，我还允许偶尔出错：直接安装程序包，因为它只影响调 试和开发。
目前，它看起来如下：
FROM vidarh/devbase
RUN apt-get update
RUN apt-get -y install openssh-server emacs23-nox
htop screen
#用于调试
RUN apt-get -y install sudo wget curl telnet tcpd ump
# 针对 32 位试验
RUN apt-get -y install gcc-multilib
#参考手册页和“most”viewer:
RUN apt-get install -y man most
RUN mkdir /var/run/sshd
ENTRYPOINT /usr/sbin/sshd -D
VOLUME ["/home"]
EXPOSE 22
EXPOSE 8080
结合共享“/ home “，这给了我一个足够实用的小地方可以通过ssh
连入。我确信，用它用得越多，我会补充它，但眼下它证明完全能满 足我的需要。
不同环境下测试容器
我特别喜欢Docker的一个方面是，可以在不同环境下轻松测试代码。 比如说，我升级Ruby编译项目以便处理Ruby （早就该有了）后，创 建了这个小小的Docker文件，, 在 Ruby 。
FROM vidarh/devbase
RUN apt-get update
RUN apt-get -y install ruby1 8 git -dev
当然，你可以用rbenv等获得类似的效果。但我总是觉得这些工具很 烦人，因为我更喜欢尽量使用发行版程序包来部署，尤其是由于，如 果我确保这顺利开展，它让其他人更容易使用我的代码。
拥有这样一个 Docker 容器：当我暂时需要不同的环境时，只要运行
“docker run”，圆满地解决了这个问题，而且还有这个好处