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

AWS CDK でシステムをデプロイできるようになったら、次にやりたいのは各環境へのデプロイ処理の自動化です。

今回は GitHub Actions を使って AWS CDK の CI/CD パイプラインを構築する際のポイント（CI および　CD の実行タイミング、権限の最小化、環境変数の設定など）についてお話します。

こちらのイベントで登壇した際の資料です。
https://classmethod.connpass.com/event/286676/

1. AWS CDK on CI/CD パイプライン CX 事業本部 Delivery 部 若槻龍太 1 2023/06/27
2. 2 自己紹介 • 若槻龍太 • 2019年11月入社（4年目） • やっていること ◦ サーバーサイド開発（メイン） ◦ フロントエンド開発 ◦ モバイル開発 ◦ 各種タスクフォース参加 • 好きなAWSサービス AWS IoT TwinMaker AWS Step Functions AWS CDK
3. 3 しゃべる内容 AWS CDK : GitHub Actions 2 : 8 くらい
4. 4 AWS CDK によるデプロイ処理を 自動化したい
5. 5 CI / CD パイプラインを構築しよう
6. 6 CI / CD って？ CI（継続的インテグレーション） • ビルド、リント、ユニットテストなど CD（継続的デプロイ） • デプロイ、E2Eテストなど ソフトウェア開発に伴う定型的な作業を自動化 し、迅速に価値を届け続ける仕組み
7. 7 CI/CD ツールはいろいろある • AWS Code シリーズ • CircleCI • GitHub Actions • GitLab CI/CD • Travis CI
8. 8 CI/CD ツールはいろいろある • AWS Code シリーズ • CircleCI • GitHub Actions • GitLab CI/CD • Travis CI ⇐ 今回はこれ
9. 9 GitHub Actions とは • GitHub の CI/CD ツール • GitHub とのシームレスな連携 • 豊富な機能のほとんどを Free で利用可能
10. 10 AWS CDK × GitHub Actions での CI/CD パイプライン 構築について 話していきます
11. 11 AWS CDK × GitHub Actions どちらもとても奥が深いツールなので しゃべるポイントをしぼります
12. 12 今回しゃべるポイント 1. OIDC によるセキュリティの向上 2. キャッシュによる実行時間とコストの削減 3. Reusable Workflow によるワークフローの可読 性やメンテナンス性の確保 4. Environments による環境ごとのデプロイメント の容易な管理
13. 13 1. OIDC によるセキュリティの向上
14. 14 1.OIDC GitHub Actions から CDK デプロイを行う際には、 AWS への接続が必要 https://dev.classmethod.jp/articles/cdk-github-actions/ より引用 CDK デプロイで AWS へ接続
15. 15 ただし、 永続的な認証情報である アクセスキーは出来れば使いたくない...
16. 16 1.OIDC アクセスキー流出による様々なリスク • 多額の利用費請求 • 情報漏洩 • 脅迫 • 攻撃の加害者
17. 17 1.OIDC アクセスキー流出は様々な経路から起こり得る • システムのバグ • ソースコードへコミットしてしまい漏洩 • キーを格納した外部サービスから漏洩 ユーザーが気を付けようが無い場合も。
18. 18 アクセスキーの利用は できるだけ避けるべき
19. 19 1.OIDC 解決方法： GitHub Actions と AWS の間で OIDC 信頼を構成しよう！
20. OIDC（Open ID Connet）の使い方 • IAM ロール側で、AWS と GitHub Actions Workflow 間の OIDC 信頼をあらかじめ構成 • GitHub Actions 側に保管するのは IAM ロール のみ • AssumeRoleWithWebIdentity により取得した一 時クレデンシャルを Workflow から AWS への 接続に使用する 20 1.OIDC
21. OIDC（Open ID Connet）の使い方 • IAM ロール側で、AWS と GitHub Actions Workflow 間の OIDC 信頼をあらかじめ構成 • GitHub Actions 側に保管するのは IAM ロール のみ • AssumeRoleWithWebIdentity により取得した一 時クレデンシャルを Workflow から AWS への 接続に使用する 21 1.OIDC 信頼を設定する GitHub アカウント やリポジトリをきめ細かく制御できる （必要最低限の信頼を構成可能）
22. OIDC（Open ID Connet）の使い方 • AWS と GitHub Actions Workflow 間であらかじ め OIDC 信頼を構成 • GitHub Actions 側に保管するのは IAM ロール のみ • AssumeRoleWithWebIdentity により取得した一 時クレデンシャルを Workflow から AWS への 接続に使用する 22 1.OIDC アクセスキーの発行は不要
23. OIDC（Open ID Connet）の使い方 • AWS と GitHub Actions Workflow 間であらかじ め OIDC 信頼を構成 • GitHub Actions 側に保管するのは IAM ロール のみ • AssumeRoleWithWebIdentity により取得した一 時クレデンシャルを Workflow から AWS への 接続に使用する 23 1.OIDC 公式アクションを使って、ジョブ実行 内でのみ有効な短期間のクレデン シャルを取得可能
24. 24 1.OIDC OIDC 連携の図解 https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-secu rity-hardening-with-openid-connect
25. 参考 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 公式ドキュメント
26. 26 2. キャッシュによる実行時間とコストの 削減
27. 27 2. キャッシュ AWS Lambda のバンドルや AWS CDK コマンド実 行に必要な依存関係は、GitHub Actions の Workflow 内でインストールする
28. 28 依存関係のインストール を必要以上に行っていませんか？
29. 29 2. キャッシュ 問題 • 依存関係に変更が無いにも関わらずインス トールを行うのは、実行時間とコストの無駄。 • GitHub Actions の実行インスタンス（ランナー） は時間あたりの課金となる
30. 30 解決方法： 依存関係をキャッシュさせよう！ 2. キャッシュ
31. 31 2. キャッシュ • パスレベルのキャッシュ/セーブをよしなにして くれる便利なアクションが公式提供されている ロックファイルのハッ シュをキーにして依 存関係の生成物を キャッシュ キャッシュヒット時は 依存関係のインス トールをスキップ
32. 32 2. キャッシュ 参考 https://docs.github.com/en/actions/using-workflows/ caching-dependencies-to-speed-up-workflows 公式ドキュメント actions/cache@v3 https://github.com/actions/cache
33. 33 3. Reusable Workflow によるワークフローの 可読性やメンテナンス性の確保
34. 34 3. Reusable Workflow Workflow の yaml ファイル は長くなりがち 課題 • ジョブの記述が長くなると、可 読性が悪くなる • ジョブやワークフローで処理 を共通化したい 長くなった Workflow ファイル
35. 35 解決方法： Reusable Workflowを使おう！ 3. Reusable Workflow
36. 36 3. Reusable Workflow Reusable Workflow の使用 • Reusable Workflow （再使用可能なワークフ ロー）で処理の共通化と分離を行うことができ る ◦ 呼び出す側（caller workflow） ◦ 呼び出される側（called workflow） • 同じ called を異なるジョブ、Workflow、リポジト リから呼び出せる
37. 37 3. Reusable Workflow Reusable Workflow の使用 caller 側で 呼び出しを 宣言 called 側でト リガーを明示
38. 38 3. Reusable Workflow Reusable Workflow の使用 caller 側から called 側のジョブ が呼び出されてい る
39. 参考 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 公式ドキュメント
40. 40 4. Environments による環境ごとの デプロイメントの容易な管理
41. 41 単一の GitHub Actions Workflow から複数の環境 （development、staging、production など）にデプ ロイを行いたい 4. Environments https://dev.classmethod.jp/articles/github-actions-workflow-for-each-branch-into-one/ より引用
42. 42 複数環境へのデプロイを行う上での問題 • デプロイメントの管理が複雑化してしまう ◦ 変数やシークレット ▪ デプロイ先ごとの IAM ロール管理など ◦ デプロイ先ごとに処理を変える ▪ production へのデプロイ時は E2E テスト をスキップなど ◦ デプロイ履歴 4. Environments
43. 43 複数環境へのデプロイを行う上での問題 • デプロイメントの管理が複雑化してしまう ◦ 変数やシークレット ◦ デプロイ先ごとに処理を変える ◦ デプロイ履歴 4. Environments
44. 44 複数環境へのデプロイを行う上での問題 • デプロイメントの管理が複雑化してしまう ◦ 変数やシークレット ◦ デプロイ先ごとに処理を変える ◦ デプロイ履歴 4. Environments 環境ごとに変数名 にプレフィクスを付 ける涙ぐましさ
45. 45 複数環境へのデプロイを行う上での問題 • デプロイメントの管理が複雑化してしまう ◦ 変数やシークレット ◦ デプロイ先ごとに処理を変える ◦ デプロイ履歴 4. Environments production へのデプロイ時は E2E テストをスキップ等。 ステップごとに if 分岐を設ける などして、記述が複雑になりが ち
46. 46 複数環境へのデプロイを行う上での問題 • デプロイメントの管理が複雑化してしまう ◦ 変数やシークレット ◦ デプロイ先ごとに処理を変える ◦ デプロイ履歴 4. Environments “各環境への CDK デプロイを 含む” 様々な Workflow 実行 が履歴に出てきて、ログを追い にくい
47. 47 解決方法： Environmentsを使おう！ 4. Environments
48. 48 GitHub Actions の Environments を使用して、環 境ごとにデプロイメントを分離する • ブランチ保護の設定 ◦ デプロイメントブランチ ◦ 人間によるレビュー • 環境変数、環境シークレットの設定 • デプロイメント履歴 4. Environments
49. 49 GitHub Actions の Environments を使用して、環 境ごとにデプロイメントを分離する • ブランチ保護の設定 ◦ デプロイメントブランチ ◦ 人間によるレビュー • 環境変数、環境シークレットの設定 • デプロイメント履歴 4. Environments 環境(Environment) ごとにブランチを対応 づけられる
50. 50 GitHub Actions の Environments を使用して、環 境ごとにデプロイメントを分離する • ブランチ保護の設定 ◦ デプロイメントブランチ ◦ 人間によるレビュー • 環境変数、環境シークレットの設定 • デプロイメント履歴 4. Environments Workflow の進行に、人 間によるレビューを組み 込める（※条件あり）
51. 51 GitHub Actions の Environments を使用して、環 境ごとにデプロイメントを分離する • ブランチ保護の設定 ◦ デプロイメントブランチ ◦ 人間によるレビュー • 環境変数、環境シークレットの設定 • デプロイメント履歴 4. Environments 環境ごとに変数、シーク レットの設定領域があ る。環境間で重複可 能！
52. 52 GitHub Actions の Environments を使用して、環 境ごとにデプロイメントを分離する • ブランチ保護の設定 ◦ デプロイメントブランチ ◦ 人間によるレビュー • 環境変数、環境シークレットの設定 • デプロイメント履歴 4. Environments 環境ごとに”デプロイメン ト”の実行履歴や最終ス テータスを確認できる
53. 53 理想と現実
54. 54 理想と現実 • 「人間によるレビュー」機能が使えるのは GitHub Enterprise プランのみ • GitHub Pro / Team プランを使用した開発も多 いはず • その場合は、”Pull Request のレビュー"で代用 することができます 4. Environments
55. 55 理想（GitHub Enterprise） 人間によるレビューを使 用した場合の、 Workflow 実行履歴 4. Environments
56. 56 現実（GitHub Pro / Team） 4. Environments Pull Request のレ ビュー"で代用した場合 の、Workflow 実行履 歴。
57. 参考 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 公式ドキュメント
58. 58 最後に...
59. 59 DevelopersIO 2023 (東京 2日目) 登壇します！ 宣伝
60. 60 ありがとうございました