本文讲的是在生产环境中使用Docker必须注意的事情，【编者的话】本文以最近非常火的希特勒怒喷Docker的视频为线索，详细分析了Docker存在的一些问题和弱点，以及在生产环境中使用Docker所要注意的方面。这些问题包括隔离性、镜像安全、Docker缺省配置、发布及部署；文章的最后分析了微软最近在容器支持方面的动作。
我们不能否认Linux容器是一个非常强大的概念，它组合了众多优秀的Linux内核功能和Docker开源工具，任何背景知识的开发者都很容易使用。
在2016年容器峰会上，Bryan Cantrill深入的比较了容器技术造成的业界以及大众接受的问题与对新的用户可能出现的问题（链接中是大约48分钟的专题讨论）。
问题诸如：由于对新技术背后的支撑功能的理解不够深入而造成的技术不当使用以及使人不愉快的意外。
昨天，Avishai Ish-Shalom做了一个恶搞视频指出了在还没有准备好的情况下使用Docker带来的挫折、意外和震惊。
非常搞笑的视频，希特勒使用Docker：https://t.co/cmXB2Clj8D （译者注：该视频的中文版本在http://v.qq.com/page/n/u/a/n0193j4ylua.html）。
在这篇博文中，我们希望看一下其中的每一个陈述并解构它们，以更深入的理解是什么使得这个视频如此精巧，而同时也可以作为任何一个希望在生产环境中使用Docker的单位和个人的有益参考。
隔离性
视频以一个非常流行的CI/CD场景开始，使用Docker的公有镜像源、Docker Hub及其多容器管理工具Docker-Compose。应该指出的是，Docker的官方文档明确说明了Docker-Compose在目前主要是针对开发和测试环境的，并不适合在大规模的生产环境中使用。
这强调了共享内核带来的第一个问题：降低了可靠性与冗余。
我们相信，这一段的启示应该是：
如果你的基础设施的整体设计没有保证每一种资源的可靠性和冗余性则不要使用容器。你或许可以通过很多技术的运用重新提升可靠性，例如使用共享存储、服务编排、监控以及带有自愈功能的框架如Swarm中的当有节点失败时进行容器重新调度；或者Kubernetes副本设置中的“The Reconciliation Loop”的概念。
但是这个视频中也犀利的指出了上面的技术运用方面的问题：
#GIFEE
之后，视频指出了另外一个关于实施容器运行时隔离的问题：
神化Docker的想法的幻灭。
Jérôme Petazzoni在他的DockerCon EU 2015上的演讲包含了更多的细节，cgroups完整的涵盖了Linux容器对于资源管理的基本需求。对于视频里关于fork炸弹的吐槽，Docker 1.11包含了一个修改，详情见这个视频的作者和Docker的维护者@jfrazelle之间的一段Twitter会话：
@frazelledazzell @francesc @nixcraft @m1keil nproc cgroup的支持只会在1.11.0中https://t.co/lCKjdNmx5Y在云环境中另一个值得注意的问题是熵的消耗（译者注：entropy depletion https://en.wikipedia.org/wiki/ ... %2529），这在共享内核的场景中是非常有意义的，可以参考HAVEGED作为一个变通方案。
— Avishai Ish-Shalom (@nukemberg) April 11, 2016
镜像安全
这个视频中强调的第二个问题是针对从公共镜像源中抓取的容器镜像的不当信任。
博文Sandwich Analogy深入的解释了为什么使用Docker Hub上的非官方公共镜像应该是使人担心的。
让我们在三明治的上下文中思考容器技术。通过观察，你可以轻易的了解到三明治的基本信息例如里面夹的是番茄还是生菜还是火腿或者火鸡肉；或许里面有些你看不到的东西，但是你基本上可以了解大部分的内容。这就跟容器类似，你可以了解到的信息诸如操作系统是Fedora或者RedHat或者Ubuntu，是否有httpd，shell类型，systemd的使用等等，但是里面也可能有你意想不到的隐藏问题，例如/bin/sh或许被替换成了一个Python脚本，这就像是三明治里在生菜后面藏着橄榄一样。镜像内容的安全问题出现在2014和2015年的很多新闻中。Docker一直努力的为解决这个问题添加必须的功能。内容可寻址镜像层用来验证镜像的签名内容，有镜像抓取验证功能的镜像源不再将镜像ID作为保密内容，Docker Hub的Nautilus深度检视保证官方公共镜像的安全漏洞被及时被修复，另外Docker引擎还包含了诸如用户名字空间，Secomp和AppArmor配置以及其它一些安全相关的功能。
可以参考Docker docs和the Docker Security Portal。
Docker缺省配置
正如博文Docker Internals强调的那样，如果你的Linux内核版本大于2.6.x，你需要关闭Docker守护进程上的userland-proxy以支持Hairpin NAT。
通常来说，需要仔细研究Docker的缺省值在你的环境和使用案例中是否是一种优化的配置。例如Docker文档中覆盖了如何选择COW文件系统的所有内容。
容器vs 虚机
容易在“应用打包”的场景中提供了比虚机更多的优势，容器可以更快的构造，更容易分享，也可以更快的启动和停止。
不幸的是，在Windows和OSX中，要使用Linux容器需要在虚拟化环境中运行Linux内核，如果这个问题没有被充分的理解则可能带来的问题和挫折。
Docker也正在通过Docker客户端来改善这个问题（在写这篇文章的时候这个新的Docker客户端版本还在Beta阶段）。新的Docker客户端所使用的解决方法是通过更为紧密的与宿主机操作系统整合来简化开发人员在非Linux操作系统上的体验。
发布&部署
Docker工具箱不仅使得容器技术更流行，也包含了关键的发布功能组件使得容器成为更流行的代码打包和部署方式。容器镜像使用已有的打包和部署工具解决了很多实际的问题。
然而，容器技术被大众接受的方式与虚拟机的使用方式并没有什么区别，镜像经常包含了整个Linux系统和大量非必须的二进制程序。这不但使得镜像文件变大进而使得部署变慢，也使得在生产环境中使用时增大了被攻击的可能性。
幸运的是社区已经接受了slim应用容器的概念，通过使用最小化的Linux发行版例如Alpine – 现在所有的Docker官方镜像都使用Alpine，Alpine包含了静态编译的仅依赖于其所编译的内核的二进制程序。
程序的可扩展性依然需要你自己去关注，需要去探索适合容器的用户场景。
容器Pods的概念鼓励将程序分解成更小、更专注、相互协作的模块。容器提供的隔离性足够允许通过可重用的模块提供比单个的容器更可靠，更可扩展和更快的服务。我们相信这些概念需要一种针对如何构建云环境中的应用的思考方式的变化。请参考容器编排模式。
即使对于那些传统的不是那么“CloudNative”的应用，容器也提供了强大的部署模式例如Joyent倡导的自动驾驶模式。
微软
微软前段时间承诺在Windows Server 2016中支持Windows容器的Docker API。在向Docker社区贡献代码使得Docke客户端工具可以在Windows工作之后,微软在Windows内核中实现了文件系统和容器基础功能，甚至开源了Dot Net核心CLR 。
微软似乎扩展了Astoria项目（一个Andriod模拟器）成为一个令人印象深刻的模拟Linux的Windows子系统（WSL），微软上周宣布了WSL使得整个业界感到震惊。
目前在Windows中集成的Linux内核API的目标是大部分的Linux系统调用，可以使得Windows对软件开发者来说成为一个更有吸引力的平台（仅对目前）。
将最近发生的一些事件通过一个如此精彩的方式来展现，我们向这个视频的创造者致敬！
Hacker-News上的讨论
参考：Ignore the Hype
原文链接：Docker Caveats（翻译：李光成）
========================================================
译者介绍
李光成，IBM中国研究院资深研究员，研究方向是云计算基础设施及技术。目前在做的是Docker资源隔离方面的研究项目。
原文发布时间为：2016-04-17
本文作者：liguangcheng
本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。
原文标题：在生产环境中使用Docker必须注意的事情