はじめに
「Terraformってよく聞くけど、結局どうやって始めればいいんだろう...」
正直に言うと、私はTerraform初学者です。チュートリアルをほんの少し触ったことがある程度で、「インフラをコードで管理するのが良いらしい」くらいの理解しかありません。ましてや、既存のリソースをIaC化するというのは今回が初めての経験でした。
ただ、業務で使っているGCPプロジェクトを見ると、VMやCloud Storage、ファイアウォールルールなど、いつの間にかリソースが増えている状態。「このままコンソールでポチポチ管理し続けるのもな...」という漠然とした不安がありました。
そんな時、GCPの既存リソースを一括でTerraformコードに変換できるという gcloud beta resource-config bulk-export コマンドの存在を知りました。
「これなら、1から書かなくても既存リソースをコード化できるのでは？」という単純な考え。
勉強も兼ねて、とりあえず実験的に試してみることにしました。結果、約80リソースのTerraformコード自動生成に成功...したのですが、生成されたコードを見て「あれ、これどうすればいいんだ？」となりました。
この記事では、Terraform初心者の私が実際に試してみた手順と、「とりあえずコードは出たけど、この先どうするの？」という正直な感想をまとめます。
結論：とりあえずコードは出た。でも「これで終わり」ではなかった
先に結論を言うと、bulk-exportを実行すればTerraformコードは確かに生成されます。初心者の私でも、手順通りにやれば複数リソース分のコードが出力されました。
ただ、出力されたコードを眺めて思ったのは...
「で、この後どうすんねん？」
| わかったこと | わからなかったこと |
|---|---|
| コマンドを打てばコードは出る | 出力されたコードをどう整理すればいいか |
| 約60種類のGCPサービスに対応している |
.tfstateって何？なぜ生成されない？ |
| GKEクラスタは不要だった | 変数化・モジュール化はどうやるの？ |
正直、「IaC化できた！」というよりは「IaC化の入口に立った」という感覚。
実行環境と前提条件
- OS: macOS（Windows/Linuxでも同様の手順で可能）
- 必要な権限: GCPプロジェクトの Owner または Editor
- 対象プロジェクト: 匿名
- 対象リージョン: asia-northeast1（東京）
手順①：gcloud CLIのインストールと初期化
まず、gcloud CLIをインストールするところから始めました。Terraformを触る前に、まずGCPのCLIツールが必要だった（このあたりも最初はよくわかっていませんでした）
インストール
Google Cloud公式サイトからインストーラーをダウンロードして実行します。
# インストール確認
gcloud --version
# 出力例: Google Cloud SDK 541.0.0
初期化
gcloud init
ブラウザが開くのでGoogleアカウントでログインし、対象プロジェクトとリージョンを選択。
# 設定確認
gcloud config list
手順②：必要なAPIの有効化
bulk-exportを実行するには、事前に2つのAPIを有効化する必要があるようです。
# リソースをスキャンするためのAPI
gcloud services enable cloudasset.googleapis.com
# プロジェクト構造を理解するためのAPI
gcloud services enable cloudresourcemanager.googleapis.com
正直、「なんでAPIを有効化しないといけないの？」と思いましたが、調べてみるとCloud Asset Inventory APIがプロジェクト内のリソースを探し出し、Cloud Resource Manager APIがプロジェクトの構造を理解するために必要とのこと。
「へー、GCPって内部的にこういう仕組みで動いてるんだ」と少し勉強になりました。
手順③：bulk-exportの実行
いよいよ本題のコマンドを実行します。
コマンド実行
gcloud beta resource-config bulk-export \
--project=匿名 \
--resource-format=terraform \
--path=./terraform-export
| パラメータ | 意味 |
|---|---|
--project |
エクスポート対象のプロジェクトID |
--resource-format=terraform |
出力形式をTerraformに指定 |
--path |
出力先ディレクトリ |
初回実行時に「なんだこれ」となったこと
初回実行時、いくつかのインストール確認が出てきて少し戸惑いました。
This command requires the `config-connector` binary to be installed.
Would you like to install the `config-connector` binary? (Y/n)?
「Config Connector...？GKEが必要なやつ？」と一瞬焦りましたが、調べてみるとこれはローカルで動作する変換ツールのインストールでした。Kubernetesは使いません。Y を入力して進めます。
実行結果
しばらく待つと、処理が完了。
# ファイル数確認
ls ./terraform-export/*.tf | wc -l
# 出力: 80
約80ファイルのTerraformコードが生成されました。「おお、本当に出た...！」というのが正直な感想です。
生成されたコードの中身
ファイル構造
リソースごとに個別の.tfファイルが生成されます。
terraform-export/
├── ComputeFirewall_allow-ssh.tf
├── ComputeInstance_my-vm.tf
├── StorageBucket_my-bucket.tf
└── ...
コードの例
resource "google_compute_instance" "my-vm" {
name = "my-vm"
machine_type = "e2-medium"
zone = "asia-northeast1-a"
boot_disk {
initialize_params {
image = "debian-cloud/debian-11"
}
}
network_interface {
network = "default"
}
}
実際の設定値が出力されます。
「コードは出たけど...これどうするねん？」となった3つのポイント
80ファイルも生成されて「やった！」と思ったのも束の間、中身を見て**「あれ、これそのまま使えるの？」**という疑問が湧いてきました。
①リソース名が暗号みたいで読めない
# 自動生成された名前
resource "google_compute_firewall" "tfer--allow-002D-ssh-002D-from-002D-iap" {
...
}
「002Dって何...？」と思って調べたら、ハイフンがエンコードされた結果でした。人間が読むには厳しい名前です。
後から知ったこと: これは手動で読みやすい名前にリネームする必要があるようです。
# こう直すべきらしい
resource "google_compute_firewall" "allow_ssh_from_iap" {
...
}
②設定値が全部ベタ書き
# 生成されたコード
zone = "asia-northeast1-a"
machine_type = "e2-medium"
「変数化」という言葉は聞いたことがありましたが、生成されたコードは全部直接値が書かれている状態。環境ごとに変えたい場合はどうするんだろう...と思いました。
後から知ったこと: variables.tf というファイルを作って変数化するのがベストプラクティスらしいです。
# variables.tf
variable "default_zone" {
default = "asia-northeast1-a"
}
# main.tf
zone = var.default_zone
③.tfstateファイルがない
Terraformについて少し調べると、「状態ファイル（.tfstate）」というものが重要らしいことがわかりました。でも、bulk-exportで生成されたのは.tfファイルだけ。
後から知ったこと: bulk-exportはコードだけを生成するツールで、状態ファイルは別途 terraform plan や terraform apply で作る必要があるとのこと。
cd ./terraform-export
terraform init
terraform plan
このあたり、まだ完全には理解できていませんが、とりあえず「コードを生成しただけでは終わりじゃない」ということはわかりました。
今後の課題
今回の実験で、「コードを生成すること」と「Terraformで管理できる状態にすること」は別物だということがわかりました。
生成されたコードを眺めてみると、まず気になったのは以下の2点です：
正直、この先の作業はまだ手をつけられていません。まずは生成されたファイルを1つずつ確認して、実際のGCPコンソールと見比べながら整理していこうと思います。
その後、Terraformの基本（変数化やモジュール化など）を勉強して、ちゃんと運用できる状態にしていくのが目標です。
余談：「GKEが必要」と思って焦った話
bulk-exportについて調べていると、公式ドキュメントで「Config Connector経由でエクスポート」という方法が紹介されていました。
そのドキュメントを読むと、**「GKEクラスタを作成 → Config Connectorアドオンを有効化 → bulk-export実行」**という流れが書かれていて...
「え、GKEクラスタとは？立てないといけないの...？」
GKEクラスタを立てるとお金がかかるし、そもそもKubernetesの知識がない私には敷居が高すぎる。「初心者には無理では...」と一瞬諦めかけました。
でも、よく調べてみると今回使った方法（bulk-export直接実行）ならGKEは不要でした。
| 方法 | 私の理解 |
|---|---|
| Config Connector経由 | GKEクラスタが必要。継続的にリソースを管理したい人向け？ |
| bulk-export直接実行 | GKE不要。とりあえずコードを出したいだけならこっち |
公式ドキュメントがConfig Connector経由を詳しく説明していたので混乱しましたが、「とりあえず既存リソースをコード化してみたい」という目的なら、シンプルな方法で十分でした。
まとめ
Terraform初心者の私が、勉強のために gcloud beta resource-config bulk-export を試してみました。
結果、GCPの既存リソース約80個分のTerraformコードを生成することができました。
今後は、生成されたファイルが実際のリソースと対応しているか確認し、リネーム作業を進めていく予定です。
**「IaC化の入口に立った」**という感覚。ここからが本当のスタートです。
同じように「とりあえずIaC化してみたい」という人の参考になれば幸いです。
参考
今回参考にしたドキュメントです。