CodeDeployが東京にキタ!
AWS CodeDeployがアジア・パシフィック(東京)で利用可能になりました
早速使いたい!と思ったのですが、「そういえばデプロイの途中で失敗した場合、どんな挙動となるのか」についてよく分かってなかったので試してみた時のメモ。
具体的に失敗とはどういうことかということですが、今回の実験ではCodeDeployのフロー（下図)の最後に実施されるValidateServiceで失敗(終了ステータスコード1)とさせてみて検証。
結論
失敗した場合、CodeDeployは自動でロールバックしてくれる!とか思ってたのですが、 そんなことはない ので、失敗時の挙動はしっかり確認し、失敗した場合にどうするか、失敗しても大丈夫なように設定する方法を導入前に検討した方が良いです。
以下引用。確かにコンセプトとしてそういうことはやってないみたいですね。
AWS CodeDeploy does not directly support the concept of an automatic rollback of a deployment
Redeployments and Deployment Rollbacks
条件
- オートケールグループにELBが紐付いている
- Amazon Linux AMI 2015.03 (HVM)
- CodeDeployAegntの配置や設定などは実施済み
CodeDeploy設定の詳細は以前書いたものを参照ください。
GitHubへのpush時にCodeDeployを使ってEC2にアプリケーションをデプロイする
既存のオートスケールグループのインスタンス群にデプロイする時に失敗する場合
以下の手順で実施。
- オートスケールグループで2つのインスタンスを作成
- 成功するリビジョンのアプリをデプロイ(OK-app)
- その後失敗するリビジョンのアプリをデプロイ(NG-app)
失敗した場合、ロールバックして対象インスタンスにはOK-appが正常リストアされるかと勝手に思っていたのですが、ロールバックはしませんし、失敗するまでの処理は実行されたままの状態となります。(図でいうApplicationStopやBeforeInstallなどの処理)
なお、DeploymentConfigurationの設定でどのようにデプロイするのかという設定があります。
- AllAtOnce（一気に全部)
- HalfAtTime（半分ずつ)
- OneAtTime(一つずつ)
OneAtTimeでやってみると一つのインスタンスにデプロイして失敗した場合、以降のインスタンスでのデプロイはスキップされました。
どこの処理で失敗したか、およびその時の具体的なログなどはマネージメントコンソールからも確認可能です。
なのでデバッグや原因確認はsshログインしなくてもできそうです。
ただ、上記のようなNG-appにトラフィックが流れる状態に本番環境でなってしまうと 非常にまずい のでオートスケール連携の場合、CodeDeployのフローのApplicationStopで一旦オートスケールからデタッチしてELBからのトラフィックを止めて、validatedで問題なければ再アタッチするみたいな事が必要そうかと思われます。（そうしないとNG-appにトラフィックが流れる）
なお、本件は公式ドキュメントにELBとの連携の話が書いてあり
In your application revision's AppSpec File, instruct AWS CodeDeploy to run the register_with_elb.sh script during the ApplicationStart event and to run the deregister_from_elb.sh script during the ApplicationStop event.
となっていてデプロイの途中でELBから外す、終わったらアタッチするなどの処理をしてねというのがあったのでこういった対応が必要であるという認識が必要です。
なお、サンプルがGitHubにあったのでこれを参考にすれば良いかと思います。
awslabs/aws-codedeploy-samples
リストアですが、デプロイしたアプリのリビジョンはCodeDeployで管理はされているので手動ではありますが、OK-appを再度デプロイすればその状態に戻すことはできます。
最新のデプロイが失敗した状態でオートスケールによってEC2が起動した場合
以下で実験。
- オートスケールグループを作成
- 成功するリビジョンのアプリをデプロイ(OK-app)
- その後失敗するリビジョンのアプリをデプロイ(NG-app)
- オートスケールグループのmin,max,desireインスタンス数を1増加
上記だと新規に起動するインスタンスにはNG-appが配布されるのでは?という恐れがあったのですが、実際にはOK-appが配布され、ELBのInServiceとなりました。なるほど。
ただ、上の章で書いたようにNG-appがデプロイされた状態で何もしないとオートスケールグループ内にOK-appとNG-appがあってこれはこれでカオスとなってしまうので未然の予防(上に書いたようにNG-appにトラフィックが流れないように)が必要そうです。
オートスケール新規起動時に失敗した場合
以下で実験。
- オートスケールグループを作成
- 対象サーバーにsshログインして適当なファイルを作成する
- 「2」で作成したファイルがある場合のみ成功するデプロイを行う(NG-app)
- オートスケールグループのmin,max,desireインスタンス数を1増加
上記をすると・・
新規インスタンスが起動->CodeDeployに失敗->対象インスタンスはshutdownされて別のインスタンスが起動しようとする->・・・・ 無限ループ!
まあこのケースはあんまりない気もしますが、ありえない訳ではないのでこういうこともあるという事をしっかり認識しておくと良いかと思います。
なお、オートスケール新規起動のCodeDeployはオートスケールのライフサイクルイベントでやるようなのでこの場合、デプロイに失敗したインスタンスへのトラフィックが流れる事はなさそうです。