为了便于讨论,我有一个非常简单的cloudformation设置,其中包含一个附加了卷的EC2实例。为了保留数据,卷不是堆栈的一部分,所以即使我销毁并重建完整的堆栈,数据也不会被破坏。
我的问题是,当我为我的EC2实例创建一个新的ami
作为基本映像并升级我的堆栈以推出新映像时,我得到了可以理解的冲突。
EC2升级实例的方式是创建新实例,然后删除旧实例。但由于cloudformation脚本声明卷应该附加到实例,因此升级过程因创建升级的实例而失败,因为卷不可用。
在图像升级之间保留数据的最佳方法是什么?我现在一直在寻找合适的解决方案,但没有运气。似乎有许多狡猾的解决方案,人们对推出/升级过程中的手动任务感到满意。我想通过完全自动化基础设施来避免所有人为错误。
答案 0 :(得分:2)
您是否考虑过使用群集大小为1的AutoScalingGroup然后修改UpdatePolicy?这可以让您对给定时间内将要播放的实例数量以及更新方式进行更精细的控制。如果您能够发布模板的关键部分,它也会有所帮助。
另一个选择是使用bash或Python进行堆栈创建/更新,您可以通过编程方式附加/分离。
我能想到的另一种方法是将AutoScalingGroup minSize和maxSize设置为零(可以使用CLI完成),等待实例降速,然后使用新的AMI运行更新(和最小/最大回到1)这将使他们重新上线。
"ServerGroup" : {
"Type" : "AWS::AutoScaling::AutoScalingGroup",
"Properties" : {
"AvailabilityZones" : {
"Fn::If" : [
"UseAllAvailabilityZones",
{ "Fn::GetAZs": "" },
{"Ref" : "AvailabilityZones"}
},
"LaunchConfigurationName" : { "Ref" : "LaunchConfig" },
"MinSize" : 1,
"MaxSize" : 1,
"DesiredCapacity" : 1,
"LoadBalancerNames" : [ { "Ref" : "PublicElb" }, { "Ref" : "PrivateElb" } ],
"VPCZoneIdentifier" : { "Ref" : "Subnets" }
},
"UpdatePolicy" : {
"AutoScalingScheduledAction" : {
"IgnoreUnmodifiedGroupSizeProperties" : "true"
},
"AutoScalingRollingUpdate" : {
"MinInstancesInService" : "0",
"MaxBatchSize" : "1"
}
}
}
我还发现这个项目似乎与卷做了类似的事情。 https://github.com/thefactory/cloudformation-graphite/blob/master/graphite.json