获取Docker映像（在CI阶段创建并推送）。
将docker-compose .yml模板复制到目标服务器。
运行应用程序。
我们直接进入第三点。我可以使用docker-compose up来运行应用程序，但是我不知道如何处理配置。目标服务器是由Chief在AWS上创建的Ubuntu Server，我可以访问所有AWS服务，例如Parameter Store等。
所以这是我管理配置的想法：
在运行应用程序之前将机密保存到配置文件中，并将此文件附加到docker-compose模板中的特定位置（我不喜欢这种解决方案，我可以通过一些将机密注入文件的bash脚本来处理此问题。） br />在运行应用程序之前设置环境变量（我与一些DevOps进行了交谈，并且基本上他们喜欢这种解决方案）。
从AWS Parameter Store获取机密（不幸的是，我无法通过角色管理访问，只能通过密钥访问）我需要通过环境或配置文件在服务器上进行设置。）
在实际情况下，如何管理配置？我担心服务器崩溃或类似情况。第一个解决方案将幸免于此，但是在第二个和第三个解决方案的情况下，崩溃/重启后环境变量将丢失。什么是最好的解决方案？
#1 楼
[从重复的帖子中复制答案]如果使用环境变量启动容器，则该变量是容器定义的一部分。作为专家，重新启动服务器后，容器重新启动时将存在相同的变量。但是，不利的是，任何有权使用docker API的人都可以以明文形式查看该秘密，并且某些应用程序在调试时会记录其环境。
使用群体模式（Kubernetes有他们自己的类似解决方案），您可以可以在管理器上定义您的秘密，并将根据需要将其提供给运行容器的节点。秘密可以作为文件在容器内访问，但是该文件仅存储在工作节点上的内存中，并且如果应用程序期望这样做，则可以使用容器中的入口点脚本将其加载到环境中。群模式的秘密和配置具有可移植性的优势，因为在发生工伤事故时，容器将重新安排在其他节点上。从docker-compose安装迁移到单节点群集集群并部署堆栈是一项非常简单的任务。 Hashicorp的保险柜。 Swarm模式和Kubernetes都使用键/值存储进行自己的设置，使您了解社区如何将其视为最佳实践。缺点是您经常希望将应用程序配置为直接从这些键/值存储之一读取和写入配置。如果您使用诸如群模式秘密和配置之类的东西，这些将被存储在docker的内部键/值数据库中，那么您可以毫不费力地获得类似的解决方案。
#2 楼
我们的情况与您的情况非常相似。我们的配置是一个纯文本YAML文件，该文件存储在绑定安装到容器中的主机上。这是不理想的，因为秘密是明文形式的。保持2个节点之间的奇偶校验也是有问题的。
评论中提到的人； k8s是一种潜在的解决方案，但是对于2节点系统而言，这似乎有些过头了。我还没在
docker-compose和k8s之间找到任何东西。#3 楼
我想这里的要点是，您希望在所有环境中都保持相同的部署方法，并在一处更新配置。如果您查看了12个因素的应用程序，则说明应用程序配置应该生活在环境中，例如保管库，配置存储，AWS参数存储。 Kubernetes秘密的作用域仅限于名称空间。
环境变量也不被认为是非常安全的，因为可以在运行时对其进行检查。
出于多种原因，我更喜欢选择3：
应用程序会在运行时从config存储（AWS参数存储）中提取配置。
Application可以动态更改配置（无需重新部署应用程序）
无需在部署脚本中添加逻辑，从而可以从配置存储中提取秘密，然后在部署期间将其注入到组合文件中。
部署编排工具不需要访问您的应用程序秘密。
另一方面：
需要更新应用程序以支持从
商店。
一方面（与您的问题无关），如果您只是为一个简单的应用程序部署几个容器并且k8不适合，为什么呢？您看一下ECS Fargate吗？无需管理任何基础架构。