我有一个共享的 Wordpress 托管服务器，上面大约有 50 个站点，完全通过 Ansible 配置。
我正在尝试找到一个良好的界限
a) 每次添加站点或更改配置时更新 AMI，例如，这将影响虚拟主机和 PHP 池文件
b）使用自定义启动脚本运行其中一些配置更改，并在实例从负载均衡器接收流量之前为其提供更多启动时间
目前只有一个实例，可能暂时不需要自动伸缩来应对流量的大幅变化。相反，如果实例在非工作时间发生故障，则需要使用自动伸缩来自动替换实例。
根据我目前的规模，为了实现良好的成本管理，我最好在晚上运行一个 c5.large，并在白天安排 2 个 c5.large 的自动缩放，这将使我以与单个 c5.xlarge 相同的成本获得多可用区的可靠性
我计划使用 EFS 共享所有 Wordpress 文件，并可能使用 Redis 进行共享会话管理，但这不是这个问题的主题。
我对解决方案 a) 的担忧是，每次添加新站点、创建临时站点或需要进行任何其他配置更改时，我都需要创建一个新实例、进行更改、创建 AMI 并将 AMI 轮换到我的自动扩展组中。即使完全自动化，我也认为这会花费太长时间，无法达到可接受的周转速度。
相反，我可以在少数实例上进行这些更改，并以编程方式更新 AMI。然后，它只会在发生故障时、在进行恢复测试时或在测试堆栈上测试开发时才会被使用
这是管理共享托管环境的好方法吗？
答案1
我计划使用 EFS 共享所有 Wordpress 文件，并可能使用 Redis 进行共享会话管理，但这不是这个问题的主题。
嗯，真可惜。我正要建议你把所有配置和用户数据从实例转移到耐用、共享的存储并将实例纯粹用作无状态 Web 服务器 - 易于扩展，易于替换。从本地存储到 EFS 的转换很容易（这实际上不是重新架构系统，只是将一些目录移动到 EFS），并且可以在很少的停机时间内完成。
所有 Apache / Nginx / PHP 和 Wordpress 配置文件以及上传的用户媒体文件都将存储在共享文件系统上，实例将从那里进行自我配置。
无论如何，如果你直接忽略最佳且明显的解决方案我们只能建议一些较差的选择。我有一个 CloudFormation 模板，它的功能与你想要的接近：
- EC2 实例位于AutoScaling 组最小值=1/最大值=1。也就是说，如果它死机了，它会自动重新启动。
- 每天晚上Lambda 创建快照将实例作为新的 AMI 并更新ASG 启动配置使用新的 AMI ID。例如，如果实例在第二天死亡，它将从昨晚的快照中启动。
这对于不经常更改的实例非常有效。例如，我们的 CMS 将所有数据放在数据库中，将所有应用程序配置和用户文件放在 EFS 上，并且只有一些包和系统配置文件会不时更新实例，但更新频率不高。
类似的东西对你有用吗？但是，实施该方案所需的努力很可能比一开始就迁移到 EFS 要大，而且结果也不是那么好，弹性也不大。
希望有帮助:)