Amazon Web Services ブログ
GitHub Actions と AWS CodeBuild テストを使用して Amazon ECS の CI/CD パイプラインを作成する
Amazon Elastic Container Service (Amazon ECS) は、フルマネージド型のコンテナオーケストレーションサービスであり、コンテナ化されたワークロードを大規模かつ簡単に運用できます。 また、Amazon Route 53、AWS Identity and Access Management (IAM)、Amazon CloudWatch などの他の主要な AWS のサービスと統合します。 コンテナの管理に使用しているプラットフォームに関係なく、コンテナ化されたアプリケーションにとって効果的かつ効率的な CI/CD パイプラインを確立することは重要です。
この投稿では、ソースコードリポジトリとして GitHub を使用している組織が、GitHub アクションを使用して Amazon ECS にデプロイされたアプリケーション用の完全な CI/CD パイプラインを構築する方法を探り、そのデモを行います。 また、この投稿では、完全な CI/CD パイプラインの一部としてアプリケーションテストを実行するための、GitHub Actions を用いた AWS CodeBulid の使用方法を説明します。
Amazon ECS または AWS CodeBuild を初めて使用する場合は、「Amazon ECS の使用開始」および「AWS の開発者用ツール」をご覧ください。
GitHub Actions
GitHub をソースコードリポジトリとして使用している組織の場合、GitHub Actions は、GitHub イベントでワークフローを開始することにより、GitHub に複雑な CI/CD 機能を直接実装することを可能にします。
GitHub Action は、他の GitHub Actions と組み合わせて、特定の GitHub イベント (プル、プッシュ、コミットなど) に応答してトリガーされるワークフローを作成できる個々の機能ユニットです。 ワークフローは、GitHub がホストするサーバーの管理環境内で実行されます。
Amazon ECS で実行されているアプリケーションの CI/CD 操作をサポートするために、AWS は github.com/aws-actions で次の JavaScript ベースの GitHub Actions をオープンソース化しました。
- github.com/aws-actions/configure-aws-credentials – 他の GitHub Acions で使用するために AWS 認証情報とリージョン環境変数を設定する
- github.com/aws-actions/amazon-ecr-login – ローカル Docker クライアントを 1 つ以上の Amazon Elastic Container Registry (ECR) レジストリにログインさせる
- github.com/aws-actions/amazon-Amazon ECS-render-task-definition – Amazon ECS タスク定義 JSON ファイルにコンテナイメージ URI を挿入する
- github.com/aws-actions/amazon-Amazon ECS-deploy-task-definition – Amazon ECS タスク定義を登録し、Amazon ECS サービスにデプロイする
AWS および GitHub によって提供されるものに加えて、カスタム GitHub Actions を使用してワークフローを構築することにより、GitHub から直接、Amazon ECS アプリケーションの CI/CD 機能を簡単に提供できます。
AWS CodeBulid を使用したテスト
GitHub がソースコードリポジトリとして使用される場合、AWS CodeBulid は webhook をサポートします。 これにより、CodeBulid は、GitHub に保存されたソースコードを操作し、コード変更が GitHub リポジトリにプッシュされるたびに webhook を使用してソースコードのビルドをトリガーできます。
CodeBuild は、アプリケーションコードのコンパイルまたはアプリケーションコンテナイメージの構築以外にも使用できます。 CodeBuild を使用することで、ユニットテスト、静的コード解析、統合テストなど、コードに対してさまざまなテストを簡単に実行できます。 CI/CD パイプラインを構築する場合、「テスト」ステージを含めることは、アプリケーションの品質基準を維持するために重要です。
この投稿では、CI/CD パイプラインの「ビルド」アクションとして CodeBuild を使用しません。 代わりに、テストを実行する環境として CodeBuild を使用します。CodeBuild をテストプラットフォームとして使用すると、AWS にデプロイされたアプリケーションのテストを簡単に実行できます。 他の AWS のサービスと簡単に統合できる管理された環境を提供することに加えて、CodeBuild プロジェクトを実行して、AWS の外部に到達できないコンポーネントとの統合テストを実行できます。 また、ユニットテストと統合テストの結果から、CodeBuild を使用してテストレポートを生成することもできます。 この投稿の例では、CodeBuild を使用して単純なユニットテストを実行し、ステータスを GitHub に報告します。
サンプルアーキテクチャ
次の図は、実装する高レベルアーキテクチャを示しています。 このアーキテクチャは、GitHub ワークフローを使用してリポジトリへのコミットごとに ECS へのアプリケーションの構築、テスト、デプロイを自動的に調整する完全な CI/CD パイプラインを表します。 この GitHub ワークフローは、AWS オープンソース GitHub Actions を使用してタスクのビルドとデプロイを調整し、CodeBuild を使用してアプリケーションテストを実行します。 また、このパイプラインにカスタム GitHub Action を導入して、CodeBuild テストのステータスを評価します。

