AWS Service Catalog を使用しての、Amazon ECS 継続的デリバリー用の自動設計図の共有

この記事は、AWS Dev Tech のスペシャリスト SA である Mahmoud ElZayet が執筆しました

現代的なアプリケーション開発プロセスは、各組織がスピードや品質を継続的に向上することを可能にしています。このような革新的なカルチャーにおいては、小型の自律的なチームに、アプリケーションの全ライフサイクルがゆだねられます。ただ、こういった敏速かつ自律的なチームは、製品デリバリーを加速する一方で、コンプライアンスや品質保証、およびコードデプロイのためのインフラストラクチャに対するコストを生じさせます。

標準化したツールやアプリケーションリリース用コードを用いることで、チーム間でベストプラクティスを共有でき、冗長的なコードを削減し、オンボーディングを加速し、一貫性のあるガバナンスを作り上げながらリソースのオーバープロビジョニングを減らせます。

概要

今回の記事では、標準化され自動化されたデプロイ設計図を、AWS Service Catalog を使用して提供する方法をご紹介していきます。これは、製品チームによる Amazon ECS でのアプリケーションリリースワークフローの改善と迅速化に役立ちます。ここでの手順を実施していただくと、お客様の製品チームが ECS 上でコンテナ化されたアプリケーションをリリースするために使用できる、サンプル設計図が作成できます。この設計図のコンセプトは、サーバーレスや Amazon EC2 をベースとするデプロイなど、他のテクノロジーにも適用が可能です。

本稿で提供するサンプルテンプレートやスクリプトはデモ用に用意したものなので、実稼働環境でそのまま使用するには適しません。これらのリソースになじんだ後で、手元にあるツールや、チームのスキル、そして適用すべき規格や規制をすべて考慮しながら、実稼働環境向けにカスタマイズしたバージョンを作成してください。

前提条件

ここでのソリューションには、次に挙げる各リソースが必要です。

AWS アカウントでの管理者アクセス権限
AWS CLI

サンプルシナリオ

Example Corp という企業では、アプリケーションやサービスを AWS 上で開発するために、いくつかの製品チームを抱えています。同社内の各チームは、ECS 上の AWS Fargate で管理するコンテナ化したアプリケーションのデプロイに関心を示しています。ここでは、Example Corp. における主幹ツール管理チームとして、各チームが Fargate で迅速にアプリケーションをリリースできることを目指します。さらに、すべてのベストプラクティスやガバナンス要件を、各チームが準拠することも保証していきます。

事情を単純にするために、製品チームはすでに構成済みであり、サービスのデプロイ用に AWS のアカウントを共有しながら、同じドメイン、アプリケーション、もしくはプロジェクトで作業をしていると想定します。この 1 つのアカウントを通じ、チーム全体が同じ ECS クラスターに対しデプロイしています。

このシナリオでは、これらのチームに対し、ECS Fargate での共有デプロイ設計図の作成および提供が可能です。AWS Service Catalog を使用すると、各チームとの間で、次に示すような設計図の共有ができます。

製品チームが、ECS で新規にコンテナ化アプリケーションをリリースしようとする際には、AWS Service Catalog で作成した ECS 設計図を新たに取得します。これにより、必要なインフラストラクチャ、アクセス許可、ツールなどが手渡されます。前提条件としてこの ECS 設計図には、Git レポジトリ、あるいはAWS CodeBuild プロジェクトなどのブロックの構築が必要です。繰り返しになりますが、これらのブロックは、別の AWS Service Catalog 製品から入手可能です。
製品チーム側では、ECS 設計図が必要とするパラメータを定義します。これらには、実行したい ECS タスクの数や、アプリケーション名などが含まれます。管理者側は、VPC やクラスター名など、一部のパラメータの値を制約することができます。詳細については「AWS Service Catalog テンプレート制約」をご参照ください。
ECS の設計図機能では、必要なすべての ECS リソースを、ベストプラクティスに則り定義しながらデプロイします。また、AWS Cloud Development Kit (CDK) を使用すると、インフラストラクチャ用に定義済みの構造を、管理およびプロビジョニングできるようになります。
標準化した CI/CD パイプラインも生成に使え、製品チームからのアプリケーションを、ECS に対し自動的に公開できるようにします。理想を言えば、このパイプラインには、アプリケーションのリリースに必要な、すべてのステージ、手順、セキュリティチェック、規格などが備わっているべきです。ただ依然として製品チームには、アプリケーションコードや Dockerfile の作成、仕様の構成、自動テストとデプロイスクリプトの実行、その他の、アプリケーションリリースに必要なタスクを実施する必要があります。
ECS 設計図は、組織全体からのフィードバックを通じ継続的に更新し、新たなユースケースをサポートしていくことが可能です。製品チームは、AWS Service Catalog 経由で、いつでも最新バージョンにアクセスが可能です。各種のテクノロジー向けに、カスタマイズ可能な複数の設計図を取得しておくことを推奨します。

