こんにちは。クラウドの深淵を覗き込み、インフラをコードの海へ沈める旅へようこそ。
現場で「なぜこの独自APIだけTerraformで管理できないんだ！」と絶望したことはありませんか？ AWSやGCPのリソースはTerraformで完結するのに、社内のレガシーな管理システムや独自の内製ツールだけが、未だに手動のWebコンソール操作や叩きにくいcurlコマンドで運用されている……。
そんな「インフラの最後の聖域」をTerraformの管理下に置く。今日は、Go言語を使って自作プロバイダーを構築し、社内APIをIaC（Infrastructure as Code）の支配下に置くための極意を伝授します。
—
1. なぜ「自作プロバイダー」が必要なのか？
Terraformの本質は、あらゆるリソースを「宣言的」に管理することにあります。しかし、社内ツールには公式プロバイダーが存在しません。
ここで多くのエンジニアは「独自スクリプトを書いて実行する」という場当たり的な対応をしますが、それは冪等性（べきとうせい）の欠如という悪夢を招きます。
自作プロバイダーを開発すれば、`terraform plan` で変更差分が可視化され、`terraform apply` で安全に反映される。この世界観を手に入れれば、あなたのインフラ運用は「苦行」から「設計」へと劇的に進化します。
—
2. プロバイダー開発の深淵：実装のステップ
Terraformプロバイダーは、HashiCorpが提供している `terraform-plugin-framework` を使うのが現代の標準です。これを使えば、複雑なAPIリクエストの抽象化をフレームワークに任せることができます。
ステップ1：スケルトンの作成
まずは、Goのプロジェクトを立ち上げます。
mkdir terraform-provider-mycorp
cd terraform-provider-mycorp
go mod init github.com/yourname/terraform-provider-mycorp
次に、プロバイダーの骨組みを書きます。まずは「何もしないが、Terraformに認識されるだけのプロバイダー」を目指しましょう。
// main.go
package main
import (
“context”
“github.com/hashicorp/terraform-plugin-framework/providerserver”
“github.com/yourname/terraform-provider-mycorp/provider”
)
func main() {
// Terraformとの通信を確立するサーバーの起動
providerserver.Serve(context.Background(), provider.New, providerserver.ServeOpts{
Address: “registry.terraform.io/mycorp/mycorp”,
})
}
ステップ2：CRUD操作の実装（魂を込める場所）
次に、「Resource」を定義します。例えば「社内DBユーザー」を作成するリソースなら、`Create`, `Read`, `Update`, `Delete` の4メソッドを実装します。
ここで最も重要なのは、「APIのレスポンスとTerraformの状態（State）をどうマッピングするか」です。
// provider/user_resource.go のイメージ
func (r userResource) Create(ctx context.Context, req resource.CreateRequest, resp resource.CreateResponse) {
// 1. Plan（これから作成したい状態）を取得
var plan userModel
resp.Diagnostics.Append(req.Plan.Get(ctx, &plan)…)
// 2. 社内APIをコール
apiClient.CreateUser(plan.Name.ValueString())
// 3. 成功したらState（現在の状態）を更新
resp.Diagnostics.Append(resp.State.Set(ctx, &plan)…)
}
—
3. ローカルテストと魔法のデバッグ
作ったプロバイダーが動くか試すには、Terraformの「dev_overrides」設定を使います。これを設定すると、Terraformはわざわざレジストリを探しに行かず、あなたのローカルバイナリを直接叩いてくれます。
`~/.terraformrc` (または `terraform.rc`) に以下を追記してください。
provider_installation {
dev_overrides {
“registry.terraform.io/mycorp/mycorp” = “/path/to/your/bin/terraform-provider-mycorp”
}
direct {}
}
これで、`go build` するだけであなたのコードが即座にTerraformから呼び出せるようになります。IDEのデバッガーを繋げば、APIコールの瞬間を一行ずつ追うことも可能です。
—
4. 最後に：レジストリへの道
ある程度動くようになったら、GitHub Actionsを使ってバイナリをビルドし、Terraform Registryへ公開しましょう。
- 重要な知見: プロバイダーは必ず「冪等」であること。何度 `apply` しても、すでにリソースが存在するならエラーを出さず、変更がないことを検知して終了する。これができて初めて「プロバイダー」と呼べます。
結び
最初は難しく感じるかもしれません。しかし、一度この壁を越えると、あなたは「ツールを使うエンジニア」から「ツールを支配するエンジニア」へと変わります。
社内の非効率な運用をコードで美しく抽象化する。その達成感は、何物にも代えがたいものです。さあ、あなたの最初のプロバイダーを書き始めましょう。準備ができたら、いつでも相談に乗りますよ。
インフラは、コードで美しくなる。頑張ってください。