deployment - 如何用 Docker 实现 "One Binary"原则

Question

一元原理在这里解释:
http://programmer.97things.oreilly.com/wiki/index.php/One_Binary说一个人应该...

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

我看到许多 dev-ops 工程师通过为每个环境创建一个 docker 镜像(即 my-app-qa、my-app-prod 等)而违反了这一原则。我知道 Docker 喜欢不可变的基础设施，这意味着在部署后不更改镜像，因此在部署后不上传或下载配置。不可 rebase 础设施和一个二元原则之间是否存在权衡，或者它们可以相互补充吗？当谈到将配置与代码分离时，Docker 世界中的最佳实践是什么？？？应该采取以下哪一种方法...

1) 创建一个基本的二进制镜像，然后有一个配置 Dockerfile，通过添加环境特定的配置来增强这个镜像。 (即我的应用程序 -> 我的应用程序产品)

2) 将仅二进制的 docker 镜像部署到容器中，并在部署时通过环境变量等传入配置。

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

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

5) 将配置保留在主机环境中，并通过绑定(bind)挂载使其可用于正在运行的 Docker 实例。

有没有上面没有提到的另一种更好的方法？

如何使用不可变的基础设施强制执行一元二元原则？它可以完成还是有一个权衡？什么是最佳实践？

Answer 1

我现在有大约 2 年部署 Docker 容器的经验，所以我将谈谈我所做的和/或知道的工作。

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

主要做法:

通过设置静态入口点并通过覆盖容器启动命令覆盖配置文件位置来使用配置文件 - 这不太灵活，因为必须提交更改并重新部署才能启用它；不适合密码、安全 token 等

通过使用环境变量覆盖它们的位置来使用配置文件 - 同样，取决于预先准备好配置文件； ;不适合密码、安全 token 等

使用环境变量 - 这可能需要更改部署代码，从而减少使配置更改生效的时间，因为它不需要经过应用程序构建阶段(在大多数情况下)，部署这样的更改可能是挺容易。这是一个示例 - 如果将容器化应用程序部署到 Marathon，更改环境变量可能只是从上次使用的容器镜像(甚至可能在同一主机上)启动一个新容器，这意味着这可以在几秒钟内完成；不适合密码、安全 token 等，尤其是在 Docker 中

将配置存储在像 Consul 这样的 k/v 存储中，让应用程序意识到这一点，并让它甚至可以动态重新配置。同时启动功能的好方法 - 甚至可能跨越多个服务；如果使用诸如 HashiCorp Vault 之类的解决方案来实现敏感信息的安全存储，您甚至可以拥有临时 secret (例如，Vault 的 PostgreSQL secret 后端 - https://www.vaultproject.io/docs/secrets/postgresql/index.html)

在启动主应用程序之前让应用程序或脚本创建配置文件 - 将配置存储在像 Consul 这样的 k/v 存储中，使用类似 consul-template 的东西来填充应用程序配置；更安全一点 - 因为你没有将所有东西作为代码在整个管道中传递

在启动主应用程序之前让应用程序或脚本填充环境变量 - 一个例子是 envconsul；不适合敏感信息 - 可以访问 Docker API(通过 TCP 或 UNIX 套接字)的人将能够读取这些

我什至遇到过这样的情况，我们将变量填充到 AWS 的实例 user_data 中，并在启动时将它们注入(inject)到容器中(使用脚本在启动时修改容器的 json 配置)

我会考虑的主要事项:

我暴露的变量是什么以及我从何时何地获取它们的值(可能是 CD 软件或其他东西)-例如，您可以将 AWS RDS 端点和凭证发布到实例的 user_data，甚至可能是 EC2 标签带有一些 IAM 实例配置文件魔法

我们需要管理多少变量以及我们多久更改其中一些变量 - 如果我们有一些，我们可能只使用环境变量，或者将环境变量用于最常更改的变量和存储在文件中的变量那些我们不经常更改的

以及我们希望看到它们更改的速度有多快 - 如果是文件，通常需要更多时间将其部署到生产环境；如果我们使用环境变量
s，我们通常可以更快地部署这些更改

我们如何保护其中一些 - 我们在哪里注入(inject)它们以及如何 - 例如 Ansible Vault、HashiCorp Vault，将它们保存在单独的存储库中等

我们如何部署 - 这可能是发送到部署框架端点、Ansible 等的 JSON 配置文件

我们所处的环境是什么 - 将 Consul 之类的东西作为配置数据存储是否现实(Consul 有 2 种不同类型的代理 - 客户端和服务器)

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

缓慢的部署管道 - 这使得更改配置文件并部署它变得非常缓慢

有太多的环境变量 - 这真的会失控

必须一次打开整个车队(由数十个服务组成)的功能标志

通过更好地处理敏感配置数据来真正努力提高安全性的环境

我可能错过了一些东西，但我想这应该足以触发思考什么最适合您的环境