第12章 アップストリームレジストリーのプロキシーキャッシュとしての Red Hat Quay
コンテナー開発の人気が高まるにつれ、お客様はサービスを稼働させるために Docker や Google Cloud Platform などのアップストリームレジストリーからのコンテナーイメージにますます依存するようになっています。現在、レジストリーにはレート制限があり、ユーザーがこれらのレジストリーからプルできる回数が制限されています。
この機能により、Red Hat Quay は、アップストリームレジストリーからのプルレート制限を回避するためのプロキシーキャッシュとして機能します。キャッシュ機能を追加すると、アップストリームの依存関係ではなくキャッシュからイメージがプルされるため、プルのパフォーマンスも向上します。キャッシュされたイメージは、アップストリームのイメージダイジェストがキャッシュされたイメージと異なる場合にのみ更新され、レート制限と潜在的なスロットリングを削減します。
Red Hat Quay キャッシュプロキシーを使用すると、次の機能が利用可能になります。
- 特定の組織は、アップストリームレジストリーのキャッシュとして定義できます。
特定のアップストリームレジストリーのキャッシュとして機能する Quay 組織の設定。このリポジトリーは、Quay UI を使用して定義でき、次の設定を提供します。
- プライベートリポジトリーのアップストリームレジストリークレデンシャルまたはレート制限の強化。
- キャッシュ組織のサイズを超えないようにするための有効期限タイマー。
- 設定アプリケーションを介して設定可能なグローバルオン/オフ。
-
アップストリームレジストリー全体または単一の名前空間 (たとえば、すべての
docker.ioまたは単にdocker.io/libraryのキャッシュ。 - すべてのキャッシュプルのログ。
- Clair によるキャッシュイメージのスキャン可能性。
12.1. プロキシーキャッシュアーキテクチャー
次のイメージは、プロキシーキャッシュ機能の予想される設計フローおよびアーキテクチャーを示しています。
ユーザーが Red Hat Quay のアップストリームリポジトリーからイメージ (postgres:14 など) をプルすると、リポジトリーはイメージが存在するかどうかを確認します。イメージが存在しない場合は、新しいプルが開始します。プルされた後、イメージレイヤーはキャッシュに保存され、サーバーに並行してユーザーに提供されます。次のイメージは、このシナリオのアーキテクチャーの概要を示しています。
キャッシュ内のイメージが存在する場合、ユーザーは Quay のキャッシュを利用してアップストリームソースを最新の状態に保ち、キャッシュから新しいイメージが自動的にプルされるようにできます。これは、元のイメージのタグがアップストリームレジストリーで上書きされた場合に発生します。次のイメージは、アップストリームイメージとキャッシュされたバージョンのイメージが異なる場合に何が起こるかを示すアーキテクチャーの概要を示しています。
アップストリームイメージとキャッシュされたバージョンが同じである場合、レイヤーはプルされず、キャッシュされたイメージがユーザーに配信されます。
場合によっては、アップストリームレジストリーがダウンしたときにユーザーがプルを開始します。設定された失効期間でこれが発生した場合は、キャッシュに保存されたイメージが配信されます。設定された失効期間の後にプルが発生すると、エラーはユーザーに伝播されます。次のイメージは、設定された失効期間の後にプルが発生した場合のアーキテクチャーの概要を示しています。
Quay 管理者は、組織の設定可能なサイズ制限を利用してキャッシュサイズを制限できるため、バックエンドストレージの消費量を予測できます。これは、イメージが使用される頻度に応じてキャッシュからイメージを破棄することで実現されます。次のイメージは、このシナリオのアーキテクチャーの概要を示しています。
