More than 1 year has passed since last update.

AWSで始めるCI/CD 〜Code系サービス解説〜

Last updated at 2023-02-05Posted at 2022-08-03

はじめに

みなさんCI/CDのツールって何を使っていますか？？
『Jenkins』『Circle CI』『GitLab』その他諸々色々ありますよね。
今回取り上げるのはAWSのサービスを使ったCI/CDです。

AWSでCI/CDを構築するにはCode型のサービス、通称Code兄弟が必要になります。
ちなみにCode兄弟は以下のサービスをまとめてそのように呼んでいます。
『CodeCommit』『CodeBuild』『CodeDeploy』『CodePipeline』
※ Code兄弟は僕が勝手にそう読んでいるだけで公式ではありません笑

今回の記事では、AWSで構築するCI/CDの仕組みや、その時出てくるサービス（Code兄弟）の紹介していきます！
長くなってしまったので2つに分けました。
※ハンズオンというよりは、各サービスやAWSでのCI/CDの仕組みを書いた記事になりますので、ご注意ください。

それぞれ単発で読んでも理解できると思いますが、2つとも読んでいただけるとより理解が深まるかなと思います（というのは建前で両方読んでいただけると著者が喜びます笑）
本記事ではCode兄弟達がどのような役割なのか、ライフサイクル含めて書いています。

それではまずCode兄弟達を簡単に見ていきましょう！！

Code兄弟達の概要

CodeCommit

AWSのGitホスティングサービスです。
簡単にいうとGithubのようなものですね。
Githubのように幅広い機能はありませんが、他のAWSサービスとの連携が楽です。
結構シンプルなサービスなので、今回の記事では詳細には述べません。

CodeBuild

CodeBuildは自動テストやビルドを実行してくれるサービスです。
DockerImageから環境を立ち上げて、S3やCodeCommit, Githubからソースコードを取得した後にビルドやテストを実行してくれます。

CodeDeploy

CodeDeployはデプロイを実行してくれるサービスです。
S3またはGithubにあるソースコードを、EC2やLambda, オンプレミス環境にデプロイしてくれます。
またECSにてBlue/Greenデプロイを実行する時にもCodeDeployを使って実行します。

CodePipeline

CodePipelineはCI/CDを管理してくれるサービスです。
CodeBuildの処理が終わればCodeDeployに処理を渡す等をしてくれます。

CodeBuild, CodeDeploy, CodePipelineの説明

それではここからCodeBuild, CodeDeploy, CodePipelineに関して詳しく述べていきます。
※CodeCommitはそんなに複雑なサービスではないので説明を割愛します。

CodeBuild

先ほども記載しましたが、CodeBuildは自動テストやビルドを実行してくれるサービスです。
ではどのように処理が行われるのか、ライフサイクルの各フェーズをみていきます。

CodeBuildは以下のようなフェーズで処理が実行されます。

フェーズ	説明	補足
SUBMITTED	CodeBuildにビルドの依頼がくるステップです。この後CodeBuildが動きます。	-
QUEUED	queueに入ります。他のビルドがある場合は、待ちの状態です。	-
PROVISIONING	ビルド環境を立ち上げます	CodeBuildがデフォルトで用意しているDockerImageもしくは、自身で用意したDockerImageどちらも使えます。
DOWNLOAD_SOURCE	ソースコードを各ソースプロバイダーから取得します。	ソースプロバイダーはS3, CodeCommit, Github等が当たります。
INSTALL	ライブラリ等のインストールをしていきます。	ビルド環境でのパッケージのインストールにのみ使用することが推奨されています
PRE_BUILD	ビルド前の準備をします。	このフェーズを使用して Amazon ECRにサインインしたり、npmの依存関係をインストールする等ができます
BUILD	ビルドをします。メインのアクションです。
POST_BUILD	ビルド後の処理を実行します。	Maven を使用してビルドアーティファクトを JAR または WAR ファイルにパッケージ化する、Dockerイメージを Amazon ECR にプッシュする等ができます。
UPLOAD_ARTIFACTS	ビルドのアーティファクトファイルを指定の場所にアップロードします。	アーティファクトファイルはCI/CDにおいて、次の処理に渡すファイルのようなものです。
FINALIZING	CodeBuildの処理を完了する処理です。	CodeBuildのビルド環境を閉じる等しています。
COMPLETED	CodeBuildの処理を全て完了したフェーズです。	-

