TerraformからPulumiへ：Stateを壊さず、インフラを「プログラム」に変える極意
こんにちは。インフラの世界へようこそ。
これまでTerraform（HCL）で苦労して構築してきたインフラを、より柔軟で強力な「プログラミング言語」で管理したいと考えたことはありませんか？
今回は、TerraformからPulumiへの移行という、一見リスキーで難易度の高い冒険を、安全かつ確実に行うための「現場の設計思想」を伝授します。これをマスターすれば、JSONやHCLの制約に縛られず、ユニットテストやリファクタリングが可能な「真のInfrastructure as Code」を手に入れられますよ。
—
1. なぜ今、Pulumiなのか？（Stateの概念を変える）
TerraformとPulumiの最大の違いは、「設定ファイル」か「プログラム」かという点です。PulumiはTypeScript、Python、Goなどの汎用言語でインフラを定義します。これにより、ループ処理や条件分岐が極めて直感的になり、CI/CDパイプラインとの親和性が爆発的に向上します。
インストールとセットアップ
まずは、Pulumiのバイナリをインストールしましょう。
macOSの場合
brew install pulumi
インストール確認
pulumi version
次に、AWS等のプロバイダに対する認証を通します（Terraformで使っていた環境変数 `AWS_ACCESS_KEY_ID` などがそのまま使えます）。
—
2. HelloWorld：インフラを「プログラム」として記述する
Pulumiの醍醐味は、型安全なインフラ定義です。TypeScriptでの最小構成（HelloWorld）を見てみましょう。
import as aws from “@pulumi/aws”;
// S3バケットをプログラムとして宣言
const bucket = new aws.s3.BucketV2(“my-pulumi-bucket”, {
bucket: “my-bucket-name-unique-12345”,
});
// バケット名をエクスポート（デプロイ後にコンソールへ出力される）
export const bucketName = bucket.bucket;
ここがポイント:
`pulumi up` を実行すると、Pulumiがクラウドの現在状態をスキャンし、不足しているリソースだけを完璧に配置します。
—
3. TerraformからPulumiへの移行戦略（State移行の極意）
ここからが本題です。既存のTerraform Stateを捨てずにPulumiへ移行するには、「import」機能の活用が不可欠です。
ステップA：既存リソースのImport
無理に一括移行しようとせず、まずはPulumiに既存インフラを認識させることから始めます。
既存のリソースをPulumiコードとして生成させる（魔法のコマンド）
pulumi import aws:s3/bucketV2:BucketV2 my-bucket-name-unique-12345 my-bucket-name-unique-12345
ステップB：コード変換の戦略
Terraformの `main.tf` をそのままコピー＆ペーストして成功することはありません。以下の順序でリファクタリングを行います。
1. 疎結合化: 巨大な `tf` ファイルをモジュール単位でPulumiの「ComponentResource」に分割する。
2. ビジネスロジックの注入: HCLでは書けなかった複雑な命名規則や、外部APIを叩くロジックをTypeScriptの関数として実装する。
3. Stateの完全移行: `pulumi stack import` を使い、既存のStateファイルをPulumiのBackend（Pulumi Cloud等）に流し込むのが理想ですが、最初は「並行稼働」させて徐々にPulumi側にリソースを移譲（`pulumi import`）していくのが最も安全です。
—
4. 移行時に発生しやすいトラブルと回避策
現場でよくある失敗は「焦り」です。以下のルールを守ってください。
- 「破壊的変更」を避けろ: 移行時は必ず `pulumi preview` を実行し、既存リソースが `destroy` されないかを確認してください。`protect: true` オプションを付与することで、誤削除を物理的に防げます。
- Providerバージョンの不一致: TerraformとPulumiでは内部で利用するAWS Providerのバージョンや挙動が微妙に異なる場合があります。本番環境で試す前に、必ず検証環境で「Terraform管理下のリソースをPulumiで読み込めるか」をテストしてください。
—
5. 段階的移行のベストプラクティス
いきなり全てを捨ててPulumiに乗り換える必要はありません。
1. 新規開発から導入: まずは新規のスタックをPulumiで構築し、その便利さをチームで体感する。
2. 枯れたリソースから移行: 変更頻度の低いネットワーク基盤などはTerraformのまま残し、頻繁にデプロイするアプリケーションリソース（Lambda, ECS, S3等）からPulumi化する。
3. テスト駆動開発（TDD）の導入: Pulumiの強みはテストコードが書けることです。`mocha` や `jest` を使い、構築前に「S3は必ず暗号化されているか？」をテストする習慣をつけましょう。
—
最後に：エンジニアとしての心構え
ツールを変えることは、単なる記法の変更ではありません。「インフラをコードとして扱い、テストし、再利用可能な資産にする」という設計思想へのアップグレードです。
最初は少し戸惑うかもしれませんが、一度Pulumiでインフラを組み上げれば、もうHCLの制約には戻れなくなるはずです。あなたのインフラ構築が、より創造的で楽しい作業になることを願っています。
さあ、まずは `pulumi new aws-typescript` を叩いて、新しい世界への第一歩を踏み出しましょう！