CI/CD パイプライン環境を構築します。
今回は Angular(アプリ)、Git、CodePipeline、CodeCommit、CodeBuild、CodeDeploy、Auto Scaling、ALB の組み合わせで行います。
今までは EC2 インスタンス単体へのデプロイでしたが、今回はロードバランサー(ALB)を利用してロードバランサをして、更に Auto Scaling でオートスケールをするような環境を構築しています。
CI/CD のサンプルとしては他にも以下の記事があります。
CodeDeploy の解説です。
AWS CodeDeploy
AWSインフラ研究所
https://go-journey.club/archives/14899
AWSを中心としたクラウドインフラ技術サイト
【AWS】CodeDeployとAuto Scaling+ALBを組み合わせる環境の構築手順
AWSインフラ研究所
https://go-journey.club/archives/16268
AWSを中心としたクラウドインフラ技術サイト
【AWS】DevOps(CI/CD)の導入手順(Spring Tools、Git、CodePipeline、CodeCommit、CodeBuild、CodeDeploy)
AWSインフラ研究所
https://go-journey.club/archives/15996
AWSを中心としたクラウドインフラ技術サイト
【AWS】DevOps(CI/CD)の導入手順(CodePipeline、CodeCommit、CodeBuild、CodeDeploy)
AWSインフラ研究所
https://go-journey.club/archives/15726
AWSを中心としたクラウドインフラ技術サイト
CodeDeploy でデプロイエラーになった場合は以下の記事を参考にしてください。
【AWS】CodePipeline での CodeDeploy でのデプロイでエラーになった場合のトラブル対応手順
AWSインフラ研究所
https://go-journey.club/archives/16551
AWSを中心としたクラウドインフラ技術サイト
構成図
今回は以下の構成でパブリックサブネットとプライベートサブネットを作成し、更に 2つのアベイラビリティゾーンに分けて ALB と EC2 インスタンスを配置し Auto Scaling でスケーリングをする環境を構築します。
■構成図
パブリックサブネット :10.0.10.0/24、10.0.11.0/24
プライベートサブネット:10.0.12.0/24、10.0.13.0/24
CodeCommit の設定
最初に CodeCommit から設定します。
AWS 管理画面にログインして CodeCommit のダッシュボードに移動します。
「リポジトリを作成」ボタンをクリックします。
「リポジトリ名」を設定して「作成」ボタンをクリックします。
Git 用のアカウントの設定
既存の IAM ユーザーを利用して Git の認証情報を作成します。
もし Git コマンド用に別途新規アカウントを作成したい場合は、新規で IAM ユーザーを作成します。
今回は既存の IAM ユーザーを利用する手順となります。
IAM ダッシュボードに移動します。
左側ペインより「ユーザー」をクリックします。
「認証情報」タブをクリックします。
「認証情報を生成」ボタンをクリックします。
「証明書のダウンロード」ボタンをクリックしてユーザーとパスワード情報を保存します。
CodeCommit リポジトリへの接続設定
PCのCドライブ直下に「work」フォルダを作成し、work フォルダに Angular 用のフォルダ「my-angular-project」フォルダを作成して Angular のソースコードを配置します。
フォルダ構成:C:\work\my-angular-project
CodeCommit の今回作成したリポジトリの画面より「URL のクローン」‐「HTTPS のクローン」をクリックして URL をコピーします。
コマンドプロンプトを起動し C:\work\my-angular-project フォルダに移動し git コマンドを実行します。
■C:\work\my-angular-project に移動する
c:\work>cd my-angular-project
■CodeCommitのリモートリポジトリを登録する
c:\work\my-angular-project>git remote add origin https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/MyAngularRepo01
「git remote add origin リモートリポジトリ(CodeCommitのリポジトリ)の場所」コマンドで、現在のローカルリポジトリに指定したリモートリポジトリを追加します。
■リモートリポジトリにプッシュする
c:\work\my-angular-project>git push origin master
Enumerating objects: 56, done.
Counting objects: 100% (56/56), done.
Delta compression using up to 8 threads
Compressing objects: 100% (54/54), done.
Writing objects: 100% (56/56), 140.03 KiB | 5.83 MiB/s, done.
Total 56 (delta 10), reused 0 (delta 0), pack-reused 0
To https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/MyAngularRepo01
* [new branch] master -> master
c:\work\my-angular-project>
「git push origin master」コマンドでローカルリポジトリ master をリモートレポジトリ(origin)に push します。
毎回リモートリポジトリにプッシュする際にアカウントとパスワードを入力したい場合
gitコマンドで一度リモートリポジトリにプッシュする際に認証情報を入力すると、認証情報が残り次回以降はアカウントとパスワードを入力するプロンプトは出てきません。
もしセキュリティ上、毎回リモートリポジトリにプッシュする際にアカウントとパスワードを入力したい場合はコンフィグファイルを修正します。
■確認コマンド
C:\work\my-angular-project> git config -l
diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean — %f
filter.lfs.smudge=git-lfs smudge — %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
http.sslbackend=openssl
http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
core.autocrlf=true
core.fscache=true
core.symlinks=false
pull.rebase=false
credential.helper=manager-core ← credential.helper 設定が有効になっていて、認証情報がキャッシュ、またはファイル 保存されています。
credential.https://dev.azure.com.usehttppath=true
init.defaultbranch=master
core.editor=”C:\Users\xxxx\AppData\Local\Programs\Microsoft VS Code\Code.exe” –wait
user.email=xxxxxxx@gmail.com
user.name=xxxxxxx
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
core.precomposeunicode=true
remote.origin.url=https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/xxxxxxxxxx
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
PS C:\work\my-angular-project>
毎回アカウントとパスワードを入力する設定にする場合、etc フォルダ配下にある gitconfig ファイルを修正します。
■Before
[diff “astextplain”]
textconv = astextplain
[filter “lfs”]
clean = git-lfs clean — %f
smudge = git-lfs smudge — %f
process = git-lfs filter-process
required = true
[http]
sslBackend = openssl
sslCAInfo = C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
[core]
autocrlf = true
fscache = true
symlinks = false
[pull]
rebase = false
[credential]
helper = manager-core ← この helper の行を削除します。
[credential “https://dev.azure.com”]
useHttpPath = true
[init]
defaultBranch = master
■After
[diff “astextplain”]
textconv = astextplain
[filter “lfs”]
clean = git-lfs clean — %f
smudge = git-lfs smudge — %f
process = git-lfs filter-process
required = true
[http]
sslBackend = openssl
sslCAInfo = C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
[core]
autocrlf = true
fscache = true
symlinks = false
[pull]
rebase = false
[credential]
[credential “https://dev.azure.com”]
useHttpPath = true
[init]
defaultBranch = master
ファイルを変更して保存すると毎回以下のようにアカウントとパスワードを入力する画面が表示されるようになります。
入力するアカウントとパスワードは、Git 用アカウント(IAM ユーザー)を作成した際に取得した(ダウンロードした)Git の認証情報のアカウントとパスワードになります。
■アカウント入力画面
■パスワード入力画面
CodeCommitのリポジトリにソースコードが書き込まれていることを確認します。
以上で CodeCommit の設定は完了です。
CodeBuid の設定
CodeBuid の設定は、CodePipeline のパイプラインを作成する際に設定します。
ここでは buildspec.yml ファイルを作成します。
buildspec.yml ファイルを作成する
まずは buildspec.yml ファイルを作成します。
■buildspec.yml ファイル
version: 0.2
phases:
install:
runtime-versions:
nodejs: 12
commands:
– npm install -g @angular/cli@9.0.6
pre_build:
commands:
– npm install
build:
commands:
– ng build –prod
artifacts:
base-directory: dist/my-angular-project
files:
– ‘**/*’
phasesで下図のように
install
pre_build
build
post_build
の順番でコマンドが実行されます。
■AWS CodeBuild のビルドフェーズの流れ
installフェーズでは文字通りinstallのみ実行されるので、ここでインストールしたいパッケージを指定します。
npm install -g @angular/cli@x.x.x コマンドで angular/cli パッケージをグローバルインストールします。
npm install -g パッケージ でパッケージをグローバルインストールできます。
npm install のみの場合は package.json ファイルで定義された依存関係をダウンロードしてインストールされたモジュールを含む node_modules フォルダを生成します。
ng build –prod で production(本番環境)としてビルドします。
angular アプリケーションをビルドすると dist/project フォルダにプログラムが保存されます。
install フェーズで Ubuntu 標準イメージ 2.0 以降および Amazon Linux 2 標準イメージ 1.0 以降の場合、ランタイムバージョンが指定できます。
逆に pre_build フェーズや build フェーズではランタイムバージョンは指定できずに単純にコマンドが実行できます。
各フェーズでの使用例としては一般的に以下の 用途で使用します。
install: ビルド環境のパッケージインストール
pre_build: ビルド前に実行したいコマンド(例えば Amazon ECR のサインイン等)
build: ビルド時に実行するコマンド
post_build: ビルド前に実行したいコマンド(例えば Docker イメージを Amazon ECR にプッシュする等)
ビルドフェーズの移行
https://docs.aws.amazon.com/ja _jp/codebuild/latest/userguide /view-build-details.html#view- build-details-phases
CodeBuild のビルド仕様に関するリファレンス – AWS CodeBuild – phases
https://docs.aws.amazon.com/ja _jp/codebuild/latest/userguide /build-spec-ref.html#build- spec.phases
buildspec.yml ファイルで echo コマンドを実行した場合の出力先は?
buildspec.yml ファイルで echo コマンドを実行した場合の出力先はどこになるのでしょうか?
echo コマンドの出力先は AWS CodeBuild のビルドログになります。
ログの出力先はビルドプロジェクトの設定により CloudW atch Logs または S3 を出力先として指定可能です。
ビルドプロジェクトの設定の変更 (コンソール) – AWS CodeBuild – Logs
https://docs.aws.amazon.com/ja _jp/codebuild/latest/userguide /change-project-console.html# change-project-console-logs
以下のようにビルドプロジェクト の設定を変更して、CloudWatch Logs または S3 へのログ出力を有効化することで echo コマンドで出力される内容が指定された先にログ出力されるよ うになります。
「編集」‐「ログ」をクリックします。
必要な場合は「CloudWatch Logs ‐ オプショナル」にチェックを入れます。
S3 にログを出力させたい場合は「S3ログ ‐ オプショナル」にチェックを入れます。
ビルドプロジェクトの作成時に も設定できます。
上記のログ設定にて CloudWatch Logs を有効化している場合、CodeBuild コンソール画面「ビルド履歴」より該当のビルドを選択して 「ビルドログ」のタブを表示するとログの一部を確 認できます。
CodeDeploy の設定
CodeDeploy の設定をします。
デプロイ用の IAM ロールの作成
最初にデプロイ用の IAM ロールを作成します。
IAM ダッシュボードに移動します。
左側ペインより「ロール」をクリックします。
「ロールを作成」ボタンをクリックします。
今回は EC2 インスタンスに作成するロールをアタッチします。
ロールの作成画面で信頼されたエンティティの種類で「AWS サービス」を選択し、ユースケースで「EC2」を選択し「次のステップ:アクセス権限」ボタンをクリックします。
IAM ロールを作成します。
EC2 インスタンスに割り当てるロールでポリシー「AmazonEC2RoleforAWSCodeDeploy」を選択します。
■AmazonEC2RoleforAWSCodeDeploy ポリシーの内容
“Version”: “2012-10-17”,
“Statement”: [
{
“Action”: [
“s3:GetObject”,
“s3:GetObjectVersion”,
“s3:ListBucket”
],
“Effect”: “Allow”,
“Resource”: “*”
}
]
}
こうしてポリシーを確認してみると EC2インスタンスや CodeDeploy は出てこなくて、内容は S3 へのアクセス権だけです。
デプロイをする際に S3 バケットからアーティファクトを取得するために使用すると思われます。
「タグの追加(オプション)」画面でそのまま「次のステップ:確認」ボタンをクリックします。
「ロール名」を入力し「ロールの作成」ボタンをクリックします。
EC2 インスタンスの構築(起動)
デプロイをする EC2 インスタンスを構築(起動)します。
EC2 のダッシュボードに移動します。
まずは EC2 インスタンスにアプリケーションをデプロイをするので「自動割り当てパブリックIP」を「有効」に設定します。
サブネットはインターネットゲートウェイがアタッチされているパブリックサブネットを選択します。
先ほど作成した IAM ロールを忘れないように設定します。
CodeDeploy Agent のインストール
EC2 インスタンスに CodeDeploy Agent をインストールします。
■yum update の実施
[ec2-user@ip-10-0-10-234 ~]$ sudo su –
[root@ip-10-0-10-234 ~]# yum update
■Ruby のインストール
[root@ip-10-0-10-234 ~]# yum install ruby
■CodeDeploy Agent のインストールファイルのダウンロード
[root@ip-10-0-10-234 ~]# wget https://aws-codedeploy-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/install
■install ファイルに実行権限付与
[root@ip-10-0-10-234 ~]# chmod +x ./install
■インストール
[root@ip-10-0-10-234 ~]# ./install auto
■CodeDeploy Agent の起動確認
[root@ip-10-0-10-234 ~]# service codedeploy-agent status
The AWS CodeDeploy agent is running as PID 7737
[root@ip-10-0-10-234 ~]#
EC2 インスタンスに nginx のインストール
■nginxのインストール
[root@ip-10-0-10-234 ~]# amazon-linux-extras install nginx1
■nginxのステータス確認
[root@ip-10-0-10-234 ~]# systemctl status nginx
● nginx.service – The nginx HTTP and reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
Active: inactive (dead)
[root@ip-10-0-10-234 ~]#
■nginxの起動
[root@ip-10-0-10-234 ~]# systemctl start nginx
■nginxの起動確認
[root@ip-10-0-10-234 ~]# systemctl status nginx
● nginx.service – The nginx HTTP and reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
Active: active (running) since Tue 2021-09-28 14:54:17 UTC; 2s ago
Process: 7978 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
Process: 7974 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
Process: 7973 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
Main PID: 7980 (nginx)
CGroup: /system.slice/nginx.service
tq7980 nginx: master process /usr/sbin/nginx
mq7981 nginx: worker process
Sep 28 14:54:17 ip-10-0-10-234.ap-northeast-1.compute.internal systemd[1]: Starting The nginx HTTP and rever….
Sep 28 14:54:17 ip-10-0-10-234.ap-northeast-1.compute.internal nginx[7974]: nginx: the configuration file /e…k
Sep 28 14:54:17 ip-10-0-10-234.ap-northeast-1.compute.internal nginx[7974]: nginx: configuration file /etc/n…l
Sep 28 14:54:17 ip-10-0-10-234.ap-northeast-1.compute.internal systemd[1]: Started The nginx HTTP and revers….
Hint: Some lines were ellipsized, use -l to show in full.
[root@ip-10-0-10-234 ~]#
■nginx の自動起動設定
[root@ip-10-0-10-234 ~]# systemctl enable nginx
Created symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service.
[root@ip-10-0-10-234 ~]#
■nginx の自動起動設定確認
[root@ip-10-0-10-234 ~]# systemctl list-unit-files | grep nginx
nginx.service enabled
[root@ip-10-0-10-234 ~]#
nginx の動作確認をします。
ブラウザを起動して EC2 インスタンスのグローバルIPアドレスを入力して nginx の画面が表示されることを確認します。
Angular アプリ用の nginx の設定をする
Angular アプリ用の nginx の設定をします。
具体的には、Angular アプリ用のディレクトリを作成し nginx の root フォルダの設定をします。
■Angular用のディレクトリを作成する
[root@ip-10-0-10-234 ~]# mkdir -p /var/www/my-angular-project
■nginx.conf ファイルを編集する
[root@ip-10-0-10-234 ~]# vi /etc/nginx/nginx.conf
server {
listen 80;
listen [::]:80;
server_name _;
root /var/www/my-angular-project; ← root フォルダを設定します。
■nginx の再起動
[root@ip-10-0-10-234 ~]# systemctl restart nginx
■nginx の起動確認
[root@ip-10-0-10-234 ~]# systemctl status nginx
● nginx.service – The nginx HTTP and reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2021-09-28 15:01:11 UTC; 4s ago
Process: 8068 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
Process: 8064 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
Process: 8062 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
Main PID: 8071 (nginx)
CGroup: /system.slice/nginx.service
tq8071 nginx: master process /usr/sbin/nginx
mq8072 nginx: worker process
Sep 28 15:01:11 ip-10-0-10-234.ap-northeast-1.compute.internal systemd[1]: Stopped The nginx HTTP and revers….
Sep 28 15:01:11 ip-10-0-10-234.ap-northeast-1.compute.internal systemd[1]: Starting The nginx HTTP and rever….
Sep 28 15:01:11 ip-10-0-10-234.ap-northeast-1.compute.internal nginx[8064]: nginx: the configuration file /e…k
Sep 28 15:01:11 ip-10-0-10-234.ap-northeast-1.compute.internal nginx[8064]: nginx: configuration file /etc/n…l
Sep 28 15:01:11 ip-10-0-10-234.ap-northeast-1.compute.internal systemd[1]: Started The nginx HTTP and revers….
Hint: Some lines were ellipsized, use -l to show in full.
[root@ip-10-0-10-234 ~]#
root フォルダは空っぽの状態なので、以下のように 403 Forbidden が表示されることを確認します。
appspec.yml ファイルを作成する
CodeDeploy 用に appspec.yml ファイルを作成します。
■appspec.yml ファイル
version: 0.0
os: linux
files:
– source: dist/my-angular-project
destination: /var/www/my-angular-project ← nginx.conf で設定した root に合わせます。
permissions:
– object: /var/www/my-angular-project
pattern: ‘**’
mode: ‘0755’
owner: root
group: root
type:
– file
– directory
hooks:
ApplicationStart:
– location: deploy-scripts/application-start-hook.sh
timeout: 300
application-start-hook.sh の作成
次に application-start-hook.sh ファイルを作成します。
■application-start-hook.sh ファイル
#!/bin/bash
sudo service nginx restart
シェルスクリプトの内容は nginx の再起動です。
CodeDeploy用のIAMロールの作成
最初に CodeDeploy 用の IAM ロールを作成します。
IAM のダッシュボードに移動します。
ポリシー「AWSCodeDeployRole」が選択されていることを確認します。
■AWSCodeDeployRole ポリシーの内容
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“autoscaling:CompleteLifecycleAction”,
“autoscaling:DeleteLifecycleHook”,
“autoscaling:DescribeAutoScalingGroups”,
“autoscaling:DescribeLifecycleHooks”,
“autoscaling:PutLifecycleHook”,
“autoscaling:RecordLifecycleActionHeartbeat”,
“autoscaling:CreateAutoScalingGroup”,
“autoscaling:UpdateAutoScalingGroup”,
“autoscaling:EnableMetricsCollection”,
“autoscaling:DescribePolicies”,
“autoscaling:DescribeScheduledActions”,
“autoscaling:DescribeNotificationConfigurations”,
“autoscaling:SuspendProcesses”,
“autoscaling:ResumeProcesses”,
“autoscaling:AttachLoadBalancers”,
“autoscaling:AttachLoadBalancerTargetGroups”,
“autoscaling:PutScalingPolicy”,
“autoscaling:PutScheduledUpdateGroupAction”,
“autoscaling:PutNotificationConfiguration”,
“autoscaling:PutWarmPool”,
“autoscaling:DescribeScalingActivities”,
“autoscaling:DeleteAutoScalingGroup”,
“ec2:DescribeInstances”,
“ec2:DescribeInstanceStatus”,
“ec2:TerminateInstances”,
“tag:GetResources”,
“sns:Publish”,
“cloudwatch:DescribeAlarms”,
“cloudwatch:PutMetricAlarm”,
“elasticloadbalancing:DescribeLoadBalancers”,
“elasticloadbalancing:DescribeInstanceHealth”,
“elasticloadbalancing:RegisterInstancesWithLoadBalancer”,
“elasticloadbalancing:DeregisterInstancesFromLoadBalancer”,
“elasticloadbalancing:DescribeTargetGroups”,
“elasticloadbalancing:DescribeTargetHealth”,
“elasticloadbalancing:RegisterTargets”,
“elasticloadbalancing:DeregisterTargets”
],
“Resource”: “*”
}
]
}
AWSCodeDeployRole ポリシーの内容ですが、まとめると以下のようになります。
インスタンスのタグを読み取る、または Amazon EC2 Auto Scaling グループ名により Amazon EC2 インスタンスを識別します。
Auto Scaling グループ、ライフサイクルフック、スケーリングポリシーの読み取り、作成、更新、削除を行います。
Amazon SNS トピックに情報を公開します。
CloudWatch アラームに関する情報を取得します。
Elastic Load Balancing を操作します。
CodeDeploy のアプリケーションの作成
CodeDeploy のダッシュボードに移動します。
CodeDeploy デプロイグループの作成
CodeDeploy のデプロイグループを作成します。
デプロイに追加する環境は一旦 EC2 インスタンスを設定します。後程動作確認をしてから「Amazon EC2 Auto Scaling グループ」に変更します。
デプロイ対象の EC2 インスタンスで設定した Application タグで指定します。
CodePipeline の設定
CodePipeline のダッシュボードに移動します。
パイプラインを作成すると自動的に最初のパイプラインが実行されます。
動作確認
EC2 インスタンスのパブリック IP アドレスにアクセスをして動作確認をします。
■S3 バケットの内容
パイプライン名と同じ名前のオブジェクトが作成されています。
例えば、もう1つ test-pipeline-001 という名前のパイプランを作成した場合、この同じオブジェクト(フォルダ)の下に「test-pipeline-001」という名前のオブジェクト(フォルダ)が作成されます。
codepipeline-ap-northeast-1-xxxxx は CodePipeline が自動的に作成するアーティファクト用のオブジェクトになります。
2つのオブジェクトが自動的に作成されています。
BuildArtif/ ← CodeBuild でビルドされたアーティファクトが入っています。
SourceArti/ ← CodeBuild に引き渡すアーティファクトが入っています。
■SourceArti/ の中
0v3aFZ4 をダウンロードして解凍してみます。
ソースコード一式が入っています。
■BuildArtif/ の中
ビルド後のアーティファクトと、appspec.ymlファイルと nginx を再起動するスクリプトが入っている「deploy-scripts」フォルダが見えます。
buildspec.yml ファイルはありません。
CodeDeploy でデプロイ時のログの確認
■codedeploy-agent-deployments.log の内容
[root@ip-10-0-10-234 deployment-logs]# pwd
/opt/codedeploy-agent/deployment-root/deployment-logs
[root@ip-10-0-10-234 deployment-logs]# ls
codedeploy-agent-deployments.log
[root@ip-10-0-10-234 deployment-logs]# less codedeploy-agent-deployments.log
# Logfile created on 2021-10-01 12:47:34 +0000 by logger.rb/41954
[2021-10-01 12:47:34.755] [d-MKTGCO03D]LifecycleEvent – ApplicationStart
[2021-10-01 12:47:34.755] [d-MKTGCO03D]Script – deploy-scripts/application-start-hook.sh
[2021-10-01 12:47:34.841] [d-MKTGCO03D][stderr]Redirecting to /bin/systemctl restart nginx.service
[root@ip-10-0-10-234 deployment-logs]#
CodeDeploy Agent が CloudWatch にログを出力させるようにする設定
CodeDeploy Agent が CloudWatch にログを出力させるようにする設定をします。
CloudWatch にログを出力させるには CloudWatch Agent のインストールと CloudWatch にアクセスするための IAM ロールの設定が必要になります。
CloudWatch Agent のインストール
CloudWatch Agent をインストールします。
CloudWatch エージェントのインストール
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html
■CloudWatch Agent のインストール
[root@ip-10-0-10-234 ~]# yum install amazon-cloudwatch-agent
■CloudWatch Agent の設定
[root@ip-10-0-10-234 ~]# /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard
=============================================================
= Welcome to the AWS CloudWatch Agent Configuration Manager =
=============================================================
On which OS are you planning to use the agent?
1. linux
2. windows
3. darwin
default choice: [1]:
1
Trying to fetch the default region based on ec2 metadata…
Are you using EC2 or On-Premises hosts?
1. EC2
2. On-Premises
default choice: [1]:
1
Which user are you planning to run the agent?
1. root
2. cwagent
3. others
default choice: [1]:
2
Do you want to turn on StatsD daemon?
1. yes
2. no
default choice: [1]:
2
Do you want to monitor metrics from CollectD?
1. yes
2. no
default choice: [1]:
2
Do you want to monitor any host metrics? e.g. CPU, memory, etc.
1. yes
2. no
default choice: [1]:
2
Do you have any existing CloudWatch Log Agent (http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AgentReference.html) configuration file to import for migration?
1. yes
2. no
default choice: [2]:
2
Do you want to monitor any log files?
1. yes
2. no
default choice: [1]:
1
Log file path:
/opt/codedeploy-agent/deployment-root/deployment-logs/codedeploy-agent-deployments.log
Log group name:
default choice: [codedeploy-agent-deployments.log]
Log stream name:
default choice: [{instance_id}]
Do you want to specify any additional log files to monitor?
1. yes
2. no
default choice: [1]:
2
Saved config file to /opt/aws/amazon-cloudwatch-agent/bin/config.json successfully.
Current config as follows:
{
“agent”: {
“run_as_user”: “cwagent”
},
“logs”: {
“logs_collected”: {
“files”: {
“collect_list”: [
{
“file_path”: “/opt/codedeploy-agent/deployment-root/deployment-logs/codedeploy-agent-deployments.log”,
“log_group_name”: “codedeploy-agent-deployments.log”,
“log_stream_name”: “{instance_id}”
}
]
}
}
}
}
Please check the above content of the config.
The config file is also located at /opt/aws/amazon-cloudwatch-agent/bin/config.json.
Edit it manually if needed.
Do you want to store the config in the SSM parameter store?
1. yes
2. no
default choice: [1]:
2
Program exits now.
■コンフィグファイルを確認する
[root@ip-10-0-10-234 ~]# less /opt/aws/amazon-cloudwatch-agent/bin/config.json
{
“agent”: {
“run_as_user”: “cwagent”
},
“logs”: {
“logs_collected”: {
“files”: {
“collect_list”: [
{
“file_path”: “/opt/codedeploy-agent/deployment-root/deployment-logs/codedeploy-agent-deployments.log”,
“log_group_name”: “codedeploy-agent-deployments.log”,
“log_stream_name”: “{instance_id}”
}
]
}
}
}
}
■コンフィグファイルを編集する
[root@ip-10-0-10-234 ~]# vi /opt/aws/amazon-cloudwatch-agent/bin/config.json
{
“agent”: {
“run_as_user”: “cwagent”
},
“logs”: {
“logs_collected”: {
“files”: {
“collect_list”: [
{
“file_path”: “/opt/codedeploy-agent/deployment-root/deployment-logs/codedeploy-agent-deployments.log”,
“log_group_name”: “codedeploy-agent-deployments.log”,
“log_stream_name”: “{instance_id}”,
“timestamp_format”: “[%Y-%m-%d %H:%M:%S.%f]” ← この1行を追加します。
}
]
}
}
}
}
■CloudWatch Agent の更新されたコンフィグを読み込んでの起動
[root@ip-10-0-10-234 ~]# /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json -s
****** processing amazon-cloudwatch-agent ******
/opt/aws/amazon-cloudwatch-agent/bin/config-downloader –output-dir /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d –download-source file:/opt/aws/amazon-cloudwatch-agent/bin/config.json –mode ec2 –config /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml –multi-config default
Successfully fetched the config and saved in /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_config.json.tmp
Start configuration validation…
/opt/aws/amazon-cloudwatch-agent/bin/config-translator –input /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json –input-dir /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d –output /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml –mode ec2 –config /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml –multi-config default
2021/10/01 23:34:59 Reading json config file path: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_config.json.tmp …
Valid Json input schema.
I! Detecting run_as_user…
No csm configuration found.
No metric configuration found.
Configuration validation first phase succeeded
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent -schematest -config /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml
Configuration validation second phase succeeded
Configuration validation succeeded
amazon-cloudwatch-agent has already been stopped
Created symlink from /etc/systemd/system/multi-user.target.wants/amazon-cloudwatch-agent.service to /etc/systemd/system/amazon-cloudwatch-agent.service.
Redirecting to /bin/systemctl restart amazon-cloudwatch-agent.service
[root@ip-10-0-10-234 ~]#
■CloudWatch Agent の起動確認
[root@ip-10-0-10-234 ~]# ps -ef | grep cloudwatch-agent
cwagent 3480 1 0 23:35 ? 00:00:00 /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent -config /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml -envconfig /opt/aws/amazon-cloudwatch-agent/etc/env-config.json -pidfile /opt/aws/amazon-cloudwatch-agent/var/amazon-cloudwatch-agent.pid
ec2-user 3503 3227 0 23:36 pts/0 00:00:00 grep –color=auto cloudwatch-agent
[root@ip-10-0-10-234 ~]#
■CloudWatch Agent の起動確認
[root@ip-10-0-10-234 ~]# /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status
{
“status”: “running”,
“starttime”: “2021-10-01T23:35:00+0000”,
“configstatus”: “configured”,
“cwoc_status”: “stopped”,
“cwoc_starttime”: “”,
“cwoc_configstatus”: “not configured”,
“version”: “1.247347.4”
}
[root@ip-10-0-10-234 ~]#
■CloudWatch Agent の自動起動確認
[root@ip-10-0-10-234 ~]# sudo systemctl list-unit-files | grep cloudwatch
amazon-cloudwatch-agent.service enabled
[root@ip-10-0-10-234 ~]#
IAM ロールの修正
EC2 インスタンスの CloudWatch Agent が CloudWatch にログを書き込めるように IAM ロールを修正します。
現在の EC2 インスタンスに割り当てた IAM ロールを確認します。
AmazonEC2RoleforAWSCodeDeploy しかないので、CloudWatch のポリシーを割り当てて CloudWatch にログを出力できるようにします。
CloudWatch のログ確認
CloudWatch でログが出力されていることを確認します。
以上が第一段階の EC2 インスタンスへのデプロイの環境構築の手順となります。
次にここから Auto Scaling グループと ELB で環境を構築します。
EC2 インスタンスの環境準備
Auto Scaling 用に EC2 インスタンスの準備をします。
CodeDeploy でデプロイされたアーティファクトを削除する
CodeDeploy でデプロイされたアーティファクトを削除します。
■デプロイされたアーティファクトを削除
[root@ip-10-0-10-234 ~]# rm -f /var/www/my-angular-project/*
[root@ip-10-0-10-234 ~]# ls /var/www/my-angular-project/*
[root@ip-10-0-10-234 ~]#
EC2 インスタンスのイメージを作成
EC2 インスタンスを停止します。
ELB(ALB)の作成
ターゲットグループを作成しますが、ターゲットは何も追加しません。Auto Scaling で自動的に EC2 インスタンスが起動されます。
ターゲットグループの設定変更
Auto Scaling の起動設定をする
Auto Scaling グループの作成
作成した起動設定から Auto Scaling グループを作成します。
上記で作成した起動設定にチェックを入れて「アクション」‐「Auto Scaling グループの作成」をクリックします。
以下の設定をして「次へ」ボタンをクリックします。
Auto Scaling グループ名 ← 任意のグループ名を設定します。
起動設定 ← 先ほどチェックを入れた起動設定になっていることを確認します。
以下のようにネットワークの設定をして「次へ」ボタンをクリックします。
VPC ← 今回利用する VPC を指定します。
サブネット ← EC2 インスタンスを配置するサブネットを指定します。通常 EC2 インスタンスはプライベートサブネットに配置するのでプライベートサブネットを複数選択します。
最大キャパシティが 1 の設定で高負荷を掛けた場合はどうなるのか?
今回は「最大キャパシティ」を「2」にして構築しましたが、「最大キャパシティ」が「1」の場合で高負荷を掛けた場合はどうなるでしょうか?
EC2 Auto Scaling の自動スケーリングで設定される動的なスケーリングポリシーでは 希望する容量が最大キャパシティのサイズ制限に達するとスケールアウトは停 止します。
そのため最大キャパシティが 1 で、現在のインスタンスの数が 1 の場合はスケールアウトは行われず、既存のインスタンスが起動し 続けます。
つまり何も変化は起きないということになります。
例えば 1台から 2台になることもなければ、1台が再起動してワンランク上のインスタンスタイプで起動するということもありません。
動的スケーリングポリシーの仕組み | Amazon EC2 Auto Scaling の動的スケーリング
https://docs.aws.amazon.com/ja _jp/autoscaling/ec2/userguide/ as-scale-based-on-demand.html# as-how-scaling-policies-work
================
希望する容量が最大サイズ制限に達すると、スケールアウトは停止 します。
需要が低下し、容量が減少した場合、Amazon EC2 Auto Scaling は再びスケールアウトできます。
================
CodeDeploy の設定変更
現在 Auto Scaling の設定は EC2 インスタンスを使用する設定になっているので Auto Scaling を使用するように設定を変更します。
CodePipeline の修正をする
CodePipeline の修正をして Auto Scaling +ALB の構成に切り替えます。
パイプラインを実行する
ロードバランサーのDNSにアクセスをしてアプリが稼働することを確認します。
コメント