• 要約
• 動機
  • 目標
  • 非ゴール
• 提案
  • ドライバー別サポート体制
    • ドライバー別サポートの構造化に反対する意見
    • ドライバによるサポートの構造化に賛成する意見
• 設計と実装の詳細
  • インポートツール
    • デザイン
      • ワンショットインポート
      • 最小ダウンタイムのインポート
  • ディストリビューション・パス
    • Omnibus
    • チャート
• 代替ソリューション
  • To-Do何もしない
    • 長所
    • 短所
  • 段階的マイグレーション
    • 長所
    • 短所

コンテナレジストリ セルフマネージドデータベースの展開

要約

コンテナレジストリの最新版は PostgreSQL データベースを使うように再構築され、GitLab.com にデプロイされました。今度は、データベースが提供する利点を自己管理ユーザーにも提供しなければなりません。コンテナレジストリは新しいデータベースなしでも動作する能力を保持していますが、多くの新機能や非常に望まれる機能はデータベースなしでは実装できません。さらに、GitLab.com とセルフマネージドで使うレジストリを統一することで、まとまりのあるユーザーエクスペリエンスを提供することができ、古いレジストリの実装をメンテナーする負担も減らすことができます。これを達成するために、最終的にはすべてのセルフマネージドに新しいレジストリデータベースへのマイグレーションを要求し、古いオブジェクトストレージメタデータサブシステムのサポートを廃止・削除する予定です。

この文書では、GitLab.com の何百万ものコンテナ・イメージのマイグレーションに使用され、実績のあるマイグレーション機能を使用して、セルフマネージド・ユーザーがメタデータ・データベースの利点を享受できるようにする方法について説明します。

動機

自己管理ユーザーが新しいメタデータ・データベースにマイグレーションできるようにすることで、これらのユーザーはデータベースを必要とする新機能を利用できるようになります。さらに、データベースの採用が進むことで、コンテナ・レジストリ・チームは知識と能力を集中させることができ、最終的には古いレジストリ・メタデータ・サブシステムを完全に削除することができるようになり、GitLab.com とセルフマネージド・ユーザーの両方にとってコンテナ・レジストリのメンテナーと安定性が大幅に向上します。

目標

• Chartおよびオムニバスのデプロイメントにおけるレジストリ用のPostgreSQLデータベースインスタンスという新しい依存関係を徐々に展開すること。
• Chartおよびオムニバスデプロイ用のレジストリPostgreSQLデータベースインスタンスの自動化を段階的にロールアウトします。
• 自己管理者が既存のレジストリデプロイをメタデータデータベースにマイグレーションするために使用できるプロセスとツールの開発。
• セルフマネージド管理者が、メタデータデータベースを使用するコンテナレジストリの新規インストールをスピンアップするために使用できるプロセスとツールを開発します。
• 最終的にオリジナルのオブジェクトストレージメタデータサブシステムのサポートを完全に停止できるようにする計画を作成します。

非ゴール

• 管理者がメタデータ・データベースにマイグレーションできるようにする範囲外の新しいコンテナ・レジストリ機能の開発者。
• いつデータベースをデフォルトにするか、いつデータベース以外のレジストリのサポートを終了するかなど、ライフサイクルサポートの決定。

提案

セルフマネジメント管理者がレジストリデータベースに移行するために、さらに開発しなければならない2つの主要なコンポーネントがあります：デプロイ環境とレジストリマイグレーションツールです。

デプロイ環境については、予想されるレジストリの作業負荷を考慮し、レジストリが適切なデータベースにアクセスできるように、ユーザーがデプロイをセットアップするために必要なことを文書化する必要があります。また、新規および既存のデプロイのためのレジストリ・データベースのセットアップとメンテナンスを容易にするツールと自動化を開発する必要があります。

レジストリについては、GitLab.com の全コンテナイメージのマイグレーションに使用されたインポート機能と連携するインポートツールを開発し、検証する必要があります。さらに、サポートされている各ストレージドライバについて、管理者向けのインポート時間の見積もりを提供する必要があります。

