OpenTofu の利用
OpenTofu のコアワークフローは3つのステップで構成されます。
- 記述 - インフラストラクチャをコードとして記述します。
- 計画 - 適用前に変更をプレビューします。
- 適用 - 再現可能なインフラストラクチャをプロビジョニングします。
このガイドでは、これらの3つのステップが、個人利用者、インフラストラクチャを共同で開発するチーム、そしてクラウドバックエンドによってワークフローが組織全体で円滑に実行される方法においてどのように機能するかを説明します。
個人利用者としての作業
まず、インフラストラクチャコードで作業する個人が、これらの部分がどのように連携するかを見ていきましょう。
記述
OpenTofu の設定は、コードを書くように、お好みのエディタで記述します。個人で作業する場合でも、バージョン管理されたリポジトリに作業を保存するのが一般的です。
# Create repository
$ git init my-infra && cd my-infra
Initialized empty Git repository in /.../my-infra/.git/
# Write initial config
$ vim main.tf
# Initialize OpenTofu
$ tofu init
Initializing provider plugins...
# ...
OpenTofu has been successfully initialized!
設定の作成を進める際に、計画を繰り返し実行することで、構文エラーを洗い出し、設定が期待通りに作成されていることを確認できます。
# Make edits to config
$ vim main.tf
# Review plan
$ tofu plan
# Make additional edits, and repeat
$ vim main.tf
これは、個人でアプリケーションコードを扱う場合と似ており、コードの編集とテストコマンドの実行の間の緊密なフィードバックループが役立ちます。
計画
「記述」ステップのフィードバックループによって、良好な変更が得られたら、作業をコミットし、最終的な計画を確認します。
$ git add main.tf
$ git commit -m 'Managing infrastructure as code!'
[main (root-commit) f735520] Managing infrastructure as code!
1 file changed, 1 insertion(+)
tofu apply は、インフラストラクチャを変更する前に確認のための計画を表示するため、最終確認にはこのコマンドを実行します。
$ tofu apply
An execution plan has been generated and is shown below.
# ...
適用
最終確認後、OpenTofu に実際のインフラストラクチャをプロビジョニングするよう指示できます。
Do you want to perform these actions?
OpenTofu will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
# ...
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
この時点で、安全のためにバージョン管理リポジトリをリモートロケーションにプッシュするのが一般的です。
$ git remote add origin https://github.com/*user*/*repo*.git
$ git push origin main
このコアワークフローはループです。次回変更を行う場合は、最初からプロセスをやり直します。
このワークフローが、個人でアプリケーションコードやスクリプトを作成するプロセスとどれほど似ているかにお気づきでしょうか？これが、OpenTofu がインフラストラクチャコードを可能にするという意味です。
チームでの作業
複数の人が OpenTofu の設定を共同で開発するようになった場合、全員が円滑に作業できるように、コアワークフローの各部分に新しいステップを追加する必要があります。これらのステップの多くは、個人ではなくチームでアプリケーションコードを開発する場合に行うワークフローの変更と類似していることがわかるでしょう。
記述
チームの各メンバーは、引き続きお好みのエディタで OpenTofu の設定を変更しますが、互いの作業と競合しないように、変更をバージョン管理の *ブランチ* に保存します。ブランチで作業することで、チームメンバーは通常のマージコンフリクトワークフローを使用して、相互に非互換なインフラストラクチャの変更を解決できます。
$ git checkout -b add-load-balancer
Switched to a new branch 'add-load-balancer'
設定の作成中は、反復的な計画の実行はフィードバックループとして依然として役立ちますが、時間の経過とともに、各チームメンバーのコンピュータで計画を実行することが困難になります。チームとインフラストラクチャが成長するにつれて、計画を実行するために必要な機密性の高い入力変数（APIキー、SSL証明書ペアなど）の数も増加します。
各チームメンバーがローカルですべての機密性の高い入力を準備する負担とセキュリティリスクを回避するために、チームは OpenTofu の操作を共有された継続的インテグレーション（CI）環境で実行するモデルに移行することが一般的です。このような CI 環境の作成に必要な作業は些細なものではなく、このコアワークフローの概要の範囲外です。
バージョン管理にコミットし、CI パイプラインが実行されるのを待つこの長い反復サイクルは、多くの場合、個々の OpenTofu 設定の変更を作成中に推測的な計画をフィードバックループとして使用することを妨げるほど長くなります。しかし、後ほど説明するように、新しい OpenTofu の変更が適用される前、またはメイン開発ブランチにマージされる前であっても、推測的な計画は依然として役立ちます。
計画
インフラストラクチャを共同で開発するチームの場合、OpenTofu の計画出力は、チームメンバーが互いの作業を確認する機会を生み出します。これにより、チームは質問したり、リスクを評価したり、潜在的に有害な変更が行われる前にミスを発見したりすることができます。
これらのレビューが行われる自然な場所は、バージョン管理内のプルリクエスト（個人が自分の作業ブランチから共有チームブランチへのマージを提案する時点）です。チームメンバーが推測的な計画出力と共に提案された設定の変更を確認すると、計画によって変更の意図が達成されているかどうかを評価できます。
問題は、チームがレビューするための推測的な計画出力を作成することです。OpenTofu をローカルで実行しているチームの中には、プルリクエストに、変更作成者によって生成された推測的な計画出力のコピーを添付する慣習を行っているチームもあります。その他、CI システムが推測的な計画出力をプルリクエストに自動的に投稿するように設定しているチームもあります。
作成者の意図が正しく表現されているかどうかを計画を確認することに加えて、チームは、この変更を今行うかどうかを評価することもできます。たとえば、チームが特定の変更によってサービスの中断が発生する可能性があることに気付いた場合、メンテナンスウィンドウをスケジュールできるまで、そのプルリクエストのマージを遅らせることを決定する場合があります。
適用
プルリクエストが承認されマージされた後、チームは共有チームブランチと最新のステートファイルに対して実行された最終的な具体的なプランを確認することが重要です。
このプランは、マージ順序や最近のインフラストラクチャの変更などの問題により、プルリクエストで確認されたプランとは異なる可能性があります。たとえば、プランの確認後にインフラストラクチャを手動で変更した場合、マージするとプランが異なる可能性があります。
この時点で、チームは変更を適用することによる潜在的な影響について質問します。この変更によってサービスの中断を予想しますか？この変更のどの部分が高リスクですか？この変更を適用する際に監視する必要があるシステムの部分はありますか？この変更が発生することを通知する必要がある人はいますか？
変更によっては、チームメンバーが適用出力の実行中に監視したい場合があります。ローカルでOpenTofuを実行しているチームの場合、これはチームとの画面共有を伴う場合があります。CIでOpenTofuを実行しているチームの場合、ビルドログを確認する必要があるかもしれません。
個人向けのワークフローと同様に、チーム向けの主要なワークフローは、各変更に対して実行されるループです。チームによっては、このループが週に数回発生する場合もあれば、1日に何度も発生する場合もあります。
結論
OpenTofuの使用方法には、個人ユーザー、単一チーム、大規模な組織全体など、さまざまな方法があります。必要なコラボレーションの密度に最適なアプローチを選択することで、OpenTofuの主要なワークフローへの投資から最大の利益を得ることができます。OpenTofuを大規模に使用している組織の場合、TACOS（TF Automation and Collaboration Software）は、この主要なワークフロー上に構築された新しいレイヤーを導入し、チームと組織特有の問題を解決します。