假设我从我的一个 EC2 实例创建了一个 AMI。现在，我可以手动将其添加到 LB 或让 AutoScaling 组为我执行此操作（基于我提供的条件）。到目前为止，一切都很好。
现在，假设我的开发人员添加了一个新功能，并且我在现有实例上提取了新代码。请注意，AMI 此时未更新，仍然有旧代码。我的问题是我应该如何处理这种情况，以便当自动缩放组从我的 AMI 创建一个新实例时，它将使用最新的代码。
我想到了两种方法，如果您有其他解决方案，请告诉我：
a) 始终保持 AMI 更新；这意味着只要有拉取请求，就应该删除（删除）旧的 AMI 并用新的 AMI 替换。
b) 在 AMI 上有一个启动脚本 (cloud-init)，它将在初始启动时从存储库中提取最新代码。（通过将存储库凭据存储在实例上并直接从 git 中提取代码）
这些方法中哪一种更好？如果两者都不好，那么实现这一目标的最佳做法是什么？
a) 始终保持 AMI 更新；这意味着只要有拉取请求，就应该删除（删除）旧的 AMI 并用新的 AMI 替换。
您不应将源代码存储在 AMI 中。如您所见，这会带来维护噩梦和自动缩放问题。
b) 在 AMI 上有一个启动脚本 (cloud-init)，它将在初始启动时从存储库中提取最新代码。（通过将存储库凭据存储在实例上并直接从 git 中提取代码）
这些方法中哪一种更好？如果两者都不好，那么实现这一目标的最佳做法是什么？
您的第二项，在服务器启动时下载源代码，是解决此问题的正确方法。
其他选项是使用 Amazon CodeDeploy 或其他一些部署服务来部署更新。部署服务还可用于将更新部署到现有实例，同时允许新实例在启动时自动下载最新代码。
鉴于任何东西（几乎）都可以通过 API 使用 AWS 实现自动化；它将再次归结为手头的特定用例。
一开始，人们会建议有一个基本 AMI，其中安装和配置了必要的软件包，并有一个可以下载源代码的初始化脚本，始终是最新的。这里需要计算的非常重要的因素是签出或提取代码并配置实例并使其准备好投入工作所花费的时间。如果该时间段非常大 - 那么使用该策略进行自动缩放将是一个坏主意。由于预热时间与自动缩放和云观察的统计数据相结合会导致不同的现实[可能/可能不是-但概率不为零]。这时您可能会考虑经常烘焙新的 AMI。这将使您能够最大限度地减少实例为对抗流量做准备所花费的时间。
我建议测量并查看哪种方式方便且具有成本效益。拉下实例并使用 AMI 重新启动需要真钱；但是，这就是您需要做出的权衡。
虽然，我已经回答了一些开放式的问题；因为。问题也很少。
人们已经开始使用执行配置管理的 Chef、Ansible、Puppet。这些工具完全增加了不同级别的自动化；您也想探索该选项。类似的方法是使用 Docker 或其他容器。