ベータ版の段階では、私たちが現在持っている機能、計画している機能、それらのステータス、マイグレーション体験の全体的な状態についての簡単な要約を提供するために、私たちの作業の主要な機能を強調することができます。これは、シンプルなChartを通じて自己管理ユーザーに宣伝することができ、ユーザーは一目でこのプロジェクトのステータスを知ることができ、自分のニーズやリスク許容度に対して十分な機能が揃っているかどうかを判断することができます。

これは、この設計図ではなく、コンテナレジストリ管理文書に文書化すべきです。そこにこの情報を提供することで、自己管理する管理者にとって馴染みのある場所に置くことができ、同じ文書の他のセクション、例えばガベージコレクションのセクションからの論理的な相互リンクが可能になります。

使用例：

メタデータ・データベースは、自己管理ユーザー向けの初期ベータ版です。既存のレジストリに対するマイグレーションプロセスが実装され、オンラインガベージコレクションが完全に実装されました。一部のデータベース有効化機能は GitLab.com でのみ有効であり、レジストリ・データベースの自動データベース・プロビジョニングは利用できません。コンテナ・レジストリ・データベースに関連する機能のステータスについては、以下の表をご覧ください。

ドライバー別サポート体制

インポートオペレーションは、レジストリのメタデータをデータベースに格納するために、オブジェクトストレージドライバの実装に大きく依存しています。ドライバの実装の違いが、インポート処理の性能と信頼性に大きな影響を与える可能性があります。

以下の2つのセクションでは、ドライバによるサポートの構造化に対する賛否両論を簡単にまとめます。

ドライバー別サポートの構造化に反対する意見

各ストレージドライバはコード内でうまく抽象化されており、具体的にはインポート処理で以下のメソッドを使用します：

• ウォーク
• リスト
• GetContent
• スタット
• リーダー

各メソッドは読み込みメソッドであり、オブジェクト・ストレージ・メソッドでデータを作成したり削除したりする必要はありません。さらに、これらのメソッドはすべて標準のAPIメソッドです。

インポートプロセスの一部としてオブジェクトストレージを介してデータを変更しないことを考えると、これらのドライバをダブルチェックしたり、潜在的なエラーを予測しようとしたりする必要はないはずです。ベータ期間中のユーザーからのフィードバックに頼って、私たちがここで行うべき努力を指示することで、不必要な作業をスケジューリングすることを防ぐことができます。

ドライバによるサポートの構造化に賛成する意見

オフライン・ガベージ・コレクションを強化しサポートした経験から、ストレージ・ドライバの実装は重要ではないはずですが、重要であることがわかりました。ドライバはパフォーマンスと信頼性において重要な違いがあることが証明されています。計画されているドライバ関連の改良の多くは、各ドライバのための新しい作業ではなく、テストと安定性に関連するものです。

特に、ストレージドライバ間の再試行とエラーレポーターは、期待されるほど標準化されていませんので、再試行できたはずのエラーによって、長く実行されたインポートプロセスが中断される可能性があります。

レジストリサイズとストレージドライバの組み合わせに基づいてインポートの見積もりを作成することは、マイグレーションをスケジュールしようとする自己管理管理者にとっても有益でしょう。ローカル・ファイルシステム・ストレージとオブジェクト・ストレージには違いがあり、オブジェクト・ストレージ・プロバイダーにも違いがあるかもしれません。

また、ストレージドライバの違いを滑らかにするために、インポーターと協力することもできます。ストレージドライバから統一されたリトライ可能なエラーレポートがなくても、インポーターがより多くの時間、より多くのエラーに対してリトライすることは可能です。リトライ不可能なエラーで何度もリトライするリスクはありますが、オブジェクトストレージへの書き込みは行われないので、最終的に有害になることはないはずです。

さらに、Validateセルフマネージドインポートを実装することで、インポート前とインポート後の画像のサンプルに対して一貫性チェックを行うことができ、すべてのストレージドライバの実装で一貫性を高めることができます。

設計と実装の詳細

インポートツール

