Lambda の CI/CD についての考察

[suzuki-shunsuke]

実現したいこと

• アプリケーションの開発に専念できる。 CI/CD の pipeline を Function ごとに実装しなくて済む
  • 複数のリポジトリで色々設定が必要とかだと面倒になってくる
• 本番以外の検証環境を構築できる
  • PR 環境: PR ごとにデプロイされる
  • main: 最新のデフォルトブランチのアプリケーションのコード
  • edge 環境: 本番とアプリケーションのコードは同じ
• アプリケーションのコードを全環境・ AWS アカウントで共通化出来る
  • 環境の違いは環境変数などによって吸収する
• 余計な CI が走らない
  • 変更された Function に対してだけテストやデプロイが実行される
  • Lambda の設定が変更されただけでは、アプリケーションのテストはスキップする
• 安全にリリースされる
  • Canary Release (Blue/Green)
    • CodeDeploy は Blue/Green をサポート
    • Lambda も alias の重み付けをサポート
  • DarkLaunch
    • AppConfig を使うと良いかも
  • リリース直後に問題があったときにすぐに rollback できる
  • HotFix をすぐにリリースできる
    • アプリケーションの build や test に時間がかかる分はどうしようもない
• セキュリティ
  • 悪意のある人が CI/CD のコードを修正して強力な権限で任意コードの実行をするのを防ぎたい
    • CI/CD の分離
    • PR event と push event で IAM Role 分ける
  • Function ごとや環境ごとに IAM Role を分けることで権限を最小化する。 Function A に関する CI/CD では他の Function への権限を持たなくする
    • これは simple, easy とのトレードオフだったりする

PR 環境の必要性

• Lambda Function だけデプロイされて意味があるのか
  • 依存するリソースもデプロイされないと意味ないのでは
  • 当然 Function による
  • lambroll は Lambda に特化したツールなので、 CloudFormation や SAM などが必要になってくる
  • CloudFormation 好きになれない。失敗したときに面倒くさい

[suzuki-shunsuke]

Tools

• lambroll
• Terraform
• AWS SAM
• CloudFormation
• AWS CDK

---

• CodeBuild
• CodeDeploy
• CodePipeline
• GitHub Actions (OIDC)

---

• PipeCD
• AWS Controllers for Kubernetes (ACK)
  • Lambda はまだサポートされてないらしい: Lambda service controller aws-controllers-k8s/community#238