Red Hat Quay アーキテクチャー

Red Hat Quay で使用されるコードベースは、Red Hat によってホストされる高可用性コンテナーイメージレジストリーである Quay.io で使用されるコードベースと同じです。Quay.io と Red Hat Quay は、マルチテナント SaaS ソリューションを提供します。その結果、導入環境がオンプレミスであってもパブリッククラウド上であっても、確信を持って、高可用性を備えた大規模なデプロイメントを行うことができます。

Red Hat Quay のコンテンツ配布機能には次のものが含まれます。

Red Hat Quay は、OpenShift Container Platform または Kubernetes プラットフォーム上の一連のワーカーノードを使用した Dockerfile の構築をサポートします。GitHub Webhook などのビルドトリガーを設定することで、新しいコードがコミットされたときに自動的に新しいバージョンのリポジトリーを構築できます。

Red Hat Quay 3.7 より前は、Red Hat Quay は Pod によって起動された仮想マシンで Podman コマンドを実行していました。仮想プラットフォーム上でビルドを実行するには、ネストされた仮想化を有効にする必要がありますが、これは Red Hat Enterprise Linux (RHEL) や OpenShift Container Platform には搭載されていません。その結果、ビルドはベアメタルクラスター上で実行する必要があり、リソースの使用が非効率になってしまいます。Red Hat Quay 3.7 では、この要件が削除され、仮想化プラットフォームまたはベアメタルプラットフォームで実行されている OpenShift Container Platform クラスター上でビルドを実行できるようになりました。

以下のイメージは、拡張ビルド機能の想定される設計フローとアーキテクチャーを示しています。

この機能拡張により、ビルドマネージャーは最初に Job Object を作成します。次に、Job Object は quay-builder-image を使用して Pod を作成します。quay-builder-image には、quay-builder binary サービスおよび Podman サービスが含まれます。作成された Pod は unprivileged として実行されます。次に、quay-builder binary は、ステータスを通知してビルドマネージャーからビルド情報を取得しつつ、イメージをビルドします。

Red Hat Quay は、ほぼすべての Git 互換システムと統合できます。Red Hat Quay は、GitHub、GitLab、または BitBucket の自動設定を提供し、ユーザーがコンテナー化されたソフトウェアを継続的に構築して提供できるようにします。

Red Hat Quay は、コンテンツガバナンスとセキュリティーが 2 つの主要なフォーカスエリアである実際のエンタープライズユースケース向けに構築されます。

Red Hat Quay のコンテンツガバナンスとセキュリティーには、Clair を介した組み込みの脆弱性スキャンが含まれています。

最新の機能、機能拡張、非推奨の機能、既知の問題に関する情報については、Red Hat Quay リリースノート を参照してください。

Red Hat Quay は、すべてのバイナリーブロブをストレージバックエンドに格納します。

Red Hat Quay は、設定情報を config.yaml ファイルに保存します。ユーザー情報、ロボットアカウント、チーム、権限、組織、イメージ、タグ、マニフェストなどのレジストリーメタデータは、データベースバックエンド内に保存されます。必要に応じて、ログを ElasticSearch にプッシュできます。PostgreSQL は Red Hat Quay と Clair の両方で使用できるため、データベースバックエンドとして推奨されます。

データベースバックエンドとして MySQL および MariaDB を使用するサポートは、Red Hat Quay 3.6 リリース以降非推奨となっていましたが、Red Hat Quay の今後のバージョンで削除されます。それまでは、MySQL は サポートマトリックス に従って引き続きサポートされますが、追加機能や明示的なテスト対象範囲は提供されません。Red Hat Quay Operator は、データベースを管理している場合に、PostgreSQL デプロイメントのみをサポートします。MySQL を使用する場合は、それを手動でデプロイし、データベースコンポーネントを managed: false に設定する必要があります。

Red Hat Quay を高可用性 (HA) 設定でデプロイするには、データベースサービスが高可用性向けにプロビジョニングされている必要があります。Red Hat Quay がパブリッククラウドインフラストラクチャー上で実行している場合は、クラウドプロバイダーが提供する PostgreSQL サービスを使用することを推奨しますが、MySQL もサポートされています。

Geo レプリケーションには、すべてのリージョンからアクセス可能な共有データベースが 1 つ必要です。

Red Hat Quay は Redis キャッシュ内にビルダーログを保存します。保存されるデータは一時的なものであるため、Redis はステートフルであっても高可用性を必要としません。

Redis に障害が発生すると、ビルドログ、ビルダー、ガベージコレクターサービスにアクセスできなくなります。また、ユーザーイベントも利用できなくなります。

Red Hat Software Collections、またはその他の任意のソースから Redis イメージを使用できます。

