Docker镜像用于应用程序打包

Question

显然，应用程序打包和部署有两种做法：

1. 创建一个Docker镜像并部署它。
2. 从头开始构建和部署应用程序。

我对如何使用选项1)感到困惑。前提是你可以在任何平台上重复使用一个Docker镜像。但是实际上，由于环境通常具有特定的平台和应用程序配置，这怎么能成为一个可行的解决方案呢？例如，我的测试环境中的Docker镜像不能部署到生产环境中，因为它包含模拟和测试级别的配置。

- user1340582

Answer 1

将应用程序打包为Docker镜像的想法是将所有外部/系统配置嵌入到应用程序本身中。例如：任何特定版本的外部引擎，如Java或Ruby；您系统中拥有的基本GNU / Linux软件（不再是不同版本的awk或grep），等等。

在我看来，开发和生产镜像之间可能会存在一些轻微的差异，但这些差异应该是类似日志级别或类似参数的次要配置。使用容器作为应用程序的分发系统的优点是避免与外部差异相关的所有痛苦，并提供了一个新的解决“Web规模体系结构”和弹性平台问题的方法，从而有了一种新的标准的部署方式。在测试/开发系统中模拟一些外部服务不应该成为问题，或者如果它们是问题，则认为问题出在模拟本身。模拟应该嵌入到您的应用程序容器中，但您可以将其作为另一个镜像（或在可能的情况下避免模拟服务并将其作为容器使用）。

编辑1： 如果你将 Docker 作为持续集成或部署到生产环境的工具，我不建议使用不同的容器进行开发和生产。如果你有使用 IT 自动化工具的经验，比如 Puppet、Chef、Ansible 或 Salt，它们是配置容器的一种简单且快速的方式（像 Chef 还有一个专门的 Docker 方案，叫做 chef-container，在这里有一些优势），并且如果你的基础架构使用它们构建，则考虑这个选项是个不错的选择。 但如果你正在构建/设计一个基于 Docker 的新架构，我建议你检查其他更分散且面向容器的选项，如 Consul 或 etcd，用于管理配置模板和数据、服务发现、使用编排器进行弹性部署等。

- Javier Cortejoso

---

你的意思是a)我应该为每个环境（例如使用Jenkins）创建现成的完整Docker镜像（测试，UAT，生产...），还是b)拥有一些更抽象的环境图像，然后进行最终配置（例如使用Puppet）？我们所有的应用程序配置都在属性文件中；没有“应用程序内部”的配置。 - user1340582

请检查Edit1。谢谢！ - Javier Cortejoso