AWS CDK on CI/CD パイプライン

by CM若槻龍太

Slide 1

Slide 1 text

AWS CDK on CI/CD パイプライン CX 事業本部 Delivery 部若槻龍太 1 2023/06/27

Slide 2

Slide 2 text

2 自己紹介 ● 若槻龍太 ● 2019年11月入社（4年目） ● やっていること ○ サーバーサイド開発（メイン） ○ フロントエンド開発 ○ モバイル開発 ○ 各種タスクフォース参加 ● 好きなAWSサービス AWS IoT TwinMaker AWS Step Functions AWS CDK

Slide 3

Slide 3 text

3 しゃべる内容 AWS CDK : GitHub Actions 2 : 8 くらい

Slide 4

Slide 4 text

4 AWS CDK によるデプロイ処理を自動化したい

Slide 5

Slide 5 text

5 CI / CD パイプラインを構築しよう

Slide 6

Slide 6 text

6 CI / CD って？ CI（継続的インテグレーション） ● ビルド、リント、ユニットテストなど CD（継続的デプロイ） ● デプロイ、E2Eテストなどソフトウェア開発に伴う定型的な作業を自動化し、迅速に価値を届け続ける仕組み

Slide 7

Slide 7 text

7 CI/CD ツールはいろいろある ● AWS Code シリーズ ● CircleCI ● GitHub Actions ● GitLab CI/CD ● Travis CI

Slide 8

Slide 8 text

8 CI/CD ツールはいろいろある ● AWS Code シリーズ ● CircleCI ● GitHub Actions ● GitLab CI/CD ● Travis CI ⇐ 今回はこれ

Slide 9

Slide 9 text

9 GitHub Actions とは ● GitHub の CI/CD ツール ● GitHub とのシームレスな連携 ● 豊富な機能のほとんどを Free で利用可能

Slide 10

Slide 10 text

10 AWS CDK × GitHub Actions での CI/CD パイプライン構築について話していきます

Slide 11

Slide 11 text

11 AWS CDK × GitHub Actions どちらもとても奥が深いツールなのでしゃべるポイントをしぼります

Slide 12

Slide 12 text

12 今回しゃべるポイント 1. OIDC によるセキュリティの向上 2. キャッシュによる実行時間とコストの削減 3. Reusable Workflow によるワークフローの可読性やメンテナンス性の確保 4. Environments による環境ごとのデプロイメントの容易な管理

Slide 13

Slide 13 text

13 1. OIDC によるセキュリティの向上

Slide 14

Slide 14 text

14 1.OIDC GitHub Actions から CDK デプロイを行う際には、 AWS への接続が必要 https://dev.classmethod.jp/articles/cdk-github-actions/ より引用 CDK デプロイで AWS へ接続

Slide 15

Slide 15 text

15 ただし、永続的な認証情報であるアクセスキーは出来れば使いたくない...

Slide 16

Slide 16 text

16 1.OIDC アクセスキー流出による様々なリスク ● 多額の利用費請求 ● 情報漏洩 ● 脅迫 ● 攻撃の加害者

Slide 17

Slide 17 text

17 1.OIDC アクセスキー流出は様々な経路から起こり得る ● システムのバグ ● ソースコードへコミットしてしまい漏洩 ● キーを格納した外部サービスから漏洩ユーザーが気を付けようが無い場合も。

Slide 18

Slide 18 text

18 アクセスキーの利用はできるだけ避けるべき

Slide 19

Slide 19 text

19 1.OIDC 解決方法： GitHub Actions と AWS の間で OIDC 信頼を構成しよう！

Slide 20

Slide 20 text

OIDC（Open ID Connet）の使い方 ● IAM ロール側で、AWS と GitHub Actions Workflow 間の OIDC 信頼をあらかじめ構成 ● GitHub Actions 側に保管するのは IAM ロールのみ ● AssumeRoleWithWebIdentity により取得した一時クレデンシャルを Workflow から AWS への接続に使用する 20 1.OIDC

Slide 21

Slide 21 text

Slide 22

Slide 22 text

OIDC（Open ID Connet）の使い方 ● AWS と GitHub Actions Workflow 間であらかじめ OIDC 信頼を構成 ● GitHub Actions 側に保管するのは IAM ロールのみ ● AssumeRoleWithWebIdentity により取得した一時クレデンシャルを Workflow から AWS への接続に使用する 22 1.OIDC アクセスキーの発行は不要

