OpenTFリポジトリが公開されました

 (github.com/opentffoundation)
1 ポイント 投稿者 GN⁺ 2023-09-06 | 1件のコメント | WhatsAppで共有
  • OpenTofu は、インフラを安全かつ効率的に構築・変更・バージョン管理するための OSS ツール
  • 既存の人気サービスプロバイダーと 社内向けカスタムソリューション の両方を管理可能
  • インフラを高水準の設定構文で記述する Infrastructure as Code 方式を採用し、データセンターの設計図をコードのようにバージョン管理し、共有・再利用できる
  • apply を呼び出す前に実行計画を生成する planning 段階を提供し、OpenTofu がインフラに対して実行する作業を事前に確認できる
  • すべてのリソースの Resource Graph を作成し、依存関係のないリソースの作成・変更を並列化することで、インフラ依存関係の可視性を提供する
  • 複雑な変更セットを最小限の人手介入で適用でき、実行計画とリソースグラフを通じて、何をどの順序で変更するかを確認可能
  • main の最新変更をテストするための Nightly Builds が提供されており、実験的ビルドであって本番利用向けではない
  • セキュリティ脆弱性または潜在的脆弱性は、Security Policy に従って報告する方式
  • 特定の原産国のレジストリアクセスを遮断しており、詳細は Registry Inclusion Policy に従う
  • ライセンスは Mozilla Public License v2.0

関連記事

1件のコメント

 
GN⁺ 2023-09-06
Hacker News のコメント

  • 多くの要望どおり、ついにリポジトリを公開し、今後は公開の場で開発を続ける予定です
    少し時間がかかりましたが、詳細は発表文で確認できます: https://opentf.org/fork
    これまでの支援に感謝します。リポジトリで議論に参加したり、貢献してもらえればと思います
    HN でもかなり議論されていた貢献方式は DCO に決まりました: https://developercertificate.org
    質問があれば答えられます。Spacelift で働いており、委員会主導に移行するまで OpenTF Project の暫定 Technical Lead を務めています

  • この一連の流れはかなり見事だと思います。HashiCorp は、ライセンスが「プロジェクト」そのものではなくプロジェクトのバージョンに付くことをよく理解しており、それをエンタープライズ製品の収益最大化に活用しました
    コミュニティ側も、いったん特定のバージョンにライセンスを付けると元には戻せないことを理解していましたし、そのライセンスが適用された時点からフォークして、バージョンごとに独自の「新しい」プロジェクトを作れば、オープンソースのまま維持できることも分かっていました
    今後どう展開するのか興味深く、将来のソフトウェアライセンスのケーススタディになりそうです。OpenTF が長期的にどうなるのか楽しみです

    • コミュニティへの影響と対応という面では、Hudson と Jenkins の分離に最も近いように見えます。ライセンス面は違いますが: https://en.wikipedia.org/wiki/Hudson_(software)
      こういう出来事には Oracle がほぼ必ず絡んでいる気がしますが、Terraform では意外にもそうではありませんでした :D
    • 「プロジェクトのバージョンに付いたライセンス」と「プロジェクト自体に付いたライセンス」を区別する理由はありません。HashiCorp には今後のライセンスを変更する権利があり、誰にでも以前のバージョンを使い続けたりフォークしたりする権利がありました。実際、ここでそうなったということです
    • 歴史的には Hudson/Jenkins のコードベースを見てみるのも興味深いかもしれません

  • 「名称について複数の法律専門家に相談中で、『TF』の使用により OpenTF も最終的な名称ではない可能性がある」とのことです
    名前に TF が入るだけで問題になり得るというのは興味深いです
    出典: https://github.com/opentffoundation/opentf/issues/273#issuecomment-1706947318

    • ここで潜在的な論点は文字商標だと知りました
      詳細は https://en.wikipedia.org/wiki/Wordmark を参照
      env0 の創業者であり、OpenTF イニシアチブを共同で主導しています
    • 最初から terraform ではなく xenoform にすべきだったと思っていました。たとえば OpenXenoform と xf コマンドのような形です
    • 似た理由で YP は NIS になりました
      https://en.wikipedia.org/wiki/Network_Information_Service

  • 2つお願いしたいことがあります。まず、モジュールとプロバイダーの両方に対応するスタンドアロンのレジストリパッケージを提供してほしいです。知っているのは Artifactory だけですが、Nexus を使っている環境で、さらに大きなリポジトリソフトウェアを動かしたくはありません
    2つ目も関連していますが、プロバイダーモジュールをもっと簡単にフォークできるようにしてほしいです。今のようにローカルでビルドして同僚にバイナリを手動コピーして配布したり、特にアップストリームが CLA 署名を求める場合に PR が受け入れられるのを待ったりするやり方はあまりよくありません

    • 1つ目の要望をもう少し説明してもらえますか？ 個人用のプロバイダー/モジュールレジストリを動かせる自己完結型バイナリが欲しいということなら、そのようなオープンソースプロジェクトはいくつかありますし、DockerHub や GitHub Container Registry のような OCI レジストリ経由でプロバイダーを配布する方式の概念実証も行いました
      このユースケースには OCI レジストリがかなりよく合います: https://twitter.com/opentforg/status/1696913055576387599
      この概念実証は近く公開 RFC につながる予定です
      2つ目の要望については、想定している理想的なワークフローがあるのか気になります
      Spacelift で働いており、委員会主導に移行するまで OpenTF Project の暫定 Technical Lead を務めています

  • “terrafork” にすべきでした

  • いいですね。テストできるようになるのを https://github.com/opentffoundation/roadmap/issues/8 で待っています
    ソースからビルドすることはできますが、できればリリースビルドを使いたいです

  • ざっと見たところ、ドキュメントは素晴らしそうです。Terraform の内部構造を少し扱ったことがある立場から見ると、このコードベースで作業しようとする開発者にとってはかなり大きな改善に見えます
    始めるのに適した全体概要を提供してくれています。よくやりました

    • どのドキュメントのことを指しているのか正確には分かりませんが、ほとんどのドキュメントは元のリポジトリから商標関連の部分を除けば大きく変わっていません
      ドキュメントが良くなったのなら、その功績は Terraform Core の開発者たちに帰すべきです
      Spacelift で働いており、委員会主導に移行するまで OpenTF Project の暫定 Technical Lead を務めています

  • 完全に余談ですが、ロゴが暗い背景上で濃い青なので、かなりぎこちなく見えます
    白いアウトラインも十分に太くないため、暗い背景と重なるとピクセルが目立って見えます

    • 確かに些細なデザイン論争ではありますが、TensorFlow のロゴのようにも見えて、一瞬 Google からプロジェクトを独立させるグループなのかと思いました

  • このコードベースが、最後に「使い続けても問題ない」Terraform ライセンスのコミットと比べてどう違うのか、差分を持っている人はいますか？
    新しいライセンスをめぐる論争と変更のために、実際に何を変える必要があったのかがよく分かりません

  • GitHub ページのロゴは、暗い背景では改善が必要に見えます。特に暗い文字に明るいアウトラインが付きますが、アルファのにじみのように見え、ジャギーが残っています