Baruch Sadogursky谈Docker容器生命周期管理面临的挑战
JFrog开发大使Baruch Sadogursky在多个会议上做过演讲，包括去年5月举行的DevOps Days Kiel，
内容涉及控制和跟踪Docker镜像从开发环境到生产环境的流程所面临的挑战，以及JFrog提出的解决方案。
为了更好地了解Docker容器生命周期管理所面临的部分挑战，InfoQ采访了Sadogursky。
InfoQ：如今，您看到有许多工程团队使用Docker镜像作为构件，并通过部署管道推送它们吗？
Baruch Sadogursky:我们看到，人们如今对Docker非常感兴趣。人们试图像使用先前的技术栈那样，借助Docker实现推送管道，但那并不总是有效。有些Docker的架构决策让做正确的事变得困难，而部分Docker的最大优势却让人容易做错。
InfoQ：那些使用Docker的人，他们是真正地将镜像部署到生产环境，还是只是使用它们作为复制实际的VM生产实例的一种快速而简单的方式？
Sadogursky:真正在生产环境中使用Docker的团队，比“摆弄”Docker、做概念验证或者在开发环境中使用Docker的团队要少得多。我们认为，其中的一个原因是，增加一个更不透明的抽象层会增加生产级工件不能有的不确定性。
InfoQ：您能简要地说明下，为什么您主张使用Docker镜像作为工件而不是Dockerfiles（有依赖管理）+应用程序二进制文件（比如WAR文件）？
Sadogursky:这篇博文对整个理论进行了解释，但简单来说——如果你从Dockerfiles多次构建（每个环境的）镜像，那么并没有什么方法可以确保你最终获得的工件相同。那是由Dockerfile的性质决定的——它的大多数命令都会引入不同的依赖项，而且经常会使用一个不稳定的版本。
InfoQ：在您看来，Dockerfile应该包含什么类型的信息，而又不应该包含什么信息？
Sadogursky:设法锁定所有依赖项的版本，越多越好。对于有些依赖项，这可以做到，例如使用一个版本号运行apt-get，但对于其他依赖项，这无法做到（例如基于Ubuntu的镜像会累积相同版本下的安全补丁），但要试一下。
InfoQ：通过部署管道推送Docker镜像面临什么挑战？
Sadogursky:当前，大多数Docker注册中心使用的推送模式是获取镜像、重打标签并添加到新的注册中心（或库），用于管道的下一个步骤，并把它重新放回。相当愚蠢，不是吗？
InfoQ：您如何看待（Docker及其竞争者的）Docker注册中心的现状？它们之间主要有什么不同？
Sadogursky:这是一个相当宽泛的问题。有一大堆指标可以用于比较注册中心。其中一个最有趣的是，管道的其他部分是否需要额外的工具。Docker是一种容器技术，容器会包含某些东西。如果你可以在和容器镜像一样的工件库里管理这些“东西”，你就可以在创建镜像的构建和创建容器所含内容的构建之间建立可追溯的元数据。
InfoQ：如果你需要确保源代码、应用程序二进制版本和Docker镜像版本之间的可追溯性，那么如何才能避免依赖管理地狱？
Sadogursky:“一次构建，推送不可变二进制版本”实际上同样解决了这个问题。你运行一次依赖管理系统，这样，一旦二进制版本创建了出来，到源代码的追溯就是不变的，一直到生产环境都是如此。
InfoQ：从安全的角度讲，在确保推送到生产环境的Docker镜像不易受到攻击方面，您有什么建议吗？
Sadogursky:这没有什么特别之处。你应该使用安全扫描器。务必要确保，使用的工具既能扫描Docker容器，又能扫描镜像内容及镜像内的工件内容，等等。它们都可以在运行时暴露出容器的安全漏洞。
InfoQ：基于Docker镜像的推送管道可以帮助团队实现不可变基础设施吗？为了支持那种“构建&清除（build & forget）”的基础设施建设方法，还需要考虑什么其他的因素吗？
Sadogursky:基于Docker镜像的方法就是指不可变基础设施。尽快创建不可变镜像的思想恰恰就是不可变基础设施的方法论。一旦你有了一个很好的持续集成（CI）管道，每次源代码修改就会触发一系列的CI构建和推送，最终进入一组新的Docker容器——那就是最好的不可变基础设施。
InfoQ：像Chef或Puppet这样的配置管理工具如何纳入那种场景？
Sadogursky:那是个价值10亿美元的问题。我不知道有谁现在能够回答这个问题。看可变基础设施软件在不可变基础设施领域如何自我改造是非常意思的。也许Chef Habitat是向那个方向迈出的第一步？等着瞧吧。
查看英文原文：Q&A with Baruch Sadogursky on the Challenges of Managing Docker Containers Lifecycle