今回の意義・ゴール

・CI/CDの流れを理解する
→何となくで理解をしているが、はっきりと理解するために言葉の意味も交えながら記事にする。

・ローカルにあるDockerイメージをCICD環境を通じてECSに自動デプロイすることが今回のゴール

使用サービスおよび構成図

参考先

使用サービス・環境

【AWS】

CodeCommit
CodePipeline
CodeBulid
CodeDeploy
S3
ECS
ECR
ALB
操作環境→vscode(AWS CLIインストール済み)

使用するファイル

【CodeBulid】

bulidspec.yml　→ビルド処理の定義書
Dockerfile　→Dockerを使用するための定義書

【CodeDeploy】

appspec.yml →デプロイ処理用の定義書
taskdef.json →タスク定義を作成する定義書
imageDetail.json →ECS Blue/Greenrデプロイ時に必要な定義書

CI/CDとは何なのか？

CI/CD(継続的インテグレーションと継続的デリバリー/デプロイメント)
一言でいえばソフトウェア開発と運用のプロセスを自動化して、効率的に開発と運用をするための手法やツールのセットのことを言う。

さらに深堀りしてみる。

継続的インテグレーション（CI: Continuous Integration）

定義

CIは開発者が頻繁にコードをリポジトリに統合するプラクティスで、通常毎日または数回に分けて実行される。

目的

統合に伴う問題を早期発見して修正すること。→統合作業に伴う負担が減り、ソフトウェアの品質が向上する。

プロセス

①開発者がコードを変更してリポジトリにコミット
②自動化されたビルドとテストが即座に実行される
③問題が発生された場合、開発者に通知が行く

利点

①早期のバグ検出
②チーム全体の可視性の向上
③ソフトウェアの品質向上
④主導による統合作業の削減

継続的デリバリー/デプロイメント（CD: Continuous Delivery/Deployment）

定義

継続的デリバリーはソフトウェアの変更がリリース可能な状態に常に保たれるプラクティス。
継続的デプロイメントは継続的デリバリーをさらに進めて、変更が自動的に本番環境にデプロイされることを指す。

目的

新機能や修正を迅速かつ安全にユーザーに届けること。→ユーザーからのフィードバックを早期に得ることが可能に

プロセス

①CIのプロセスを通過したコードは、デリバリーパイプラインに入る
②自動テスト、ステージング環境でのデプロイなどの一連の手順が実行される
③デプロイメントの最終段階として本番環境へのデプロイが行われる(継続的デプロイメントであれば自動的に)

利点

①リリースサイクルの短縮
②リスクの低減
③ユーザーからの迅速なフィードバック
④効率的なリリースプロセス

環境構築

上記構成図を作成する前にVPCや権限設定などを行うが、今回のメインはCI/CDパイプラインとECSへの自動デプロイの流れがメインとなるため省略
※参考先の72ページまでは省略
　また添付ファイルはサンプルコードから参照しつつ多少修正を加えるものとする

環境準備(Codecommit)

Codecommitでリポジトリを作成する

リポジトリ名を設定して作成を押下

URLのクローンを押下してURLを入手する
※今回はHTTPS

CLI上で下記コマンドを実施してクローンする

$ Git clone https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/php-sample
Cloning into 'php-sample'...
warning: You appear to have cloned an empty repository.

もしここでGitのアクセス認証ができない場合は下記で解決

ファイルの準備

ファイルを準備
※参照先からダウンロードして下記のような構成に変更

buildspec.yml

注意点
・envで環境変数を指定
・URL隣の/にはコンテナ名を記載
・最終行にはDeploy時に使用するappspec.ymlを明記

version: 0.2

env:
  variables:
    REPOSITORY_URI: 223303915231.dkr.ecr.ap-northeast-1.amazonaws.com/cicd
    AWS_DEFAULT_REGION: ap-northeast-1

