AWS Code系サービスってなんだ?
はじめに
AWSでCI/CD環境を構築する際に、Code系のサービスを利用すると思います。
筆者も業務で使用していますが、一から構築する機会はなかなかないので、code系サービスを触ってみて理解を深めていきたいと思います。
Code系サービスとは?
AWSが提供しているCode系サービスは4種類存在する。
-
CodeCommit
GithubやGitLabのようにプログラムをバージョン管理できるサービスを提供している。
かなりシンプルなサービスで、他のAWSサービスとの連携が簡単。 -
CodeBuild
CodeCommitのマージやタグ打ち等をトリガーにプログラムのビルドやテスト実施を行ってくれる。
管理には"buildspec.yml"を使用し、トリガー検知時は"buildspec.yml"ファイルの内容を読み取りCodeBuildのサービスを実行する。
# バージョンを記載する
version: 0.2
# 各種コマンドを実行するユーザーを指定する。指定がない場合はrootユーザーが使われる。
run-as: test-user
# ビルド環境の設定やシェルや環境変数の設定を行う。(必須ではない)
# 環境変数は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:
- CodeDeploy
S3・CodeCommit・Github等にあるプログラムをEC2・Lambda・ECS等AWSのサービスにデプロイしてくれる。
管理には"appspec.yml"が使用される。
# バージョンの指定を行う。
version: 0.0
# OSの設定。
os: operating-system-name
# インスタンスにコピーするファイルについて指定します。
files:
source-destination-files-mappings
# インスタンスへのコピー中に特別なアクセス権限をファイルのfilesセクションに適用する方法を指定します
permissions:
# デプロイライフサイクルのイベントにフックして実行するスクリプトをしていします。
hooks:
- CodePipeline
上記AWSサービスは、コードの管理・ビルドの実施・デプロイの実施を行うが、サービス毎の連携はできない。
(CodeCommitから検知してCodeBuildの実行は可能)
CodePipelineは上記Code系サービスを連結させて、CI/CDを自動的に実行してくれるサービス。
図にするとこんな感じ。
Code系サービスを触ってみよう!
①CodeCommitとCodePipelineを使用して静的コンテンツをS3にデプロイする
表題の通り、CodeComitとCodePiplelineを使用して静的コンテンツのCD環境を構築していきます。
図にするとこんな感じ
手順
以下の順番でCD環境の構築を行なっていく
- 成果物の確認
- S3バケットを用意
- CodeCommitを用意
- CodePipleLineの設定を行う
- 動作確認
1.成果物の確認
htmlファイルを用意して、変更を加えた後にデプロイを行う。
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Document</title>
</head>
<body>
Hello Wolrd!
</body>
</html>
2.S3バケットを用意
S3バケットを用意する際はパブリックからアクセスできるように設定を行うこと
-
任意な名前のバケットを作成
-
静的ホスティングの設定を行う
3.パブリックアクセスのブロックを全てOFFにする。
- パケットポリシーを許可するようにJSONファイルを設定する
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::20231119-hanzuon-code-servies/*"
}
]
}
- HTMLファイルをアップロードしてHTMLファイルにアクセスできるか確認する。
(プロパティの静的ウェブサイトホスティングのところからDNSを確認することができる)
3.CodeCommitを用意
任意な名前のリポジトリを作成し、HTMLファイルをプッシュする。
4.CodePipleLineの設定を行う
CodePipelineのマネジメントコンソールから設定を行なっていく。
-
任意な名前のパイプラインの名前を設定
-
ソースコードの設定を行う
-
デプロイステージの設定を行う(ビルドステージはスキップ)
オブジェクトの箇所は以下の画像の通りにすること
- 最後に設定の確認を行い、パイプラインの確認をクリック
CDのテスト実施がすぐに実施されるので、実施結果が成功することを確認する
5.動作確認を行う
HTMLを任意な内容に変更してCodeCommitにPUSHする。
その後CodePipelineの動作を確認し、CDが正常に実行されていることを確認する。
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Document</title>
</head>
<body>
Hello Wolrd! <br />
Create CodePipeline!!!
</body>
</html>
Codecommitに変更をPUSHした後の変更反映確認
変更が反映されてますね!!!
次に下の内容を試してみたいのですが、ここまででそこそこの量になってしまったので、続きは後日記載しようと思います。
- CodeCommit・Codebuild・CodeDeploye・CodePipelineを使用してLambdaにデプロイ
- 同じ内容でECSへデプロイ
Discussion