前置き
CloudFormationのロールバック処理
CloudFormationはスタック更新に失敗するとロールバックが行われる。
EC2インスタンスの更新に失敗してロールバックが行われた場合、更新前の状態でインスタンスを起動しようとする。
その時、更新前の状態に戻せないとロールバックも失敗して詰む(ROLLBACK_FAILEDの状態)。
ドキュメントにはサポートに連絡しろって書いてある。無慈悲。
慈悲によりロールバックを継続する機能がもたらされた。
失敗の原因を取り除くことでロールバックを継続できる。
Continue Rolling Back an Update
ロールバックに失敗するパターン
EC2インスタンス起動時に、設定ファイル類をS3から取得しているとする。
更新した設定ファイルに不備があり、それでスタック更新に失敗すると設定ファイルの不備は残っているのでロールバックも失敗してしまう。
ロールバックに対応する
ロールバック時、スタックのパラメータは自動的に更新前のものが使われる。
当然といえば当然だが、CloudFormation管理外のリソースは利用者がロールバックできるようにしなければならない。
S3であればバージョニングの機能があるので、それを使ってロールバックに対応できる。
試す
構成
- S3バケットのバージョニングは有効
- CloudFormationで Auto Scaling Group と Launch Configuration を定義
- インスタンスx2起動時にS3からnginxの設定ファイルを取得(VersionID指定)
- 設定ファイルを取得したらnginx起動
- nginxの起動に失敗したらCloudFormationにインスタンス起動失敗を通知
- 2台とも起動成功しなかったらロールバック
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "CloudFormation rollback test",
"Parameters": {
"VersionId": {
"Type": "String"
}
},
"Resources": {
"Group": {
"Type": "AWS::AutoScaling::AutoScalingGroup",
"CreationPolicy": {
"ResourceSignal": {
"Count": "2",
"Timeout": "PT10M"
}
},
"UpdatePolicy": {
"AutoScalingRollingUpdate": {
"MaxBatchSize": "1",
"MinInstancesInService": "1",
"WaitOnResourceSignals": "true",
"PauseTime": "PT10M"
},
"AutoScalingScheduledAction": {
"IgnoreUnmodifiedGroupSizeProperties": "true"
}
},
"Properties": {
"LaunchConfigurationName": { "Ref": "LaunchConfig" },
"VPCZoneIdentifier": [
"subnet-XXXXXXXX"
],
"HealthCheckType": "EC2",
"DesiredCapacity": "2",
"MinSize": "2",
"MaxSize": "2"
}
},
"LaunchConfig": {
"Type": "AWS::AutoScaling::LaunchConfiguration",
"Properties": {
"BlockDeviceMappings": [
{
"DeviceName": "/dev/xvda",
"Ebs": {
"VolumeType": "gp2",
"VolumeSize": "8",
"DeleteOnTermination": "true"
}
}
],
"IamInstanceProfile": "test",
"ImageId": "ami-383c1956",
"InstanceType": "t2.micro",
"InstanceMonitoring": "false",
"UserData": {
"Fn::Base64": {
"Fn::Join": [
"", [
"#!/bin/bash\n",
"yum update -y aws-cfn-bootstrap\n",
"yum install -y nginx\n",
"aws s3api get-object",
" --bucket XXXXXXX",
" --key nginx.conf",
" --version-id '", {"Ref": "VersionId"}, "'",
" /etc/nginx/nginx.conf\n",
"service nginx start\n",
"/opt/aws/bin/cfn-signal -e $?",
" --stack ", {"Ref": "AWS::StackName"},
" --resource Group",
" --region ", {"Ref": "AWS::Region"}
]
]
}
}
}
}
}
}
実行
1. S3のバージョニング有効化
あらかじめバケットの設定でバージョニングを有効にしておく。
2. S3に設定ファイルをアップロード
nginx.confは空でも起動はするので空にした。
3. スタック作成→成功
nginx.confのVersionIDを指定してスタック作成。
作成に成功し(CREATE_COMPLETE)、インスタンスが2台起動する。
Received SUCCESS signal with UniqueId i-XXXXXXXX
Received SUCCESS signal with UniqueId i-XXXXXXXX
4. S3の設定ファイル更新
nginx.confにhogeと書いてS3にアップロード。
5. スタック更新→失敗
nginx.confのVersionIDを指定してスタック更新。
VersionIDはuser-data内で使用されているので、LaunchConfigurationに変更があったとみなされ自動的にローリングアップデートが始まる。
1台目のnginxの起動が失敗し、スタックの更新が中止される(UPDATE_FAILED)。
Received 1 FAILURE signal(s) out of 2. Unable to satisfy 100% MinSuccessfulInstancesPercent requirement
6. ロールバック→成功
スタック更新失敗後、ロールバックが始まる(UPDATE_ROLLBACK_IN_PROGRESS)。
更新前のVersionIDで再度インスタンスが起動する。
旧バージョンの設定ファイルは正しいので起動に成功する(UPDATE_ROLLBACK_COMPLETE)。
Received SUCCESS signal with UniqueId i-XXXXXXXX
まとめ
CloudFormation管理外のリソースをロールバック対応させるためには利用者側の考慮が必要。
S3ならVersionIDが使える。
複数の設定ファイルはLambdaで自動的に*.gz化してバージョニングすると楽そう。