Sample Remote SWE Agents 项目中的 AMI 垃圾回收机制实现

Sample Remote SWE Agents 项目中的 AMI 垃圾回收机制实现

sample-remote-swe-agents Autonomous SWE agent working in the cloud! 项目地址: https://gitcode.com/gh_mirrors/sa/sample-remote-swe-agents

在云计算环境中，随着持续集成和持续部署(CI/CD)流程的不断运行，系统会积累大量不再使用的Amazon Machine Images(AMI)。这些未被清理的AMI不仅占用存储空间，还会产生不必要的费用。本文将深入分析Sample Remote SWE Agents项目中实现的AMI垃圾回收机制。

AMI垃圾回收的必要性

在远程软件开发环境(Remote SWE)代理项目中，EC2实例的创建依赖于预先构建的AMI。随着项目迭代和更新，系统会生成大量新版本的AMI，而旧版本往往会被遗弃。这些未被清理的AMI会带来两个主要问题：

1. 存储成本增加：每个AMI都会占用Amazon EBS存储空间，长期积累会导致显著的成本上升
2. 管理复杂度提高：大量无用AMI会使得资源管理变得困难，影响运维效率

技术实现方案

项目采用AWS CDK和Lambda函数结合的方式实现了自动化的AMI垃圾回收机制。核心逻辑部署在EC2垃圾回收构造体(EC2-GC construct)中，通过定时触发的Lambda函数执行清理任务。

AMI筛选策略

Lambda函数执行时，会通过EC2 DescribeImages API获取所有符合条件的AMI，筛选条件包括：

• 所有权属于当前账户(owner:Self)
• AMI名称以指定的imageRecipeName开头
• 创建时间超过24小时
• 不是当前正在使用的AMI(通过比对系统参数存储中的'/remote-swe/worker/ami-id'值)

清理流程

对于符合清理条件的AMI，系统会执行以下操作：

1. 删除AMI本身：直接移除不再使用的Amazon Machine Image
2. 清理关联资源：通过AMI标签中的Ec2ImageBuilderArn信息，找到并删除对应的EC2 Image Builder资源

这种双重清理机制确保了不会留下任何孤立的资源，避免了潜在的资源泄漏问题。

实现细节

在代码实现上，项目采用了TypeScript编写Lambda函数，主要处理逻辑包括：

1. 获取当前活跃的AMI ID(从系统参数存储)
2. 查询所有符合条件的AMI
3. 应用时间过滤条件(创建超过24小时)
4. 排除当前活跃的AMI
5. 执行删除操作(包括AMI本身和对应的Image Builder资源)

这种实现方式既保证了系统的稳定性(不会误删正在使用的资源)，又实现了资源的及时回收，有效控制了云资源成本。

最佳实践建议

基于此实现，我们可以总结出一些云资源管理的通用最佳实践：

1. 为所有自动生成的资源添加一致的命名前缀或标签，便于后续管理
2. 实现自动化清理机制，避免依赖人工操作
3. 保留足够的缓冲时间(如24小时)，防止误删可能还需要使用的资源
4. 清理时考虑资源间的关联性，确保完整清理所有相关资源
5. 通过系统参数或配置中心管理关键资源ID，便于状态查询和验证

这种自动化垃圾回收机制不仅适用于AMI管理，也可以推广到其他云资源的生命周期管理中，是云原生架构中成本优化的重要手段之一。

sample-remote-swe-agents Autonomous SWE agent working in the cloud! 项目地址: https://gitcode.com/gh_mirrors/sa/sample-remote-swe-agents