Parent folderOpen Confluence

RWS Architecture article

Red Hat Quay 3.17 Architecture (Summary)

Red Hat describes Red Hat Quay as a distributed, highly available container image registry for enterprise storage, distribution, access control, geo-replication, repository mirrori

  1. Typesource
  2. Statusactive
  3. Domainplatform
On this page
  1. Source - Red Hat Quay 3.17 Architecture
  2. Overview
  3. Context
  4. Decisions
  5. Current State
  6. References
  7. Future Work
  8. Related

Source - Red Hat Quay 3.17 Architecture

Overview

Red Hat describes Red Hat Quay as a distributed, highly available container image registry for enterprise storage, distribution, access control, geo-replication, repository mirroring, and governance of containers and cloud-native artifacts.

Context

This source anchors the DC 3.0 registry architecture. It is used to shape the registry ABB realization, the red-hat-quay SBB, and the Red Hat Quay Solution Architecture.

Decisions

RWS architecture implications derived from this source:

  • Use the Red Hat Quay Operator on OpenShift Container Platform for the target deployment pattern unless a later ADR approves standalone operation.
  • Treat Quay application replicas as stateless registry front ends; durability belongs to highly available PostgreSQL, Redis, and object storage services.
  • Keep local image storage outside production because the vendor architecture limits it to proof-of-concept or test use; production image layer blobs require an object-storage backend.
  • Treat S3 in the RWS design as an S3-compatible object API, not as a mandate for AWS S3. An ODF/NooBaa or Ceph Object Gateway path can satisfy the object-storage shape if it is accepted by the storage baseline and service onboarding evidence.
  • Red Hat's default shared-registry model uses one Quay registry with organizations, repositories, and RBAC for separation; do not treat one Quay per cluster or per tenant as the default recommendation.
  • Use distinct Quay deployments when different configuration or hard access boundaries are required. The RWS tenant-facing boundary is therefore modeled separately from DCS-internal platform Quay, even though tenant separation inside the tenant-facing service still uses organizations, teams, repository permissions, and robot accounts.
  • Use repository or organization mirroring for selected synchronization between distinct registries. This fits main-to-DCS platform synchronization and selected AM1-to-AM4 tenant image synchronization better than geo-replication, because geo-replication is a shared global registry pattern and does not provide selective repository movement.

Current State

The source supports the RWS target stance that Quay instances are Operator-managed, externally stateful registry tiers. It does not define the RWS-specific main seed, AM1 and AM4 DCS-internal platform, tenant-facing tiering model, service names, bucket names, support groups, or network zones.

References

  • Red Hat Quay architecture, version 3.17: Red Hat documentation
  • Relevant sections: overview, prerequisites, database backend, Redis, image storage backend, supported image storage types, running on OpenShift, distinct registries, mirroring, mirroring versus geo-replication, disconnected deployments, and sizing.

Future Work

  • Re-check the versioned source when the Quay target version changes.
  • Re-check whether a future storage ADR changes the ODF object path backed by dedicated Ceph for image blobs; any other S3 endpoint needs an exception ADR.

Related