GitHub Actionsを用いたCDK for Terraformのデプロイ

はじめに

この記事では、CDK for Terraformのザックリとした概要説明と、GitHub Actionsを利用したデプロイを紹介します。
開発段階で情報が少なく、環境構築にも苦労し様々なノウハウを蓄積しましたので、CDKTFについて複数回に分けて本ブログで発信していきます！

CDK for Terraform とは

CDK for Terraform(CDKTF)は、ざっくりいうとCDKの裏側で動かすのをCloudFormationではなくTerraformにしたものです。
CDKとTerraformの良いところを組み合わせたツールとなります。

イメージ図※引用元
以下特徴があります。

• 利用可能な言語：TypeScript、 Python、 Java、 C#、Goなど、複数の言語に対応
• マルチクラウドに対応している
• コミュニティ（Terraform Registry）が発達しており、モジュールなどを用いたアジリティのある構築が可能である
• 「2025年1月時点でのメジャーバージョンが0であり、開発段階である

他IaC(CDKとTerraform)との比較

-	CDK	Terraform	CDKTF
ベンダー制約	×	〇	〇
学習コスト	〇	×	〇
サポート体制	〇	△	△
コミュニティの発達	〇	◎	◎

GitHub Actionsを用いたデプロイ

CDKTFを用いて手動でハンズオン形式のデプロイを紹介している記事が多いため、今回はGitHub Actionsで何らかのクラウドサービスへデプロイする方法を紹介します。
まず、GitHub Actionsを利用する理由は以下の通りです。

1. メンバー個々の環境からデプロイする場合、バージョンの不一致などの環境差分が生じる
2. デプロイ時に人為的なミス（デプロイ先の環境誤り、ブランチの間違い）が生じる
3. 環境変更が可能な権限をGitHub Actionsへ集約することができる

また、デプロイ環境を【AWS CodeDeploy】や【Google Cloud Deploy】などの特定クラウドベンダー製品ではなく、GitHub Actionsにすることでマルチクラウドへ対応を行いやすくする狙いもありました。

構成図

構成図はこちらです。

フローとして、特定ブランチにpushやmergeが発生した際に、GitHub Actionsにより対象のクラウドベンダーへdiffやdeployが行われます。
（詳細なフローはまた別の機会に紹介します）

工夫した点

CDKTFのカスタムイメージを作成しています。
GitHub ActionsでCDKTFをデプロイするためイメージはterraform-cdk-actionがHashiCorp社より提供されていますが、後述する課題①,②がありました。

以降の説明で実際のディレクトリ構成がある方が理解しやすいと思うため、今回のディレクトリ構成を紹介します

├── .github/
│       └── workflows
│              └── <ワークフロー>
├── environment
│       └── <環境1>
│              ├── resources
│              │      └── <スタック識別子A>
│              │              └── <スタックA>
│              │      └── <スタック識別子B>
│              │              └── <スタックB>
│              ├── main
│              └── cdktf.json
│       └── <環境2>
│              ├── resources
│              │      └── <スタック識別子A>
│              │              └── <スタックA>
│              │      └── <スタック識別子B>
│              │              └── <スタックB>
│              ├── main
│              └── cdktf.json

課題①：複数スタックの同時デプロイ

Terraformもですが、CDKTFではスタックという単位でインフラリソースを定義していきます。
スタックの分割方法は環境ごと、アプリケーションの機能、AWSサービスなどにより分割していきます。
基本的には単一スタックで管理するケースは少なく、複数スタックで管理されるかと思います。
私達でも、環境間、及び機能単位でスタックを複数個作成していました。（ディレクトリ構成にあるスタックAやスタックBのことです）
デプロイする際も複数スタックに対応（マルチスタックでのデプロイ）する必要があります。
GitHub ActionsでCDKTFをデプロイするためのツールは前述の通り、terraform-cdk-actionが提供されていますが、注意書きからシングルスタックのデプロイのみ対応しているような記述がありました。

This action is intended to be limited to a single stack. While you could pass * as >the stack name and use multi-stack deployments, we don't currently support all the >complexities of doing accurate plans across multiple dependent workspaces within >the action.

これは面倒です。例えば、複数スタックに跨って修正が必要なケースでも、マルチスタックのデプロイに対応していない場合、スタックごとでの修正を行い、作業数（mergeやプルリクエスト）の回数が多くなります。

そのため、マルチスタックでデプロイ可能となるようなイメージ、及びワークフローの作成をしました。

課題②：複数環境へのデプロイ

ディレクトリ構成にある環境はアカウント（もしくはクラウドサービス）レベルで異なります。
AWSの場合を例としてあげると、IaCで変更が生じた環境（ディレクトリ）に対応するAWSアカウントにデプロイを行うようにロールを変更する必要があります。

このような方式は前述のterraform-cdk-actionで実現することは難しかったです。
そのため、複数環境でデプロイ可能となるようなイメージ、及びワークフローの作成をしました。

感想

CDKTFとGitHub Actionsを組み合わせることで、よりマルチクラウドへの対応がしやすくなります。
個人的には最も苦労した複数人で開発する際のデプロイ環境の差分によるデプロイエラーがなくなる点のメリットが大きいと思います。
また、元々CDKTFの利点である汎用的なプログラミング言語を利用できたため、イニシャルコストはHCLを利用するTerraformよりも確かに低かったと思います。
今回こちらで紹介した内容は、設計時の観点に限られた表面的な部分となります。
いつかデプロイ時の詳細なフローや、CDKTFならではのコード規約等を紹介したいと思います。