显然，应用程序打包和部署似乎有两种做法
我对如何使用选项1感到困惑。前提是您获取泊坞窗图像并在任何平台上重复使用它。但是，在实践中，这是一个可行的解决方案，因为环境通常具有平台和应用程序特定的配置？我的测试环境中的docker镜像无法部署到制作中，因为它包含模拟和测试级配置。
答案 0 :(得分：1)
将应用程序打包为Docker映像的想法是将所有外部/系统配置嵌入到应用程序本身中。即：外部引擎的任何特定版本，例如java或ruby;您系统中的基础GNU / Linux软件（不再是awk或grep的不同版本）等。
从我的角度来看，开发和生产映像之间可能会有一些细微差别，但这种差异应该是较小的配置参数，如日志级别或类似的东西。使用容器和应用程序的分发系统的优点是避免与外部差异相关的所有痛苦，并且还有一种解决“网络规模体系结构”问题的新方法。和弹性平台，有一种新的标准方式来部署它们。在您的测试/开发系统中嘲笑一些外部服务不应该是一个问题，或者如果它们是我认为问题是模拟本身。模拟应该嵌入到您的应用程序容器中，但您可以将它们作为另一个图像（或者在可能的情况下避免模拟服务并将其用作容器）。
编辑1： 作为一般方法，如果您使用Docker作为帮助持续集成或部署到生产的工具，我不建议使用不同的容器进行开发和生产。如果您有使用IT自动化工具（如Puppet，Chef，Ansible或Salt）的经验，那么它们是一种简单且可能快速配置容器的方法（有些是因为Chef有特定于docker的方法，chef-container，这里有一些优势），如果您使用它们构建基础架构，那么它是一个很好的选择。 但是如果您正在构建/设计基于Docker的新架构，我会检查其他更分散和面向容器的选项，如Consul或etcd，以管理配置模板和数据，服务发现，与协调器的弹性部署......