概要

【初心者向け】AWS Code シリーズ徹底入門 - ④ AWS CodeDeploy 編 です。

本記事では、AWS CodeDeploy の機能について、マネジメントコンソールを実際に触りながら整理していきます。

機能一覧

Applications

どのアプリケーションを、どこに、どのようにデプロイするか といったデプロイに関する定義をまとめたものです。
※設定項目については後述します。

Deployment configurations

デプロイ先に対して、実際にデプロイするアプリケーションを、どれくらいの割合/間隔で実環境に展開するかを定義する設定となります。
幾つか AWS によって事前に用意されています。

カスタムで作成することも可能です

本設定を、Applications の設定項目として利用するかたちとなります。

On-premises instances

こちらは機能ではないですが、デプロイ先として CodeDeploy に認識されているオンプレミスサーバーが一覧で表示されます。

オンプレミスサーバーを、CodeDeploy のデプロイ先として認識させるための前提条件は以下ドキュメントを参照してください。

`Applications` 設定項目

Compute platform

デプロイ先(サービス)を指定する項目です。
CodeDeploy でサポートされているデプロイ先は以下 4 つとなります。

EC2
Lambda
ECS
On-premises

Deployment groups

どのリソースに、どうやってデプロイするかをまとめる設定です。

Compute platform によって設定項目が少し異なるので、分けて記載していきます。

`Compute platform` = `EC2/On-premises` の場合

Service role では、CodeDeployからAWS サービスに対して API コールを実施する際に必要な権限を付与します。

Deployment type では、実環境へのデプロイ適用方法を指定します。
In-place は、実環境で稼働している EC2 に直接デプロイし再起動する方式です。
Blue/green は、デプロイ用に別途新規 EC2 を稼働させ、トラフィックを切り替える方式です。

Environment configuration では、実際にデプロイする環境を指定します。
Deployment type によって設定項目が異なります。
「タグ」もしくは「Auto Scaling Group」により、環境を識別します。

Termination hook は、Auto Scaling Group を指定した場合のみ選択可能な項目です
こちらは、デプロイ中に、現環境の Auto Scaling Group にてスケールインが発生した際に、CodeDeploy が認識可能なライフサイクルイベントの生成を有効化するものです
ライフサイクルイベントを生成することで、後述する appspec.yml にて、生成されたイベントで独自のスクリプトを実行することが可能となります

Deployment settings では、こちらでも記述した通り、デプロイ先に対して、実際にデプロイするアプリケーションを、どれくらいの割合/間隔で実環境に展開するかを指定します。
Deployment type によって設定項目が異なります。
Blue/green の場合は、新環境へのトラフィック切り替えタイミングと現環境の終了タイミング を指定することが可能です。

Load balancer では、デプロイ先の EC2 のフロントに位置する ELB を指定します。
Deployment type によって設定項目が必須かどうかが異なります。
本設定項目を有効にすることで、ELB からのトラフィックをデプロイ中の EC2 に流入しないように制御してくれます。

Triggers では、指定したイベントが発生した際に、指定の SNS トピックにイベントを push するかを指定します。
Deployment type による相違点はありません。

Alarms では、自動ロールバック判断基準とする CloudWatch Alarm を指定します。
Deployment type による相違点はありません。

Rollbacks では、デプロイ失敗時にロールバックするかを指定します。
Deployment type による相違点はありません。
Roll back when a deployment fails オプションは、何かしらの原因(権限不足等)でデプロイに失敗した場合、自動ロールバックする設定です。
Roll back when alarm thresholds are met オプションは、上述した Alarms で指定した 1つ以上の CloudWatch Alarms がアラーム状態になった場合、自動ロールバックする設定です。
Disable rollbacks は、自動ロールバックを無効にする設定です。この場合、デプロイ失敗時は手動ロールバックが必要となります。

`Compute platform` = `Lambda` の場合

Service role では、CodeDeployからAWS サービスに対して API コールを実施する際に必要な権限を付与します。

Deployment settings では、こちらでも記述した通り、デプロイ先に対して、実際にデプロイするアプリケーションを、どれくらいの割合/間隔で実環境に展開するかを指定します。

EC2 と異なり、Deployment type の設定はなく、Blue/green のみサポート

Triggers では、指定したイベントが発生した際に、指定の SNS トピックにイベントを push するかを指定します。