実行計画はbuildspec.ymlというファイルに記載していきます。
※ファイル名は必ずしも上記の名前にしなくても良いですが、公式ドキュメントには上記ファイル名で説明がされているので、本記事でも上記の名前を用いていきます。

buildspec.ymlは以下のようなパラメーターを設定してきます。

buildspec.yml

version: 0.2

# 各種コマンドを実行するユーザーを指定する。指定がない場合はrootユーザーが使われる。
run-as: Linux-user-name

# ビルド環境の設定。シェルや環境変数の設定を行う。指定しなくても良い
# 環境変数はkey, valueで直接指定もできるが、Systems Managerのパラメーターストアの値を用いることもできる
env: 

# プロキシサーバーにてCodeBuildを実行する際に指定する。指定しない場合はCodeBuildのデフォルトのまま実行される
proxy:

# バッチビルドの設定を行う。指定しない場合はバッチビルドが実行されない。
batch:

# 各種ビルドフェーズに関する設定
# 各フェーズにてrun-as（実行するユーザー）, on-failure（失敗したら次のフェーズにいくかどうか）, commands（実行コマンド）, finally（必ず_failureでも_実行するコマンド）等を設定
phases:
  # パッケージのインストールのコマンドを設定。
  install:
  # ビルド前に実行するコマンドを設定。
  pre_build:
  # ビルド時に実行するコマンドを設定
  build:
  # ビルド後の実行するコマンドを設定
  post_build:

# CodeBuildのレポート機能の設定。指定がない場合は、レポートが出力されない（ログとは異なるので注意）
reports:

# CodeBuildの出力をするための設定。出力先や出力ファイル等を指定する
artifacts:

# キャッシュの利用に関する設定。指定がない場合は特にキャッシュの利用がされない
# CodeBuildがS3キャッシュバケットへアップロードするための設定をする。
cache:

buildspec.ymlのパラメーターは一見多いですが、自動テストだけ実行したい等あればかなり記述は少なくて済みます。
例えば、PHPUnit(Laravel使用時)を使ってテストする場合はこうなります。
※環境変数が必要であれば、CodeBuildにて設定も可能です。

buildspec.yml

version: 0.2

phases:
  install:
    commands:
      - composer install
  build:
    commands:
      - php artisan test --env=test

artifacts:
  files:
    - '**/*'

結構シンプルですよね！
DockerImageをビルドしたりECRにpushしたりすると記述量も増えますが、やることが少ないと設定ファイルもシンプルなんですよね〜

ということで、CodeBuildのライフサイクルと設定ファイルを見てきました。
お次はCodeDeployのライフサイクルや設定ファイルを見ていきます。

CodeDeploy

先ほども記載しましたが、CodeDeployはデプロイを実行してくれるサービスです。
そのままですね笑

デプロイについては、ロードバランサーがデプロイグループに含まれるかどうかでフェーズがやや異なります。
ロードバランサーがデプロイグループに入っている時は、デプロイ中ロードバランサーからサーバーへの通信を停止させることができます。
※ デプロイグループとは、デプロイ対象をまとめたグループになります。

ライフサイクルのフェーズは以下の通りで、ロードバランサーが含まれるのが左の図、含まれるのが右の図です。

※図の引用：『AppSpec の「hooks」セクション』

各フェーズを詳しく見ていきます。

基本的なライフサイクル

ライフサイクルフェーズ	説明	イベント時にスクリプトが実行可能か
ApplicationStop	前回のリビジョンのスクリプトを停止します。	◯
DownloadBundle	CodeDeployの一時的なディレクトリにファイルをコピーします。	✕
BeforeInstall	Install直前のインスタンスでタスクを実行できます。	◯
Install	CodeDeployの一時的なディレクトリから、デプロイ先のディレクトリにファイルをコピーします。	✕
AfterInstall	Install直後のインスタンスでタスクを実行できます。	◯
ApplicationStart	ApplicationStop で停止したサービスを再起動するために使用します。	◯
ValidateService	デプロイが正常に完了したことを検証します。	◯

ロードバランサーがデプロイグループにある時に生じるライフサイクル

