AWS CodePipeline, AWS CodeBuild, Amazon ECR, AWS CloudFormationを利用したAmazon ECSへの継続的デプロイメント

同僚のJohn PignataがAmazon ECSに対する継続的デプロイメントパイプライン作成方法について素晴らしいブログを書いてくれました。

—

今日のビジネス環境では、新しいソフトウェアの反復を高速で提供することは競合に対するアドバンテージになります。企業がイノベーションを顧客に提供するスピード、変化する市場に適応するスピードは、ますます成功と失敗の違いを生む重要な要素になっています。

AWSは、企業がアプリケーションやサービスを高速に提供する組織の能力を向上させるDevOpsと呼ばれる文化哲学、実践、ツールの組み合わせを企業が採用できるように設計された一連の柔軟なサービスを提供します。

このポストでは、継続的デプロイメントと呼ばれるデプロイの実行方法について説明し、AWS CodePipeline、 AWS CodeBuild、および AWS CloudFormationを使用してAmazon ECS上のDockerコンテナとして提供されるアプリケーションの自動デプロイメントパイプラインを実装するためのリファレンスアーキテクチャの概要を説明します。

継続的デプロイメントとは？

俊敏性は、ITリソースのトラディショナルな提供方法に比べてクラウドコンピューティングが持つ重要な利点としてよく引用されています。他の部門が新しいサーバーをプロビジョニングするのに数週間か数ヶ月待つ代わりに、開発者はシングルクリックやAPIコールで新しいインスタンスを作成することができ、数分で使用開始することができます。この新たな速度と自律性は、開発者が新しい製品や機能を試し、できるだけ早く顧客に提供するこを可能にします。

製品の市場投入期間を短縮し、コードの品質を向上させ、より信頼性の高い製品やサービスのリリースを実現するために、開発チームはクラウド上でDevOpsの実践を採用しています。 継続的デプロイは、新しいソフトウェアリビジョンが自動的にビルドされ、テストされ、パッケージ化され、本番環境にリリースされる、DevOpsの実践です。

継続的デプロイにより、開発者は完全に自動化されたソフトウェアリリースプロセスを通じて機能や修正を出荷できます。開発者は、数週間や数ヶ月にわたる大規模なリリースをバッチ処理し、手動で展開する代わりに、新しいソフトウェアリビジョンが準備され次第、自動化されたプロセスを使用してアプリケーションのバージョンを1日に何回も配信することができます。クラウドコンピューティングがリソースの調達期間を短縮するのと同様に、継続的デプロイは新しいソフトウェアのリリースサイクルを数週間～数ヶ月から数分間に短縮します。

このスピードと敏捷性を活用することには、次のような多くの利点があります。

• 新機能やバグ修正を迅速にすることができる :  ソースコードリポジトリに置いてあるコードは、ビジネス価値をもたらしたり、顧客に利益をもたらすものではありません。新しいソフトウェアリビジョンをできるだけ早くリリースすることで、顧客はより迅速に利益を享受できるようになり、チームはより集中的なフィードバックを得ることができます。
• 変更セットが小さくなる : 大きな変更セットは、問題、バグ、およびその他の退化の根本原因を突き止める際に問題を引き起こします。より小さな変更セットを頻繁にリリースすることで、チームは発生した問題をより簡単に特定して修正することができます。
• 自働デプロイによりベストプラクティが促進される : ソースコードリポジトリにコミットされた変更は即座に自動プロセスによってデプロイすることができるため、チームはその変更が十分にテストされ、運用環境が厳重に監視されていることを確実にする必要があります。

継続的デプロイはどのように動くのか？

継続的デプロイは、ソフトウェアのリリースに関連する活動を調整する自動化されたパイプラインによって実行され、プロセスの可視性を提供します。プロセスの最中に、リリース可能な成果物が構築され、テストされ、パッケージ化され、本番環境にデプロイされます。リリース可能な成果物には、実行可能ファイル、スクリプトファイルのパッケージ、コンテナ、または最終的にプロダクションに配信されなければならないその他のコンポーネントが含まれます。

AWS CodePipelineは、新しいソフトウェアリビジョンができるたびにコードのビルド、テスト、およびデプロイを実行する継続的デプロイおよび継続的デリバリーのサービスです。 CodePipelineは、コード変更の統合、可視化を行い、ワークフローを介して最終的にユーザーの提供します。このパイプラインは、ソースコードリポジトリからのコード取得、ソースコードのビルド、テスト、および本番環境へのデプロイといったステージを定義し、これらのステージが順番に実行されること、障害が発生した場合には停止することを保証します。

CodePipelineはデリバリパイプラインを強化し、プロセスを統合しますが、ソフトウェア自体をビルドまたはテストする機能はありません。このステージでは、CodePipelineは、フルマネージドのビルドサービスであるAWS CodeBuildなど、いくつかのツールと統合されます。 CodeBuildはソースコードをコンパイルし、テストを実行し、デプロイする準備が整ったソフトウェアパッケージを生成します。このサービスは継続的なデプロイパイプラインの構築とテストに最適です。CodeBuildはDockerコンテナのビルドを含む多くの異なる種類のビルド環境をネイティブサポートしています。