Slide 23

Slide 23 text

Slide 24

Slide 24 text

24 1.OIDC OIDC 連携の図解 https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-secu rity-hardening-with-openid-connect

Slide 25

Slide 25 text

参考 25 1.OIDC https://dev.classmethod.jp/articles/use-aws-cdk-to-create-permission-r esources-when-pr-merge-is-an-action-trigger-using-the-oidc-connectio n-between-aws-and-github-actions/ DevelopersIO ブログ https://docs.github.com/en/actions/deployment/security-hardening- your-deployments/configuring-openid-connect-in-amazon-web-ser vices 公式ドキュメント

Slide 26

Slide 26 text

26 2. キャッシュによる実行時間とコストの削減

Slide 27

Slide 27 text

27 2. キャッシュ AWS Lambda のバンドルや AWS CDK コマンド実行に必要な依存関係は、GitHub Actions の Workflow 内でインストールする

Slide 28

Slide 28 text

28 依存関係のインストールを必要以上に行っていませんか？

Slide 29

Slide 29 text

29 2. キャッシュ問題 ● 依存関係に変更が無いにも関わらずインストールを行うのは、実行時間とコストの無駄。 ● GitHub Actions の実行インスタンス（ランナー）は時間あたりの課金となる

Slide 30

Slide 30 text

30 解決方法：依存関係をキャッシュさせよう！ 2. キャッシュ

Slide 31

Slide 31 text

31 2. キャッシュ ● パスレベルのキャッシュ/セーブをよしなにしてくれる便利なアクションが公式提供されているロックファイルのハッシュをキーにして依存関係の生成物をキャッシュキャッシュヒット時は依存関係のインストールをスキップ

Slide 32

Slide 32 text

32 2. キャッシュ参考 https://docs.github.com/en/actions/using-workflows/ caching-dependencies-to-speed-up-workflows 公式ドキュメント actions/cache@v3 https://github.com/actions/cache

Slide 33

Slide 33 text

33 3. Reusable Workflow によるワークフローの可読性やメンテナンス性の確保

Slide 34

Slide 34 text

34 3. Reusable Workflow Workflow の yaml ファイルは長くなりがち課題 ● ジョブの記述が長くなると、可読性が悪くなる ● ジョブやワークフローで処理を共通化したい長くなった Workflow ファイル

Slide 35

Slide 35 text

35 解決方法： Reusable Workflowを使おう！ 3. Reusable Workflow

Slide 36

Slide 36 text

36 3. Reusable Workflow Reusable Workflow の使用 ● Reusable Workflow （再使用可能なワークフロー）で処理の共通化と分離を行うことができる ○ 呼び出す側（caller workflow） ○ 呼び出される側（called workflow） ● 同じ called を異なるジョブ、Workflow、リポジトリから呼び出せる

Slide 37

Slide 37 text

37 3. Reusable Workflow Reusable Workflow の使用 caller 側で呼び出しを宣言 called 側でトリガーを明示

Slide 38

Slide 38 text

38 3. Reusable Workflow Reusable Workflow の使用 caller 側から called 側のジョブが呼び出されている

Slide 39

Slide 39 text

参考 39 3. Reusable Workflow https://dev.classmethod.jp/articles/create-a-workflow-with-github-actio ns-that-executes-ci-only-at-the-time-of-push-and-ci-and-cd-when-merg ing/ DevelopersIO ブログ https://docs.github.com/en/actions/using-workflows/reusing-workfl ows 公式ドキュメント

Slide 40

Slide 40 text

40 4. Environments による環境ごとのデプロイメントの容易な管理

Slide 41

Slide 41 text

41 単一の GitHub Actions Workflow から複数の環境（development、staging、production など）にデプロイを行いたい 4. Environments https://dev.classmethod.jp/articles/github-actions-workflow-for-each-branch-into-one/ より引用

Slide 42

Slide 42 text

42 複数環境へのデプロイを行う上での問題 ● デプロイメントの管理が複雑化してしまう ○ 変数やシークレット ■ デプロイ先ごとの IAM ロール管理など ○ デプロイ先ごとに処理を変える ■ production へのデプロイ時は E2E テストをスキップなど ○ デプロイ履歴 4. Environments

