【ITニュース解説】Day 53: CI/CD pipeline on AWS pt 4

システム開発において、コードの変更から本番環境への反映までの一連の作業を自動化する仕組みをCI/CDパイプラインと呼ぶ。CI（Continuous Integration）は継続的なコードの統合とテストを指し、CD（Continuous Delivery/Deployment）はテストが完了したコードを自動でリリースまたはデプロイすることを意味する。この仕組みを導入することで、開発者はより迅速かつ安全に新しい機能や修正をユーザーに提供できるようになる。この解説では、アマゾンウェブサービス（AWS）上でこのCI/CDパイプラインを構築する具体的な手順を説明する。

このパイプラインを構築するにあたり、いくつかの準備が必要となる。まず、開発したウェブサイトのコードを管理するAWS CodeCommitというサービスのリポジトリに、ウェブページ本体であるindex.html、コードのビルド方法を定義するbuildspec.yml、デプロイ方法を定義するappspec.yml、そしてデプロイ時に実行するスクリプト（例えばNginxというウェブサーバーを再起動するrestart_nginx.shなど）がすでに格納されていることが前提だ。ウェブサイトを公開するためのサーバーとしては、Amazon EC2インスタンスという仮想サーバーが起動しており、その上でNginxが稼働している必要がある。また、このEC2インスタンスにはAWS CodeDeployエージェントがインストールされ、稼働していることが重要だ。これはCodeDeployサービスからの指示を受け取り、デプロイを実行するソフトウェアである。さらに、AWS CodeBuildというサービスで、CodeCommitから取得したコードをビルドし、その成果物を出力するプロジェクトが事前に作成されている必要もある。パイプラインの途中で一時的にファイルを保管するために、AWS S3というクラウドストレージにバケットを作成する。そして、これらAWSサービスが互いに連携して動作するための適切な権限を持つIAMロールが設定済みか、または自動で作成されるものを使用する。

パイプライン構築の最初のステップは、CodeDeployサービスを使って、新しいウェブサイトのバージョンをどのサーバーにどのようにデプロイするかを定義することだ。まずCodeDeployで「アプリケーション」を作成し、デプロイする対象のシステム全体を識別する。この例ではMyCodeDeployAppという名前でEC2サーバー向けのアプリケーションを作成する。次に「デプロイグループ」を作成する。これは実際にコードがデプロイされるサーバー群を指定するもので、具体的にどのEC2インスタンスにデプロイするかを定義する場所だ。デプロイグループには、CodeDeployがEC2インスタンスに対して操作を行うための「サービスロール」という権限を与える。デプロイ対象のEC2インスタンスを識別する方法としては、「EC2インスタンスタグ」を使うのが推奨される。これはEC2インスタンスに目印（タグ）を付けておき、CodeDeployがその目印を持つインスタンスを探してデプロイを実行する方法だ。例えば、CodeDeploy:day53というタグをEC2インスタンスに付け、デプロイグループでこのタグを指定する。AWSコンソール（ウェブ画面）を使えば、これらの設定を簡単に行うことができ、コマンドラインインターフェース（CLI）を使って設定することも可能だ。

CodeDeployが実際にデプロイを行う際の手順は、appspec.ymlというファイルに記述される。このファイルはコードリポジトリのルートディレクトリに配置する必要がある。appspec.ymlでは、ビルドされたファイルをどのサーバーのどのパスに配置するかをfilesセクションで指定し、デプロイの特定の段階でどのようなスクリプトを実行するかをhooksセクションで定義する。例えば、index.htmlファイルをEC2インスタンスのNginxが読み込むウェブディレクトリにコピーするよう指示し、ファイルのコピーが完了した後（AfterInstall）にscripts/restart_nginx.shというスクリプトを実行してNginxを再起動させる、といった流れを定義する。デプロイで実行されるスクリプトは、必ず実行可能権限が付与されており、コードリポジトリにプッシュされている必要がある。

CodePipelineは、パイプラインの各ステージ（ソース、ビルド、デプロイなど）間でファイルをやり取りする際に、一時的にS3にファイルを保存する。このため、パイプラインと同じAWSリージョンにS3バケットを作成する必要がある。バケット名はAWS全体で一意である必要があるため、重複しない名前を選ぶ必要がある。

これらの準備が整ったら、いよいよCodePipelineを設定し、これまでの要素を連携させて一連の流れを自動化する。これもAWSコンソールから行うのが最も簡単だ。まずパイプラインの名前を決め、CodePipelineが他のAWSサービスと連携するためのサービスロールを指定する。コンソールで新しいサービスロールを自動作成させるのが手軽である。次に、パイプラインが使用するアーティファクトストアとして、先ほど作成したS3バケットを指定する。

パイプラインには複数のステージがある。最初のステージは「ソースステージ」で、コードの変更を監視する。ここでAWS CodeCommitを選択し、対象のリポジトリとブランチを指定する。CodeCommitにコードがプッシュされると、それを検知してパイプラインが自動的に開始される仕組みだ。

次のステージは「ビルドステージ」である。ここではコードを取得した後、ビルドを実行する。AWS CodeBuildを選択し、事前に作成しておいたCodeBuildプロジェクトを指定する。このプロジェクトはbuildspec.ymlに基づいてコードをビルドし、その成果物を出力する。

最後のステージは「デプロイステージ」だ。ビルドされた成果物をEC2サーバーに展開する。AWS CodeDeployを選択し、先ほど作成したCodeDeployアプリケーション名とデプロイグループ名を指定する。これらの設定が完了するとパイプラインが作成され、すぐに動き出す。

パイプラインが正しく機能するかを確認するために、コードに変更を加えてテストする。例えば、index.htmlファイルを少し修正し、その変更をCodeCommitのリポジトリにプッシュする。すると、CodeCommitへのプッシュを検知してCodePipelineが自動的に開始され、「ソース」→「ビルド」→「デプロイ」の各ステージが順に実行される様子をAWSコンソールで確認できる。デプロイが完了したら、EC2インスタンスの公開IPアドレスや、もしあればロードバランサーのURLにアクセスし、更新されたウェブページが実際に表示されることを確認する。

もしパイプラインが途中で失敗した場合は、いくつかの一般的な原因が考えられる。ソースステージで失敗する原因としては、リポジトリ名やブランチ名が間違っている、あるいはCodePipelineのサービスロールにCodeCommitへのアクセス権限がないといった場合がある。CodeBuildでの失敗は、buildspec.ymlの構文エラーやビルドプロセス自体の問題が原因であることが多い。CodeBuildのログを確認すると詳細な原因が分かるだろう。CodeDeployでの失敗は、EC2インスタンスにCodeDeployエージェントがインストールされておらず、稼働していないことが主な原因だ。また、appspec.ymlのパス設定が間違っている、デプロイスクリプトに実行権限がない、スクリプト自体にエラーがあるといったことも考えられる。EC2インスタンス上のCodeDeployエージェントのログを確認すると解決のヒントが得られる。最後に、最も一般的な問題の一つとして権限エラーが挙げられる。各AWSサービスが連携するために必要なIAMロール（CodePipeline、CodeBuild、CodeDeployそれぞれに必要）に適切な権限ポリシーがアタッチされているかを再確認することが重要だ。コンソールの自動作成機能を使えば、この種の権限問題は発生しにくい。