この記事はSRETT #11で発表されたものに加筆修正したものです。OpenTofuに関して調べたこととなります。
speakerdeck.com
先日KubeCon + CloudNativeCon North America 2024に行ってきてました。その中で共同開催されていたOpenTofu Dayを見てOpenTofuに関して興味を持ちました。普段はTerraformを利用しており、あまりOpenTofuについては触ってきてないので、この機会に深堀りをしてみたいと思いました。
また、社内活動として技術検証を行っており、私の検証テーマとしてTerraformを中心としたIaC周りの技術調査を行ってるので、ちょうどいい機会だとも思いました。
おことわり
この記事はTerraformを知っている前提で書かれています。そのため細かい説明を省略している箇所があります。
また筆者は普段はTerraformをメインで使用しており、OpenTofuを業務利用はしていません。
OpenTofuとは
2023年8月にTerraformを含めたHashiCorp製品のライセンスの変更を発表したことにより、これを懸念した企業やコミュニティによりOpenTFとしてフォークされます。その後OpenTFの名称はHashiCorp社の商標権への懸念からOpenTofuに改名されます。そのときの議論はissueを見るとたどることができます。
2023年9月にLinux Foundation傘下となります。
Terraformをフォークしたものなので基本的な使い勝手は同じです。コマンド名が terraform から tofu に差し替えられています。
ライセンス問題
前項でさらっとライセンス変更と言いましたが、HashiCorp社は2023年8月に今後のリリースに関してライセンスを変更する旨を発表しました。これはオープンソースライセンスであるMozilla Public License（MPL） v2.0から商用サービスでの利用を制限するBusiness Source License（BUSLあるいはBSL） v1.1に変更するものです。
これに対して、利用企業およびコミュニティが懸念を示し、OpenTofuをフォークしたという流れになります。
HashiCorp社の言い分
従来BSLは本番使用(production use)が制限されます。ただし、ライセンスのParameterとして追加使用許可(Additional Use Grant)をすることによりTerraformと「競合製品」でなければ本番利用の制限はないとしてます。
「競合製品」とは、有料サポート契約を含む第三者に販売される製品で、HashiCorp のライセンス対象製品の有料版の機能と大幅に重複する製品を指します。TerraformでいうところのHCP Terraform(Terraform Cloud)を想定しているのかと思います。
また組織内でTerraformをホストして利用することは「競合製品」とはみなされなません。そのため利用者としては基本的には問題なく利用できるとしてます。
問題となるのはTerraformの機能を有償で提供しているSaaSと読み取れます。
コミュニティの懸念
HashiCorp社が説明したBSLと追加使用許可はあいまいであるとしてます。そのため、自身の行動が許諾範囲内か判断が困難である。「競合製品」の定義やライセンス自体が今後変更されるか不確実であると懸念を示してます。
また、TerraformはOSSの恩恵を受けて成長してきてため、これからもオープンソースソフトウェアであるべきだと信じていると表明しています。
OpenTofuのスポンサー企業としては以下のとおりです。
HarnessはCI/CDまわりのSaaS製品、Gruntworksはterragruntの開発元、Specelift、env0、ScalrはTerraformをホストするSaaSサービスを運営しています。
この項ではそれぞれの違いについて説明していきます。
OpenTofuはTerraform1.6-alphaからフォークされているのでそれまでに実装されていたものは互換があります。
また、Terraform 1.6以降に追加された機能に関しても随時取り込まれています。そのため、1.5までの機能を使っているのであれば素直に移行できるかとは思います。
バージョンごとに移行ガイドがあるので細かくはそれを参照すると良いです。
ただし、別のコードベースで開発がされているので、OpenTofuのみの独自実装もあります。ここではいくつか個人的に気になる違いについてあげていきます。
コマンド
- 基本的には terraform を tofuに置き換えていただければよいです。サブコマンドは一緒です。
# Terraform
terraform init
terraform plan
terraform apply
terraform destroy
# OpenTofu
tofu init
tofu plan
tofu apply
tofu destroy
ファイル
terraform由来の .tf または .tofu の拡張子のファイルを設定ファイルとして認識します。json形式の .tf.json または .tofu.json の拡張子のファイルも同様です。
同じディレクトリ内に.tf と .tofu の両方のファイルがあった場合、.tofu ファイルだけ認識して、.tf ファイルは無視されます。
foo.tf # <=== このファイルは無視される
foo.tofu
Registry
Terraform同様OpenTofuにもプロバイダーやモジュールのレジストリがあります。
OpenTofu Registryが登場したときに存在したTerraform Providerは反映されています。反映されていないものに関してもissueを立てれば反映されるようです
removedブロック
removedブロックは既存のリソースを削除することなく、stateから削除することができます。
それぞれ下記のように記述できます。下記の例ではAWSインスタンス自体は削除せず、stateから外すことを意図してます。
removed {
from = aws_instance.example
lifecycle {
destroy = false
}
}
removed {
from = aws_instance.example
}
Terraformではlifecyleブロックでdestroy=falseの記述が必須です。
OpenTofuではremovedブロックを書くだけで stateから削除されます。
removedブロックでやりたいことはstateから削除することなので、単純にリソースを削除したいなら対象resouceブロックを削除すればいいので、Terraformの記述方法のほうがへんな気がします。
State Encryption
Terraformでは平文でStateに保存されてしまうという問題がありましたが、OpenTofuではクライアントサイドで暗号化する機能が追加されてます。クラウドプロバイダーの KMSキーなどを利用してStateを暗号化することができます。
Terraformではたとえsopsプロバイダーで機密情報を暗号化しても、Stateファイルには平文で保存されているので権限があれば機密情報が見えてしまう状態にありました。State自体が暗号化されることにより機密情報をよりセキュアに扱えるようになります。
backendブロックの変数参照
OpenTofuではbackendブロックで変数参照ができます
variable "env" {
type = string
}
locals {
path = "${var.env}/terraform.tfstate"
}
terraform {
backend "local" {
path = local.path
}
}
tofu init -var="env=dev" -reconfigure
tofu plan -var="env=dev"
Terraformで同じことをしたい場合、-backend-configを渡さないといけないため、backendを切り替える際に不便となります。
terraform init -backend-config=./envs/dev/terraform.backend -reconfigure
terraform plan -vars-file=./envs/dev/terraform.tfvars
OpenTofu DayのLTで紹介されてた環境名だけを渡して挙動を切り替えるパターンが現状だとterraformでは使えません
バージョン管理
複数プロジェクトでTerraform or OpenTofuを使う場合、プロジェクトごとに使用バージョンを管理する必要があります。いくつか選択肢を見ていきます。
Terraformのバージョン管理ツールとしてよく使われるtfenvはOpenTofuには対応しません。
代わりにTerraformとOpenTofuに対応したtenvができました。こちらを利用すると良さそうです。
私はTerraformも合わせてプロジェクト内のツールのバージョン管理をまとめてasdfでやってますが、こちらは対応しています。
自分はあまり使わないのですが、同じようなツールのaquaやmiseも両対応しています。
Security check
Terraformだとtfsec(現 trivy config)がセキュリティチェックとして使われてるかと思います。
ディスカッションはされており優先順位をつけて対応するとのことです。
Linter
tflintはOpenTofuをサポートしないようです。
Linterの議論自体はissueで続いているようです。
CI/CD
HCP Terraform(旧Terraform Cloud)に相当するSaaSとしては、OpenTofuスポンサーのSpacelift、env0、Scalrなどがあります。
tfactions、atlantis、diggerもOpenTofuに対応している模様です。
まとめ
現時点でOpenTofuに移行するするべきか?の問については、利用者側として現状では引き続き様子見かと思います。足回りも概ね揃ってきているが、まだ足りないエコシステムもあります。
気になるところではIBM社にHashiCorp社の買収による統合完了の様子も追っていきたいところです。予定では2025年の1-3月期に統合完了するとのことなので、その後なにか動きがあるかもしれません。
とはいえ、1つのツールが使えなくなることで業務が止まるのは避けたいので常に選択肢は複数取っておきたいところです。エンジニアとしてはOpenTofuに限らず、Pulumi、CDK(AWS)なども選択肢として取っておきたいです。
それはそれとして、OpenTofuはTerraformとは違う独自進化をしているので、変更を追っていきたいところです。個人的にはState暗号化とかBackendの変数参照とかTerraformに入ってほしいです。
それでは良い豆腐ライフを!
、、、。
ここまで書いてきたのですが、minamijoyoさんのTerraform職人のためのOpenTofu再入門2024がものすごく詳しいので、この記事以上に参考になるかと思います。
参考リンク
ライセンス変更
フォーク
OpenTofuを使うために
HachiCorp買収
