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