OpenTofuとNixで再現可能なインフラを構築する

結論

OpenTofuは資源の定義と状態を照合して変更計画を作り、Nixはその作業に使う実行環境を宣言するために使えます。両方の版を固定しても、クラウド側の状態、資格情報、外部サービスまで同一になるわけではありません。再現性の対象を「道具」「変更の入力」「実環境」に分けて記録します。

三つの管理対象

Providerのロックファイル、モジュールの参照先、Nixの入力は別々に確認します。Providerを固定しただけで、すべてのモジュールや実行ツールが固定されるわけではありません。

既存プロジェクトでの変更手順

以下は、対象構成、認証、Stateの保存先とロック、Nixの開発環境が用意されているプロジェクトでの手順です。

nix develop
tofu version
tofu init -lockfile=readonly
tofu validate
tofu plan -out=review.tfplan
tofu show -no-color review.tfplan

init -lockfile=readonlyが失敗した場合は、ロックファイルの不足や設定との差を調べます。通常の変更確認と依存の更新を同時に進めず、更新が必要な場合は差分としてレビューします。

計画では削除・置換、権限変更、公開範囲、想定外の資源を確認します。承認する対象は構成の版と保存した計画を結び付けます。適用までに構成、State、実環境が変わった場合は、状況を再確認し、必要に応じて計画と承認を取り直します。

Stateや保存した計画には秘密情報が含まれ得ます。公開リポジトリや一般向けのログへ出さず、保存先、暗号化、参照権限、保持期間を管理します。

復旧を別の手順にする

構成を以前の版へ戻しても、削除したデータや外部の変更が戻るとは限りません。Stateのバックアップも業務データのバックアップの代わりにはなりません。資源の再作成、データの復元、利用再開の確認を分け、復旧に必要な資格情報を利用できるかまで確認します。

トレードオフと制約

環境の固定と計画の保存は差分を説明しやすくしますが、依存の更新、Stateの保護、レビューの運用が必要です。再現性と復旧可能性を別々に評価し、同じコマンドが動くことだけを完了条件にしないようにします。

資料

• OpenTofu plan
• OpenTofu Sensitive Data in State
• Nix: Declarative shell environments
• Kubernetesの更新をNixで扱う

関連事例

• 新規SaaSプロダクト開発

関連事例の担当範囲や設計判断を参照します。記事で提案する実験・構成を、その事例で実施済みとするものではありません。