インポートツールはコンテナレジストリプロジェクトで十分に検証されたコンポーネントであり、ローカルテストを行う方法として当初から使用しています。このツールは、インポート機能のコア部分を薄く包んだもので、インポートロジックを処理するコードは広範囲にわたって検証されています。

コアとなるインポート機能はしっかりしていますが、このツールとその周辺のプロセスによって、専門家ではないユーザーでも最小限のリスクとGitLabチームメンバーからの最小限のサポートでレジストリをインポートできるようにしなければなりません。そのため、残された最も重要な作業は、これらの目標が達成されるようにこのツールの UX を作り上げることです。このエピックは、提案されている改善点の多くを捉えています。

デザイン

このツールは、単一の実行フローで、リードオンリーの時間を極限まで短縮するためにより複雑なプロセスを利用できる、アップタイム要件が厳しい大規模レジストリのユーザーと、合理化されたワークフローの恩恵を受ける小規模レジストリのユーザーの両方をサポートできるように設計されています。これは、GitLab.comで使われていたのと同じプレインポート、フルインポートのサイクルに加え、共通ストレージに保持されている参照されていないブロブをすべてカタログ化する追加ステップによって実現されます。

ワンショットインポート

ほとんどの場合、ユーザーはレジストリがオフラインまたは読み取り専用モードになっている間にインポートツールを実行することを選択できます。これは、オフラインのガベージコレクションを実行するために管理者がすでに行わなければならないことと似ています。各ステップは順番に完了し、直接次のステップに移ります。インポートプロセスが完了し、レジストリがメタデータデータベースをフルに使用できるようになると、コマンドは終了します。

最小ダウンタイムのインポート

For users with large registries and who are interested in the minimum possible downtime, each step can be ran independently when the tool is passed the appropriate flag. The user will first run the pre-import step while the registry is performing its usual workload. Once that has completed, and the user is ready to stop writes to the registry, the tag import step can be ran. As with the GitLab.com migration, importing tags requires that the registry be offline or in read-only mode. This step does the minimum possible work to achieve fast and efficient tag imports and will always be the fastest of the three steps, reducing the downtime component to a fraction of the total import time. The user can then bring up the registry configured to use the metadata database. After that, the user is free to run the third step during standard registry operations. This step makes any dangling blobs in common storage visible to the database and therefore the online garbage collection process.

ディストリビューション・パス

メタデータ・データベースの使用を希望するユーザーをサポートするために、特にマイグレーションに必要な新しいデータベース・インスタンスの基盤を提供することに関して、ツール、プロセス、文書を開発する必要があります。

新しいデプロイについては、一般サポートに移行し、レジストリデータベースとマイグレーションのための自動化を整備し、GitLabのメジャーバージョンアップを待ってから、デフォルトでデータベースをセルフマネジメントできるようにすべきです。

Omnibus

チャート

代替ソリューション

To-Do何もしない

長所

• データベースと関連機能は、一般的に大規模で高可用性のデプロイに最も役立ちます。
• 自己管理型のデプロイでは、追加の論理データベースまたは物理データベースをサポートする必要がなくなります。

短所

• GitLab.comのレジストリとセルフマネージドで使われるレジストリは、時間の経過とともにサポートされる機能が大きく異なります。
• 二つのレジストリ実装をサポートすることによるメンテナンスの負担は、レジストリの新機能をリリースする速度を低下させるでしょう。
• GitLab.com上のレジストリは、自己管理にリリースする前に変更を検証する効果的な方法ではなくなってしまいます。
• 大規模なセルフマネージドユーザーは、ニーズに合わせてレジストリを拡張することができません。

段階的マイグレーション

このアプローチは、GitLab.comのマイグレーションをセルフマネージドで正確に再現するものです。

長所

• すでに成功しているプロセスを複製。
• インスタンスではなくリポジトリ単位でダウンタイムをスコープします。

短所

• マイグレーションプロセスのあらゆる面で複雑さが劇的に増加。
• データの整合性に問題が生じる可能性が大幅に増加。
• レジストリマイグレーションの進捗状況の明確な区分けが困難。