はじめに
弱く春風が包むので初投稿です。
株式会社カナリーでは現在「Canary」というお部屋探しのアプリを作っています。
我々はTerraformのplan/apply自動化を目的としてtfactionを利用しています。
tfactionはGitHub Actionsを通して、Terraform plan/applyなどのワークフローの構築を簡単にしてくれるフレームワークです。
個々人がplan/apply用のcredentialを持たなくてよくなる、plan結果を自動でGitHub上にコメントしてくれるなど、tfactionのおかげで運用負荷を一定下げることができています。
他方、従来Git管理しつつ手動で運用していたところに導入したため、その名残でいくつか不恰好なまま運用してしまっている部分があります。
今回はtfaction v1.3.0のリリースでその1つを解消できたので、その知見を共有できればと思います。
この記事では包括的なtfactionの説明は省いているため、わからない概念があればドキュメントを参照してください。
前提
弊社では大まかに環境別のディレクトリとそれらが参照する共用のディレクトリを用意しています。
以下のようなイメージです。
terraform_dir
├── dev
├── prod
└── shared # 共用ディレクトリ
共用ディレクトリに各リソースの大体の定義を置きつつ、そこに差し込む変数を環境別ディレクトリで宣言するような形です。
これによりDRYの原則を実現しつつ、環境別の差分も吸収できるようにしています。
課題
ただしこのような構成をtfactionで管理しようとすると、少し不都合が生じます。
tfactionでは、plan/applyの対象とするファイルパスを"working directory"と呼んで管理しています。
working directoryとして登録されたパス以下で変更が生じた場合に、関連するactionをtriggerしてplanやapplyを実行する、といった寸法です。
上記の構成だと環境別ディレクトリをworking directoryとして登録することになりますが、これでは共用ディレクトリに差分を作ってもそれぞれの環境別ディレクトリでplan/applyをtriggerさせることができません。
v1.3.0以前では共用ディレクトリの差分を手ずから検知し、無理やりtfactionに渡すことで何とかしていました。
具体的には下記のようなstepを挟んでいたのですが、これでは差分検出から対象となるworking directoryの指定までこちらでやる必要があります。
弊社では似たようなディレクトリ構造を複数のチームで持っており、それぞれのチームごとにこの差分検出部分を書いていくと、このhackyな手法ではワークフローが煩雑になっていくことが必至でした。
# 以下のようなstepが必要
- uses: dorny/paths-filter@de90cc6fb38fc0963ad72b210f1f284cd68cea36 # v3.0.2
id: changes
with:
# ここで見つけた差分から `TFACTION_TARGET` を設定する
filters: |
shared:
- 'terraform/shared/**'
tfaction v1.3.0での解決策
tfaction v1.3.0ではこの課題を解決してくれる機能が導入されています（リリースノート）。
working directoryの依存関係にあるlocal Terraform moduleが更新されるとplan/applyをtriggerしてくれる機能です。
機能の詳細については公式ドキュメントを確認してください。
たとえば、以下のような宣言を環境別ディレクトリ内で行なっている場合、tfactionがsharedの差分があるかを確認し、存在する場合はplan/applyをtriggerしてくれるようになります：
module "foo" {
source = "../shared/foo"
}
この機能は tfaction-root.yaml 内で以下の記述を入れることで有効化できます：
update_local_path_module_caller:
enabled: true
差分の検知にはterraform-config-inspectと呼ばれるツールを用いているようで、こちらのインストールも必要です。
試しに弊社のディレクトリ上でこのCLIツールを実行してみましたが、"Child Modules"としてうまく共用ディレクトリへの参照を見つけてくれました。すばら。
この機能を有効化することで前述の差分検出部分をワークフローから削除でき、結果としてほとんどtfactionに乗っかるだけのワークフローに収められるようになりました。
まとめ
今回紹介した機能を有効化したことで、弊社では自前のworkaroundを持つことなく、また既存のディレクトリ構成を変えることもなくtfactionを利用できるようになりました。
この手の自動化はセキュアさと利便性のトレードオフが気になるところですが、tfactionではGitHub Appなどを用いることでエフェメラルなトークンで諸々を処理できます。小町的にポイント高いです。
ただし、drift detection機能を用いたトリアージ方針など、まだまだtfactionを十全に使えている状態ではないので、引き続きtfactionと弊社のベストな関係性を模索していきたいところです。
Discussion