JAWS-UG コンテナ支部 #24 ecspresso MeetUp CodeBuildで動かすecspresso 株式会社スマートラウンド 山原 崇史(@shonansurvivors)

自己紹介 株式会社スマートラウンド SRE/コーポレートITチーム エンジニアリングマネージャー 山原 崇史 (やまはら たかし)　 経歴等 　・SIer → 銀行 → Web系ベンチャー数社 → 現職 　・2023 Japan AWS Top Engineers(Software) 　・AWS Startup Community Core Member 好きなAWSサービス 　IAM Identity Center / Security Hub shonansurvivors

ecspressoと私 実務のほか、過去の登壇、 Zenn、ブログ、書籍等のアウトプットでも取り扱わせていただいています

アジェンダ 1. CodeBuildでecspressoを動かす理由 2. ecspressoのインストールと実行 3. 関連AWSリソース情報取得方法の選択肢 4. ecspresso rollback用のCodeBuild 5. まとめ

1. CodeBuildでecspressoを動かす理由

当社がCodeBuild上でecspressoを動かしている理由 ● 元々、CDをCodePipelineで動かしていた (なお、CIはCircleCIを経て現在はGitHub Actions) ● Beanstalk→ECSへの基盤移行の際、複数の観点から検討した結果、 CodePipelineを継続採用 ● CodePipelineで呼び出し可能なCodeBuild上でecspressoを動かすこととした

2. ecspressoのインストールと実行

ecspressoをCodeBuildにインストールして実行する buildspecの例 version: 0.2 env: variables: ECSPRESSO_VERSION: 2.2.2 phases: install: commands: - curl -sL -O https://github.com/kayac/ecspresso/releases/download/ v${ECSPRESSO_VERSION}/ecspresso_${ECSPRESSO_VERSION}_linux_amd64.tar.gz - tar xzvf ecspresso_${ECSPRESSO_VERSION}_linux_amd64.tar.gz - sudo install ecspresso /usr/local/bin/ecspresso - ecspresso version # 略 build: commands: - ecspresso deploy

GitHub Actionsのアクションを使う場合 よりシンプルに記述できる version: 0.2 phases: # 略 build: steps: - uses: kayac/ecspresso@v2 # ecspressoのインストールのみを行うアクション with: version: v2.2.2 - run: ecspresso deploy

CodeBuildの各phaseにおける処理内容について phaseごとに推奨される処理内容がある (お作法のようなもの) phase ビルドを行う場合 テストを行う場合 デプロイを行う場合(※) install 各種パッケージのインストール等 各種パッケージのインストール等 各種パッケージのインストール等 pre_build ・依存関係のインストール ・ECRへのログイン 等 依存関係のインストール 依存関係のインストール build ビルドの実行 テストの実行 デプロイの実行 post_build ・アーティファクトのパッケージ ・イメージをECRにプッシュ 等 - - ※デプロイに関しては AWS公式ドキュメントに記載は無く、筆者の独自解釈

アクションを使う場合はphase分けしない 以下のようにphaseを分けるとエラーになるので注意 version: 0.2 phases: install: steps: - uses: kayac/ecspresso@v2 # ecspressoのインストール with: version: v2.2.2 # 略 build: steps: - run: ecspresso deploy # command not foundになってしまう

3. 関連AWSリソース情報取得の選択肢

ecspressoが管理するファイル ecspressoではECSサービスやタスク定義をファイルで管理する . └── ecspresso ├── buildspec.yml ├── ecspresso.yml # ecspresso全体の設定ファイル ├── ecs-service-def.json # ECSサービスの定義 └── ecs-task-def.json # タスク定義

