如何在码头上实现“一个二进制”原则

Question

这里解释的一个二进制原则是：Binary说.

“构建一个二进制文件，您可以在发布管道的所有阶段识别和推广该二进制文件。在环境中保存特定于环境的详细信息。这可能意味着，例如，将它们保存在组件容器、已知文件或路径中。”

我看到许多开发工程师可以说违反了这个原则，为每个环境创建了一个对接者映像(例如，many qa，many prod等等)。我知道Docker支持不可变的基础结构，这意味着部署后不会更改映像，因此不会在部署后上传或下载配置。在不可变的基础设施和一个二进制原则之间是否存在一种权衡，或者它们是否能够相互补充？当涉及到将配置与代码分离时，Docker世界中的最佳实践是什么？下列哪一种方法应该采取..。

1)创建一个基本二进制映像，然后具有一个配置Dockerfile，该文件通过添加特定于环境的配置来增强该映像。(即我的应用程序->我的应用程序-prod)

2)在部署时向容器部署一个只有二进制的停靠映像，并通过环境变量等传递配置。

3)将Docker文件部署到容器后上传配置

4)从容器内正在运行的坞映像中从配置管理服务器下载配置。

5)将配置保存在主机环境中，并通过绑定挂载将其提供给正在运行的Docker实例。

还有其他更好的方法没有上面提到吗？

如何使用不可变的基础结构来执行一个二进制原则？这能做吗?还是做个交易？最好的做法是什么？

Answer 1

我现在大约有两年部署码头集装箱的经验，所以我要谈谈我做了什么和/或知道如何工作。

所以，首先让我说容器绝对是不可变的(我甚至将我的容器标记为只读)。

主要方法：

• 通过设置静态入口点和通过重写容器启动命令来重写配置文件位置来使用配置文件--这就不那么灵活了，因为必须提交更改并重新部署才能启用它；不适合密码、安全令牌等。
• 通过使用环境变量重写配置文件的位置使用配置文件，这同样取决于预先准备配置文件；不适合密码、安全令牌等。
• 使用环境变量--这可能需要在部署代码中进行更改，从而缩短了实时获取配置更改的时间，因为它不需要经过应用程序构建阶段(在大多数情况下)，部署这样的更改可能非常容易。下面是一个例子--如果将一个容器化的应用程序部署到马拉松，更改环境变量可能只是从上次使用的容器映像(可能在同一个主机上)启动一个新容器，这意味着这可以在几秒钟内完成；不适合密码、安全令牌等，尤其是在Docker中。
• 将配置存储在k/v存储区，让应用程序意识到这一点，甚至可以动态地重新配置它。同时启动功能的好方法--甚至可能跨越多个服务；如果使用HashiCorp Vault这样的解决方案来实现，那么您甚至可以拥有短暂的秘密(例如，Vault -https://www.vaultproject.io/docs/secrets/postgresql/index.html的PostgreSQL秘密后端)。
• 让一个应用程序或脚本在启动主应用程序之前创建配置文件--将配置存储在k/v存储区中，如领事，使用类似Consul的内容来填充应用程序配置；更安全一点--因为您没有将所有的内容都作为代码传递到整个管道中。
• 在启动主应用程序之前，让应用程序或脚本填充环境变量--例如envconsul；不适合用于敏感信息--可以通过TCP或UNIX套接字访问Docker API的人能够读取这些变量。
• 我甚至遇到过这样的情况:我们将变量填充到AWS的实例user_data中，并在启动时将它们注入容器(在启动时使用修改容器的json的脚本)。

我要考虑的主要事情是：

• 我公开的变量是什么，何时何地获得它们的值(可能是CD软件或其他什么东西)？例如，您可以将AWS端点和凭据发布到实例的user_data，甚至可能是带有IAM实例配置文件魔术的EC2标记。
• 我们需要管理多少个变量？？我们有多少个变量？？如果我们有少数变量，我们可能只需要使用环境变量，或者将环境变量用于存储在文件中的最常用的变量和存储在文件中的变量，这些变量的更改频率较低。
• 如果它是一个文件，通常需要更多的时间将其部署到生产中；如果我们使用环境变量s，通常可以更快地部署这些更改。
• 我们如何保护他们中的一些人-我们应该把他们注射到哪里？
• 如何部署--这可能是发送到部署框架端点、Ansible等的JSON配置文件
• 我们现在所处的环境是什么

我倾向于选择将它们存储在中心位置(k/v存储、数据库)并动态更改它们的最复杂情况，因为我遇到了以下情况：

• 慢部署管道--这使得更改配置文件和部署配置文件的速度非常慢。
• 有太多的环境变量-这可能会失控。
• 必须同时打开整个舰队的特色旗(包括数十项服务)
• 一个真正通过更好地处理敏感配置数据来提高安全性的环境。

我可能漏掉了一些东西，但我想这应该足以引发人们思考什么才是对你的环境最好的。

Answer 2

我过去是如何做到的，就是在执行构建后将令牌化集成到打包过程中。这些令牌可以在顶层管理平台工具的业务流程层中进行管理。因此，对于给定的令牌，有一个匹配的regex或xpath表达式。该令牌将链接到一个或多个配置文件，具体取决于所选择的关系。然后，当将此构建部署到容器中时，平台服务(即config mgmt)将使用与其环境有关的正确值戳出这些令牌。这些戳值很可能是从保险库中提取出来的。