跟踪AMI的后代的最佳方法是什么？

问题描述

我们有几个黄金AMI，团队已经从（孩子）那里构建了AMI，一些AMI从那些（大孩子）那里建立了AMI，现在我们想弄清楚如何将后代追踪到其父黄金AMI 。有一个/etc/os-release用于Amazon AMI，这很有用，但是很难在两者之间找到AMI。

可能的解决方案

1. AMI的标记和衰落的AMI的标记

   • 这可以工作，但需要为所有可能忘记包含的打包程序脚本提供这种标记方法。

     "tags": {
       "source_ami": "{{ .SourceAMI }}","source_ami_name": "{{ .SourceAMIName }}","source_ami_date": "{{ .SourceAMICreationDate }}"
     }
     

   • 除此之外，我们还可以创建云托管策略，以注销任何新的AMI（在特定日期之后），以在不包含上述授权标签的情况下自动注销。
   • 此方法的另一个问题是与其他帐户共享这些AMI会丢失那些共享帐户中的标签。此解决方案需要可以在子帐户中扮演角色的Lambda或packer post processor才能将AMI的标签从主构建帐户复制到子帐户。

2. Manifest json file（example）在启动时下载到EC2

   • 这不能在AMI本身上包含生成的AMI ID，因为在完成之前我们不知道AMI是什么。我们可以做的是使用清单后处理器输出a manifest.json，并根据其各自的AMI将其上传到前缀，例如aws s3 cp manifest.json s3://bucket-ami-output/<ami-id>/manifest.json，然后让EC2启动使用/etc/rc.local脚本来敲击其元数据以获取其AMI，下载相应的AMI manifest.json，检查是否存在/etc/os-<parent-id>.json例如/etc/os-0.json。如果os-0.json已经存在，则增加父ID直到可用。最后，将json文件移至系统上的可用文件。
   • 或者我们可以创建一个包含源ami而不是结果ami的文件。可以使用脚本在打包过程中命中元数据端点http://169.254.169.254/latest/meta-data/ami-id以获取当前AMI，然后将该信息转储到/etc/os-0.json文件中。

我倾向于第一种方法，或者混合使用第一种方法和第二种方法。

解决方法

暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！

如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。

小编邮箱:dio#foxmail.com (将#修改为@）