最初の安定版リリースに向けた最終段階であるOpenTofu v1.6.0-rc1が本日公開されました。これは、年末年始休暇明けの2024年1月10日に予定されている一般提供リリースに向けて、アルファ版とベータ版のリリースに続くものです。
このリリースには、バグ修正、安定性の向上、ドキュメントの更新が含まれています。重要なのは、このバージョンでは、3週間前にv1.6.0-beta1リリースでデビューし、OpenTofuコミュニティのアーリーアダプターによって広範にテストされてきた、新しいパブリックレジストリの安定性が強調されていることです。
アイデアからリリース候補版まで4ヶ月
OpenTofuの旅は、提案からリリース候補版までわずか4か月という、旋風のような道のりでした。
これは私たちにとって大きなマイルストーンですが、同時にほろ苦い瞬間でもあります。私たちの旅の始まりを振り返ってみると、HashiCorpが私たちの訴えに耳を傾け、決定を覆し、エコシステムのバランスを取り戻してくれるという希望がありました。
しかし、私たちはここにいます…そして、最初の数週間の驚き、希望、そして失望の後で起こったすべてのことハ、コラボレーションのケーススタディとしてしか特徴づけることができません。仲間、コミュニティ、そして競合他社がすべて団結して、Infrastructure-as-Codeのためのオープンソースオプションを維持するために協力しました。
これまでの主要なマイルストーンを振り返ってみましょう。
12月18日現在、OpenTofuは31,000ダウンロードを突破し、60人のコミッターが参加し、1,000件以上のプルリクエストとイシューが寄せられています。プロジェクトのメインリポジトリは、マニフェストの36,200以上のGitHubスターに加えて、16,450以上のGitHubスターを獲得しています。
さて、それでは本題に入りましょう。
レジストリの課題
OpenTFフォークが発表された瞬間から、新しいパブリックレジストリが必要になることは明らかでした。利用規約の変更後、Terraform以外のプロジェクトではアクセスできなくなったTerraformレジストリのオープンソース代替品です。
機能的には前身と似ていますが、この新しいレジストリは、OpenTofuで使用されるすべてのプロバイダーとモジュールのための、可用性の高いパッケージ解決サービスでなければなりませんでした。さらに、以下のようないくつかの具体的な基準を満たす必要がありました。
- レジストリは可能な限り自立し、メンテナンスを最小限に抑える必要があります。
- 需要の増加を見越し、高可用性とスケーラビリティを考慮して構築する必要がありました。
- 「ドロップイン置換」アプローチに従い、HashiCorpのレジストリからスムーズに移行できる必要があります。
- 何を選んだとしても、オープンソースでなければなりませんでした。
共に醸造する
Homebrewは、APKやRPMがLinuxに、Chocolatey/WingetがWindowsにあるように、macOSの事実上の標準パッケージマネージャーです。そのシンプルな性質、コアとなるオープンソースのパッケージデータベース、そしてアプリケーションのパッケージ化効率は、私たちのニーズに理想的な何かをインスパイアし、その人気はスケーラビリティの証となりました。
私たちがこれについて議論していたとき、14年以上もそのプロジェクトに取り組んできたHomebrewのリーダーであるMike McQuaid氏が私たちの会話に気づき、リポジトリ構造についての有益な洞察を提供してくれました。
私にとって、この経験はオープンソースの概念の重要性を強調し、その本質的に協調的な性質がなければ、そのような関わりはほとんどないだろうということを思い出させてくれました。
この本能的で抑制のない仲間意識こそが、オープンソースの真髄です。
実装
Mike氏のアドバイスの中で、パフォーマンスを向上させるためにリポジトリを断片化するというものがありました。
「私たちは最近、「シャーディング」プロセスを経て、最大のリポジトリにあるformulae/casksをサブディレクトリに分割しました…この形式では「git」のパフォーマンスが劇的に向上します。」
それに続いて、レジストリ(https://registry.opentofu.org)を、名前空間ごとにアルファベット順に分類されたサブディレクトリのコレクションとして構築しました。これらは、GitHubで現在利用可能なすべてのプロバイダーとモジュールからの情報でハイドレートされ、それぞれがメタデータやその他の詳細を含む独自のJSONファイルを持っています。
重要なのは、静的ファイルを使用し、Cloudflare R2 パブリックバケットでホスティングすることで、CDN機能を最大限に活用できることです。これにより、94%を超えるキャッシュヒット率でパフォーマンスと高可用性が確保されます(この点に関して、このプロジェクトをスポンサーしてくださったCloudFlareに大変感謝いたします!)。
私たち自身のテスト以外で、最もリクエストの多かった4つのファイルは次のとおりです。
/.well-known/terraform.json
/v1/providers/hashicorp/null/versions
/v1/providers/hashicorp/template/versions
/v1/providers/hashicorp/aws/versions
レジストリが稼働状態になったので、インデックス付きリソースの更新をスキャンするための GitHubアクション を設定しました。また、新しいプロバイダーを追加するための IssueOpsプロセス も導入しました。これにより、新しい申請はレジストリに登録されると自動的に処理および検証され、Issueによってコンテキストと透明性が提供されます。
現在、パッケージとドキュメントを閲覧するための専用のUIを検討しています。
次のステップ:1月10日
年末年始の休暇シーズンを迎え、まずはリリース候補版を公開し、正式リリース(GA)を1月10日に予定することにしました。一方で、こちらの手順 に従うだけで、OpenTofuのテストをすでに開始できます。ドロップイン型の代替品であるため、Terraformユーザーはすぐに使いこなせるはずです。それがまさに狙いです。
プロジェクトへの貢献に興味がある方は、コントリビューションガイドライン をご確認いただき、Slackコミュニティ にもぜひご参加ください。
ハッピーホリデー!
追伸
この投稿と今後のリリースに関する作業を締めくくっている際に、HashiCorpの伝説的な共同創設者であるMitchell Hashimoto氏が、11年間在籍した同社を退社することを発表したことを知りました。
Vagrant、Consul、Vault、そしてもちろんTerraformといったプロジェクトにおけるMitchell氏の功績は、私たちやオープンソースコミュニティの多くの人々にとって、インスピレーションの源となっています。
OpenTofuチーム一同、Mitchell氏の数々の貢献に心から感謝するとともに、彼のすでに素晴らしい道のりの次のステップについて知るのを楽しみにしています。