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