Alarms では、自動ロールバック判断基準とする CloudWatch Alarm を指定します。

`Compute platform` = `ECS` の場合

Service role では、CodeDeployからAWS サービスに対して API コールを実施する際に必要な権限を付与します。

Environment configuration では、デプロイ先の ECS クラスターを指定します。

Load balancer では、デプロイ先の ECS タスクのフロントに位置する ELB を指定します。

Deployment settings では、こちらでも記述した通り、デプロイ先に対して、実際にデプロイするアプリケーションを、どれくらいの割合/間隔で実環境に展開するかを指定します。
加えて、新環境へのトラフィック切り替えタイミングと現環境の終了タイミング を指定することが可能です。

Lambda と同様に、Deployment type の設定はなく、Blue/green のみサポート

Triggers では、指定したイベントが発生した際に、指定の SNS トピックにイベントを push するかを指定します。

Alarms では、自動ロールバック判断基準とする CloudWatch Alarm を指定します。

Deployments

実際にデプロイするコード・スクリプト・定義ファイルをまとめたもの(= リビジョンと言う) をどこから取得し、どの Deployment groups にデプロイするか をまとめる設定です。
Compute platform によって設定項目が少し異なるので、分けて記載していきます。

`Compute platform` = `EC2/On-premises` の場合

Deployment settings では、デプロイ先となる Deployment group の指定と、リビジョンが格納されている場所を指定します。
リビジョンは、S3 or GitHub から指定可能です。

Additional deployment behavior settings では、一部デプロイ時の動作について指定します。
ApplicationStop lifecycle event failure オプションは、デプロイ先の EC2 で ApplicationStop イベントが失敗した場合、デプロイ処理を失敗させるかどうかの設定です。
Content options オプションは、リビジョン内にあるデプロイするファイル名が、デプロイ先の EC2 にあるファイル名と一致している場合の挙動を設定します。

`Compute platform` = `Lambda` の場合

Deployment settings では、デプロイ先となる Deployment group の指定と、リビジョンが格納されている場所を指定します。
リビジョンは、S3 or 直接定義ファイルを記述する から指定可能です。

`Compute platform` = `ECS` の場合

Notification rules

Applications 毎に作成が可能で、Applications 内で管理している Deployments のデプロイ処理結果に対して通知を送信する設定です。
設定の中身は、Compute platform にかかわらず同じです。

デプロイ処理のステータスに応じて、「SNS」「Slack」に通知が可能となります。

定義ファイル (`appspec.yml`) について

CodeDeploy によるデプロイ処理は、appspec.yml に記述されている内容を基に実行されます。
ファイル名は appspec.yml 固定でルートディレクトリに保存する必要があるのと、書き方も決まってます。
詳細は以下ドキュメントを参照してください。

まとめ（全体像）

今まで説明してきた内容の全体像は以下の通りです。

おわりに

次回は AWS CodePipeline 編 です！

🌟この記事が誰かの役に立てば幸いです！
また、ご質問やフィードバックもお待ちしています。

概要

機能一覧

Applications

Deployment configurations

On-premises instances

`Applications` 設定項目

Compute platform

Deployment groups

`Compute platform` = `EC2/On-premises` の場合

`Compute platform` = `Lambda` の場合

`Compute platform` = `ECS` の場合

Deployments

`Compute platform` = `EC2/On-premises` の場合

`Compute platform` = `Lambda` の場合

`Compute platform` = `ECS` の場合

Notification rules

定義ファイル (`appspec.yml`) について

まとめ（全体像）

おわりに

参考資料

リファレンス

概要

機能一覧

Applications

Deployment configurations

On-premises instances

Applications 設定項目

Compute platform

Deployment groups

Compute platform = EC2/On-premises の場合

Compute platform = Lambda の場合

Compute platform = ECS の場合

Deployments

Compute platform = EC2/On-premises の場合

Compute platform = Lambda の場合

Compute platform = ECS の場合

Notification rules

定義ファイル (appspec.yml) について

まとめ（全体像）

おわりに

参考資料

リファレンス

`Applications` 設定項目

`Compute platform` = `EC2/On-premises` の場合

`Compute platform` = `Lambda` の場合

`Compute platform` = `ECS` の場合

`Compute platform` = `EC2/On-premises` の場合

`Compute platform` = `Lambda` の場合

`Compute platform` = `ECS` の場合

定義ファイル (`appspec.yml`) について