Terraformの深淵：社内独自APIを「ファーストクラス市民」にするカスタムプロバイダー開発の極意
クラウドネイティブなインフラ管理において、Terraformは事実上の標準だ。しかし、多くの現場では「AWSやGCPはTerraformで管理しているが、社内のレガシーな管理画面や独自開発の内部APIは、手動または場当たり的なスクリプトで運用している」という歪な構造が放置されている。
この「IaCの空白地帯」を埋め、全インフラリソースを単一のステートで制御することこそ、真のSREが追求すべき境地だ。本稿では、Go言語を用いてTerraformカスタムプロバイダーをゼロから実装し、社内APIをTerraformの管理下に完全統合するための「生存戦略」を説く。
—
1. なぜ「スクリプト」ではなく「カスタムプロバイダー」なのか
多くのエンジニアは、とりあえず `shell` や `python` スクリプトでAPIを叩いてリソースを構築しようとする。だが、それは「冪等性の欠如」という地獄への入り口だ。
- 状態の不整合: スクリプトは「今どうなっているか」を記憶しない。
- 依存関係の崩壊: リソース間の参照関係（IDの受け渡し等）を、手動の変数管理や一時ファイルで解決するのは破綻を招く。
- Terraformの強み: `terraform plan` による事前検証、`refresh` によるドリフト検知、そして `destroy` 時のクリーンな削除。これらを独自APIに持ち込むには、Terraform SDKを用いたプロバイダー実装が不可欠なのだ。
—
2. 実装の解剖学：プロバイダーのスケルトンとCRUDの設計
現在、Terraformプロバイダーは `terraform-plugin-framework` を使用するのが定石だ。古い `sdk/v2` を使ってはならない。型安全性とメモリ効率が段違いである。
プロジェクトの骨格
まずは `terraform-plugin-framework` を導入し、リソースの定義を行う。
// internal/provider/resource_example.go
// リソースのスキーマ定義。ここでAPIのレスポンスとTerraformの属性をマッピングする
func (r exampleResource) Schema(ctx context.Context, req resource.SchemaRequest, resp resource.SchemaResponse) {
resp.Schema = schema.Schema{
Attributes: map[string]schema.Attribute{
“id”: schema.StringAttribute{Computed: true},
“name”: schema.StringAttribute{Required: true},
},
}
}
CRUD操作の極意
最も重要なのは `Create`, `Read`, `Update`, `Delete` (CRUD) の実装だ。ここで意識すべきは以下の点である。
1. Read（ドリフト検知）: `Read` メソッドは単なる情報の取得ではない。「現在の実環境とStateを同期させる」という責務を持つ。APIがダウンしている場合や、リソースが消滅している場合、適切に `resp.State.RemoveResource(ctx)` を呼び出すことで、Terraform側に削除を認識させる必要がある。
2. APIクライアントの共有: プロバイダーの `Configure` メソッドでAPIクライアントを初期化し、`resource.Metadata` を通じて各メソッドに伝播させる。グローバル変数はデバッグと並列実行の敵である。
—
3. 高度な連携とパフォーマンス・ハック
カスタムプロバイダーを本番環境で運用する場合、以下の「低レイヤの作法」を守らねばならない。
- コンテキスト管理の徹底: APIリクエストには必ず `context` を伝播させ、Terraformのキャンセル要求（Ctrl+C）に応答できるようにせよ。さもなくば、リソース構築中にプロセスを殺した際、ゾンビ状態のリソースがクラウド上に放置される。
- レートリミット対策: 社内APIはAWSほど堅牢ではないことが多い。プロバイダー内で `exponential backoff`（指数バックオフ）を実装し、APIの負荷を制御せよ。
- パフォーマンス最適化: `Read` メソッド内で必要以上にAPIを叩くな。不要なデータ取得を避けるため、フィールドの変更有無をチェックする `PlanModification` を適切に実装し、APIの呼び出し回数を最小化する。
—
4. ローカルテストからレジストリ共有まで
開発中のプロバイダーを動作させるには、`.terraformrc` (または `terraform.rc`) に開発用ディレクトリを登録するのが最短経路だ。
~/.terraformrc
provider_installation {
dev_overrides {
“registry.terraform.io/my-org/my-api” = “/path/to/your/provider/bin”
}
}
チームへの展開と自動化
プロバイダーが完成したら、必ず `GoReleaser` を使ったCIパイプラインを構築せよ。
1. GitHub Actionsによる自動ビルド: マルチプラットフォーム（Linux, Darwin, Windows）向けにバイナリを署名・圧縮してリリース。
2. Terraform Registryへの登録: 独自のリポジトリで公開することで、`terraform init` 時に自動的にバイナリをダウンロードさせることが可能になる。
—
最後に：職人としての矜持
カスタムプロバイダーを書くということは、単なるAPIのラッパーを作ることではない。「社内の独自リソースを、Terraformという巨大なエコシステムの一員として再定義する」という設計行為だ。
コードを書き終えた後、あなたが作成したリソースが `terraform plan` によって美しく可視化され、`apply` によって一瞬で構築される瞬間、そのAPIは「管理不能なレガシー」から「IaCの恩恵を受けるモダンなインフラ」へと進化を遂げる。
技術の細部にまでこだわり抜き、運用負荷を限界まで削ぎ落とす。それこそが、我々SREが果たすべき、コードに対する誠実さである。さあ、今すぐ `go mod init` を叩け。インフラの未来は、君のコードの手の中にある。