docker好文，短小精炼。水平有限，请不吝指教。
原文
http://developerblog.redhat.com/2016/02/24/10-things-to-avoid-in-docker-containers/
翻译正文
ps：为了保证一致性，文中的容器即container，是docker container的简称。
最终，你选择了容器技术并且发现它解决了很多问题并且有着很多的优点：
1. 第一：不可变更－因为OS，库文件，配置参数，文件夹，应用等都包含在容器中，所以只要你保证你生产环境中使用的是和QA一样的镜像，那么它的行为就一定是一样的。
2. 第二：轻量级－容器的内存占用很小。不需要成百上千MB，只需要为主进程分配数十MB的内存就可以。
3. 第三：运行超快－启动容器就像开启一个单进程，不需要几分钟，只要短短几秒就可以完成。
但是很多用户仍然将容器仅仅当作虚拟机使用，而另外的人仅仅知道：容器是一次性的，而忘记了它还有其他很多优点。
关于容器的口头禅：容器是短暂的。
这一特性“本身”迫使用户去改变他们关于如何处理和管理容器的想法。而我也将阐述为了获取最佳性能而需要避免做的事情：
1）不要在容器中存储数据－容器可以被停止，销毁，或者替换。一个1.0版的应用应该很容易的就被替换成1.1而不应有任何影响和数据丢失。基于这个原因，如果你需要存储数据，把它存储在宿主的硬盘上，但是要避免两个容器同时写数据，造成数据异常，确保你的应用是将数据写到共享的数据路径的。
2）不要把你的应用分成两部分－因为很多人把容器当虚拟机使用，所以他们的做法是部署应用到已经在运行的容器中。也许开发中确实如此，因为你要不间断的部署和调试，但是在正式的QA和生产环节流程中，你的应用应该是容器的一部分。请记住：容器应该是不可变更的。
3）不要创建过大的镜像－镜像过大不易分发。请确认你只包含了必要的文件和库，不要包含不必要的开发包，也不要在容器运行时运行"updates"(yum update)。
4）不要使用单层的镜像－合理的使用分层的文件系统，OS是一层，安全和用户定义组件是一层，库文件是一层，配置文件是一层，最后是你的应用独立为一层。这样将使镜像的重建和管理变的容易同时易于分发。
译者：这里的层指得是"layer"，关于什么是"layer"，请参见docker中的”layers”指的是什么东西
5）不要从运行的容器中创建镜像－换个说法，不要用"docker commit"去创建镜像。这样创建的镜像不可准确重建和版本化管理，应该彻底避免。要使用Dockerfile或者其他可重建的S2I(source to image)方式。
6）不要只使用最新标签的版本－最新的标签就想maven中的"SNAPSHOT"。应该使用特定的标签的版本。我想你应该不想在你2个月后重新编译镜像时，收到惊奇，发现你的应用不能运行是因为顶层的layer使用了新的版本，没有向前兼容或者最新的版本是有问题的。当部署容器到生产环境时也要避免使用新的版本。
7）不要在一个容器中运行多于1个的进程－容积最好是运行单一的进程（http守护进程，应用服务器，数据库）。当你运行多个时，你将会遇到要单独管理，处理日志，以及更新的困难。
8）不要存储身份数据到镜像中，尽量使用环境变量－你应该不希望直接存储你的用户名，密码到镜像中。所以使用容器外的环境变量去获取相关的信息，一个较好的例子是postres image。
9）请使用非root权限运行进程－“docker默认是以root身份运行的。当docker运行时，将会获取到默认的安全选项。而被他人获取root是危险的，并且也不是所有环境都支持的。你的镜像应该使用 USER 指令去指定一个非root用户来运行容器”（摘自Guidance for Docker image Authors）。
10）不要依赖特定的IP－每一个容器都有它们自己的内部ip，而且这个ip可能在开启或者停止时变化。假如你的应用或者微服务需要和其他的容器通讯，请使用名称或者环境变量去传递相关的信息。
更多关于容器的信息请参见：http://developers.redhat.com/containers/