Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
CodeBuildで動かすecspresso
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
shonansurvivors
August 08, 2023
Technology
5.1k
2
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
CodeBuildで動かすecspresso
JAWS-UG コンテナ支部 #24 ecspresso MeetUp
登壇資料
shonansurvivors
August 08, 2023
More Decks by shonansurvivors
See All by shonansurvivors
SREのキャリアから経営に近づく - Enterprise Risk Managementを基に -
shonansurvivors
2
1.5k
Adminaで実現するISMS/SOC2運用の効率化 〜 アカウント管理編 〜
shonansurvivors
4
690
SOC2取得の全体像
shonansurvivors
4
2.9k
非エンジニアによるDevin開発のためにSREができること
shonansurvivors
0
260
SREによる隣接領域への越境とその先の信頼性
shonansurvivors
2
1k
スタートアップがAWSパートナーになって得られたこと
shonansurvivors
3
1.3k
AWSで構築するCDパイプラインとその改善
shonansurvivors
5
4.2k
Terraformでmoduleを使わずに複数環境を構築して感じた利点
shonansurvivors
3
4.2k
クロステナントアクセスを要件とするsmartroundのマルチテナントSaaSアーキテクチャ
shonansurvivors
0
610
Other Decks in Technology
See All in Technology
アラート調査向けAIエージェントの本番導入とその後/AI Agents for Alert Investigation: Production Deployment and After
taddy_919
0
140
AIのReact習熟度を測る
uhyo
2
680
When Platform Engineering Meets GenAI
sucitw
0
170
AI-DLCを “そのまま導入しなかった”話 ~組織に合わせてアジャストした 私たちの実践共有~
hiroramos4
PRO
1
430
From Prompt Engineering to Loop Engineering
shibuiwilliam
1
220
AIネイティブな開発のサプライチェーンリスク対策 〜激動の開発現場でリスクに立ち向かう〜【ZennFes】
cscengineer
PRO
2
160
MySQL & MySQL HeatWave Report - June 2026
freshdaz
0
120
起点・思考・出力で分解する 〜PM業務の自動化設計〜
kazu_kichi_67
1
1.1k
AIチャットの改善から見えた、良いAI体験とは / What Constitutes a Good AI Experience: Insights from Improving AI Chat
kubode
0
120
データレイクの「見えない問題」を可視化する
sansantech
PRO
1
200
AIに障害切り分けを全部やってもらった。 。 。 。
estie
0
150
スタートアップにAmazon EKSは早すぎる? マルチプロダクト戦略を加速する Platform Engineeringの実践 / Is Amazon EKS Too Soon for Startups? Practical Platform Engineering to Accelerate a Multi-Product Strategy
elmodev09
1
1.8k
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
3.5k
Claude Code のすすめ
schroneko
67
230k
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
160
Accessibility Awareness
sabderemane
1
140
Raft: Consensus for Rubyists
vanstee
141
7.6k
Winning Ecommerce Organic Search in an AI Era - #searchnstuff2025
aleyda
1
2.1k
Darren the Foodie - Storyboard
khoart
PRO
3
3.4k
A designer walks into a library…
pauljervisheath
211
24k
Building Adaptive Systems
keathley
44
3.1k
Agile that works and the tools we love
rasmusluckow
331
22k
The SEO identity crisis: Don't let AI make you average
varn
0
500
How to make the Groovebox
asonas
2
2.2k
Transcript
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