CloudFormation AutoScalingGroup不等待更新/放大信号

本文介绍了CloudFormation AutoScalingGroup不等待更新/放大信号的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 29岁程序员，3月因学历无情被辞！ 我正在使用CloudFormation模板，该模板可根据我的要求调出尽可能多的实例，并希望在堆栈创建/更新被视为完成之前等待它们完成初始化（通过用户数据）。 期望 创建或更新堆栈应等待所有新创建实例的信号，以确保初始化完成 如果创建的任何实例均未初始化，我不希望将堆栈创建或更新视为成功。 现实 CloudFormation似乎仅在首次创建堆栈时等待实例发出的信号。更新堆栈和增加实例数似乎忽略了信令。更新操作非常快速地成功完成，而实例仍在初始化中。 由于更新堆栈而创建的实例可能无法初始化，但是更新操作会已经被认为是成功的。 问题 使用CloudFormation，我如何才能使现实满足 我希望创建堆栈时和更新堆栈时具有相同的行为。 类似问题 我只找到了与我的问题相符的以下问题： 已经开放了一年，没有收到答案。 我正在创建另一个问题，因为我有更多信息可以咨询。 dd，我不确定这些细节是否与该问题中的作者相匹配。 复制 此AWS文档页面上的Auto Scaling Group标头，其中包括信令。 创建的模板已进行如下修改： 它使用Ubuntu AMI（在 ap-northeast-1 地区）。 cfn-signal 命令已被引导并考虑到此更改在必要时调用。 一个新参数指示要在其中启动多少个实例自动缩放组。 在发出信号之前添加了2分钟的睡眠时间，以模拟初始化时所花费的时间。 这是模板，保存到 template.yml ： 参数：所需容量：类型：数字说明：您希望在Auto Scaling组中有多少个实例？ 资源： AutoScalingGroup：类型：AWS :: AutoScaling :: AutoScalingGroup 属性： AvailabilityZones：！GetAZs'' LaunchConfigurationName ：！Ref LaunchConfig 最小大小：！Ref DesiredCapacity 最大大小：！Ref DesiredCapacity CreationPolicy： ResourceSignal：计数：！Ref DesiredCapacity 超时：PT5M UpdatePolicy： AutoScalingScheduledAction： IgnoreUnmodifiedGroupSizeProperties：true AutoScalingRollingUpdate： MinInstancesInService：1 MaxBatchSize：2 PauseTime：PT5M WaitOnResourceSignals：真 LaunchConfig：类型：AWS :: AutoScaling :: LaunchConfiguration 属性： ImageId：ami-b7d829d6 InstanceType：t2.micro 用户数据：'Fn :: Base64'：！Sub | ＃！/ bin / bash -xe sleep 120 apt-get -y install python-setuptools TMP =`mktemp -d` 卷曲https://s3.amazonaws.com/cloudformation-examples/aws-cfn-bootstrap-latest.tar.gz | \ tar xz -C $ TMP --strip-components 1 easy_install $ TMP / usr / local / bin / cfn-signal -e $？ \ --stack $ {AWS :: StackName} \ -资源AutoScalingGroup \ --region $ {AWS :: Region} 现在，我通过以下方式创建具有单个实例的堆栈： $ aws cloudformation创建堆栈\ --region = ap-northeast-1 \ --stack-name = asg-test \ - -template-body = file：//template.yml \ --parameters ParameterKey =所需容量，ParameterValue = 1 等待几分钟完成创建后，让我们看一些关键的堆栈事件： $ aws cloudformation describe-stack-events \ --region = ap-northeast-1 \ --stack-name = asg-test   ... { Timestamp： 2017-02-03T05：36：45.445Z， ... LogicalResourceId： AutoScalingGroup， ... ResourceStatus： CREAT E_COMPLETE， ... }， { Timestamp： 2017-02-03T05：36：42.487Z， ... LogicalResourceId： AutoScalingGroup， ... ResourceStatusReason：接收到的具有UniqueId的SUCCESS信号...， ResourceStatus： CREATE_IN_PROGRESS }， { Timestamp： 2017-02-03T05：33：33.274Z， ... LogicalResourceId： AutoScalingGroup， ... ResourceStatusReason：已启动资源创建， ResourceStatus： CREATE_IN_PROGRESS， ... } .. 。 您可以看到自动缩放组在05:33:33开始启动。在05:36:42（启动后3分钟），它收到了成功信号。这样一来，自动缩放组仅在之后的05:36:45才达到自己的成功状态。 这太棒了-就像一个魅力。 现在，让我们尝试通过更新堆栈将此自动伸缩组中的实例数增加到2： $ aws cloudformation更新堆栈\ --region = ap-northeast-1 \ --stack-name = asg-test \ --template -body = file：//template.yml \ --parameters ParameterKey =所需容量，ParameterValue = 2 在等待更短的时间以完成更新之后，让我们看一些新的堆栈事件： $ aws cloudformation describe-stack-events \ --region = ap-northeast-1 \ --stack-name = asg-test   { ResourceStatus： UPDATE_COMPLETE， ... ResourceType： AWS :: CloudFormation :: Stack， ... Timestamp： 2017-02-03T05：45：47.063Z }， ... { ResourceStatus ： UPDATE_COMPLETE， ... LogicalResourceId： AutoScalingGroup， Timestamp： 2017-02-03T05：45：43.047Z }， { ResourceStatus： UPDATE_IN_PROGRESS， ...， LogicalResourceId： AutoScalingGroup， Timestamp： 2017-02- 03T05：44：20.845Z }， { ResourceStatus： UPDATE_IN_PROGRESS， ... ResourceType： AWS :: CloudFormation :: Stack， ... 时间戳： 2017-02-03T05：44：15.671Z， ResourceStatusReason：用户启动 } ， .... 现在，您可以看到自动缩放组开始更新在05:44:20，它已在05:45:43完成-不到一分半钟才能完成，考虑到用户数据中的120秒睡眠时间，这是明智的。 然后，堆栈更新将继续进行，而自动伸缩组不会收到任何信号。 新实例确实存在。 在我的实际用例中，我通过SSH进入了这些新实例之一来查找即使堆栈更新完成后，它仍在初始化过程中。 我尝试过的内容 我已阅读并重新阅读了 CreationPolicy 和 UpdatePolicy ，但未能识别出我所缺少的内容。 看一下上面使用的更新策略，我不知道它实际上在做什么。为什么 WaitOnResourceSignals 为真，却没有等待？ 还是这些新实例不属于滚动更新策略？如果它们不属于那里，那么我希望它们会受创建政策的约束，但这似乎也不适用。 因此，我 我有一个偷偷摸摸的感觉，它的功能符合设计/预期的要求，但是如果的话，这意味着什么呢？ c $ c> WaitOnResourceSignals 属性，如何满足上面的期望？解决方案 a href = http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-updatepolicy.html#cfn-attributes-updatepolicy-rollingupdate rel = noreferrer> AutoScalingRollingUpdate 策略可处理Auto Scaling组中的整个实例集，以响应对基础 LaunchConfiguration 的更改。它不适用于对现有组中实例数的单独更改。根据 UpdatePolicy属性文档， AutoScalingReplacingUpdate 和 AutoScalingRollingUpdate 策略仅在您执行以下一项或多项操作时适用： 更改Auto Scaling组的 AWS :: AutoScaling :: LaunchConfiguration 。 更改Auto Scaling组的 VPCZoneIdentifier 属性 更新一个Auto Scaling组，其中包含与当前 LaunchConfiguration 不匹配的实例。 更改Auto Scaling组的 DesiredCapacity 属性不在此列表中，因此 AutoScalingRollingUpdate 策略不适用于此类更改。 据我所知，这是不可能的（通常g标准的AWS CloudFormation资源）以延迟完成修改 DesiredCapacity 的堆栈更新的完成，直到完全配置了添加到Auto Scaling组的任何新实例为止。 以下是一些替代选择： 而不是仅修改 DesiredCapacity ，同时修改 LaunchConfiguration 属性。这将触发 AutoScalingRollingUpdate 达到所需的容量（缺点是它还将更新现有实例，而实际上可能不需要修改）。 添加 AWS :: AutoScaling :: LifecycleHook 资源到您的Auto Scaling组，然后调用 除 > cfn-signal ，表示生命周期挂钩完成。这不会延迟您的CloudFormation堆栈更新，但会 将各个自动缩放的实例延迟进入 InService 状态，直到生命周期接收到信号。 （有关更多信息，请参见生命周期挂钩文档信息。） 作为对＃2的扩展，应该可以将生命周期挂钩添加到您的Auto Scaling组中，以及一个自定义资源会轮询您的Auto Scaling组，并且仅在Auto Scaling组包含 DesiredCapacity 处于 InService 状态的实例数。 I'm working with a CloudFormation template that brings up as many instances as I request, and want to wait for them to finish initialising (via User Data) before the stack creation/update is considered complete.The ExpectationCreating or updating the stack should wait for signals from all newly created instances, such to ensure that their initialisation is complete.I don't want the stack creation or update to be considered successful if any of the created instances fail to initialise.The RealityCloudFormation only seems to wait for signals from instances when the stack is first created. Updating the stack and increasing the number of instances seems to disregard signalling. The update operation finishes successfully very quickly, whilst instances are still being initialised.Instances created as a result of updating the stack can fail to initialise, but the update action would've already been considered a success.The QuestionUsing CloudFormation, how can I make the reality meet the expectation?I want the same behaviour that applies when the stack is created, to when the stack is updated.Similar QuestionsI have found only the following question that matches my problem: UpdatePolicy in Autoscaling group not working correctly for AWS CloudFormation updateIt's been open for a year and has not received an answer.I'm creating another question as I've more information to add, and I'm not sure if these particulars will match those of the author in that question.ReproducingTo demonstrate the problem, I've created a template based off of the example beneath the Auto Scaling Group header on this AWS documentation page, which includes signalling.The created template has been adapted as so:It uses an Ubuntu AMI (in region ap-northeast-1). The cfn-signal command has been bootstrapped and called as necessary considering this change.A new parameter dictates how many instances to launch in the auto scaling group.A sleep time of 2 minutes has been added before signalling, to simulate the time spent whilst initialising.Here's the template, saved to template.yml:Parameters: DesiredCapacity: Type: Number Description: How many instances would you like in the Auto Scaling Group?Resources: AutoScalingGroup: Type: AWS::AutoScaling::AutoScalingGroup Properties: AvailabilityZones: !GetAZs '' LaunchConfigurationName: !Ref LaunchConfig MinSize: !Ref DesiredCapacity MaxSize: !Ref DesiredCapacity CreationPolicy: ResourceSignal: Count: !Ref DesiredCapacity Timeout: PT5M UpdatePolicy: AutoScalingScheduledAction: IgnoreUnmodifiedGroupSizeProperties: true AutoScalingRollingUpdate: MinInstancesInService: 1 MaxBatchSize: 2 PauseTime: PT5M WaitOnResourceSignals: true LaunchConfig: Type: AWS::AutoScaling::LaunchConfiguration Properties: ImageId: ami-b7d829d6 InstanceType: t2.micro UserData: 'Fn::Base64': !Sub | #!/bin/bash -xe sleep 120 apt-get -y install python-setuptools TMP=`mktemp -d` curl https://s3.amazonaws.com/cloudformation-examples/aws-cfn-bootstrap-latest.tar.gz | \ tar xz -C $TMP --strip-components 1 easy_install $TMP /usr/local/bin/cfn-signal -e $? \ --stack ${AWS::StackName} \ --resource AutoScalingGroup \ --region ${AWS::Region}Now I create the stack with a single instance, via:$ aws cloudformation create-stack \ --region=ap-northeast-1 \ --stack-name=asg-test \ --template-body=file://template.yml \ --parameters ParameterKey=DesiredCapacity,ParameterValue=1After waiting a few minutes for the creation to complete, let's look some key stack events:$ aws cloudformation describe-stack-events \ --region=ap-northeast-1 \ --stack-name=asg-test  ... { "Timestamp": "2017-02-03T05:36:45.445Z", ... "LogicalResourceId": "AutoScalingGroup", ... "ResourceStatus": "CREATE_COMPLETE", ... }, { "Timestamp": "2017-02-03T05:36:42.487Z", ... "LogicalResourceId": "AutoScalingGroup", ... "ResourceStatusReason": "Received SUCCESS signal with UniqueId ...", "ResourceStatus": "CREATE_IN_PROGRESS" }, { "Timestamp": "2017-02-03T05:33:33.274Z", ... "LogicalResourceId": "AutoScalingGroup", ... "ResourceStatusReason": "Resource creation Initiated", "ResourceStatus": "CREATE_IN_PROGRESS", ... } ...You can see that the auto scaling group started initiating at 05:33:33. At 05:36:42 (3 minutes after initiation), it received a success signal. This allowed the auto scaling group to reach its own success status only moments after, at 05:36:45.That's awesome - working like a charm.Now let's try increasing the number of instances in this auto scaling group to 2 by updating the stack:$ aws cloudformation update-stack \ --region=ap-northeast-1 \ --stack-name=asg-test \ --template-body=file://template.yml \ --parameters ParameterKey=DesiredCapacity,ParameterValue=2After waiting a much shorter time for the update to complete, let's look at some of the new stack events:$ aws cloudformation describe-stack-events \ --region=ap-northeast-1 \ --stack-name=asg-test  { "ResourceStatus": "UPDATE_COMPLETE", ... "ResourceType": "AWS::CloudFormation::Stack", ... "Timestamp": "2017-02-03T05:45:47.063Z" }, ... { "ResourceStatus": "UPDATE_COMPLETE", ... "LogicalResourceId": "AutoScalingGroup", "Timestamp": "2017-02-03T05:45:43.047Z" }, { "ResourceStatus": "UPDATE_IN_PROGRESS", ..., "LogicalResourceId": "AutoScalingGroup", "Timestamp": "2017-02-03T05:44:20.845Z" }, { "ResourceStatus": "UPDATE_IN_PROGRESS", ... "ResourceType": "AWS::CloudFormation::Stack", ... "Timestamp": "2017-02-03T05:44:15.671Z", "ResourceStatusReason": "User Initiated" }, ....Now you can see that whilst the auto scaling group started updating at 05:44:20, it completed at 05:45:43 - that's less than one and a half minutes to completion, which shouldn't be possible considering a sleep time of 120 seconds in the user data.The stack update then proceeds to completion without the auto scaling group ever having received any signals.The new instance does indeed exist.In my real use case I've SSHed into one of these new instances to find that it was still in the process of initialising even after the stack update completed.What I've TriedI've read and re-read the documentation surrounding CreationPolicy and UpdatePolicy, but have failed to identify what I'm missing.Taking a look at the update policy in use above, I don't understand what it's actually doing. Why is WaitOnResourceSignals true, but it's not waiting? Is it serving some other purpose?Or are these new instances not falling under the "rolling update" policy? If they don't belong there, then I'd expect them to fall under the creation policy, but that doesn't seem to apply either.As such, I don't really know what else to try.I have a sneaking feeling that it's functioning as designed/expected, but if it is then what's the point of that WaitOnResourceSignals property and how can I meet the expectation set above? 解决方案 The AutoScalingRollingUpdate policy handles rotating out an entire set of instances in an Auto Scaling group in response to changes to the underlying LaunchConfiguration. It doesn't apply to individual changes to the number of instances in the existing group. According to the UpdatePolicy Attribute documentation, The AutoScalingReplacingUpdate and AutoScalingRollingUpdate policies apply only when you do one or more of the following: Change the Auto Scaling group's AWS::AutoScaling::LaunchConfiguration. Change the Auto Scaling group's VPCZoneIdentifier property Update an Auto Scaling group that contains instances that don't match the current LaunchConfiguration.Changing the Auto Scaling group's DesiredCapacity property is not in this list, so the AutoScalingRollingUpdate policy does not apply to this type of change.As far as I know, it is not possible (using standard AWS CloudFormation resources) to delay the completion of a Stack Update modifying DesiredCapacity until any new instances added to the Auto Scaling Group are fully provisioned.Here are some alternative options:Instead of modifying only DesiredCapacity, modify a LaunchConfiguration property at the same time. This will trigger an AutoScalingRollingUpdate to the desired capacity (the downside is that it will also update existing instances, which may not actually need to be modified).Add an AWS::AutoScaling::LifecycleHook resource to your Auto Scaling Group, and call aws autoscaling complete-lifecycle-action in addition to cfn-signal, to signal lifecycle-hook completion. This won't delay your CloudFormation stack update as desired, but it will delay the individual auto-scaled instances from entering the InService state until the lifecycle signal is received. (See Lifecycle Hooks documentation for more info.)As an extension to #2, it should be possible to add a Lifecycle Hook to your Auto Scaling group, as well as a Custom Resource that polls your Auto Scaling Group and only completes when the Auto Scaling group contains the DesiredCapacity number of instances all in the InService state. 这篇关于CloudFormation AutoScalingGroup不等待更新/放大信号的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！