はじめに

AWSハンズオン for Beginnersシリーズとして提供されている「AWS Hands-on for Beginners AWS Code サービス群を活用して、CI/CD のための構成を構築しよう！」を実施した際のメモです。
近年変化の激しいビジネス市場で結果を出していくためには、ビジネスニーズを満たすアプリケーションを迅速に開発することが必要です。
そのため、スピードを重視したアジャイル開発手法が広まってきました。アジャイル開発とは小さな変更をインクリメンタルに加えていくことで、プロダクトを少しずつ開発していく手法です。
アジャイル開発のように細かい粒度の変更をスピード感を持ってユーザーに提供するには、変更を検知した際に自動でテストを行い、デプロイやロールバックも自動で行うCI/CDの考えが重要になります。
CI/CDとは、「Continuous Integration／Continuous Delivery」の略で、日本語では継続的インテグレーション／継続的デリバリーといいます。
AWSには、CI/CDを実現するサービスであるCodeシリーズがあります。
本ハンズオンでは、このCodeシリーズを使用し、実際にアプリの自動デプロイを体験してみます。

アジェンダ

今回のハンズオンので構築する構成の紹介 + ハンズオンで登場するサービスの紹介
S3をデプロイ先とした、CI/CD環境を構築する【事前準備 + CodeCommit編】
S3をデプロイ先とした、CI/CD環境を構築する【CodePipeline編】
EC2インスタンスをデプロイ先とした、CI/CD環境を構築する【事前準備編】
EC2インスタンスをデプロイ先とした、CI/CD環境を構築する【CodeBuild編】
EC2インスタンスをデプロイ先とした、CI/CD環境を構築する【CodeDeploy編】
EC2インスタンスをデプロイ先とした、CI/CD環境を構築する【CodePipeline編】
削除手順の紹介、本シリーズのまとめ、Next Stepのご案内

メモ

ゴール

Codeシリーズを利用して、継続的インテグレーション・継続的デリバリーのための簡単な構成を作成します。
ハンズオンを通して、CodeCommit, CodeDeploy, CodeBuild, CodePipelineの各サービスの特徴を理解します。

ハンズオンで作成する構成

本ハンズオンでは、以下2つの構成を作成します。
①CodeCommitへのpushを検知し、S3に静的ホスティングされているコンテンツをデプロイします。
（使用するサービス：CodeCommit、CodePipeline）
②CodeCommitへのpushを検知し、CodeBuildでの成果物作成、CodeDeployでEC2インスタンスにデプロイを行います。一連の流れはCodePipelineにまとめます。
（使用するサービス：CodeCommit、CodeBuild、CodeDeploy、CodePipeline）

構成①について

S3の静的ホスティング機能

S3の静的ホスティング機能を利用するため、以下の手順が必要です。
なお、こここにその機能を体験するハンズオンのメモを記載しています。

バケット名に取得したドメイン名を指定します。
パブリックアクセスのブロックをオフにします。
S3バケットの設定から静的ウェブサイトホスティングを有効にします。
S3バケットポリシーで外部からのアクセスを許可します。

認証ヘルパー

Cloud9からCodeCommitにアクセスするため、認証ヘルパーを使用します。
以下コマンドを実行し、初期設定します。

git config --global credential.helper '!aws codecommit credential-helper $@'
git config --global credential.UseHttpPath true
git config --global user.name "xxx"
git config --global user.email "xxx@xxx"

CodePipelineでS3に自動デプロイ

CodePipelineでS3に自動デプロイするパイプラインを作成できます。
ソースプロバイダーとしてCodeCommitを選択し、作成したリポジトリ名、ブランチ名を指定します。
S3へのデプロイの際はデプロイプロバイダーとしてCodeDeployではなくS3を選択します。また、デプロイ先のS3バケット名やオブジェクトキーを指定します。

構成②について

CodeBuildの設定

CodeBuildのソースにCodeCommitおよびリポジトリ名、ブランチを指定します。また、ビルドするサーバのスペックなどを指定します。
CodeBuildに付与されているIAMロールにCodeDeployへアクセスするためのポリシー(AWSCodeDeployDeployerAccess)を追加しておく必要があります。

CodeBuildの設定ファイル

CodeBuildがビルド時に実行するコマンドなどはbuildspec.ymlに記述します。CodeBuildとCodeDeployを連携するため、buildspec.ymlのcommandsパラメタにCodeDeployへpushをするコマンドを記述します。application-nameオプションには、CodeDeployの管理単位であるアプリの名前を指定します。

CodeDeployの事前準備

CodeDeployを使用してEC2インスタンスにデプロイを行うには、デプロイ先となるインスタンスにCodeDeployエージェントを事前にインストールしておく必要があります。

CodeDeployの設定ファイル

CodeDeployを使用して、アーティファクトとデプロイ先のどこに配置するか、デプロイ時に実行するコマンドなどの設定をappspec.ymlに記述します。
CodeDeployはアプリケーションという単位でデプロイを管理します。
最初に、アプリケーションを登録し、アプリケーション名とデプロイ先（オンプレ、EC2、Lambda、ECS）を登録する必要があります。
次に、デプロイグループを作成します。グループには、サービスロール、デプロイタイプ（インプレース、Blue/Green）デプロイ設定（AllAtOnceなど）、デプロイ対象となる情報がまとめられています。また、CodeDeploy用のIAMポリシー（AWSCodeDeployRole）が必要なので事前に作成しておきましょう。

詰まったところ

EC2コンソールでインスタンスを選んで、パブリックIPv4アドレスのリンクを押下すると「https」でアクセスするため注意が必要です。今回のハンズオンでは「http」でインスタンスのアクセスを許可する手順であるため、上記リンクからはアクセスできません。手動で「https」から「http」に変更してアクセスするなど必要です。

ハンズオンの感想

おおよそ5年前ぐらいからGitLabのCI/CD機能に触れ始め、自動テスト、自動デプロイの素晴らしさを知り始めました。（Jenkinsを触ったこともありますが、インストールに手こずったり、設定が難しく感じました。）
CI/CDは一度手を出すと手動でのテスト、デプロイがバカらしくなるほど開発を効率化できる印象です。複雑なプロジェクトではこのCI/CDの設定で色々な苦労がありますが、ボディブローのように徐々に効果が出てくるタイプなので、プロダクトが比較的複雑でないプロジェクト開発初期から導入することをお勧めします。
さて、本ハンズオンで使用したCodeシリーズについてはAWSで開発する際、必要不可欠なサービスという認識です。今回のEC2へのデプロイのほかECSやLambdaなどさまざまなサービスと連携し、CI/CDを実現できるからです。
設定ファイルについては多数のパラメタがあるため、少しずつ理解していきたいです。