GitHub Actions と CodeBuild を使用した ECS アプリケーション用 CI/CD パイプライン
GitHub リポジトリは、シンプルなウェブアプリケーションとそれに付随するインフラストラクチャファイルで構成されています。 CI/CD パイプラインの目標は、ユニットテストの実行、コンテナイメージの構築、コンテナイメージの ECR へのアップロード、GitHub リポジトリへのコミットごとの ECS タスク定義の更新です。
GitHub リポジトリの作成
サンプルアーキテクチャの構築に必要なコンポーネントの作成を開始するには、GitHub リポジトリが必要です。 このプロセスに慣れていない場合は、「GitHub でリポジトリを作成する」をご覧ください。 この例では、次のファイルを GitHub リポジトリに配置する必要があります。
-
app.py
: シンプルな Flask ウェブアプリケーション。 このアプリケーションには、要求された URI を反転して返す 1 つのエンドポイントが含まれます
-
app_test.py
: 文字列が正しく反転されることを確認するためのapp.py
のユニットテストファイル
-
requirements.txt
:app.py
の依存関係
flask==1.0.2
-
buildspec.yml
: AWS CodeBulid がユニットテストを実行するための手順。 buildspec ファイルで使用可能な機能および構文の詳細については、「ビルド仕様のリファレンス」を参照してください。
-
Dockerfile
: アプリケーションコンテナイメージの構築手順
FROM python:3
# Set application working directory
WORKDIR /usr/src/app
# Install requirements
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt
# Install application
COPY app.py ./
# Run application
CMD python app.py
-
task-definition.json
: ECS タスク定義の仕様。 注意: このファイルで、プレースホルダーの値を AWS アカウント ID に置き換えます
このステップの最終結果は、すべてのアプリケーション、テスト、およびデプロイメントファイルを含む GitHub リポジトリになるはずです。

GitHub リポジトリの例
ECS インフラストラクチャの作成
ソリューションの概要で説明されているアーキテクチャを構築するには、次の ECS コンポーネントが必要です。
- ECR リポジトリー: バージョン管理されたアプリケーションコンテナイメージを保存します
- ECS クラスター: アプリケーションコンテナインスタンスを実行するための計算能力を提供します
- ECS タスク定義: アプリケーションコンテナイメージのバージョンと環境の考慮事項を指定します
- ECS サービス: 基になる計算リソースにタスク定義をデプロイする方法を指定します
このインフラストラクチャを構築するには、AWS Cloud Development Kit (CDK) を使用します。CDK を初めて使用する場合は、AWS CDK の使用開始を参照してください。この投稿では、Python 3.7 で CDK を使用します。
アプリケーションインフラストラクチャを作成する方法:
1.以下のテンプレートで説明されているリソース (VPC、ECS、ECR、IAM ロール) を作成する権限を持つ IAM ユーザーで AWS CLI を設定します。カスタムユーザーとポリシーの作成の詳細については、「IAM アクセス許可の管理」を参照してください。
2.次のコマンドを実行して、CDK プロジェクトを初期化します
3.ファイルの内容の ecs_devops_sandbox_cdk/ecs_devops_sandbox_cdk_stack.py
(CDK によって自動作成されます) を以下のコードに置き換えます
4.CDK プロジェクトのルートディレクトリから次のコマンドを実行します
このコードは、CDK を使用して、アプリケーションに必要な ECS インフラストラクチャを含む CloudFormation スタックを構築およびデプロイします。 上記のコードでは、パブリック AWS サンプルレジストリのサンプルコンテナで実行するタスク定義を最初に指定しています。 CI/CD パイプラインがタスク定義を更新すると、このサンプルコンテナはアプリケーションコンテナに置き換えられます。 サンプルレジストリのコンテナを使用して、アプリケーションコンテナイメージが ECR リポジトリに追加される前にサービスを安定させます。
このステップの最終結果は、タスク定義 ecs-devops-sandbox-task-definition
で構成されるサービス ecs-devops-sandbox-service
を実行するクラスター ecs-devops-sandbox-cluster
になります。
CodeBuild プロジェクトの作成
CodeBulid は、アプリケーションテストを実行し、これらのテストのステータスを GitHub に提供するために使用されます。 テストに合格しない場合、CodeBulid はビルドを Failed
としてマークし、このステータスは GitHub に報告されます。 このアーキテクチャでは、GitHub リポジトリの master
ブランチへのコミットがあるたびに、CodeBulid によって自動的に作成される webhook を使用して、アプリケーションコードのビルドをトリガーします。
GitHub と統合して CodeBulid プロジェクトを作成する方法:
1. AWS CodeBulid に移動し、[Create build project] を選択します
2. [Project Configuration] で [Project name] に ecs-devops-sandbox
と入力します

CodeBuild プロジェクトの設定の例
3. [Source] の [Source Provider] で [GitHub] を選択します
4. [Source] の [Repository] で [Connect using OAuth] を選択し、[Connect to GitHub] を選択します
5. ポップアップウィンドウで、使用するリポジトリを所有する GitHub アカウントにログインします
6. [Source] の [Repository] で [Repository in my GitHub account] を選択します
7. [Source] の [GitHub repository] で前に設定したリポジトリを選択します
8. [Source – Additional configuration] の [Build Status – optional] でボックスにチェックを入れます

