我是配置管理和部署工具的新手 . 我必须为我曾经掌握过的最有趣的项目之一实施持续交付/持续部署工具 .
首先，单独地，我对 AWS 很满意，我知道 Ansible 是什么，它背后的逻辑及其目的 . 我对 Docker 的理解程度不一样，但我明白了 . 我经历了很多互联网资源，但我无法了解全局 .
我一直在努力的是他们如何融合在一起 . 使用 Ansible ，我可以管理我的基础设施作为代码;构建 EC2 实例，安装包...我甚至可以通过拉动代码，修改配置文件和启动Web服务器来部署完整的应用程序 . Docker 本身就是一个打包应用程序的工具，并确保它可以在您部署应用程序的任何地方运行 .
我的问题是：
How does Docker (or Ansible and Docker) extend the Continuous Integration process!?
假设我们有一个源代码存储库，团队成员完成了一项功能，他们推动了他们的工作 . Jenkins检测到这一点，运行所有接受/单元/集成测试套件，如果它们全部通过，则将其声明为稳定版本 . Docker如何适合这里？我的意思是当团队推动他们的工作时，Jenkins是否必须在应用程序中提取编码的Docker文件源，构建应用程序的映像，启动容器并针对它运行所有测试，或者以经典方式运行测试，如果一切都很好然后它从Docker文件构建Docker镜像并将其保存在私人场所？詹金斯应该使用x.y.z标记最终图像吗？
Docker containers configuration :
假设我们有一个由 Jenkins 构建的图像存储在某个地方，如何处理将相同的图像部署到不同的环境，甚至，不同的配置参数（Vhosts配置，数据库主机，队列URL，S3 endpoints 等......）最多灵活的方式处理这个问题而不破坏 Docker 原则？这些配置是在构建时还是基于它的容器启动时支持在映像中，如果是这样，它们是如何注入的？
Ansible and Docker ：
Ansible 提供 Docker 模块来管理 Docker 容器 . 假设我解决了上面提到的问题，当我想部署我的应用程序的新版本x.t.z时，我告诉 Ansible 从存储它的位置拉出该图像，启动应用程序容器，以便如何注入配置设置！？ Ansible是否必须在运行之前登录Docker镜像（这对我来说听起来很疯狂）并且使用其Jinja2模板与经典主机相同！？如果没有，这是如何处理的？！
对不起，如果这是一个很长的问题，或者我拼错了什么，但这是我大声思考的问题 . 过去两周我被封锁了，我无法弄清楚正确的工作流程 . 我希望这能成为未来读者的参考 .
请阅读您的经验和解决方案非常有用，因为这看起来像是一个常见的工作流程 .
3 回答
我想部分回答
由于docker图像在任何地方都相同，因此您可以使用docker图像，就好像它们是 生产环境 图像一样 . 因此，当有人提交代码时，您构建了docker镜像 . 你对它运行测试 . 所有测试通过后，您都会相应地标记该图像 . 由于docker很快，这是一个可行的工作流程 . docker的更改也是增量的;因此，您的图像对存储的影响最小 . 此外，当您的测试失败时，您也可以选择保存该图像 . 通过这种方式，开发人员将提取该图像并轻松调查测试失败的原因 . 开发人员也可以选择在他们的机器上运行测试，因为jenkins中的docker镜像和他们的机器没有区别 .
这带来了所有开发人员将拥有相同的环境，所有软件的相同版本，因为您决定在docker镜像中使用哪一个 . 我遇到了由于开发人员机器之间的差异而导致的错误 . 例如，在同一操作系统中，unicode设置可能会影响您的代码 . 但是在docker镜像中，所有开发人员都将测试相同的设置，相同的版本软件 .
如果您使用的是私有存储库，并且应该使用私有存储库，那么配置更改不会对硬盘空间造成太大影响 . 因此，除了安全配置（例如db密码）之外，您可以应用配置更改为泊坞窗图像（Baking the Configuration into the Container） . 然后，您可以使用ansible在启动之前/之后使用环境变量或Docker Volumes将未存储的配置应用于已部署的映像 .
https://dantehranian.wordpress.com/2015/03/25/how-should-i-get-application-configuration-into-my-docker-containers/
不，ansible不会登录Docker镜像，但可以使用带有Jinja2模板的ansible来更改dockerfile . 您可以使用模板更改dockerfile，并将配置注入不同的文件 . 相应地标记您的文件，并将图像配置为旋转 .
关于使用相同的Docker镜像处理多个环境配置的问题，我一直在计划使用像Consul这样的服务发现工具作为集中的配置/属性管理工具 . 因此，当你启动容器时，你设置一个ENV var来告诉它它是什么应用程序（appID），以及它应该使用什么环境配置（例如：MyApplication：Dev），它将在启动时从Consul获取其配置 . 我仍然需要调查Consul周围的安全性（好像我们在那里存储数据库连接凭证，例如，我们如何限制谁可以查询/更新这些值） . 我不想只将它用于容器，而是一般用于所有应用程序 . 另一个很酷的功能是更改Consul中的配置值并挂钩到您的应用程序中以立即应用更改（可能类似于应用程序上的REST endpoints 以将更改推送到并动态应用它） . 当然，你的应用程序必须编写支持这个！
您可能有兴趣查看Martin Fowler在immutable infrastructure和Phoenix servers上的博客文章 .
虽然不是一个完整的解决方案，但我对您的两个问题提出了建议 . 虽然它们可能并不完美，但这些是我们在工作流程中使用的实践，并证明了自己到目前为止 .
定义不同的环境 - 假设您为启动的每个环境编写了不同的Ansible角色，我们定义一个环境变量来设置我们希望容器所属的环境 . 然后，我们使用之前设置的env变量从S3存储桶中下载合适的配置文件（如果您提供AWS信誉或为服务器提供IAM角色，则应该可以这样），并在构建时将这些参数注入代码中 .
Ansible不需要登录docker app，但解决方案有点棘手 . 我已经尝试了两种解决这个问题的方法，但两者都不理想 . 第一个是将配置文件作为docker image命令行的一部分下载，并在容器启动时构建应用程序 . 虽然这个解决方案有效 - 它破坏了Docker的理念，并使图像极易构建错误 . 另一种解决方案是将多个图像推送到docker hub repo，然后根据手头的环境拉出适当的图像 .
在更广泛的描述中，我尝试使用Ansible完全启动我们的应用程序，这很糟糕，许多配置步骤都很棘手，当你尝试将它们作为一个剧本实现时会变得更加棘手 . 当我转而使用Ansible单独维护服务器，并使用Docker部署应用程序时，事情变得容易多了 .