phases:
  pre_build:
    commands:
      - echo Logging in to Amazon ECR...
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $REPOSITORY_URI
      - IMAGE_TAG=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
  build:
    commands:
      - echo Build started on `date`
      - echo Building the Docker image...
      - docker build -t $REPOSITORY_URI:latest .
      - docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
  post_build:
    commands:
      - echo Build completed on `date`
      - echo Pushing the Docker image...
      - docker push $REPOSITORY_URI:latest
      - docker push $REPOSITORY_URI:$IMAGE_TAG
      - printf '{"Version":"1.0","ImageURI":"%s"}' $REPOSITORY_URI:$IMAGE_TAG > imageDetail.json

artifacts:
  files:
    - appspec.yml

appspec.ymlファイル

注意点
・task定義にはARNを指定
・コンテナ名にはECSで稼働中の対象コンテナ名を記載

version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: "arn:aws:ecs:ap-northeast-1:223303915231:task-definition/cicd-fargate:1"
        LoadBalancerInfo:
            ContainerName: "cicd" 
            ContainerPort: 80

taskdef.json

ECSのリビジョンにてJSONをコピー

→ローカルにあるtaskdef.jsonファイルへコピーする

補足

Dockerfile

FROM php:7.4.0-apache
COPY src/ /var/www/html/

index,html

<!DOCTYPE html>
<html lang="ja">
  <head>
    <title>PHP Sample</title>
  </head>
  <body>
    <?php echo gethostname(); ?>
  </body>
</html>

ここからリポジトリへのPushを行う

#php-sampleディレクトリへの移動
cd php-sample

#全ファイルをadd
git add -A

#add→commitとコメント
git commit -m "my first commit"

#commit→push
git push origin master

CodePipeline(build,Deploy含む)の作成

CodePipelineの作成過程でCodebuildとCodeDeployも作成出来るためパイプラインを作成する

プロジェクトの作成を押下

下記設定でCodeBulidを作成する

続いてCodeDeployを設定

上記でパイプラインを作成する
→Bulidのbulidspec.ymlファイル実行権取得のためIAMロールよりcodebuild-php-sample-build-service-roleを付与する→AmazonEC2ContainerRegistryPowerUserをアタッチ

続いてCodePiplineの設定変更→編集を押下

ステージを編集するを押下→デプロイステージを編集

入力アーティファクトにSourceArtfactへ変更

続いてCodeDeployの設定編集

デプロイ設定を下記に変更
※今回は５分で設定

改めてパイプラインを実行する

下記のようなエラーが出たため調べたところCodeBuildのbulidspecファイルが見つからないというエラーが出た場合は下記を参照

[Container] 2024/06/12 12:21:57.224498 Running on CodeBuild On-demand
[Container] 2024/06/12 12:21:57.224517 Waiting for agent ping
[Container] 2024/06/12 12:21:57.426057 Waiting for DOWNLOAD_SOURCE
[Container] 2024/06/12 12:21:58.839623 Phase is DOWNLOAD_SOURCE
[Container] 2024/06/12 12:21:58.840508 CODEBUILD_SRC_DIR=/codebuild/output/src3662395164/src
[Container] 2024/06/12 12:21:58.844368 Phase complete: DOWNLOAD_SOURCE State: FAILED
[Container] 2024/06/12 12:21:58.844386 Phase context status code: YAML_FILE_ERROR Message: stat /codebuild/output/src3662395164/src/bulidspec.yml: no such file or directory

下記のようにCICD環境の作成に成功

改めてローカルからGit pushしても新しいファイルの内容でのデプロイを確認

トラブル(時間がかかったもの)

①buildspec.ymlファイルが見つからないというエラー

→(解決策)
変数の指定を前に持ってくる
特にURLの部分を先にしてしたことでこのエラーが解消された

②ECRへアクセスできない

→(解決策)
再度AWS CLIの情報を確認する。
筆者は別リージョンでaws configureを入力していたためログインができない場合は要チェック。

③appspec.ymlファイルが見つからない

→(解決策)
buildspec.ymlのアーティファクトでbuildspec.ymlを指定することで解消

やってみて

まずはCICDの基本的な流れを理解できたことが良かった。
(Github自体は使用したことがあったため割と理解はしやすかった)
特に両specファイルの中身がかなりエラーに直結していたため要注意のように感じた。
→最初だからかも？？