Parent folderOpen Confluence

RWS Architecture article

Registry

Registry is the product-neutral architecture building block for container image, artifact, and metadata registry services. It states what DC 3.0 needs from this capability before a

  1. Typeabb
  2. Statuscandidate
  3. Domainplatform
On this page
  1. ABB Registry
  2. Summary
  3. Capabilities
  4. Constraints
  5. Service Description
  6. Roadmaps
  7. Landing Zones
  8. Interfaces
  9. Dependencies
  10. EIRA Alignment
  11. Available SBB's

ABB Registry

Summary

Registry is the product-neutral architecture building block for container image, artifact, and metadata registry services. It states what DC 3.0 needs from this capability before a concrete SBB, product, or operating model is selected.

Capabilities

  • Provides container image, artifact, and metadata registry services.
  • Defines the functional, technical, security, and quality expectations that SBBs must satisfy.
  • Keeps service ownership, interfaces, and consumption boundaries visible before product selection.
  • Enables traceability from architecture intent to implementation, operational evidence, and consuming services.

Constraints

  • The resulting SBB must fit the datacenters ownership model and document the support, lifecycle, and service-management boundary.
  • Security, privacy, logging, evidence, and compliance controls must be explicit enough to assess BIO2-aligned implementation where applicable.
  • Registry content must support vulnerability scanning, provenance, retention, and access control.
  • SBBs must prevent unsigned or untraceable artifacts from entering trusted deployment paths where policy requires trust evidence.
  • The container-image and OCI-artifact registry path is realized by red-hat-quay; non-OCI metadata registry use must keep its own scope explicit.

Service Description

This ABB offers a registry service that stores and distributes approved images and artifacts for DC 3.0 delivery flows. It is consumed by solution architects, platform teams, and service owners as the capability contract for selecting and shaping SBBs.

The service description remains implementation-neutral: product selection, hosting pattern, detailed runbooks, and service levels belong in the mapped SBB and related ADRs.

Roadmaps

  • Baseline: confirm scope, service ownership, constraints, and acceptance criteria for Registry.
  • MVP: validate the mapped SBB implementations and record the selected support and lifecycle model.
  • Next: add measurable service levels, evidence requirements, and roadmap dependencies once the SBB is selected.

Landing Zones

  • Private cloud and central DC 3.0 landing zone for core infrastructure and platform services.
  • Government cloud or external cloud landing zones only when the SBB documents the required control set, connectivity model, and data classification fit.

Interfaces

  • OCI registry APIs.
  • CI/CD, GitOps, scanning, and signing integrations.
  • Identity, audit, and retention interfaces.
  • OpenShift cluster pull and mirror-policy integrations.
  • Object-storage, metadata database, and cache dependencies for the selected SBB.

Dependencies

  • Depends on git for a supporting capability or integration boundary.
  • Depends on automation for a supporting capability or integration boundary.
  • Depends on federated-authentication for a supporting capability or integration boundary.
  • Implemented by red-hat-quay as the selected SBB for the OCI and container-image registry scope.
  • red-hat-quay depends on durable object storage, metadata database, cache, IAM, TLS, monitoring, and backup capabilities, as detailed in quay-registry-architecture.
  • Consuming ABB and SBB dependencies must be recorded as links when solution design identifies concrete upstream or downstream use.

EIRA Alignment

Available SBB's