Slide 43

Slide 43 text

43 複数環境へのデプロイを行う上での問題 ● デプロイメントの管理が複雑化してしまう ○ 変数やシークレット ○ デプロイ先ごとに処理を変える ○ デプロイ履歴 4. Environments

Slide 44

Slide 44 text

44 複数環境へのデプロイを行う上での問題 ● デプロイメントの管理が複雑化してしまう ○ 変数やシークレット ○ デプロイ先ごとに処理を変える ○ デプロイ履歴 4. Environments 環境ごとに変数名にプレフィクスを付ける涙ぐましさ

Slide 45

Slide 45 text

45 複数環境へのデプロイを行う上での問題 ● デプロイメントの管理が複雑化してしまう ○ 変数やシークレット ○ デプロイ先ごとに処理を変える ○ デプロイ履歴 4. Environments production へのデプロイ時は E2E テストをスキップ等。ステップごとに if 分岐を設けるなどして、記述が複雑になりがち

Slide 46

Slide 46 text

46 複数環境へのデプロイを行う上での問題 ● デプロイメントの管理が複雑化してしまう ○ 変数やシークレット ○ デプロイ先ごとに処理を変える ○ デプロイ履歴 4. Environments “各環境への CDK デプロイを含む” 様々な Workflow 実行が履歴に出てきて、ログを追いにくい

Slide 47

Slide 47 text

47 解決方法： Environmentsを使おう！ 4. Environments

Slide 48

Slide 48 text

48 GitHub Actions の Environments を使用して、環境ごとにデプロイメントを分離する ● ブランチ保護の設定 ○ デプロイメントブランチ ○ 人間によるレビュー ● 環境変数、環境シークレットの設定 ● デプロイメント履歴 4. Environments

Slide 49

Slide 49 text

49 GitHub Actions の Environments を使用して、環境ごとにデプロイメントを分離する ● ブランチ保護の設定 ○ デプロイメントブランチ ○ 人間によるレビュー ● 環境変数、環境シークレットの設定 ● デプロイメント履歴 4. Environments 環境(Environment) ごとにブランチを対応づけられる

Slide 50

Slide 50 text

50 GitHub Actions の Environments を使用して、環境ごとにデプロイメントを分離する ● ブランチ保護の設定 ○ デプロイメントブランチ ○ 人間によるレビュー ● 環境変数、環境シークレットの設定 ● デプロイメント履歴 4. Environments Workflow の進行に、人間によるレビューを組み込める（※条件あり）

Slide 51

Slide 51 text

51 GitHub Actions の Environments を使用して、環境ごとにデプロイメントを分離する ● ブランチ保護の設定 ○ デプロイメントブランチ ○ 人間によるレビュー ● 環境変数、環境シークレットの設定 ● デプロイメント履歴 4. Environments 環境ごとに変数、シークレットの設定領域がある。環境間で重複可能！

Slide 52

Slide 52 text

52 GitHub Actions の Environments を使用して、環境ごとにデプロイメントを分離する ● ブランチ保護の設定 ○ デプロイメントブランチ ○ 人間によるレビュー ● 環境変数、環境シークレットの設定 ● デプロイメント履歴 4. Environments 環境ごとに”デプロイメント”の実行履歴や最終ステータスを確認できる

Slide 53

Slide 53 text

53 理想と現実

Slide 54

Slide 54 text

54 理想と現実 ● 「人間によるレビュー」機能が使えるのは GitHub Enterprise プランのみ ● GitHub Pro / Team プランを使用した開発も多いはず ● その場合は、”Pull Request のレビュー"で代用することができます 4. Environments

Slide 55

Slide 55 text

55 理想（GitHub Enterprise）人間によるレビューを使用した場合の、 Workflow 実行履歴 4. Environments

Slide 56

Slide 56 text

56 現実（GitHub Pro / Team） 4. Environments Pull Request のレビュー"で代用した場合の、Workflow 実行履歴。

Slide 57

Slide 57 text

参考 57 4. Environments https://dev.classmethod.jp/articles/github-actions-environment-secrets -and-environment-variables/ DevelopersIO ブログ https://docs.github.com/en/actions/deployment/targeting-different- environments/using-environments-for-deployment 公式ドキュメント