【编者按】本文做者为 Rafael Benevides,主要介绍使用 Docker 容器时应该注意的十个陷阱。文章系国内 ITOM 管理平台 OneAPM 编译呈现,如下为正文。html
当你刚开始使用容器时,会发现容器能解决许多问题,并且好处不少:linux
然而,许多用户仍然只是将容器视为典型的虚拟机。他们忘记了容器的一个重要特征:容器是可丢弃的。git
围绕容器的咒语:“容器是临时的”。github
鉴于这一特征,用户必须转变他们使用以及管理容器时的心态。下面,笔者将介绍为了充分利用 Docker 容器的好处,用户应该避免的十个陷阱:docker
1)不要在容器内存储数据 —— 容器能够被中止、销毁或者取代。运行在容器中的应用1.0版本应该可以轻易地被1.1版本所取代,且不产生任何影响或数据丢失。所以,若是你须要存储数据,请将其存储在卷组(volume)中。在这种状况下,你要格外当心两个容器向同一卷组写入数据的状况,由于这很容易致使数据污染。总之,要确保本身的应用向共享的数据存储区填写数据。数据库
2)不要将应用分开发布 —— 有些人会将容器视为虚拟机,他们中的大部分人认为,应该在现有的运行容器中部署应用。在开发阶段,由于须要不断地修改配置并调试应用,这样作无可厚非。可是,当持续交付管道行进至 QA 与生产阶段时,不该该把镜像和应用分开。记住:容器是不可变的。缓存
3)不要建立太大的镜像 —— 镜像越大,越难以分发。确保只留有运行应用或进程所需的文件和库。不要安装没必要要的包或运行“update”(yum update)指令下载太多文件到新的镜像层。安全
更新:关于这条建议,有一篇解释更为详尽的文章:《保持小巧:细究 Docker 镜像大小》服务器
4)不要使用单层镜像 —— 为了有效利用分层的文件系统,老是为操做系统建立基础镜像层,此外,分别为用户名定义、运行时安装、配置、以及本身的应用建立不一样的镜像层。这样一来,重现、管理以及传送镜像会变得更为简单。运维
5)不用为运行中的容器建立镜像 —— 换句话说,不要使用 “docker commit” 指令建立镜像。这种建立镜像的方法是不可重现的,应该彻底避免。相反,老是使用 Dockerfile 或任何 S2I (source-to-image,源码到镜像) —— 彻底可重现的方法来建立镜像。这样一来,若是你将 Dockerfile 保存在源码存储控制库(git)内,就能够追踪其后续变化。
6)不要单独使用“latest(最新)”标签 —— 最新标签就像 Maven 用户眼中的 “SNAPSHOT(快照)”。由于容器自己的分层式文件系统,咱们鼓励使用标签。可是,你可不想在几个月后正打算建立镜像时,却惊讶地发现应用没法运行,而缘由竟然是一个父层(Dockerfile 中的 FROM)已经被没法向后兼容的新版取代,或是建立缓存中检索出的“最新”版本是错的。此外,因为你没法追踪当前运行镜像的版本,“最新”标签也不该该在生产环境中部署容器时使用。
7)不要在一个容器内运行多个进程 —— 容器在运行单一进程(http 后台进程、应用服务器、数据库)时几乎无可挑剔,可是,若是运行多个进程,你可能会在管理、检索日志以及独个更新进程时遇到麻烦。
8)不要在镜像中存储凭证 —— 使用环境变量。不要将镜像中的任何用户名或密码写死。使用环境变量从容器外部检索这些信息。Postgress 镜像就是践行该准则的好榜样。
9)不要以 root 用户运行进程 —— “默认状况下,docker 容器以 root 权限运行。(…)随着 Docker 的不断完善,更多安全的默认选项会逐渐出现。就当下而言,要求 root 权限对有些用户而言比较危险,可能没法在全部环境中实现。你的镜像应该使用 USER 指令为容器肯定一个非 root 运行权限。”(摘自《Docker 镜像做者指南》)
10)不要依赖 IP 地址 —— 每一个容器都有其内部 IP 地址,该地址可能由于启动或中止容器而发生改变。若是你的应用或微服务须要与另外一个容器交换消息,应该使用环境变量在容器间传送合适的主机名与端口号。
OneAPM Cloud Insight 产品集监控、管理、计算、协做、可视化于一身,帮助全部 IT 公司,减小在系统监控上的人力和时间成本投入,让运维工做更加高效、简单。想阅读更多技术文章,请访问 OneAPM 官方技术博客。
本文转自 OneAPM 官方博客
原文地址:http://developerblog.redhat.com/2016/02/24/10-things-to-avoid-in-docker-containers/