有什么最佳实践和/或工具可以定期更新AMI？

#1 楼

我们计划为Jenkins EC2从站自动化此过程。

当前，每次构建新的AMI时，我们都必须手动更新AMI ID，但要利用Jenkins存储所有内容的config.xml文件它的配置，我们应该能够自动更新此文件中的AMI值，然后重新启动Jenkins以使这些更改生效。

EDIT：请参见下面的注释，以获得进行这些更改的更好方法，而不是config.xml文件

#2 楼

我可以回答实际的操作方法：

我们在AWS及其CI系统上使用了私有的Gitlab。
我们有一个用于构建环境的存储库（带有Packer的docker映像/ scripts / json描述amis）和一个带有.gitlab-ci.yml的文件，用于描述我们每个基本AMI的构建和导出任务。
每个项目在每次推送时都从我们的基础上构建自己的AMI，使用DynamoDb表存储部署的版本和AMI ID。

这是一种方法，其中ML taks更新将触发AMI构建。

在docker方式上，您应该看一下AWS ECS，它将在拉取docker映像之前减轻启动EC2实例的负担。

另一种选择是完全迁移到Amazon Machine Learning，但在这种情况下，如果需要的话，您将增加将工作迁移到AWS之外的负担。

我认为没有“最佳”方法，所有方法都是有效的，而您最满意的是应该 是您的选择:)

#3 楼

您应该看一下打包程序，我们发现它对于自动构建包括AMI在内的映像类型非常有帮助。

我们利用带有厨师簿的Chef客户预配程序来管理应用于映像，尽管支持许多其他配置程序（shell，木偶，ansible等）。我们可以从共享配置中输出docker映像，AMI和无用的盒子，所有版本均由其余的配置管理代码控制。

请参阅此处，了解适用于更广泛过程的细分。这种方法听起来很明智。

使用打包程序之类的工具意味着，如果您决定切换到容器，图像生成方面就很难转换了。

#4 楼

将容器用于此类计算节点非常有意义，并且还将提供其他优势。但这不是灵丹妙药。

要真正回答您的问题，我需要知道您如何部署系统（是使用ASG还是手动部署？还是使用诸如Ansible之类的工具进行部署？ ）。

如果您使用的是ASG，则对其进行泊坞化无法解决必须更新AMI的问题。它仍然需要更新，因为启动配置引用了它，而ASG将启动“旧”版本。当然，您可以使用Chef或类似工具使ASG实例更智能，然后让它们自行配置并获取其应运行版本的最新版本。但这意味着如果您还没有基础设施，请投资于它。而且这还意味着增加了扩展延迟，因为在启动新实例时需要花费一些时间来进行自我更新。

如果您不使用ASG，则可以推送最新的映像部署时将其部署到实例上。在这里，使用docker化解决方案确实非常方便。例如如果将实例加入Docker群中，则可以使用一条指令来部署新版本，并通过滚动升级等方式来完成。

因此，如您所见，有一个一堆方法来做到这一点。取决于您现在已经在做什么以及您的需求是什么。

#5 楼

也许您可以从软件中抽象出平台（具有基本依赖性的AMI）而受益。每次更新算法和模型时，您真的需要重新滚动AMI吗？或者，是否在更改库后重新滚动并将部署设置添加到在AMI上设置ML堆栈的设置中？如果可以对执行模型进行重新设计以支持这一点，则您的迭代速度可能会更高。

如果不能，我建议让CI流程生成并发布新的AMI或图像。