第6章 Red Hat Quay によるコンテンツ配信
Red Hat Quay のコンテンツ配信機能は以下のとおりです。
6.1. Red Hat Quay とのミラーリング リンクのコピーリンクがクリップボードにコピーされました!
外部レジストリーからイメージを Red Hat Quay クラスターにミラーリングし、リポジトリー名または組織名とタグで同期するには、リポジトリーミラーリングを使用できます。
ミラーリングが有効になっている Red Hat Quay クラスターから、以下の操作を実行できます。
- 外部レジストリーからミラーリングするリポジトリーまたは組織を選択してください。
- 外部レジストリーにアクセスするための認証情報を追加する
- 同期する特定のコンテナーイメージリポジトリーまたは組織名とタグを指定します。
- リポジトリーまたは組織の同期間隔を設定します。
- 同期の現在の状態を確認する
- ミラーリングされているアーキテクチャーをフィルタリングする
ミラーリング機能を使用するには、次のアクションを実行する必要があります。
- Red Hat Quay の設定ファイルでミラーリングを有効にする
- ミラーリングワーカーを実行する
- ミラーリングされたリポジトリーを作成する
ミラーリングの設定はすべて、設定ツールの UI または Red Hat Quay API を使用して実行できます。
6.1.1. ミラーリングを使用する リンクのコピーリンクがクリップボードにコピーされました!
異なる環境間でコンテナーイメージを自動的に同期するには、Red Hat Quay リポジトリーまたは組織のミラーリングを設定してください。この機能でサポートされている機能と制限事項を確認することで、レジストリー同期アーキテクチャーを適切に計画できます。
以下のリストは、リポジトリーまたは組織に対する Red Hat Quay ミラーリングの機能と制限事項を示しています。
ミラーリングに関するドキュメントでは、エンティティー という言葉はリポジトリーまたは組織のいずれかを指すために使用されています。
- ミラーリング機能を使用すると、エンティティー全体をミラーリングすることも、同期するイメージを選択的に制限することもできます。フィルターは、コンマ区切りのタグのリスト、タグの範囲、または Unix シェルスタイルのワイルドカードを使用してタグを識別するその他の手段に基づくことができます。詳細は、ワイルドカード のドキュメントを参照してください。
- エンティティーのミラーリングを設定した後は、そのエンティティーに他のイメージを手動で追加することはできません。
- ミラーリングされたエンティティーは、設定したエンティティーとタグに基づいて作成されるため、エンティティーには、エンティティーとタグのペアによって表されるコンテンツのみが含まれます。たとえば、タグを変更してエンティティー内の一部のイメージが一致しなくなった場合、それらのイメージは削除されます。
- 指定されたロボットのみがミラーリングされたエンティティーにイメージをプッシュすることができ、エンティティーに設定されているロールベースのアクセス制御権限はすべて無効になります。
- ミラーリングは、障害時にロールバックする、または ベストエフォートベースで実行するように設定できます。
- ミラーリングされたエンティティーの場合、読み取り 権限を持つユーザーはエンティティーからイメージを取得することはできますが、エンティティーにイメージをプッシュすることはできません。
- ミラーリングされたエンティティーの設定を変更するには、Red Hat Quay のユーザーインターフェイスを使用します。
- イメージは一定の間隔で同期されますが、必要に応じて同期することもできます。
現在の組織レベルのリポジトリーミラーリングの実装では、Red Hat Quay はソースレジストリーからの削除を複製しません。以下のエンティティーのいずれかがアップストリームソースから削除または欠落した場合、それらはローカルの Quay ミラーに保持されます。
- ソースネームスペースまたは組織とそのリポジトリー。上流のソースネームスペース全体 (たとえば、Harbor プロジェクトや Quay 組織など) が削除された場合でも、以前にミラーリングされていたすべてのリポジトリーとそのコンテンツはローカルミラーに残ります。
- 個別のリポジトリー。以前に検出され同期されたリポジトリーは、たとえ上流ソースから削除されたとしても、引き続き追跡され、提供されます。
- イメージタグ。前回の同期時に存在していたタグは、上流で削除された場合でもミラーに保持されます。
- 紹介者。OCI Referrers API のアーティファクト (Cosign 署名や SBOM など) は、現在ミラーリングされていません。ローカルに存在する場合、自動的にクリーンアップされません。
下流側のミラーは累積アーカイブとして機能する。上流の名前空間が空になったり、そのリポジトリーやタグが削除されたりした場合でも、ミラーはそれらのオブジェクトの最後に正常に同期されたバージョンを提供し続けます。これにより、ミラー側のストレージ消費量がソース側よりも高くなる可能性があります。
注記注: この動作はリポジトリーレベルのミラーリングとは異なります。リポジトリーレベルのミラーリングでは、ソースレジストリーに存在しなくなったローカルタグが自動的に削除されます。
これらのエンティティーをミラーから削除するには、Red Hat Quay の UI または API を介した手動削除が必要です。今後のリリースでは、ローカルミラーから組織、リポジトリー、タグ、リファラー、マニフェストリストの子要素など、存在しない項目を自動的に削除する設定可能なオプションが導入される予定です。
6.1.2. リポジトリーのミラーリングの推奨事項 リンクのコピーリンクがクリップボードにコピーされました!
リポジトリーミラーリングのベストプラクティスには次のようなものがあります。
- リポジトリーミラーリング Pod は任意のノードで実行できます。これは、Red Hat Quay がすでに実行されているノードでミラーリングを実行できることを意味します。
- リポジトリーのミラーリングは、データベースでスケジュールされ、一括して実行されます。その結果、リポジトリーワーカーは各リポジトリーミラー設定ファイルをチェックし、次の同期が必要なタイミングを読み取ります。ミラーワーカーが増えると、より多くのリポジトリーを同時にミラーリングできるようになります。たとえば、10 個のミラーワーカーを実行すると、ユーザーは 10 個のミラーリング Operator を並行して実行できることになります。ミラー設定が 10 個あるワーカーが 2 つしかない場合に、実行できる Operator は 2 つのみです。
ミラーリング Pod の最適な数は、次の条件によって異なります。
- ミラーリングされるリポジトリーの合計数
- リポジトリー内のイメージやタグの数と変更の頻度
並列バッチ処理
たとえば、タグが 100 個あるリポジトリーをミラーリングしている場合に、このミラーは 1 つのワーカーで完了されます。ユーザーは、並行してミラーリングするリポジトリーの数を検討し、それに基づいてワーカーの数を決定する必要があります。
同じリポジトリー内の複数のタグを並行してミラーリングすることはできません。
6.1.3. ミラーリングのイベント通知 リンクのコピーリンクがクリップボードにコピーされました!
リポジトリーミラーリングには、3 つの通知イベントがあります。
- リポジトリーミラーリングの開始
- リポジトリーのミラーリングの成功
- リポジトリーミラーリングの失敗
イベントは各リポジトリーの Settings タブ内で設定でき、電子メール、Slack、Quay UI、Webhook などの既存の通知方法がすべてサポートされています。
6.1.4. ミラーリング API リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Quay API を使用して、リポジトリーミラーリングを設定できます。
ミラーリング API
詳細は 、Red Hat Quay API ガイド を参照してください。