- コマンドライン
- OpenTofu CLIでのクラウドバックエンドの使用
- クラウドバックエンドの設定
クラウドバックエンドの設定
OpenTofu CLIは、クラウドバックエンドと統合し、そのクライアントとして機能できます。
特定の作業ディレクトリでクラウドバックエンドを使用するには、以下の設定を行う必要があります。
tofu loginコマンドを使用するなどして、クラウドバックエンドにアクセスするための認証情報を提供します。- どの組織とワークスペースを使用するかを指定するために、ディレクトリのOpenTofu構成に
cloudブロックを追加します。 - 必要に応じて、プランと適用を実行する際にOpenTofu構成と一緒にアップロードしないファイルを指定するために、
.terraformignoreファイルを使用します。
cloudブロックを追加または変更した後、tofu initを実行する必要があります。
cloudブロック
cloudブロックは、トップレベルのterraform設定ブロック内のネストされたブロックです。これは、現在の作業ディレクトリで使用するクラウドバックエンドワークスペースを指定します。
terraform {
cloud {
organization = "my-org"
hostname = "app.example.org"
workspaces {
project = "networking-development"
tags = ["networking", "source:cli"]
}
}
}
cloudブロックには、いくつかの特別な制限もあります。
- 構成で指定できる
cloudブロックは1つのみです。 cloudブロックは、ステートバックエンドと一緒に使用することはできません。構成では、どちらか一方を使用できますが、両方を使用することはできません。cloudブロックは、名前付きの値(入力変数、ローカル変数、またはデータソース属性など)を参照することはできません。
cloudブロックは、OpenTofu CLIの動作にのみ影響します。クラウドバックエンドがクラウドブロックを含む構成を使用する場合(たとえば、ワークスペースがVCSプロバイダーを直接使用するように構成されている場合)、ブロックを無視し、独自のワークスペース設定に従って動作します。
引数
cloudブロックは、次の構成引数をサポートします。
-
hostname- (必須) クラウドバックエンドのホスト名。 -
organization- (必須) 現在の構成で使用する必要があるワークスペースを含む組織の名前。 -
workspaces- (必須) 現在の構成で使用するリモートクラウドバックエンドワークスペースを指定するネストされたブロック。workspacesブロックには、ワークスペースのマッピング方法を示す次の引数のうち、1つだけを含める必要があります。-
tags- (オプション) クラウドバックエンドのワークスペースタグのセット。指定されたすべてのタグを持つワークスペースでこの作業ディレクトリを使用でき、tofu workspaceコマンドを使用して、ワークスペースを切り替えたり、新しいワークスペースを作成したりできます。新しいワークスペースには、指定されたタグが自動的に設定されます。このオプションは、nameと競合します。 -
name- (オプション) 単一のクラウドバックエンドワークスペースの名前。この作業ディレクトリで構成に指定されたワークスペースのみを使用でき、CLIからワークスペースを管理することはできません(例:tofu workspace selectまたはtofu workspace new)。このオプションは、tagsと競合します。 -
project- (オプション) クラウドバックエンドプロジェクトの名前。作成する必要があるワークスペースは、このプロジェクト内に作成されます。tofu workspace listは、提供されたプロジェクト内のワークスペースでフィルタリングされます。
-
-
token- (オプション) クラウドバックエンドとの認証に使用されるトークン。構成からトークンを省略し、代わりにtofu loginを使用するか、CLI構成ファイルでcredentialsを手動で構成することをお勧めします。
環境変数
環境変数を使用して、1つ以上のcloudブロック属性を構成できます。これは、継続的インテグレーション(CI)パイプラインの一部としてOpenTofuを構成する場合に役立ちます。OpenTofuは、対応する属性が構成ファイルから省略されている場合にのみ、これらの変数を読み取ります。環境変数を使用してcloudブロック全体を構成することを選択した場合は、構成ファイルに空のcloudブロックを追加する必要があります。
非対話型ワークフローでのリモート実行には、自動承認されたデプロイが必要です。自動化されたビルドパイプライン以外で誰もインフラストラクチャを変更できないようにすることで、予測不可能なインフラストラクチャの変更や構成のずれのリスクを最小限に抑えます。
cloud ブロックを設定するには、次の環境変数を使用します。
-
TF_CLOUD_ORGANIZATION- 組織の名前。OpenTofu は、cloudブロックからorganizationが省略されている場合にこの変数を読み取ります。両方が指定されている場合、構成が優先されます。 -
TF_CLOUD_HOSTNAME- クラウドバックエンドのホスト名。OpenTofu は、cloudブロックからhostnameが省略されている場合にこれを読み取ります。両方が指定されている場合、構成が優先されます。 -
TF_CLOUD_PROJECT- クラウドバックエンドプロジェクトの名前。OpenTofu は、cloudブロックからworkspaces.projectが省略されている場合にこれを読み取ります。両方が指定されている場合、クラウドブロックの構成が優先されます。 -
TF_WORKSPACE- 単一のクラウドバックエンドワークスペースの名前。OpenTofu は、cloudブロックからworkspacesが省略されている場合にこれを読み取ります。クラウドバックエンドはこの変数から新しいワークスペースを作成しません。ワークスペースは指定された組織に存在する必要があります。cloudブロックがタグを使用している場合は、TF_WORKSPACEを設定できます。ただし、TF_WORKSPACEの値は、タグのセットに含まれている必要があります。この変数は、ローカル環境でワークスペースを選択するためにも使用されます。詳細については、TF_WORKSPACE を参照してください。
.terraformignore を使用したアップロードからのファイルの除外
CLIドリブン実行でリモートの plan または apply を実行すると、構成ディレクトリのコピーがクラウドバックエンドにアップロードされます。構成ディレクトリのルートに .terraformignore ファイルを追加することで、アップロードから除外するパスを定義できます。このファイルが存在しない場合、アップロードはデフォルトで以下を除外します。
.git/ディレクトリ.terraform/ディレクトリ (.terraform/modulesを除く)
.terraformignore ファイルのルールは、.gitignore ファイルで許可されているルールに似ています。
- コメント (
#で始まる) または空白行は無視されます。 - パターンをフォワードスラッシュ
/で終わらせると、ディレクトリを指定します。 - 感嘆符
!で始めることでパターンを否定します。
.gitignore とは異なり、構成ディレクトリのルートにある .terraformignore のみが考慮されます。