(レポート)DVO305: コンテナを使用した継続的なデプロイメントパイプラインの加速 #reinvent

丹内です。掲題のセッションをレポートします。

スピーカー

• Daniele Stroppa - Cloud Specialist, Amazon Web Services UK Ltd
• Dan Sommerfield - Senior Manager, Software Development, Amazon Web Services

デモアプリケーション

今回のセッションで説明用に作成された簡単なアプリケーションは、以下の構成です。

• Nginx Proxyコンテナ
• Rails Applicationコンテナ
• PosggresQL DBコンテナ

よくある3層構造ですね。　　

AWSのサービスは、以下のものを使用します。

• ECS
  • コンテナ管理サービス
  • コンテナの配置やホストEC2クラスタのスケーリングを行う
  • 拡張性が高い(カスタムスケジューラを指していると思われます)
• CodePipeline
  • オーケストレーションに使用
• ElasticBeanstalk
  • デプロイ管理として使用
  • EB with DockerはEC2インスタンスに1つのコンテナをデプロイするものですが、Multi-Containerスタックを使用した場合は複数コンテナをECS管理下のクラスタにデプロイできます。

以下、各段階を詳しく見ていきます。

Stage1: Source

ソースコードがコミットされるところからパイプラインは始まります。 このセッションでは、CodeCommitが取り上げられていました。これについては「GitHubやBitBucketの方が良いのでは？」と思っていたのですが、IAMを適用することでセキュアな運用が可能である利点を今回知りました。
大人数が携わる開発で、JiraAgileなど別途タスク管理を行うのであれば、CodeCommitも選択肢になるのかなと思いました。

コミット前にlocalで動作確認する際は、新しくリリースされたAmazon ECS CLIを使うことができます。また、複数のコンテナを協調動作させる際は、docker-composeを使って行うことができます。
これらはECS CLIに統合されており、適切なDockerfileがあれば簡単に動作確認することが可能です。

Stage2: Build

コードをコミットした後は、まずビルドを行います。
このフェーズでも、AWSには様々なパートナーのツールを活用することができます。このセッションではCloudBeesのJenkinsが取り上げられていました。
コンテナにつけるタグは、ビルドナンバーを使うことで、あとからトラッキングできます。
ビルドが完了したらイメージをレジストリに登録します。
ここで使うレジストリには、re:Inventで新たに発表されたAmazon ECS Registry(ECR)を使うことが、年内に出来るようになる予定です。ECRは容量を気にすすること無く、安価でセキュア(IAM)にイメージを管理できます。
ECRのリリースが楽しみです！

Stage3: Test

ビルドしたイメージをテストします。
デモではcapybara-webkitを使ってテストしていました。

Stage4: Deploy

テストに通ったら、いよいよデプロイです。ECS CLIを使います。
セッションでは、デプロイにElastic Beanstalkを使っていました。
ElasticBeanstalkはEC2/ECSへのデプロイをサポートするAWSリソースです。EBを使うことによってデプロイやインスタンスの管理が簡単になり、AWSをHerokuのように使うことができます。複数コンテナをデプロイするようにすると、ECSがバックエンドになります。

Orchestration

一連の流れば、CodePipelineで管理します。

感想

CodePipelineを使ってプロセスを管理するまでに必要なことが知ることができました。
ビルドしたコンテナをテストしそのままデプロイするプロセスは複雑になりますが、CodePipelineによる管理を試してみたいところです。