Docker和Ansible如何配合实现Continuos Delivery/Continuous Deployment

Question

我不熟悉配置管理和部署工具。我必须实施一个持续交付/持续部署工具，用于我曾经投入的最有趣的项目之一。

首先，我个人很喜欢AWS，我知道Ansible是什么，它背后的逻辑及其目的。我对Docker的理解水平并不相同，但我明白了。我经历了很多互联网资源，但我无法得到大局。

我一直在努力的是他们是如何融合在一起的。使用Ansible，我可以将我的基础架构作为代码进行管理;构建EC2实例，安装软件包......我甚至可以通过拉取代码，修改配置文件并启动Web服务器来部署完整的应用程序。 Docker本身就是一个打包应用程序的工具，并确保它可以在您部署它的任何位置运行。

我的问题是：

如何泊坞（或Ansible和码头工人）延长持续集成过程！？

假设我们有一个源代码库，团队成员完成了一个功能的工作，他们推动他们的工作。詹金斯检测到这一点，运行所有的验收/单元/集成测试套件，如果他们都通过了，它会将其声明为稳定版本。 Docker如何适合这里？我的意思是，当团队推动他们的工作时，Jenkins是否必须将应用程序中编码的Docker文件源编译，构建应用程序的映像，启动容器并运行所有测试，或者按照经典方式运行测试一切都很好，那么它会从Docker文件构建Docker镜像并将其保存在一个私人位置？ Jenkins应该用x.y.z标记最终图像！

Docker容器配置：

假设我们通过Jenkins内置图像存储的地方，如何处理部署相同的图像到不同的环境，甚至，不同的配置参数（虚拟主机配置，DB主机，队列URLs，S3端点等）在不破坏Docker原则的情况下，处理这个问题的最灵活方法是什么？这些配置是否在构建时或者基于它的容器开始时支持在映像中，如果是，它们是如何被注入的？

Ansible和泊坞：

Ansible提供Docker模块来管理Docker容器。假设我解决了上面提到的问题，当我想部署一个新版本的x.t.z我的应用程序时，我告诉Ansible从存储它的位置拉取该映像，启动应用程序容器，以便如何注入配置设置！ Ansible是否必须在运行之前登录Docker镜像（这听起来令人觉得很疯狂），并且以与经典主机相同的方式使用它的Jinja2模板！如果不是，这是如何处理的？！

对不起，如果这是一个很长的问题，或者我拼错了一些东西，但这是我的想法大声。我在过去两周内被封锁，无法找出正确的工作流程。我希望这是未来读者的参考。

请阅读您的经验和解决方案非常有帮助，因为这看起来像一个常见的工作流程。 预先感谢您。任何帮助深表感谢。

Answer 1

我想在部分

回答如何泊坞（或Ansible和码头工人）延长持续集成过程！？

由于码头图像处处相同，因此您使用泊坞窗图像就好像它们是生产图像一样。因此，当有人提交了代码时，您可以构建您的泊坞窗图像。你对它进行测试。当所有测试通过时，都会相应地标记该图像。由于码头速度很快，这是一个可行的工作流程。 码头更改也是增量式的;因此，您的图像对存储影响最小。此外，当您的测试失败时，您也可以选择保存该图像。通过这种方式，开发人员将拉取该图像并轻松调查您的测试失败的原因。开发人员也可能选择在他们的机器上运行测试，因为詹金斯和他们的机器中的码头图像没有区别。

这是什么带来了所有开发人员将有相同的环境，相同版本的所有软件，因为你决定哪一个将在码头图像中使用。我遇到了由于开发人员机器之间的差异而导致的错误。例如，在相同的操作系统中，unicode设置可能会影响您的代码。但是在docker映像中，所有开发人员都将测试相同的设置，相同版本的软件。

Docker容器配置：

如果您使用的是专用库，你应该使用一个，那么配置更改不会影响硬盘空间很大。因此，除安全性配置（如db密码）外，可以将配置更改应用于泊坞窗图像（Baking the Configuration into the Container）。然后，您可以使用ansible在启动之前/之后使用环境变量或Docker卷将未存储的配置应用于已部署的映像。

https://dantehranian.wordpress.com/2015/03/25/how-should-i-get-application-configuration-into-my-docker-containers/

确实Ansible必须登录泊坞窗图像中，它的运行之前（ 这听起来很疯狂的我）并使用其模板的Jinja2以同样的方式 采用了经典的主机！？如果不是，这是如何处理的？！

不，可以登录Docker镜像，但可以使用Jinja2模板来更改dockerfile。您可以使用模板更改dockerfile，并可以将您的配置注入到不同的文件中。相应地标记文件，并将图像配置为旋转起来。

Answer 2

虽然不是一个完整的解决方案，但我有两个问题的建议。虽然它们可能并不完美，但这些是我们在工作流程中使用的做法，并且迄今已证明自己。

1. 定义不同的环境 - 假设你写的每次启动环境不同Ansible作用，我们定义了一个环境变量设置，我们希望容器属于环境。然后，我们使用之前设置的env变量，将一个合适的配置文件从S3存储桶下载到容器中（如果您提供AWS creds或为您的服务器提供IAM角色，这应该是可能的），并在构建代码时将这些参数注入代码中。

2. Ansible不需要登录泊坞窗应用程序，但解决方案有点棘手。我尝试了两种解决这个问题的方法，但都不理想。第一个是将配置文件作为docker image命令行的一部分下载，并在容器启动时构建应用程序。虽然这个解决方案有效 - 它违反了Docker的理念，并使图像极易出现错误。 另一个解决方案是将几张图像推送到您的码头中心仓库，然后根据当前的环境提取适当的图像。

在更广泛的行程，我已经试过完全启动我们的应用程序与Ansible，这是地狱，很多配置步骤是棘手的，并得到棘手，当你试图实现他们的剧本。当我转向使用Ansible单独维护服务器时，使用Docker部署应用程序本身变得更容易。

Answer 3

关于您使用同一个Docker镜像处理多个环境配置的问题，我一直在计划使用Consul之类的服务发现工具作为集中式配置/属性管理工具。因此，当你启动你的容器时，你设置一个ENV变量，告诉它它是什么应用程序（appID），以及它应该使用什么样的环境配置（例如：MyApplication：Dev），并且它将在启动时从Consul中取出它的配置。我仍然需要调查Consul周围的安全性（就像我们在那里存储数据库连接凭证，例如，我们如何限制谁可以查询/更新这些值）。我不想只用这个容器，但一般来说所有的应用程序。另一个很酷的功能是更改Consul中的配置值，并将钩子放回到您的应用中以立即应用这些更改（也许就像应用上的REST端点一样，将更改推送到动态应用它）。当然你的应用必须写成支持这个！

你可能会想看看Martin Fowler的关于immutable infrastructure和Phoenix servers的博客文章。