CodeDeployを利用してAutoScalingグループにサンプルアプリケーションをデプロイして確認する

こんにちは、yagiです。

本日は、CodeDeployを利用してAutoScalingグループにサンプルアプリケーションをデプロイして確認しましたのでご紹介します。途中エラーとなり対応した点もあったので、その点も記載します。

AWS CodeDeployとは？

AWS CodeDeploy は、Amazon EC2 インスタンス、およびオンプレミスで稼働するインスタンスを含む、さまざまなインスタンスへのコードのデプロイを自動化するサービスです。AWS CodeDeploy を使用すると、アプリケーションの複雑なアップデート処理、デプロイ中のダウンタイムの回避、新規機能の迅速なリリースが容易になります。AWS CodeDeploy を使用すると、エラーを起こしやすい手動操作やインフラストラクチャのサービススケールの必要性を排除しながら、デプロイの自動化を行うことが可能となり、1 つのインスタンスへのデプロイや、数千のインスタンスへのデプロイも容易に行うことができます。

（公式ドキュメントからの引用）

設定してみた

チュートリアル：CodeDeployを使用して、Amazon EC2 AutoScalingグループにアプリケーションをデプロイします

上記公式ドキュメントのチュートリアルにしたがって進めて行きましたが、途中でエラーとなり対応したポイントが２点ほどありましたのでご紹介しようと思います。 なお、以下のステップで進めました。

＞Step 1. Amazon EC2 Auto Scaling グループを作成して設定する

＞Step 2. アプリケーションをAmazon EC2 AutoScalingグループにデプロイします

＞Step 3. 結果を確認する

Step 1. Amazon EC2 Auto Scaling グループを作成して設定する

まずは起動設定を作成します。EC2コンソールで起動テンプレートに移動し、「起動テンプレートを作成」を押下します。 起動テンプレートの作成画面でチュートリアルにしたがって入力します。AMIは先日の投稿でCodeDeployエージェントをインストール済みのAMIを使用します。

なおカスタムAMIを使用する場合について、こちらに記載があります。 CodeDeployとAmazonEC2 AutoScalingでカスタムAMIを使用する

なお、セキュリティグループとIAMインスタンスプロファイルは並行して作成しました。「起動テンプレートを作成」を押下します。 作成した起動テンプレートは以下となります。タグはAutoScalingGroup側で付与することとしてここでは設定しません。

なおインスタンスタイプに「t2.micro」を選択したため、EC2インスタンスのメモリまたはハードディスクの空き容量が不足してしまい、デプロイエラーを起こしたため、 起動テンプレートの新しいバージョンを作成してt2.mediumに変更しています。

次に、AutoScalingGroupを作成します。「Auto Scaling グループを作成する」を押下します。 Auto Scaling グループ名を入力し、起動テンプレートを選択します。「次へ」を押下します。

インスタンスの購入オプションにて「起動テンプレートに準拠する」を選択し、ネットワーク にて、VPCとサブネット（複数）を選択します。

グループサイズは1を設定します。タグを追加します。「次へ」押下し、「Auto Scaling グループを作成」を押下して作成します。

設定した内容は以下となります。

Step 2. デプロイを作成する

AWSコンソールでCodeDeployコンソールに移動し、デプロイから「アプリケーション」を押下します。続いて「アプリケーションの作成」を押下します。

アプリケーション名を入力し、コンピューティングプラットフォームを「EC2/オンプレミス」を選択します。「アプリケーションの作成」を押下します。

次に、「デプロイグループの作成」を押下します。

デプロイグループ名、サービスロールを入力します。サービスロールは準備作業で作成しておく必要があります。

デプロイタイプはインプレースを選択します。環境設定で「Amazon EC2 Auto Scaling グループ」にチェックを入れ、AutoScalingGroupを選択します。

デプロイ設定でCodeDeployDefault.OneAtATimeを選択し、ロードバランサーの有効のチェックを外しておきます。「デプロイグループの作成」を押下します。

デプロイグループが作成されましたので、次に「デプロイの作成」を押下します。

リビジョンタイプにS3の方を選択して、リビジョンの場所を指定します。「デプロイの作成」を押下します。

デプロイが作成され、ステータスが進行中となります。

そして、失敗しました。

「View events」から各イベントの状況を確認していきます。

※なお、イベントについてはこちらをご参照ください。 Q: デプロイのライフサイクルイベントとは何ですか?

イベント「Install」にて失敗していることがわかります。それ以前のイベントは成功しているので、セキュリティグループやサービスへのアクセスロールなどは問題なさそうに見えます。 エラーコード「UnknownError」を押下して原因を見ていきます。

エラーメッセージ「The deployment failed because a specified file already exists at this location: /var/www/html/index.html」の内容から、 こちらは以前AMIに仕込んでおいた、稼働確認用の /var/www/html/index.html が存在していたことに原因がありましたので、削除します。

[ec2-user@ip-XXX-XXX-XXX-XXX codedeploy-agent]$ cd /var/www/html/
[ec2-user@ip-XXX-XXX-XXX-XXX html]$ ls
index.html
[ec2-user@ip-XXX-XXX-XXX-XXX html]$ sudo rm index.html
[ec2-user@ip-XXX-XXX-XXX-XXX html]$ ls
[ec2-user@ip-XXX-XXX-XXX-XXX html]$

なお原因調査にあたっては、CodeDeployエージェントのログも参照して確認しました。 CodeDeployエージェントのログは

/var/log/aws/codedeploy-agent/

配下にあるので、こちらもエラー時の調査に役立ちます。

今回は以下のエラーが出ていました。

[ec2-user@ip-XXX-XXX-XXX-XXX html]$ cd /var/log/aws/codedeploy-agent/
[ec2-user@ip-XXX-XXX-XXX-XXX codedeploy-agent]$ ls
codedeploy-agent.20210330.log  codedeploy-agent.log  codedeploy-agent.log.age
[ec2-user@ip-XXX-XXX-XXX-XXX codedeploy-agent]$ cat codedeploy-agent.20210330.log

 
 ```
 
 ERROR [codedeploy-agent(XXXX)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Network error: #<Seahorse::Client::NetworkingError: unable to connect to `codedeploy-commands.eu-central-1.amazonaws.com`; SocketError: getaddrinfo: Name or service not known>

不要なファイルを削除したところで、再度デプロイを試してみます。

成功しました。

View eventsを押下して、イベントの状況を見ていきます。

全てのイベントにおいて、成功していることがわかります。

結論

CodeDeployを利用してAutoScalingグループにサンプルアプリケーションをデプロイして確認するまでを実施しました。 初回のデプロイでエラーのため色々調査しましたので、その内容もあわせて記載しました。どこかでどなたかのお役にたてば嬉しいです。

参考リンク

デプロイの各ライフサイクルイベントについては、以下のブログでも詳しく解説されています。

CodeDeployのApplicationStopイベントフックはどう実行される?