簡単化のために、ここでの解説では、使用する環境が 1 つの AWS アカウントに含まれていると想定します。実際には、仮に 1 つのアカウントを共有していたとしても IAM による制御を使用すれば、チーム内のアクセス権をそれぞれ別のリソースごとに分離することもできます。ただしここでは、最低 2 つの AWS アカウントを、それぞれテスト用と実稼働用に用意することを推奨します。

複数のアカウントで AWS Service Catalog 製品をデプロイする際に役立つフレームワークについては、AWS Deployment Framework (ADF) をご参照ください。また、このフレームワークでは、異なる製品チームからの要件に対応するクロスアカウントのパイプラインを作成できます。これは、各チームが同じテクノロジースタックでデプロイしているような場合にも役立ちます。

製品チーム向けにデプロイの共有設計図をセットアップするには、次のセクションで説明する手順に従ってください。

環境のセットアップ

このセクションでは、各チームがコンテナーをデプロイできる適切な VPC 内に、中心的な ECS クラスターを作成する方法を解説します。これらのリソースを設定するため役に立つ、AWS CloudFormation テンプレートを用意しています。このテンプレートは、後に AWS Service Catalog が使用するための IAM ロールも作成します。

CloudFormation テンプレートを実行するための手順は次のとおりです。

1. git クライアントを使用し、ローカルディレクトリに、次に示す GitHub レポジトリを複製します。これが、後にすべての AWS CLI コマンドを実行するディレクトリとなります。

2.AWS CLI で、次のコマンドを実行します。<Application_Name> の部分は、製品チームがリリースしようとするアプリケーションもしくはマイクロサービスを示す文字列 (小文字のみでスペースは含みません) で置き換えます。たとえば、myapp のように指定します。

aws cloudformation create-stack --stack-name "fargate-blueprint-prereqs" --template-body file://environment-setup.yaml --capabilities CAPABILITY_NAMED_IAM --parameters ParameterKey=ApplicationName,ParameterValue=<Application_Name>

3.次のコマンドを、CREATE_COMPLETE が出力に表示されるまで継続して実行します。

aws cloudformation describe-stacks --stack-name "fargate-blueprint-prereqs" --query Stacks[0].StackStatus

4.エラーが発生した場合は、describe-events CLI を実行するか、コンソールからエラーの詳細を確認します。

5.スタックの作成が CREATE_COMPLETE と表示されたら次のコマンドを実行します。その上で、出力された値を適当なエディター上に記録しておきます。今後のステップでこの情報が必要になります。

aws cloudformation describe-stacks  --stack-name fargate-blueprint-prereqs --query Stacks[0].Outputs

6.次のコマンドを実行し、CloudFormation テンプレートを Amazon S3 にコピーします。<Template_Bucket_Name> の部分は、先にご自身のエディタ上にコピーしてあるテンプレートバケットからの出力値で置き換えます。

aws s3 cp core-build-tools.yml s3://<Template_Bucket_Name>/core-build-tools.yml

aws s3 cp ecs-fargate-deployment-blueprint.yml s3://<Template_Bucket_Name>/ecs-fargate-deployment-blueprint.yml

AWS Service Catalog 製品を作成する

このセクションでは、各チームがコンテナ化したアプリケーションを公開する際に使用する、次に挙げる 2 つの AWS Service Catalog 製品を作成します。

主要な構築ツール
ECS Fargate のデプロイ設計図

これらの製品を含む AWS Service Catalog ポートフォリオを作成するには、次の手順に従います。

1.AWS CLI から次のコマンドを実行します。この際、<Application_Name> の部分は
アプリケーションで先に定義済みの名前で置き換え、また、<Template_Bucket_Name> は、
エディタにコピーしてある、テンプレートバケットからの出力値で置換えます。

aws cloudformation create-stack --stack-name "fargate-blueprint-catalog-products" --template-body file://catalog-products.yaml --parameters ParameterKey=ApplicationName,ParameterValue=<Application_Name> ParameterKey=TemplateBucketName,ParameterValue=<Template_Bucket_Name>