Ansible または別の自動化スイートを使用して、スタンドアロンデプロイメントプロセスを自動化できます。すべてのスタンドアロンホストには、有効な Red Hat Enterprise Linux (RHEL) サブスクリプションが必要です。

Red Hat Quay Operator for OpenShift Container Platform は、以下の機能を提供します。

Red Hat Quay は、OpenShift Container Platform インフラストラクチャーノード上で実行できます。そのため、それ以上のサブスクリプションは必要ありません。OpenShift Container Platform 上で Red Hat Quay を実行すると、次の利点があります。

Red Hat Quay Operator は、OpenShift Container Platform 上で実行される Red Hat Quay のシームレスなデプロイメントと管理を保証しますが、Red Hat Quay をスタンドアロンモードで実行し、実行されている場所に関係なく、1 つまたは複数の OpenShift Container Platform クラスターにコンテンツを提供することもできます。

以下のような、Red Hat Quay のスタンドアロンおよび Operator ベースのデプロイメントを OpenShift Container Platform と統合するのに役立つ Operator がいくつか用意されています。

Red Hat OpenShift 導入用のミラーレジストリーは、Red Hat Quay の小規模バージョンであり、切断されたインストール用の OpenShift Container Platform の必要なコンテナーイメージをミラーリングするためのターゲットとして使用できます。

OpenShift Container Platform の切断されたデプロイメントの場合に、クラスターのインストールを実行するためにコンテナーレジストリーが必要です。このようなクラスターで実稼働レベルのレジストリーサービスを実行するには、別のレジストリーデプロイメントを作成して最初のクラスターをインストールする必要があります。Red Hat OpenShift 導入用のミラーレジストリー は、このニーズに対応し、すべての OpenShift Container Platform サブスクリプションに含まれています。これは、OpenShift コンソールの ダウンロード ページからダウンロードできます。

Red Hat OpenShift 導入用のミラーレジストリー を使用すると、ユーザーは、mirror-registry コマンドラインインターフェイス (CLI) ツールを使用して、Red Hat Quay の小規模バージョンとその必要なコンポーネントをインストールできます。Red Hat OpenShift 導入用のミラーレジストリー は、事前設定されたローカルストレージとローカルデータベースを使用して自動的にデプロイされます。また、このレジストリーには、自動生成されたユーザー認証情報とアクセス許可も含まれており、単一の入力セットを使用するだけで開始でき、追加の設定を選択する必要はありません。

Red Hat OpenShift のミラーレジストリー は、事前に決定されたネットワーク設定を提供し、成功時にデプロイされたコンポーネントの認証情報とアクセス URL を報告します。完全修飾ドメイン名 (FQDN) サービス、スーパーユーザー名とパスワード、カスタム TLS 証明書などのオプションの設定入力のセットも少しだけ含まれています。これにより、ユーザーはコンテナーレジストリーを利用できるため、制限されたネットワーク環境で OpenShift Container Platform を実行するときに、すべての OpenShift Container Platform リリースコンテンツのオフラインミラーを簡単に作成できます。

Red Hat OpenShift 導入用のミラーレジストリー は、リリースイメージや Operator イメージなど、切断された OpenShift Container Platform クラスターのインストールに必要なイメージのホスティングに限定されます。ローカルストレージを使用します。お客様が作成したコンテンツは、Red Hat OpenShift のミラーレジストリー でホストしないでください。

Red Hat Quay とは異なり、Red Hat OpenShift のミラーレジストリー は高可用性レジストリーではありません。ローカルファイルシステムストレージのみがサポートされます。クラスターのグループの更新時にクラスターが複数あると単一障害点を生み出す可能性があるため、複数のクラスターで Red Hat OpenShift のミラーレジストリー を使用することは推奨しません。Red Hat OpenShift のミラーレジストリー を使用して、OpenShift Container Platform コンテンツを他のクラスターに提供できる Red Hat Quay などの実稼働グレードの高可用性レジストリーをホストできるクラスターをインストールすることを推奨します。

詳細は、Red Hat OpenShift のミラーレジストリー を使用したミラーレジストリーの作成 を参照してください。

多くのユーザーは、複数の個別のレジストリーを実行することを検討しています。Red Hat Quay で推奨されるアプローチは、単一の共有レジストリーを持つことです。

要約すると、共有レジストリーを実行すると、ストレージ、インフラストラクチャー、および運用コストを節約できますが、特定の状況では専用のレジストリーが必要になる場合があります。

以下の図は、Red Hat Quay の 3 つの可能なデプロイメントを示しています。

以下の図は、Red Hat Quay デプロイメントトポロジーの概要を示しています。

