メインコンテンツにスキップ

ワークスペースの管理

OpenTofu CLIのワークスペースとは、同じOpenTofu作業ディレクトリ内の状態データの別々のインスタンスを指します。これらは、独自のOpenTofu設定を持ち、別の作業ディレクトリとして機能するクラウドバックエンドのワークスペースとは明らかに異なります。

OpenTofuは実世界のオブジェクトにリソースを関連付けるために状態に依存します。同じ構成を別々の状態データで複数回実行すると、OpenTofuは重複しない複数のリソースセットを管理できます。

ワークスペースは特定のユースケースに役立ちますが、OpenTofu CLIを使用するために必要ではありません。別々の資格情報とアクセス制御を必要とする複雑な展開には、代替アプローチを使用することをお勧めします。

CLIワークスペースの管理​

すべての初期化された作業ディレクトリは、「default」という名前の1つのワークスペースから始まります。

現在の作業ディレクトリで使用可能なワークスペースを管理するには、tofu workspace list、tofu workspace new、tofu workspace deleteコマンドを使用します。

現在選択されているワークスペースを変更するには、tofu workspace select コマンド を使用します。指定した作業用ディレクトリでは、一度に 1 つのワークスペースしか選択できません。ほとんどの OpenTofu コマンドは、現在選択されているワークスペースのみとやり取りします。これには、プロビジョニング と 状態の操作 が含まれます。

各ワークスペースでインフラストラクチャをプロビジョニングすると、通常は異なる 入力変数 を手動で指定して、各コレクションを区別する必要があります。たとえば、テストインフラストラクチャを別のリージョンにデプロイする場合があります。

使用例​

複数の 作業用ディレクトリ を作成して、完全に独立した状態データを持つ構成の複数のインスタンスを管理できます。ただし、OpenTofu は各作業用ディレクトリにプラグインとモジュールの個別のキャッシュをインストールするため、複数のディレクトリを管理すると帯域幅とディスク容量が無駄になる可能性があります。このアプローチでは、各ディレクトリの構成をバージョン管理から個別にアップデートしたり、構成を変更するたびに各ディレクトリを再初期化したりするなどの追加のタスクも必要です。ワークスペースは、同じ作業用構成とプラグインおよびモジュールキャッシュを使って別のインフラストラクチャセットを作成できるため、便利です。

複数のワークスペースを一般的に使用する場合は、インフラストラクチャセットの並列の別のコピーを作成して、本番環境のインフラストラクチャを変更する前に一連の変更をテストします。

既定以外のワークスペースは、バージョン管理のフィーチャーブランチに関連していることがよくあります。既定のワークスペースは、本番環境インフラストラクチャの意図された状態を表す main ブランチまたは trunk ブランチに対応する場合があります。開発者が変更のためにフィーチャーブランチを作成すると、対応するワークスペースを作成して、メインインフラストラクチャの一時的なコピーをそのワークスペースにデプロイする場合があります。その後、本番環境インフラストラクチャに影響を与えることなく、コピー上で変更をテストできます。変更がマージされ、既定のワークスペースにデプロイされると、テストインフラストラクチャを破棄し、一時的なワークスペースを削除します。

複数のワークスペースを使用しない場合​

ワークスペースを使用すると、単一構成の複数のインスタンス間を単一のバックエンド内で素早く切り替えられます。すべての問題を解決するようには設計されていません。

OpenTofu を使用してより大規模なシステムを管理する場合は、システム内のアーキテクチャ境界に対応する個別の OpenTofu 構成を作成する必要があります。これにより、チームはさまざまなコンポーネントを個別に管理できます。各サブシステムには個別の構成とバックエンドが必要であるため、ワークスペース単独ではシステム分解に適したツールではありません。

特に、同じインフラストラクチャの複数のデプロイメントを、異なる開発段階または異なる内部チームに対応させるために強固な分離を作成したい組織が一般的です。この場合、各デプロイメントのバックエンドには、通常、異なる資格情報とアクセス制御があります。作業用ディレクトリ内の CLI ワークスペースは同じバックエンドを使用するため、このシナリオには適していません。

ワークスペースの代替​

CLIワークスペースを作成する代わりに、1つ以上の再利用可能なモジュールを使用して一般的な要素を表してから、各インスタンスを、別のバックエンドのコンテキストでこれらの一般的な要素をインスタンス化する個別の設定として表すことができます。各設定のルートモジュールは、バックエンド設定と、デプロイメント間のわずかな違いを説明する引数を含む少数のモジュールブロックだけで構成されます。

複数の設定が複数のデプロイメントではなく、個別のシステムコンポーネントを表す場合、ペアになったリソースタイプとデータソースを使用して、あるコンポーネントから別のコンポーネントにデータを渡すことができます。

  • すべての設定からアクセスできる構成管理システムがある場合、1つは変数をエクスポートするためのリソースを使用し、もう1つの設定はそれらをインポートするためのデータソースを使用できます。

  • ユーザー定義のラベルまたはタグをサポートするシステムでは、タグ付けの規則を使用して、リソースを自動的に検出できるようにします。たとえば、aws_vpcリソースタイプを使用して適切なタグを割り当て、aws_vpcデータソースを使用して、他の設定内のこれらのタグでクエリを実行します。

  • サーバーアドレスの場合は、プロバイダー固有のリソースを使用して、予測可能な名前を持つDNSレコードを作成します。その後、その名前を直接使用するか、dnsプロバイダーを使用して、他の設定で公開されたアドレスを取得できます。

  • ある設定のOpenTofu状態を、他の設定がアクセスできるリモートバックエンドに保存する場合、他の設定はterraform_remote_stateを使用して、そのルートモジュールの出力を直接使用できます。この設定により、設定間の結合が緊密になり、ルート設定は結果を別のシステムに公開する必要がなくなります。

ワークスペースの内部機構​

ワークスペースは、技術的には状態ファイルを名前変更することと同等です。 OpenTofuには、リモート状態に対する保護とサポートのセットが含まれています。

ワークスペースは共有リソースになることも想定されています。純粋にローカル状態を使用し、状態をバージョン管理にコミットしない場合を除き、プライベートではありません。

ローカル状態の場合、OpenTofuはterraform.tfstate.dというディレクトリにワークスペース状態を格納します。このディレクトリは、ローカルのみのterraform.tfstateと同様に扱う必要があります。これらのファイルをバージョン管理にコミットするチームもありますが、複数の共同作業者がいる場合は、代わりにリモートバックエンドを使用することをお勧めします。

リモート状態の場合、ワークスペースは設定済みバックエンドに直接格納されます。たとえば、Consulを使用する場合、ワークスペースは状態パスにワークスペース名を付加することで格納されます。ワークスペース名がすべてのバックエンドに正しく安全に格納されるようにするには、その名前はエスケープせずにURLパスセグメントで使用できる必要があります。

OpenTofuは、無視される.terraformディレクトリに現在のワークスペース名をローカルに格納します。これにより、複数のチームメンバーが同時に異なるワークスペースで作業できます。ワークスペース名は、クラウドバックエンド内の関連するリモートワークスペースにも関連付けられます。クラウドバックエンドのワークスペース名の詳細については、CLI統合（推奨）とリモートバックエンドとドキュメントを参照してください。