「Docker」と「AWS」は“継続的デリバリー”のゴールデンコンビか：継続的デリバリー効率化のヒント

昨今のソフトウェアのリリース頻度の高さは著しい。リリース効率を上げて企業の対応力を高める鍵が継続的デリバリーの手法だ。このパイプラインを構築するのに役立つノウハウを紹介する。

[Mike Pfeiffer，TechTarget]

Dockerの公式Webサイト《クリックして拡大》

　昨今、ITチームがソフトウェアの更新をリリースする頻度は異常なほど高まっている。効率良くリリースするために、ITチームはアジャイルソフトウェア開発プラクティスに従い、DevOpsの考え方を採用している。ここまで効率を高める主な目的の1つは、新しい変更がアプリケーションに組み込まれたときに素早くフィードバックを入手することだ。このプロセスを加速するために、多くの組織がコンテナとクラウドプラットフォームを組み合わせて使用し、毎日のように複数のアプリケーションの更新を素早くリリースしている。このような組み合わせの1つが、「Docker」と「Amazon Web Services」（AWS）だ。

　「Amazon Elastic Compute Cloud（Amazon EC2）」インスタンスはカスタムのアプリケーションコードを実行するのに適しているが、起動に時間がかかるため、開発者はOSが起動するのを待たなくてはならない。その一方コンテナは、移植可能かつ軽量で、典型的な仮想マシン（VM）につきものの障害が全くない。 CPU、メモリ、ストレージリソースの一部を取得するために既存のホストでプロセスの分離を使用するが、既存のクラスタ化されたホストをAmazon EC2で実行すれば、ITチームはコンテナを素早く稼働させることができる。

併せて読みたいお薦め記事

Docker最新事情

• ユーザーもパートナーも心配するDockerの「俺様」っぷり
• 「Dockerを使わない理由」はもうない？　コンテナのセキュリティ技術が充実へ
• Dockerの新世代ユーティリティーが「コンテナ管理の決定版」になれない理由

Dockerのメリット

• 求められるのは“スピード基準”　IT部門が開発部隊になれない2つの壁
• Amazon Web Servicesで「Dockerコンテナ」を使うと何がうれしいのか

　Dockerは事実上のコンテナ向けのオープンソーステクノロジーである。継続的デリバリーを構築するのに強力なタッグとなるのがDockerとAWSだ。「Amazon EC2 Container Service（ECS）」を使えば、EC2インスタンスのマネージドクラスタでDockerコンテナを実行可能になる。また、必要に応じて、単一のEC2インスタンスでDockerを実行することもできる。

DockerとAWSによる継続的デリバリー

　AWSは、ITチームが継続的デリバリーのパイプラインをコンテナベースで構築できるようにする機能を、Amazon ECS以外にも幾つか提供している。そのようなパイプラインをAWSでセットアップする方法を以下で簡単に説明する。

ローカルでの開発

　ローカルで作業する際、開発者はOS XまたはWindowsで「Docker Toolbox」を使用できる。このツールを使用すると、運用環境で実行するのと同じコンテナ環境でアプリケーションを素早くテストできる。まず、使用する基本イメージやインストールするソフトウェアパッケージなど、コンテナの設定を定義するDockerfileを作成する。docker runコマンドを使用して開発用コンピュータのローカルでコンテナを実行すれば、アプリケーションが期待通りに動作することを確認できる。複数のコンテナが必要なマルチティアアプリケーションの場合は、docker-composeコマンドを使用すれば、docker-compose.yml構成ファイルで定義されている複数のコンテナを稼働させることが可能だ。

ソース管理

　アプリケーションに問題がないことを確認したら、コードをバージョン管理リポジトリにコミットできる。ここで、変更点についてソース管理リポジトリにクエリして残りのパイプラインを開始するために、オーケストレーションツールが必要になる。これは「AWS CodePipeline」を使えば簡単で、CodePipelineは「AWS CodeCommit」に変更をクエリするように構成することができる。また、GitHubでホストされているリポジトリも使用可能だ。このリポジトリには、アプリケーションコードに加え、Dockerfileとdocker-compose.ymlファイルを保存する。

ビルド

　開発者がバージョン管理リポジトリにコードをコミットしたら、CodePipelineがビルド段階をトリガーする。 CodePipelineと互換性のあるビルドサーバは多数存在する。「Jenkins」が一般的だが、他にもサードパーティー製のツールを使える。 ビルド段階では、アプリケーションのソースコードをコンパイルできる。また、コンテナのイメージを作成するためにDockerビルドを実行することが可能だ。 コンテナのイメージは、パブリックまたはプライベートのコンテナレジストリからアクセスできなければならない。 なお、ビルド段階では、これらのDockerイメージを「Docker Hub」か「Amazon EC2 Container Registry」にプッシュできる。

テスト

　AWSでコンテナを使用する一般的な方法として、CodePipelineで1つ以上のテスト段階を作成するというものもある。例えば、テスト段階ではコンテナを実行する前にアプリケーションコードに対して単体テストを実行できる。全てが稼働した後、もう1つの段階が必要になる。この段階では、アプリケーションが機能してアクセス可能で適切なコンテンツを提供していることを確認するための統合テストを実行する。

展開

　コンテナのセットアップが全ての段階を通過したら、変更を運用環境にプッシュできる。変更をプッシュするとコンテナは、ビルド段階でコンテナレジストリにプッシュされたイメージから実行する。運用環境への展開は2通りある。自動的に行われる場合は継続的展開と見なされる。また、チームの準備ができたら最新バージョンのアプリケーションが運用環境に展開可能と見なされる方法もある。DockerとAWSがあればITチームは、継続的デリバリーのパイプラインを構築するための展開段階をさまざまな方法でセットアップできる。例えばECSと直接連係させることも、「AWS Elastic Beanstalk」を使用することも可能だ。AWS Elastic Beanstalkは、1つ以上のコンテナのDocker環境もサポートしている。