CodeBuild ソースの設定の例
9. [Primary source webhook events] の [Webhook – optional] でボックスにチェックを入れます

CodeBuild webhook の設定の例
10.[Environment] の [Environment image] で [Managed image] を選択します
11.[Environment] の [Operating system] で [Ubuntu] を選択します
12.[Environment] の [Runtime] で [Standard] を選択します
13.[Environment] の [Image] で [aws/AWS CodeBulid/standard:3.0] を選択します

CodeBuild 環境の設定の例
14.残りのデフォルト値のまま、[Create build project] を選択します
GitHub ワークフローの作成
AWS は、AWS オープンソース GitHub Actions を利用して、リポジトリの master
ブランチへのコミットごとに、ECS でコンテナを構築およびデプロイするスターター GitHub ワークフローを提供しています。
スターター GitHub ワークフローを GitHub リポジトリに追加する方法:
1. [Actions] タブで [New workflow] を選択します

GitHub ワークフローの追加の例
2. [Deploy to Amazon ECS] を検索して、[Set up this workflow] を選択します

AWS ECS スターターワークフローの追加の例
3. このワークフローをアプリケーションで使用するには、スターターワークフローファイルに記載されている指示に従ってください。 すでに ECR リポジトリ、ECS タスク定義、ECS クラスター、ECS サービスを作成していることに留意してください。

ECS のための GitHub ワークフローの例
実際には、CodeBulid で実行されたテストが成功した場合にのみ、GitHub ワークフローで新しいコンテナを構築して ECS にデプロイする必要があります。 前に作成した CodeBulid プロジェクトは、コミットごとにビルド実行の成功または失敗を GitHub に報告します。 CodeBulid プロジェクトがコミットに失敗した場合、GitHub はこのコミットに failure
のステータスをマークします。 CodeBuild プロジェクトが成功または失敗をまだ報告していない場合、GitHub はこのコミットに pending
のステータスをマークします (詳細は、「GitHub のコミットステータス」を参照してください)。
この例では、master
ブランチへのコミットごとに、GitHub ワークフローと CodeBulid プロジェクトを並行して実行しています。 ワークフローが必要なテストに合格しないコミットをデプロイしないようにするため、スターター GitHub ワークフローに追加のステップを導入して、コミットのステータスを確認します。
以下のコードは、新しい GitHub Action である「Check commit status」を含む完全な GitHub ワークフロー (AWS が提供するスターターワークフローに基づく) を示しています。 この新しい GitHub Action は、GitHub によってプロビジョニングされた環境と変数を使用して、GitHub API から現在のコミットのステータスをクエリします。 現在のコミットが pending
の場合、10 秒後に再度確認します。 コミットステータスが failure
の場合、つまり CodeBulid テストに合格しなかった場合、GitHub ワークフローは失敗します。
結果
AWS CodeBulid プロジェクトと GitHub ワークフローを配置すると、すべてのテストに合格した場合に Amazon ECS に自動的にデプロイする新しい機能をアプリケーションに追加できます。
この例は、ユニットテストに合格しないアプリケーションコード (app.py
) の変更を示しています。
このコードがリポジトリにチェックインされると、CodeBuild が webhook を介して自動的に呼び出され、アプリケーションテストが実行されることがわかります。

失敗した CodeBuild テストの実行の例
CodeBuild は、失敗したテストの実行を GitHub に報告します。

失敗した GitHub コミットステータスの例
GitHub ワークフローがコミットのステータスを failure
と検出したため、ワークフローは「Check commit status」のステップを通過しませんでした。

失敗した GitHub ワークフローの例
次の例は、アプリケーションコード (app.py
) の変更を示しています。このコードは、追加のロギングステートメントを導入しますが、ユニットテストに合格します。
このコードがリポジトリにチェックインされると、CodeBuild が webhook を介して再び呼び出され、アプリケーションテストが正常に実行されることがわかります。

CodeBuild テストの正常な実行の例
CodeBuild は、テストの正常な実行を GitHub に報告します。

正常な GitHub コミットステータスの例
GitHub ワークフローは、コミットのステータスが success
になることを検出し、ワークフロー内の残りのステップが ECS へのアプリケーションのデプロイを正常に実行します。

正常な GitHub ワークフローの例
最後に、ECS タスク定義が更新され、新しいアプリケーションコンテナイメージが反映されていることがわかります。 Git コミットハッシュがコンテナイメージタグとして使用されることに注意してください。

Git コミットハッシュを用いた ECS タスク定義の例
まとめ
この投稿では、GitHub Actions を使用して Amazon ECS で実行されているアプリケーションをサポートする方法を説明しました。 DevOps インフラストラクチャの一部として GitHub Actions を使用したい組織にとって、GitHub Actions を他の CI/CD サービス (AWS CodeBuild など) と組み合わせることは、機能豊富な CI/CD パイプラインを提供するためのシンプルで強力な方法となり得ます。 GitHub Actions の詳細については、「GitHub Actions の機能」を参照してください。