ライフサイクルフェーズ	説明	イベント時にスクリプトが実行可能か
BeforeBlockTraffic	ロードバランサーから登録解除される前のインスタンスでタスクを実行できます。	◯
BlockTraffic	ロードバランサーからインスタンスに対するアクセスがブロックされます。	✕
AfterBlockTraffic	ロードバランサーから登録解除された後のインスタンスでタスクを実行できます。	◯
BeforeAllowTraffic	ロードバランサーに登録される前のインスタンスでタスクを実行できます。	◯
AllowTraffic	ロードバランサーからインスタンスへのアクセスが許可されます。	✕
AfterAllowTraffic	ロードバランサーに登録された後のインスタンスでタスクを実行できます。	◯

※イベント時のスクリプトについて、各ライフサイクルのイベントについて、自身で用意したスクリプトを実行することができます。

CodeDeployではappspec.ymlというファイルに設定を記載します。
以下簡単に書いていますが、もっと詳細に知りたいという方は、『AppSpec ファイル構造』『AWS CodeDeploy の AppSpec を読み解く』を参考にしてみてください。

appspec.yml

version: 0.0

# OSの設定をしていきます。
os: operating-system-name

# インスタンスにコピーするファイルについて指定します。
files:
  source-destination-files-mappings

# インスタンスへのコピー中に特別なアクセス権限をファイルのfilesセクションに適用する方法を指定します
permissions:

# デプロイライフサイクルのイベントにフックして実行するスクリプトをしていします。
hooks:

ちなみに、CodeBuild同様例を書いてみます。
例えば、デプロイ元ファイルの全ファイルをEC2の/var/www/html配下にデプロイしたい且つ、デプロイ終了後にafter_install.shを実行したい時、以下のような記述になります。

appspec.yml

version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/html

hooks:
  AfterInstall:
    - location: after_install.sh
      timeout: 120
      runas: root

ということで、ここまででCodeDeployを見てきました。
最後にCodePiplineを見ていきます！

CodePipeline

CodePipelineはCI/CDを管理してくれるサービスです。
CodePipelineが実際の処理をしてくれるというよりは、各サービスに処理を依頼してCI/CDを成立させるのが役割になります。まあ管理職のような立場ですね笑

CI/CDに関して、CodePipelineが管理できるサービスはこんな感じです。
結構色々なサービスを使えます！
※デプロイについては、記載しているサービス以外にも使用可能サービスがあります。

CodePipelineが実行する各フェーズをステージと呼びます。
例えば、ビルドのステージやデプロイのステージという風に呼びます。

CodePipelineがCI/CDを実行する際には、いくつかのルールがあります。
※図の引用『パイプライン実行の仕組み』

ルール 1: 実行の処理中はステージがロックされる

各ステージは一度に1つの実行しか処理できないため、進行中のステージはロックされます。

ルール 2: 後続の実行は、ステージのロックが解除されるまで待機する

例えば、パイプラインに2つの処理が走っている時（処理1, 処理2とします）、処理1がビルドステージにあったら処理2はビルドステージに移行できないイメージです。

ルール 3: 待機中の実行はより最近の実行によって置き換えられる

例えば、パイプラインに3つの処理が走っている（処理1, 処理2, 処理3）とします。
処理2が待機中で処理3が前ステージを終えると、待機の優先順位が処理3>処理2になります。

CodeBuildとCodeDeployと組み合わせた説明はAWSで始めるCI/CD 〜CI/CDの仕組み〜にて説明しておりますので、良かったら見ていってください！
ということで、本記事でのCodePipelineのご紹介は以上になります。

おわり

一通りCode兄弟の役割やライフサイクルの詳細を見ていきました。
案外内部では色々な処理がなされていましたよね！
これらのサービスを使ってCI/CDを構築する時の仕組みはAWSで始めるCI/CD 〜CI/CDの仕組み〜をご参照ください！
最後まで読んでいただきありがとうございました！

AWSで始めるCI/CD 〜Code系サービス解説〜

はじめに

Code兄弟達の概要

CodeCommit

CodeBuild

CodeDeploy

CodePipeline

CodeBuild, CodeDeploy, CodePipelineの説明

CodeBuild

CodeDeploy

CodePipeline

おわり

参考文献

CodeBuild

CodeDeploy

CodePipeline