コンテナは、予測可能で再現可能な環境を実現し、ある環境でテストされた変更が正常に展開できるという高いレベルの信頼性を提供するため、ソフトウェア提供の強力なメカニズムです。 AWSは、Dockerコンテナイメージを実行・管理するためのいくつかのサービスを提供しています。 Amazon ECSは、非常に高い拡張性とパフォーマンスを持つコンテナ管理サービスで、Amazon EC2インスタンスのクラスタ上でアプリケーションの実行環境を提供します。  Amazon ECRは、フルマネージドのDockerコンテナレジストリで、開発者は簡単にDockerコンテナイメージの格納、管理、およびデプロイが可能です。

最後に、CodePipelineはデプロイメントを容易にするために、AWS Elastic Beanstalk、AWS CodeDeploy、AWS OpsWorksや、AWS LambdaまたはAWS CloudFormationを使用した独自のカスタムデプロイメントコードやデプロイプロセスなど、いくつかのサービスと統合されます。これらのデプロイアクションを使用してパイプラインの最後に新しく構築された変更を本番環境にプッシュすることができます。

Amazon ECSへの継続的デプロイ

これらのコンポーネントを組み合わせて、Dockerアプリケーションの継続的なデプロイパイプラインをECSに提供するためのリファレンスアーキテクチャを次に示します。

このアーキテクチャーは、CodePipelineを使用してECSおよびECRにコンテナをデプロイし、AWS上でフルマネージドの継続的デプロイパイプラインを構築する方法を示しています。この継続的デプロイのアプローチは、完全にサーバーレスであり、ソフトウェアの統合、ビルド、およびデプロイにマネージドサービスを使用します。

リファレンスアーキテクチャで作成されたパイプラインは、次のようになります。

このポストでは、このリファレンスアーキテクチャの各ステージについて説明します。開発者がランディングページの原稿を変更し、その変更をソースコードリポジトリにプッシュするとどうなるでしょう？

まず、Source ステージでは、ソースコードリポジトリシステムにアクセスするための詳細がパイプラインに設定されます。リファレンスアーキテクチャでは、GitHubリポジトリにホストされているサンプルアプリケーションがあります。 CodePipelineはこのリポジトリをポーリングし、新しいコミットごとに新しいパイプラインを実行開始します。 GitHubに加えて、CodePipelineは、AWS CodeCommitのGitリポジトリやAmazon S3に格納されたバージョン管理されたオブジェクトなどのソースロケーションもサポートしています。新しいビルドはそれぞれソースコードリポジトリから取得され、zipファイルとしてパッケージ化され、S3に格納され、パイプラインの次のステージに送られます。

Sourceステージでは、Amazon S3に格納されているテンプレートも定義されます。これは、アプリケーションのビルドが成功した後に、デプロイメントステージで使用されるデプロイメント環境を定義するテンプレートです。

Build ステージではCodeBuildを使用して、最新のソースコードに基づいて新しいDockerコンテナイメージを作成し、ECRリポジトリにプッシュします。 CodePipelineは、Jenkins、CloudBees、Solano CI、TeamCityなどのサードパーティのビルドシステムとも統合されています。

最後に、DeployステージではCloudFormationを使用して、新しく作成されたDockerコンテナイメージを指す新しいタスク定義リビジョンを作成し、新しいタスク定義リビジョンを使用するためにECSサービスを更新しています。こうすることで、ECSは新しいDockerコンテナをECRから取得し、サービスを再起動することによってデプロイを開始します。

パイプラインのステージがすべてグリーンになったら、Webブラウザでアプリケーションをリロードして、開発者の原稿の変更を本番環境で確認することができます。これは人手での作業は何もしなくても自動的に実行されます。

このパイプラインはすでにプロダクション状態であり、ソースコードリポジトリから新しいコードを取得し、チームがプロダクションにプッシュする将来の変更を出荷する用意ができています。また、拡張可能なので、新しいステップを追加して追加のステージを含めることもできます。たとえば、新しいコードリビジョンが本番環境に安全にデプロイされることを確認するために、テストステージを組み込んでユニットテストと受入テストを実行することができます。デプロイ後、新しいバージョンが稼動したことおよび、本番環境にデプロイされた変更セットの詳細について、電子メールまたはSlackチャンネルでチームにアラートを送るための通知ステップも追加することができます。

最後に

私たちはこのアプローチを使用してあなた方がどのような種類のアプリケーションをユーザーに提供できるのか、またそれが製品開発プロセスにどのような影響を及ぼすのかを見せていただけることを楽しみにしています。クラウドは俊敏性において大きなメリットを発揮し、継続的デプロイなどの技術を実装する能力は、競争上の大きな利点を生み出します。

GitHub上のAWS Labs EC2 Container Service – Reference Architecture: Continuous Deploymentリポジトリには、独自の継続的デプロイパイプラインを起動するために必要なすべてのものを含むAWS CloudFormationテンプレートがあります。

ご質問、ご意見、ご提案がありましたら是非お知らせください！

(翻訳はSA千葉が担当しました。原文はこちら)