Docker容器使用十大注意事项

当下最火爆的Docker，是一个开源的应用容器引擎。大家已经开始认同并接受容器技术，并意识到它能够解决多种现实问题并具备一系列无可比拟的优势。今天小数就和大家聊一聊容器技术的优势和误区，帮助大家更好地理解和使用Docker。

Docker容器的三大优势：

1. 第一：具备恒定特性–操作系统、库版本、配置、文件夹以及应用程序全部涵盖在内。大家可以将质量检查流程中使用的测试镜像原封不动地引入生产环境当中。
2. 第二：具备轻量化特性 – 容器的体积非常小巧。相较于动辄成百上千MB的操作系统，它只需要配备主进程所必需的内存外加数十MB额外容量。
3. 第三：速度惊人–大家可以享受等同于单一进程的容器启动速度。相较于长达数分钟的传统负载启动时长，现在我们完全能够在几秒钟内启动一套新容器。
   不过很多用户仍然在以对待典型虚拟机的方式审视容器，在这种情况下他们往往没办法发挥容器技术所蕴含的各类优势。因此我们需要再次强调一项基本原则：容器具备一次性特征。

容器座右铭： “容器属于临时性（一次性）系统。”

这一特性的存在要求用户转变既有思路，选择更为合适的方针处理并管理容器。接下来，我会通过十种常见误区帮助大家了解发挥容器优势的合理途径：

1) 不要将数据存放在容器内 – 容器系统可随时进行停止、销毁或者替换。运行在容器环境下的应用程序1.0版本应该可以轻松更换为1.1版本，且不会影响或者破坏相关数据。考虑到这一点，如果大家需要保存数据，请将其存储在存储卷当中；不过需要注意的是，如果有两套容器同时指向同一存储卷，则可能引发故障。大家必须确保自己的应用程序使用面向共享式数据存储机制的写入设计方案。

2) 不要以拆分方式进行应用程序发布 – 有些朋友仍然带着虚拟机思路审视容器。他们大多认为自己应该将应用程序部署至当前正在运行的容器当中。然而，这种作法只适用于开发阶段，从而实现应用开发所必需的持续部署与调试；一旦转移至质量检查与生产环境下的持续部署流程，应用程序则必须作为镜像本身的组成部分。请记住：容器具有恒定特性。

3) 不要创建大型镜像 – 体积过大的镜像会加大其发布难度。大家需要确保在镜像中只保留运行应用程序/进程所必需的文件与库。不要安装任何非必要软件包或者在构建过程中运行“更新”（yum update）。

4) 不要使用单层镜像 – 为了更为合理地使用分层文件系统，请大家务必为操作系统、安装软件、配置以及应用程序分别创建独立层。这不仅能够简化镜像的创建与管理工作，亦能降低分发难度。

5) 不要利用运行中的容器创建镜像 – 换言之，不要使用“docker commit”创建镜像。以这种方式创建的镜像不具备再生产能力且无法实现版本控制性，因此绝对不值得提倡。相反，使用Dockerfile或者任何S2I（即源到镜像）方法能够有效确保整体再生产能力。

6) 不要只使用“最新”标签 – 最新标签类似于Maven用户所熟悉的“SNAPSHOT”。各标签只适合在分层文件系统当中使用。如果大家在镜像构建完成的两个月之后，意外发现自己的应用程序由于顶层版本替换而造成向下兼容性缺失或者build缓存“最新”版本无法运行，那么无疑会造成巨大的麻烦。总体来讲，在向生产环境中部署容器时，必须避免使用最新标签。

7) 不要在单一容器内运行多个进程 – 容器系统非常适合运行单一进程（例如http域名、应用程序服务器以及数据库等等），但如果大家在容器内使用多个进程，则可能很难对其分别进行管理、获取日志记录以及更新。

8) 不要在镜像内保存凭证，建议使用环境变量 – 大家绝对不要以硬编码形式在镜像中保存任何用户名/密码。相反，我们应当利用环境变量从容器之外获取此类信息。在这方面，最完美的示例就是postgres镜像。

9) 以非root用户运行进程 – “默认情况下，Docker容器以root方式运行。随着Docker的不断发展成熟，更多更为安全的默认选项亦陆续出现。就目前而言，使用root权限仍有可能造成安全隐患且缺乏对全部环境的良好适应效果。大家的镜像应当使用USER指令将容器指定为非root用户角色”。（来自Docker镜像创建者指南）

10) 不要依赖于IP地址 – 每套容器都拥有自己的内部IP地址，而容器的每次启动与停止都有可能导致IP地址发生改变。如果应用程序或者微服务需要与其它容器通信，那么请使用能够将相关信息由此容器传递至彼容器的名称与/或环境变量。

Docker技术作为当前最火爆的技术，仍在一个落地和普及的过程中。大家在使用过程中应当抛开传统的观念和想法，避免走入误区、绕进弯路，在技术转型的过程中先人一步。

原文链接：

1. 中文：http://blog.dataman-inc.com/untitled-24/
2. 英文：http://developerblog.redhat.com/2016/02/24/10-things-to-avoid-in-docker-containers/