関連AWSリソースのARNやIDの取得について ECSサービスの定義ファイル (ecs-service-def.json)には以下の指定が必要 ● ターゲットグループの ARN : arn:aws:elasticloadbalancing:region:account_id:targetgroup/name/xxxxxxxxxxxxxxxxxx ● サブネットID : subnet-xxxxxxxxxxxxxxxxx ● セキュリティグループ ID: sg-xxxxxxxxxxxxxxxx 👉こうした値を定義ファイルに直接記述すると可読性やメンテナンス性が落ちる懸念がある

あるWebサービスの例で考える . ├── ... ├── batch ├── db ├── ... └── web ├── buildspec.yml # ビルド用 ├── ... └── ecspresso ├── buildspec.yml # デプロイ用 ├── ecspresso.yml ├── ecs-service-def.json └── ecs-task-def.json . ├── ... └── some_service ├── alb.tf ├── codebuild.tf ├── codebuild_iam.tf ├── ecs.tf ├── ecs_iam.tf ├── ... └── vpc.tf アプリケーションのリポジトリ Terraformのリポジトリ

関連AWSリソースのARNやID取得方法の選択肢 1. ecspressoのtfstate読み込み機能を使ってARNやIDを取得 👉詳しくは「ecspresso handbook v2対応版」を参照(https://zenn.dev/fujiwara/books/ecspresso-handbook-v2) 2. CodeBuildのbuildspec上でAWS CLIを実行し、Nameタグなどを元にARNやIDを取得 👉詳しくは「EC2からのECS移行においてIaCとCDをどう変えたか」を参照 　(https://speakerdeck.com/shonansurvivors/transitioning-from-ec2-to-ecs-adapting-iac-and-cd-strategies) 3. CodeBuildのビルドプロジェクトの環境変数に ARNやIDを設定する 👉今回採り上げるのはこちら

ビルドプロジェクトの環境変数経由で取得する ビルドプロジェクトの環境変数に他リソースの属性をセットし、さらに ECS定義ファイルで参照させる resource "aws_codebuild_project" "deploy_webapp" { # 略 environment { # 略 environment_variable { name = "TARGET_GROUP_ARN" value = aws_lb_target_group.webapp.arn type = "PLAINTEXT" } # 略 } # 略 } # ecs-service-def.jsonより抜粋 { # 略 "loadBalancers": [ { "containerName": "nginx", "containerPort": 80, "targetGroupArn": "{{ must_env `TARGET_GROUP_ARN` }}" } ], # 略 }

4. ecspresso rollback用のCodeBuild

当初考えた案 「ecspresso rollback」を実行するbuildspecのファイルを用意しておく(実行は手動を想定) . ├── ... ├── db ├── ... └── web ├── buildspec.yml # ビルド用 ├── ... └── ecspresso ├── buildspec.yml # デプロイ用 ├── buildspec_rollback.yml # ロールバック用 ├── ecspresso.yml ├── ecs-service-def.json └── ecs-task-def.json アプリケーションのリポジトリ version: 0.2 # 略 phases: build: commands: # 略 - ecspresso rollback

ロールバック用のCodeBuildの運用フェーズでの懸念 処理の詳細を知らない人間は、 ソースバージョンの指定に迷うかもしれない 本番環境ではmainブランチのバージョンのECSが動いていて、 それをロールバックしたいのに、 mainブランチを指定して実行して大丈夫なんだっけ？ 戻し先のバージョンのタグ等を指定する必要があるのでは？

buildspecをファイルではなくコマンドにする ソースバージョンを指定するフォームが 非表示となり、CodeBuild実行に際し迷う要素は無くなる ソースバージョンの指定フォームは非表示

5. まとめ

まとめ 1. CodeBuildでもecspressoはもちろん動かせる ○ GitHub Actionsのkayac/ecspressoアクションも利用可能 2. 関連AWSリソースのARN・ID取得に、ビルドプロジェクトの環境変数 を使うという選択肢もあり 3. ecspresso rollbackを行う場合は、buildspecはファイルではなくコマンドを推したい

ご清聴ありがとうございました！ Startup comes first! Join our team! jobs.smartround.com