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