我们的部署系统借鉴了不可变服务器模式也就是说，我们以一种方式将 AMI 与应用程序一起烘焙，这样当它们启动时，应用程序就会运行，并且可以添加到 ALB 池中。
（造成这种情况的原因有些复杂，主要是因为我们的应用程序中有很多不经常更改的读取密集型数据，并且我们需要快速增加容量。即使有其他方法可以做到这一点，我们也假设这种架构是固定的！）
我们不希望正在运行的实例是 100％ 不可变的，原因如下：
根据实例的属性进行更改
我们使用 gunicorn 来提供我们的 WSGI 应用程序。Gunicorn建议2-4 x $(NUM_CORES)，但这会根据我们启动的实例而变化。
根据 AWS 账户/SSM 值/某些外部因素而变化
AMI 可能会在暂存或生产帐户中启动。暂存 AMI 与生产 AMI 相同是很好的，但我们不希望暂存 AMI 连接到生产数据库/外部服务。
我没有关注这两个示例的细节（例如，我知道我可以WEB_CONCURRENCY为 gunicorn 设置），而是试图找出执行此类 AMI 运行时配置的“最佳”方法。
我认为的选项如下：
- 在启动时使用 AWS CodeDeploy 运行，并使用我想要的配置更改来配置 CodeDeploy
- 使用实例用户数据来设置环境变量，并有一个可以改变事物的启动时脚本
- 使用一些其他自动化工具，例如 ansible
无论我使用什么系统，我都希望它能够自动扩展，这意味着我可以将实例添加到 ALB 池中并让它们正确配置。
我一直在寻找这方面的建议，但 AWS 示例似乎并没有给我带来帮助。我确信有一个常用的解决方案，甚至可能是 AWS 提供的解决方案。我错过了什么？