このデプロイメントでは、パブリック Red Hat Quay エンドポイントによって、すべてのプッシュ、ユーザーインターフェイス、および API リクエストを受け取ります。プルは object storage から直接提供されます。

以下の図は、ストレージプロキシーが設定された Red Hat Quay デプロイメントトポロジーの概要を示しています。

ストレージプロキシーが設定されている場合、すべてのトラフィックはパブリック Red Hat Quay エンドポイントを通過します。

Red Hat Quay が Amazon Web Services (AWS) 上で実行されている場合は、次の機能を使用できます。

次の図は、AWS 上で実行されている Red Hat Quay の概要を示しています。

Red Hat Quay が Microsoft Azure 上で実行されている場合は、次の機能を使用できます。

次の図は、Microsoft Azure 上で実行される Red Hat Quay の概要を示しています。

Red Hat Quay リポジトリーミラーリングを使用すると、外部コンテナーレジストリー (または別のローカルレジストリー) から Red Hat Quay クラスターにイメージをミラーリングできます。リポジトリーミラーリングを使用すると、リポジトリー名とタグに基づいてイメージを Red Hat Quay に同期できます。

リポジトリーのミラーリングが有効になっている Red Hat Quay クラスターから、以下を実行できます。

ミラーリング機能を使用するには、次のアクションを実行する必要があります。

すべてのリポジトリーのミラーリング設定は、設定ツール UI または Red Hat Quay API を使用して実行できます。

Geo レプリケーションでは、地理的に分散した複数の Red Hat Quay デプロイメントを、クライアントやユーザーの視点から、単一のレジストリーとして動作させることができます。グローバルに分散された Red Hat Quay のセットアップにおいて、プッシュとプルのパフォーマンスが大幅に向上します。イメージデータはバックグラウンドで非同期的に複製され、クライアントには透過的なフェイルオーバー/リダイレクトが行われます。

Geo レプリケーションを使用した Red Hat Quay のデプロイメントは、スタンドアロンおよび Operator デプロイメントでサポートされます。

Red Hat Quay の Geo レプリケーションは、データベースが共有されている間に、2 つ以上の異なるストレージバックエンド間でイメージストレージのバックエンドデータ全体をミラーリングします (たとえば､2 つの異なる Blob ストレージエンドポイントを持つ 1 つの Red Hat Quay レジストリー)。Geo レプリケーションの主なユースケースには、次のようなものがあります。

リポジトリーのミラーリングは、選択されたリポジトリー (またはリポジトリーのサブセット) をあるレジストリーから別のレジストリーに同期します。レジストリーは固有であり、各レジストリーには個別のデータベースおよび個別のイメージストレージがあります。

ミラーリングの主な使用例は次のとおりです。

次の図では、図の上部のデプロイメントでは、インターネットに接続された Red Hat Quay と Clair が示されており、エアギャップされた OpenShift Container Platform クラスターは、ファイアウォールの明示的なホワイトリストに登録されたホールを介して Red Hat Quay レジストリーにアクセスしています。

図の下側のデプロイメントでは、Red Hat Quay と Clair がファイアウォール内で動作しており、イメージや CVE データはオフラインメディアを使用してターゲットシステムに転送されています。データは、インターネットに接続されている別の Red Hat Quay および Clair デプロイメントからエクスポートされます。

次の図は、Red Hat Quay と Clair がエアギャップまたは切断された環境にどのようにデプロイされるかを示しています。

次の表は、概念実証、中規模、およびハイエンドのデプロイメントのおおよそのサイズを示しています。デプロイメントが同じメトリックで適切に実行されるかどうかは、以下に示されていない多くの要因によって決まります。

サイジングおよびミラーリングに関連する推奨事項の詳細は、リポジトリーのミラーリング の項を参照してください。

Redis キャッシュのサイジングは、Quay ビルダーを使用する場合にのみ関連します。それ以外の場合は、重要ではありません。

Red Hat Quay は Standard または Premium のサポートを受けることができ、サブスクリプションはデプロイメントに基づいて行われます。

Red Hat Quay サブスクリプションでは、次のオプションが利用可能です。

Red Hat Quay サブスクリプションの購入の詳細は、Red Hat Quay を参照してください。

Red Hat Quay は、内部レジストリーを持つ複数の OpenShift Container Platform クラスターの前で外部レジストリーとして使用できます。

Red Hat Quay は、ビルドやデプロイメントのロールアウトを自動化する際に、内部レジストリーの代わりに使用することもできます。Secret と ImageStream に必要な調整は、OpenShift Container Platform の OperatorHub から起動できる Quay Bridge Operator によって自動化されます。

次のセクションでは、自動プルーンワーカーに関する情報を詳しく説明します。