2.数分経過後、スタック作成が完了したことを確認します。出力に CREATE_COMPLETE が表示されるまで、次のコマンドを実行します。

aws cloudformation describe-stacks --stack-name "fargate-blueprint-catalog-products" --query Stacks[0].StackStatus

3.エラーが発生した場合は、describe-events CLI を実行するか、コンソールでエラーの詳細をチェックします。

この段階で、AWS Service Catalog 設定が使用可能になりました。

製品チームでの操作性をテストする

このセクションでは、IAM ロールに製品チームのメンバーの代役をさせ、コンテナ化されたアプリケーションのデプロイにおける初期の操作性を、シミュレーションで確認する方法を紹介します。

チームのロールを引き受ける

環境セットアップのステップで作成済みのロールを引き受けるには、次の手順を実行します。

1. マネジメントコンソールにおいて、「ロールの切り替え」に示された手順を実行します。

[アカウント] には、このサンプルソリューションで使用しているアカウント ID を入力します。AWS アカウント ID の詳細な検索方法については、「AWS アカウント ID とその別名」をご参照ください。
[ロール] には、<Application_Name>-product-team-role の形式で入力します。この際、<Application_Name> は、環境のセットアップのセクションで定義したものと同じ、アプリケーション名を指定します。
(オプション) [表示名] には、カスタムセッション値を入力します。

これで、製品チームのメンバーとしてログインができました。

主要な構築ツールのプロビジョニング

次は、設計図のための主要な構築ツールをプロビジョニングします。

Service Catalog コンソールには、先に作成済みの 2 つの製品が、[製品] の下に表示されているはずです。
最初に表示される製品、[主要な構築ツール] を選択します。
[製品の起動] を選択します。
製品に、<Application_Name>-build-tools の形式で名前を付けます。この際、<Application_Name> は、アプリケーションに定義した名前で置き換えます。
これは、先にアプリケーション用に定義したものと同じ名前を使用します。
コンテナレポジトリと関連するアクセス許可が必要なコンテナを構築する際には、ContainerBuild パラメータはデフォルトのはいのままにしておきます。
[次へ] を 3 回クリックした後、[起動] をクリックします。
[イベント] の下の [ステータス] をモニターするために、ステータスが Succeeded (成功) となるまで表示を更新しつづけます。失敗した場合は、キー CloudformationStackARN の隣にある URL 値をクリックします。この操作により、CloudFormation コンソールが開き、エラーに関するより詳細な情報が確認できます。

この段階で、必要なアクセス許可が付与されながら、次のような構築ツールが作成されています。

コード保存のための AWS CodeCommit レポジトリ
コンテナイメージの構築、および、アプリケーションのコードのテストを行う CodeBuild プロジェクト
コンテナイメージを保存するための Amazon ECR レポジトリ
構築した製品とリリースのアーティファクトを保存するための Amazon S3 バケット

ECS Fargate のデプロイ設計図のプロビジョニング

Service Catalog コンソールにおいて同じ手順を実行し、ECS デプロイ用の設計図をデプロイします。製品のプロビジョニングに関する詳細を次に示します。

製品名: <Application_Name>-fargate-blueprint.
プロビジョニング済みの製品名: <Application_Name>-ecs-fargate-blueprint.
Subnet1、Subnet2、VpcId の各パラメータには、先の環境のセットアップセクションでご自身のエディタにコピーした出力値を入力します。
他のパラメータには次のように入力します。
- ApplicationName: 先にアプリケーション用に定義したものと同じ名前を使用します。
- ClusterName: example-corp-ecs-clusterという値を入力します。これは、中心のクラスター用にテンプレート内で選択された名前です。
DesiredCount と LaunchType パラメータは、デフォルト値のままにしておきます。

設計図製品の作成が完了すると、製品チーム向けに、サンプルタスクの定義が行われた ECS サービスが提供されているはずです。先に作成済みの構築ツールには、ECS サービスに対しデプロイするため必要なアクセス権限が付与されています。同時に、製品チームがアプリケーションを ECS サービスで公開する際のガイドとなる、CI/CD パイプラインも作成されています。理想を言えば、このパイプラインには、アプリケーションのリリースに必要な、すべてのステージ、手順、セキュリティチェック、規格などが備わっているべきです。

しかしまだ製品チームには、アプリケーションコードや Dockerfile の作成、仕様の構成、自動テストとデプロイスクリプトの実行、その他のアプリケーションリリースに必要なタスクを実施する必要があります。これらの手順については、設計図製品からの Wiki リンクによりサンプルが参照できます。あるいは、プロビジョニング済みのサンプルパイプラインにアクセスすることもできます。

パイプラインのテスト

パイプラインのテストを行うために、サンプルのアプリケーションをアップロードします。

製品チームのロールを使用しながらログインします。
CodeCommit コンソールにおいて、環境のセットアップセクションで先に定義済みのアプリケーション名を含む、レポジトリを選択します。
スクロールダウンし、[ファイルの追加]、[ファイルの作成] の順にクリックします。
ページエディタに、次に示す内容を貼り付けます。これは、コンテナイメージを構築した後、それを ECR レポジトリにプッシュするスクリプトです。

version: 0.2
phases:
  pre_build:
    commands:
      - $(aws ecr get-login --no-include-email)
      - TAG="$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | head -c 8)"
      - IMAGE_URI="${REPOSITORY_URI}:${TAG}"
  build:
    commands:
      - docker build --tag "$IMAGE_URI" .
  post_build:
    commands:
      - docker push "$IMAGE_URI"      
      - printf '[{"name":"%s","imageUri":"%s"}]' "$APPLICATION_NAME" "$IMAGE_URI" > images.json
artifacts:
  files: 
    - images.json
    - '**/*'

5.[ファイル名] に、buildspec.yml. と入力します。

6.[作成者名] と [E メールアドレス] には、ご自身の名前と、コミットするために使用したい E メールアドレスを入力します。オプションではありますが、コミットのメッセージを追加することも推奨されます。

7.[変更のコミット] をクリックします。

8.Dockerfile に対しても、同様の手順を繰り返します。このサンプルでの Dockerfile は、簡単な PHP アプリケーションを作成します。通常は、このイメージに、アプリケーションに必要なコンテンツを追加して使用します。

ファイル名: Dockerfile

ファイルの内容:

FROM ubuntu:12.04

# Install dependencies
RUN apt-get update -y
RUN apt-get install -y git curl apache2 php5 libapache2-mod-php5 php5-mcrypt php5-mysql

# Configure apache
RUN a2enmod rewrite
RUN chown -R www-data:www-data /var/www
ENV APACHE_RUN_USER www-data
ENV APACHE_RUN_GROUP www-data
ENV APACHE_LOG_DIR /var/log/apache2

EXPOSE 80

CMD ["/usr/sbin/apache2", "-D",  "FOREGROUND"]

これで、パイプラインは正常に実行できるはずです。同じリージョンに、現行のすべてのパイプラインを一覧表示することは可能ですが、記述や変更ができるパイプラインは、アプリケーション名と適合するプレフィックスが付いたものだけです。確認のため、次を実行します。

AWS CodePipeline コンソールにおいて、パイプライン <Application_Name>-ecs-fargate-pipeline を選択します。
パイプラインが実行中であることが確認でます。

レポジトリには、コンソールから 2 つのコミットを実行してあるので、ECS Fargate へのデプロイが正常に完了するのは、第 2 のコミットの処理が完了してからとなります。

クリーンアップ

AWS CLI から次のコマンドを実行し、環境をクリーンアップします。この際、<Application_Name> の部分は
ご自身のアプリケーション名で置き換え、また、<Account_Id> は AWS のアカウント ID (ハイフンは除外します) により、<Template_Bucket_Name> の部分は、
エディタにコピーしてある、テンプレートバケットからの出力値で置換えます。

aws ecr delete-repository --repository-name <Application_Name> --force

aws s3 rm s3://<Application_Name>-artifactbucket-<Account_Id> --recursive

aws s3 rm s3://<Template_Bucket_Name> --recursive

AWS Service Catalog 製品を削除するには、次を実行します。

製品チームのロールでログインします。
「プロビジョニング済み製品の削除」にある手順を、コンソールから実行します。
AWS Service Catalog 製品を、設計図製品を最初に、逆順で削除していきます。

次のコマンドにより、管理用リソースを削除します。

aws cloudformation delete-stack --stack-name fargate-blueprint-catalog-products

aws cloudformation delete-stack --stack-name fargate-blueprint-prereqs

まとめ

今回の記事では、ECS Fargate のデプロイ設計図を設計および構築する方法をご紹介してきました。これらの機能が、AWS でのコンテナ化されたアプリケーションのリリースを迅速化および標準化することをご説明しました。お客様における製品チームには、これらの自動化された設計図を介し、最新の標準やコード化されたベストプラクティスが継続的に提供されます。

Amazon Web Services ブログ