Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Deploying the Red Hat Quay Operator on OpenShift Container Platform

Red Hat Quay 3.11

Deploying the Red Hat Quay Operator on OpenShift Container Platform

Red Hat OpenShift Documentation Team

Abstract

Deploy the Red Hat Quay Operator on an OpenShift Container Platform cluster

Preface
Copy link

Red Hat Quay is an enterprise-quality container registry. Use Red Hat Quay to build and store container images, then make them available to deploy across your enterprise.

The Red Hat Quay Operator provides a simple method to deploy and manage Red Hat Quay on an OpenShift cluster.

With the release of Red Hat Quay 3.4.0, the Red Hat Quay Operator was re-written to offer an enhanced experience and to add more support for Day 2 operations. As a result, the Red Hat Quay Operator is now simpler to use and is more opinionated. The key difference from versions prior to Red Hat Quay 3.4.0 include the following:

  • The QuayEcosystem custom resource has been replaced with the QuayRegistry custom resource.

  • The default installation options produces a fully supported Red Hat Quay environment, with all managed dependencies, such as database, caches, object storage, and so on, supported for production use.

    Note

    Some components might not be highly available.

  • A new validation library for Red Hat Quay’s configuration.

  • Object storage can now be managed by the Red Hat Quay Operator using the ObjectBucketClaim Kubernetes API

    Note

    Red Hat OpenShift Data Foundation can be used to provide a supported implementation of this API on OpenShift Container Platform.

  • Customization of the container images used by deployed pods for testing and development scenarios.

Use the content in this chapter to execute the following:

  • Install Red Hat Quay on OpenShift Container Platform using the Red Hat Quay Operator
  • Configure managed, or unmanaged, object storage
  • Configure unmanaged components, such as the database, Redis, routes, TLS, and so on
  • Deploy the Red Hat Quay registry on OpenShift Container Platform using the Red Hat Quay Operator
  • Use advanced features supported by Red Hat Quay
  • Upgrade the Red Hat Quay registry by using the Red Hat Quay Operator

1.1. Red Hat Quay Operator components
Copy link

Red Hat Quay has many dependencies. These dependencies include a database, object storage, Redis, and others. The Red Hat Quay Operator manages an opinionated deployment of Red Hat Quay and its dependencies on Kubernetes. These dependencies are treated as components and are configured through the QuayRegistry API.

In the QuayRegistry custom resource, the spec.components field configures components. Each component contains two fields: kind (the name of the component), and managed (a boolean that addresses whether the component lifecycle is handled by the Red Hat Quay Operator).

By default, all components are managed and auto-filled upon reconciliation for visibility:

Example QuayRegistry resource

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
  spec:
    configBundleSecret: config-bundle-secret
    components:
    - kind: quay
      managed: true
    - kind: postgres
      managed: true
    - kind: clair
      managed: true
    - kind: redis
      managed: true
    - kind: horizontalpodautoscaler
      managed: true
    - kind: objectstorage
      managed: true
    - kind: route
      managed: true
    - kind: mirror
      managed: true
    - kind: monitoring
      managed: true
    - kind: tls
      managed: true
    - kind: clairpostgres
      managed: true
Copy to Clipboard Toggle word wrap

1.2. Using managed components
Copy link

Unless your QuayRegistry custom resource specifies otherwise, the Red Hat Quay Operator uses defaults for the following managed components:

  • quay: Holds overrides for deployment of Red Hat Quay on OpenShift Container Platform, for example, environment variables and number of replicas. This component is new as of Red Hat Quay 3.7 and cannot be set to unmanaged.

  • postgres: For storing the registry metadata, As of Red Hat Quay 3.9, uses a version of PostgreSQL 13 from Software Collections.

    Note

    When upgrading from Red Hat Quay 3.8 → 3.9, the Operator automatically handles upgrading PostgreSQL 10 to PostgreSQL 13. This upgrade is required. PostgreSQL 10 had its final release on November 10, 2022 and is no longer supported.

  • clair: Provides image vulnerability scanning.
  • redis: Stores live builder logs and the Red Hat Quay tutorial. Also includes the locking mechanism that is required for garbage collection.
  • horizontalpodautoscaler: Adjusts the number of Quay pods depending on memory/cpu consumption.
  • objectstorage: For storing image layer blobs, utilizes the ObjectBucketClaim Kubernetes API which is provided by Noobaa or Red Hat OpenShift Data Foundation.
  • route: Provides an external entrypoint to the Red Hat Quay registry from outside of OpenShift Container Platform.
  • mirror: Configures repository mirror workers to support optional repository mirroring.
  • monitoring: Features include a Grafana dashboard, access to individual metrics, and notifications for frequently restarting Quay pods.
  • tls: Configures whether Red Hat Quay or OpenShift Container Platform handles SSL/TLS.
  • clairpostgres: Configures a managed Clair database. This is a separate database than the PostgreSQL database used to deploy Red Hat Quay.

The Red Hat Quay Operator handles any required configuration and installation work needed for Red Hat Quay to use the managed components. If the opinionated deployment performed by the Red Hat Quay Operator is unsuitable for your environment, you can provide the Red Hat Quay Operator with unmanaged resources, or overrides, as described in the following sections.

1.3. Using unmanaged components for dependencies
Copy link

If you have existing components such as PostgreSQL, Redis, or object storage that you want to use with Red Hat Quay, you first configure them within the Red Hat Quay configuration bundle, or the config.yaml file. Then, they must be referenced in your QuayRegistry bundle as a Kubernetes Secret while indicating which components are unmanaged.

Note

If you are using an unmanaged PostgreSQL database, and the version is PostgreSQL 10, it is highly recommended that you upgrade to PostgreSQL 13. PostgreSQL 10 had its final release on November 10, 2022 and is no longer supported. For more information, see the PostgreSQL Versioning Policy.

See the following sections for configuring unmanaged components:

1.4. Config bundle secret
Copy link

The spec.configBundleSecret field is a reference to the metadata.name of a Secret in the same namespace as the QuayRegistry resource. This Secret must contain a config.yaml key/value pair.

The config.yaml file is a Red Hat Quay config.yaml file. This field is optional, and is auto-filled by the Red Hat Quay Operator if not provided. If provided, it serves as the base set of config fields which are later merged with other fields from any managed components to form a final output Secret, which is then mounted into the Red Hat Quay application pods.

Consider the following prerequisites prior to deploying Red Hat Quay on OpenShift Container Platform using the Red Hat Quay Operator.

1.5.1. OpenShift Container Platform cluster
Copy link

To deploy the Red Hat Quay Operator, you must have an OpenShift Container Platform 4.5 or later cluster and access to an administrative account. The administrative account must have the ability to create namespaces at the cluster scope.

1.5.2. Resource Requirements
Copy link

Each Red Hat Quay application pod has the following resource requirements:

  • 8 Gi of memory
  • 2000 millicores of CPU

The Red Hat Quay Operator creates at least one application pod per Red Hat Quay deployment it manages. Ensure your OpenShift Container Platform cluster has sufficient compute resources for these requirements.

1.5.3. Object Storage
Copy link

By default, the Red Hat Quay Operator uses the ObjectBucketClaim Kubernetes API to provision object storage. Consuming this API decouples the Red Hat Quay Operator from any vendor-specific implementation. Red Hat OpenShift Data Foundation provides this API through its NooBaa component, which is used as an example throughout this documentation.

Red Hat Quay can be manually configured to use multiple storage cloud providers, including the following:

  • Amazon S3 (see S3 IAM Bucket Policy for details on configuring an S3 bucket policy for Red Hat Quay)
  • Microsoft Azure Blob Storage
  • Google Cloud Storage
  • Ceph Object Gateway (RADOS)
  • OpenStack Swift
  • CloudFront + S3

For a complete list of object storage providers, the Quay Enterprise 3.x support matrix.

1.5.4. StorageClass
Copy link

When deploying Quay and Clair PostgreSQL databases using the Red Hat Quay Operator, a default StorageClass is configured in your cluster.

The default StorageClass used by the Red Hat Quay Operator provisions the Persistent Volume Claims required by the Quay and Clair databases. These PVCs are used to store data persistently, ensuring that your Red Hat Quay registry and Clair vulnerability scanner remain available and maintain their state across restarts or failures.

Before proceeding with the installation, verify that a default StorageClass is configured in your cluster to ensure seamless provisioning of storage for Quay and Clair components.

Use the following procedure to install the Red Hat Quay Operator from the OpenShift Container Platform OperatorHub.

Procedure

  1. Using the OpenShift Container Platform console, select Operators → OperatorHub.
  2. In the search box, type Red Hat Quay and select the official Red Hat Quay Operator provided by Red Hat. This directs you to the Installation page, which outlines the features, prerequisites, and deployment information.
  3. Select Install. This directs you to the Operator Installation page.

  4. The following choices are available for customizing the installation:

    1. Update Channel: Choose the update channel, for example, stable-3.11 for the latest release.

    2. Installation Mode:

      1. Choose All namespaces on the cluster if you want the Red Hat Quay Operator to be available cluster-wide. It is recommended that you install the Red Hat Quay Operator cluster-wide. If you choose a single namespace, the monitoring component will not be available by default.

      2. Choose A specific namespace on the cluster if you want it deployed only within a single namespace.

        • Approval Strategy: Choose to approve either automatic or manual updates. Automatic update strategy is recommended.
  5. Select Install.

The Red Hat Quay Operator can manage all of the Red Hat Quay components when deployed on OpenShift Container Platform. This is the default configuration, however, you can manage one or more components externally when you want more control over the set up.

Use the following pattern to configure unmanaged Red Hat Quay components.

Procedure

  1. Create a config.yaml configuration file with the appropriate settings. Use the following reference for a minimal configuration: 

    $ touch config.yaml
    Copy to Clipboard Toggle word wrap 
    AUTHENTICATION_TYPE: Database
BUILDLOGS_REDIS:
    host: <quay-server.example.com>
    password: <strongpassword>
    port: 6379
    ssl: false
DATABASE_SECRET_KEY: <0ce4f796-c295-415b-bf9d-b315114704b8>
DB_URI: <postgresql://quayuser:quaypass@quay-server.example.com:5432/quay>
DEFAULT_TAG_EXPIRATION: 2w
DISTRIBUTED_STORAGE_CONFIG:
    default:
        - LocalStorage
        - storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default
PREFERRED_URL_SCHEME: http
SECRET_KEY: <e8f9fe68-1f84-48a8-a05f-02d72e6eccba>
SERVER_HOSTNAME: <quay-server.example.com>
SETUP_COMPLETE: true
TAG_EXPIRATION_OPTIONS:
    - 0s
    - 1d
    - 1w
    - 2w
    - 4w
USER_EVENTS_REDIS:
    host: <quay-server.example.com>
    port: 6379
    ssl: false
    Copy to Clipboard Toggle word wrap

  2. Create a Secret using the configuration file by entering the following command: 

    $ oc create secret generic --from-file config.yaml=./config.yaml config-bundle-secret
    Copy to Clipboard Toggle word wrap

  3. Create a quayregistry.yaml file, identifying the unmanaged components and also referencing the created Secret, for example:

    Example QuayRegistry YAML file

    apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  configBundleSecret: <config_bundle_secret>
  components:
    - kind: objectstorage
      managed: false
# ...
    Copy to Clipboard Toggle word wrap

  4. Enter the following command to deploy the registry by using the quayregistry.yaml file: 

    $ oc create -n quay-enterprise -f quayregistry.yaml
    Copy to Clipboard Toggle word wrap

3.1. Pre-configuring Red Hat Quay for automation
Copy link

Red Hat Quay supports several configuration options that enable automation. Users can configure these options before deployment to reduce the need for interaction with the user interface.

3.1.1. Allowing the API to create the first user
Copy link

To create the first user, users need to set the FEATURE_USER_INITIALIZE parameter to True and call the /api/v1/user/initialize API. Unlike all other registry API calls that require an OAuth token generated by an OAuth application in an existing organization, the API endpoint does not require authentication.

Users can use the API to create a user such as quayadmin after deploying Red Hat Quay, provided no other users have been created. For more information, see Using the API to create the first user.

3.1.2. Enabling general API access
Copy link

Users should set the BROWSER_API_CALLS_XHR_ONLY configuration option to False to allow general access to the Red Hat Quay registry API.

3.1.3. Adding a superuser
Copy link

After deploying Red Hat Quay, users can create a user and give the first user administrator privileges with full permissions. Users can configure full permissions in advance by using the SUPER_USER configuration object. For example: 

# ...
SERVER_HOSTNAME: quay-server.example.com
SETUP_COMPLETE: true
SUPER_USERS:
  - quayadmin
# ...
Copy to Clipboard Toggle word wrap

3.1.4. Restricting user creation
Copy link

After you have configured a superuser, you can restrict the ability to create new users to the superuser group by setting the FEATURE_USER_CREATION to False. For example: 

# ...
FEATURE_USER_INITIALIZE: true
BROWSER_API_CALLS_XHR_ONLY: false
SUPER_USERS:
- quayadmin
FEATURE_USER_CREATION: false
# ...
Copy to Clipboard Toggle word wrap

To use new Red Hat Quay 3.11 functions, enable some or all of the following features: 

# ...
FEATURE_UI_V2: true
FEATURE_UI_V2_REPO_SETTINGS: true
FEATURE_AUTO_PRUNE: true
ROBOTS_DISALLOW: false
# ...
Copy to Clipboard Toggle word wrap

3.1.6. Suggested configuration for automation
Copy link

The following config.yaml parameters are suggested for automation: 

# ...
FEATURE_USER_INITIALIZE: true
BROWSER_API_CALLS_XHR_ONLY: false
SUPER_USERS:
- quayadmin
FEATURE_USER_CREATION: false
# ...
Copy to Clipboard Toggle word wrap

3.2. Configuring object storage
Copy link

You need to configure object storage before installing Red Hat Quay, irrespective of whether you are allowing the Red Hat Quay Operator to manage the storage or managing it yourself.

If you want the Red Hat Quay Operator to be responsible for managing storage, see the section on Managed storage for information on installing and configuring NooBaa and the Red Hat OpenShift Data Foundations Operator.

If you are using a separate storage solution, set objectstorage as unmanaged when configuring the Operator. See the following section. Unmanaged storage, for details of configuring existing storage.

3.2.1. Using unmanaged storage
Copy link

This section provides configuration examples for unmanaged storage for your convenience. Refer to the Red Hat Quay configuration guide for complete instructions on how to set up object storage.

3.2.1.1. AWS S3 storage
Copy link

Use the following example when configuring AWS S3 storage for your Red Hat Quay deployment. 

DISTRIBUTED_STORAGE_CONFIG:
  s3Storage:
    - S3Storage
    - host: s3.us-east-2.amazonaws.com
      s3_access_key: ABCDEFGHIJKLMN
      s3_secret_key: OL3ABCDEFGHIJKLMN
      s3_bucket: quay_bucket
      s3_region: <region>
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - s3Storage
Copy to Clipboard Toggle word wrap
3.2.1.2. Google Cloud storage
Copy link

Use the following example when configuring Google Cloud storage for your Red Hat Quay deployment. 

DISTRIBUTED_STORAGE_CONFIG:
    googleCloudStorage:
        - GoogleCloudStorage
        - access_key: GOOGQIMFB3ABCDEFGHIJKLMN
          bucket_name: quay-bucket
          secret_key: FhDAYe2HeuAKfvZCAGyOioNaaRABCDEFGHIJKLMN
          storage_path: /datastorage/registry
          boto_timeout: 120
1 

DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - googleCloudStorage
Copy to Clipboard Toggle word wrap
1
Optional. The time, in seconds, until a timeout exception is thrown when attempting to read from a connection. The default is 60 seconds. Also encompasses the time, in seconds, until a timeout exception is thrown when attempting to make a connection. The default is 60 seconds.
3.2.1.3. Microsoft Azure storage
Copy link

Use the following example when configuring Microsoft Azure storage for your Red Hat Quay deployment. 

DISTRIBUTED_STORAGE_CONFIG:
  azureStorage:
    - AzureStorage
    - azure_account_name: azure_account_name_here
      azure_container: azure_container_here
      storage_path: /datastorage/registry
      azure_account_key: azure_account_key_here
      sas_token: some/path/
      endpoint_url: https://[account-name].blob.core.usgovcloudapi.net
1 

DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - azureStorage
Copy to Clipboard Toggle word wrap
1
The endpoint_url parameter for Microsoft Azure storage is optional and can be used with Microsoft Azure Government (MAG) endpoints. If left blank, the endpoint_url will connect to the normal Microsoft Azure region.

As of Red Hat Quay 3.7, you must use the Primary endpoint of your MAG Blob service. Using the Secondary endpoint of your MAG Blob service will result in the following error: AuthenticationErrorDetail:Cannot find the claimed account when trying to GetProperties for the account whusc8-secondary.

3.2.1.4. Ceph/RadosGW Storage
Copy link

Use the following example when configuring Ceph/RadosGW storage for your Red Hat Quay deployment. 

DISTRIBUTED_STORAGE_CONFIG:
  radosGWStorage: #storage config name
    - RadosGWStorage #actual driver
    - access_key: access_key_here #parameters
      secret_key: secret_key_here
      bucket_name: bucket_name_here
      hostname: hostname_here
      is_secure: 'true'
      port: '443'
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE: #must contain name of the storage config
    - radosGWStorage
Copy to Clipboard Toggle word wrap
3.2.1.5. Swift storage
Copy link

Use the following example when configuring Swift storage for your Red Hat Quay deployment. 

DISTRIBUTED_STORAGE_CONFIG:
  swiftStorage:
    - SwiftStorage
    - swift_user: swift_user_here
      swift_password: swift_password_here
      swift_container: swift_container_here
      auth_url: https://example.org/swift/v1/quay
      auth_version: 1
      ca_cert_path: /conf/stack/swift.cert"
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - swiftStorage
Copy to Clipboard Toggle word wrap
3.2.1.6. NooBaa unmanaged storage
Copy link

Use the following procedure to deploy NooBaa as your unmanaged storage configuration.

Procedure

  1. Create a NooBaa Object Bucket Claim in the Red Hat Quay console by navigating to Storage → Object Bucket Claims.
  2. Retrieve the Object Bucket Claim Data details, including the Access Key, Bucket Name, Endpoint (hostname), and Secret Key.

  3. Create a config.yaml configuration file that uses the information for the Object Bucket Claim: 

    DISTRIBUTED_STORAGE_CONFIG:
  default:
    - RHOCSStorage
    - access_key: WmrXtSGk8B3nABCDEFGH
      bucket_name: my-noobaa-bucket-claim-8b844191-dc6c-444e-9ea4-87ece0abcdef
      hostname: s3.openshift-storage.svc.cluster.local
      is_secure: true
      port: "443"
      secret_key: X9P5SDGJtmSuHFCMSLMbdNCMfUABCDEFGH+C5QD
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
  - default
    Copy to Clipboard Toggle word wrap

For more information about configuring an Object Bucket Claim, see Object Bucket Claim.

3.2.2. Using an unmanaged NooBaa instance
Copy link

Use the following procedure to use an unmanaged NooBaa instance for your Red Hat Quay deployment.

Procedure

  1. Create a NooBaa Object Bucket Claim in the console at Storage → Object Bucket Claims.
  2. Retrieve the Object Bucket Claim Data details including the Access Key, Bucket Name, Endpoint (hostname), and Secret Key.

  3. Create a config.yaml configuration file using the information for the Object Bucket Claim. For example: 

    DISTRIBUTED_STORAGE_CONFIG:
  default:
    - RHOCSStorage
    - access_key: WmrXtSGk8B3nABCDEFGH
      bucket_name: my-noobaa-bucket-claim-8b844191-dc6c-444e-9ea4-87ece0abcdef
      hostname: s3.openshift-storage.svc.cluster.local
      is_secure: true
      port: "443"
      secret_key: X9P5SDGJtmSuHFCMSLMbdNCMfUABCDEFGH+C5QD
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
  - default
    Copy to Clipboard Toggle word wrap

3.2.3. Managed storage
Copy link

If you want the Red Hat Quay Operator to manage object storage for Red Hat Quay, your cluster needs to be capable of providing object storage through the ObjectBucketClaim API. Using the Red Hat OpenShift Data Foundation Operator, there are two supported options available:

  • A standalone instance of the Multi-Cloud Object Gateway backed by a local Kubernetes PersistentVolume storage

    • Not highly available
    • Included in the Red Hat Quay subscription
    • Does not require a separate subscription for Red Hat OpenShift Data Foundation

  • A production deployment of Red Hat OpenShift Data Foundation with scale-out Object Service and Ceph

    • Highly available
    • Requires a separate subscription for Red Hat OpenShift Data Foundation

To use the standalone instance option, continue reading below. For production deployment of Red Hat OpenShift Data Foundation, please refer to the official documentation.

Note

Object storage disk space is allocated automatically by the Red Hat Quay Operator with 50 GiB. This number represents a usable amount of storage for most small to medium Red Hat Quay installations but might not be sufficient for your use cases. Resizing the Red Hat OpenShift Data Foundation volume is currently not handled by the Red Hat Quay Operator. See the section below about resizing managed storage for more details.

As part of a Red Hat Quay subscription, users are entitled to use the Multicloud Object Gateway component of the Red Hat OpenShift Data Foundation Operator (formerly known as OpenShift Container Storage Operator). This gateway component allows you to provide an S3-compatible object storage interface to Red Hat Quay backed by Kubernetes PersistentVolume-based block storage. The usage is limited to a Red Hat Quay deployment managed by the Operator and to the exact specifications of the multicloud Object Gateway instance as documented below.

Since Red Hat Quay does not support local filesystem storage, users can leverage the gateway in combination with Kubernetes PersistentVolume storage instead, to provide a supported deployment. A PersistentVolume is directly mounted on the gateway instance as a backing store for object storage and any block-based StorageClass is supported.

By the nature of PersistentVolume, this is not a scale-out, highly available solution and does not replace a scale-out storage system like Red Hat OpenShift Data Foundation. Only a single instance of the gateway is running. If the pod running the gateway becomes unavailable due to rescheduling, updates or unplanned downtime, this will cause temporary degradation of the connected Red Hat Quay instances.

Deploying Red Hat Quay on OpenShift Container Platform using Red Hat OpenShift Data Foundation requires you to download the Local Storage Operator, the Red Hat OpenShift Data Foundation Operator, and then deploy a standalone Multicloud Object Gateway using the OpenShift Container Platform UI. See the following Red Hat OpenShift Data Foundation documentation for these steps:

Chapter 4. Configuring traffic ingress
Copy link

4.1. Configuring SSL/TLS and Routes
Copy link

Support for OpenShift Container Platform edge termination routes have been added by way of a new managed component, tls. This separates the route component from SSL/TLS and allows users to configure both separately.

EXTERNAL_TLS_TERMINATION: true is the opinionated setting.

Note
  • Managed tls means that the default cluster wildcard certificate is used.
  • Unmanaged tls means that the user provided key and certificate pair is be injected into the route.

The ssl.cert and ssl.key are now moved to a separate, persistent secret, which ensures that the key and certificate pair are not regenerated upon every reconcile. The key and certificate pair are now formatted as edge routes and mounted to the same directory in the Quay container.

Multiple permutations are possible when configuring SSL/TLS and routes, but the following rules apply:

  • If SSL/TLS is managed, then your route must also be managed.
  • If SSL/TLS is unmanaged then you must supply certificates directly in the config bundle.

The following table describes the valid options:

Expand
Table 4.1. Valid configuration options for TLS and routes
OptionRouteTLSCerts providedResult

My own load balancer handles TLS

Managed

Managed

No

Edge route with default wildcard cert

Red Hat Quay handles TLS

Managed

Unmanaged

Yes

Passthrough route with certs mounted inside the pod

Red Hat Quay handles TLS

Unmanaged

Unmanaged

Yes

Certificates are set inside of the quay pod, but the route must be created manually

Use the following procedure to create a config bundle secret that includes your own SSL/TLS certificate and key pair.

Procedure

  • Enter the following command to create config bundle secret that includes your own SSL/TLS certificate and key pair: 

    $ oc create secret generic --from-file config.yaml=./config.yaml --from-file ssl.cert=./ssl.cert --from-file ssl.key=./ssl.key config-bundle-secret
    Copy to Clipboard Toggle word wrap

You can manually adjust the resources on Red Hat Quay on OpenShift Container Platform for the following components that have running pods:

  • quay
  • clair
  • mirroring
  • clairpostgres
  • postgres

This feature allows users to run smaller test clusters, or to request more resources upfront in order to avoid partially degraded Quay pods. Limitations and requests can be set in accordance with Kubernetes resource units.

The following components should not be set lower than their minimum requirements. This can cause issues with your deployment and, in some cases, result in failure of the pod’s deployment.

  • quay: Minimum of 6 GB, 2vCPUs
  • clair: Recommended of 2 GB memory, 2 vCPUs
  • clairpostgres: Minimum of 200 MB

You can configure resource requests on the OpenShift Container Platform UI, or by directly by updating the QuayRegistry YAML.

Important

The default values set for these components are the suggested values. Setting resource requests too high or too low might lead to inefficient resource utilization, or performance degradation, respectively.

Use the following procedure to configure resources by using the OpenShift Container Platform UI.

Procedure

  1. On the OpenShift Container Platform developer console, click Operators → Installed Operators → Red Hat Quay.
  2. Click QuayRegistry.
  3. Click the name of your registry, for example, example-registry.
  4. Click YAML.

  5. In the spec.components field, you can override the resource of the quay, clair, mirroring clairpostgres, and postgres resources by setting values for the .overrides.resources.limits and the overrides.resources.requests fields. For example: 

    spec:
  components:
    - kind: clair
      managed: true
      overrides:
        resources:
          limits:
            cpu: "5"     # Limiting to 5 CPU (equivalent to 5000m or 5000 millicpu)
            memory: "18Gi"  # Limiting to 18 Gibibytes of memory
          requests:
            cpu: "4"     # Requesting 4 CPU
            memory: "4Gi"   # Requesting 4 Gibibytes of memory
    - kind: postgres
      managed: true
      overrides:
        resources:
          limits: {}
    1 
    
          requests:
            cpu: "700m"   # Requesting 700 millicpu or 0.7 CPU
            memory: "4Gi"   # Requesting 4 Gibibytes of memory
    - kind: mirror
      managed: true
      overrides:
        resources:
          limits:
    2 
    
          requests:
            cpu: "800m"   # Requesting 800 millicpu or 0.8 CPU
            memory: "1Gi"   # Requesting 1 Gibibyte of memory
    - kind: quay
      managed: true
      overrides:
        resources:
          limits:
            cpu: "4"    # Limiting to 4 CPU
            memory: "10Gi"   # Limiting to 10 Gibibytes of memory
          requests:
            cpu: "4"   # Requesting 4 CPU
            memory: "10Gi"   # Requesting 10 Gibi of memory
    - kind: clairpostgres
      managed: true
      overrides:
        resources:
          limits:
            cpu: "800m"   # Limiting to 800 millicpu or 0.8 CPU
            memory: "3Gi"   # Limiting to 3 Gibibytes of memory
          requests: {}
    Copy to Clipboard Toggle word wrap
    1
    Setting the limits or requests fields to {} uses the default values for these resources.
    2
    Leaving the limits or requests field empty puts no limitations on these resources.

You can re-configure Red Hat Quay to configure resource requests after you have already deployed a registry. This can be done by editing the QuayRegistry YAML file directly and then re-deploying the registry.

Procedure

  1. Optional: If you do not have a local copy of the QuayRegistry YAML file, enter the following command to obtain it: 

    $ oc get quayregistry <registry_name> -n <namespace> -o yaml > quayregistry.yaml
    Copy to Clipboard Toggle word wrap

  2. Open the quayregistry.yaml created from Step 1 of this procedure and make the desired changes. For example: 

        - kind: quay
      managed: true
      overrides:
        resources:
          limits: {}
          requests:
            cpu: "0.7"   # Requesting 0.7 CPU (equivalent to 500m or 500 millicpu)
            memory: "512Mi"   # Requesting 512 Mebibytes of memory
    Copy to Clipboard Toggle word wrap
  3. Save the changes.

  4. Apply the Red Hat Quay registry using the updated configurations by running the following command: 

    $ oc replace -f quayregistry.yaml
    Copy to Clipboard Toggle word wrap

    Example output

    quayregistry.quay.redhat.com/example-registry replaced
    Copy to Clipboard Toggle word wrap

Chapter 6. Configuring the database
Copy link

6.1. Using an existing PostgreSQL database
Copy link

If you are using an externally managed PostgreSQL database, you must manually enable the pg_trgm extension for a successful deployment.

Important

You must not use the same externally managed PostgreSQL database for both Red Hat Quay and Clair deployments. Your PostgreSQL database must also not be shared with other workloads, as it might exhaust the natural connection limit on the PostgreSQL side when connection-intensive workloads, like Red Hat Quay or Clair, contend for resources. Additionally, pgBouncer is not supported with Red Hat Quay or Clair, so it is not an option to resolve this issue.

Use the following procedure to deploy an existing PostgreSQL database.

Procedure

  1. Create a config.yaml file with the necessary database fields. For example:

    Example config.yaml file:

    DB_URI: postgresql://test-quay-database:postgres@test-quay-database:5432/test-quay-database
    Copy to Clipboard Toggle word wrap

  2. Create a Secret using the configuration file: 

    $ kubectl create secret generic --from-file config.yaml=./config.yaml config-bundle-secret
    Copy to Clipboard Toggle word wrap

  3. Create a QuayRegistry.yaml file which marks the postgres component as unmanaged and references the created Secret. For example:

    Example quayregistry.yaml file

    apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  configBundleSecret: config-bundle-secret
  components:
    - kind: postgres
      managed: false
    Copy to Clipboard Toggle word wrap

Next steps

  • Continue to the following sections to deploy the registry.

6.1.1. Database configuration
Copy link

This section describes the database configuration fields available for Red Hat Quay deployments.

6.1.1.1. Database URI
Copy link

With Red Hat Quay, connection to the database is configured by using the required DB_URI field.

The following table describes the DB_URI configuration field:

Expand
Table 6.1. Database URI
FieldTypeDescription

DB_URI
(Required)

String

The URI for accessing the database, including any credentials.

Example DB_URI field:

postgresql://quayuser:quaypass@quay-server.example.com:5432/quay

6.1.1.2. Database connection arguments
Copy link

Optional connection arguments are configured by the DB_CONNECTION_ARGS parameter. Some of the key-value pairs defined under DB_CONNECTION_ARGS are generic, while others are database specific.

The following table describes database connection arguments:

Expand
Table 6.2. Database connection arguments
FieldTypeDescription

DB_CONNECTION_ARGS

Object

Optional connection arguments for the database, such as timeouts and SSL/TLS.

.autorollback

Boolean

Whether to use thread-local connections.
Should always be True

.threadlocals

Boolean

Whether to use auto-rollback connections.
Should always be True

6.1.1.2.1. PostgreSQL SSL/TLS connection arguments
Copy link

With SSL/TLS, configuration depends on the database you are deploying. The following example shows a PostgreSQL SSL/TLS configuration: 

DB_CONNECTION_ARGS:
  sslmode: verify-ca
  sslrootcert: /path/to/cacert
Copy to Clipboard Toggle word wrap

The sslmode option determines whether, or with, what priority a secure SSL/TLS TCP/IP connection will be negotiated with the server. There are six modes:

Expand
Table 6.3. SSL/TLS options
ModeDescription

disable

Your configuration only tries non-SSL/TLS connections.

allow

Your configuration first tries a non-SSL/TLS connection. Upon failure, tries an SSL/TLS connection.

prefer
(Default)

Your configuration first tries an SSL/TLS connection. Upon failure, tries a non-SSL/TLS connection.

require

Your configuration only tries an SSL/TLS connection. If a root CA file is present, it verifies the certificate in the same way as if verify-ca was specified.

verify-ca

Your configuration only tries an SSL/TLS connection, and verifies that the server certificate is issued by a trusted certificate authority (CA).

verify-full

Only tries an SSL/TLS connection, and verifies that the server certificate is issued by a trusted CA and that the requested server hostname matches that in the certificate.

For more information on the valid arguments for PostgreSQL, see Database Connection Control Functions.

6.1.1.2.2. MySQL SSL/TLS connection arguments
Copy link

The following example shows a sample MySQL SSL/TLS configuration: 

DB_CONNECTION_ARGS:
  ssl:
    ca: /path/to/cacert
Copy to Clipboard Toggle word wrap

Information on the valid connection arguments for MySQL is available at Connecting to the Server Using URI-Like Strings or Key-Value Pairs.

6.1.2. Using the managed PostgreSQL database
Copy link

With Red Hat Quay 3.9, if your database is managed by the Red Hat Quay Operator, updating from Red Hat Quay 3.8 → 3.9 automatically handles upgrading PostgreSQL 10 to PostgreSQL 13.

Important
  • Users with a managed database are required to upgrade their PostgreSQL database from 10 → 13.
  • If your Red Hat Quay and Clair databases are managed by the Operator, the database upgrades for each component must succeed for the 3.9.0 upgrade to be successful. If either of the database upgrades fail, the entire Red Hat Quay version upgrade fails. This behavior is expected.

If you do not want the Red Hat Quay Operator to upgrade your PostgreSQL deployment from PostgreSQL 10 → 13, you must set the PostgreSQL parameter to managed: false in your quayregistry.yaml file. For more information about setting your database to unmanaged, see Using an existing Postgres database.

Important
  • It is highly recommended that you upgrade to PostgreSQL 13. PostgreSQL 10 had its final release on November 10, 2022 and is no longer supported. For more information, see the PostgreSQL Versioning Policy.

If you want your PostgreSQL database to match the same version as your Red Hat Enterprise Linux (RHEL) system, see Migrating to a RHEL 8 version of PostgreSQL for RHEL 8 or Migrating to a RHEL 9 version of PostgreSQL for RHEL 9.

For more information about the Red Hat Quay 3.8 → 3.9 procedure, see Upgrading the Red Hat Quay Operator overview.

6.1.2.1. PostgreSQL database recommendations
Copy link

The Red Hat Quay team recommends the following for managing your PostgreSQL database.

  • Database backups should be performed regularly using either the supplied tools on the PostgreSQL image or your own backup infrastructure. The Red Hat Quay Operator does not currently ensure that the PostgreSQL database is backed up.
  • Restoring the PostgreSQL database from a backup must be done using PostgreSQL tools and procedures. Be aware that your Quay pods should not be running while the database restore is in progress.
  • Database disk space is allocated automatically by the Red Hat Quay Operator with 50 GiB. This number represents a usable amount of storage for most small to medium Red Hat Quay installations but might not be sufficient for your use cases. Resizing the database volume is currently not handled by the Red Hat Quay Operator.

6.2. Configuring external Redis
Copy link

Use the content in this section to set up an external Redis deployment.

6.2.1. Using an unmanaged Redis database
Copy link

Use the following procedure to set up an external Redis database.

Procedure

  1. Create a config.yaml file using the following Redis fields: 

    # ...
BUILDLOGS_REDIS:
    host: <quay-server.example.com>
    port: 6379
    ssl: false
# ...
USER_EVENTS_REDIS:
    host: <quay-server.example.com>
    port: 6379
    ssl: false
# ...
    Copy to Clipboard Toggle word wrap

  2. Enter the following command to create a secret using the configuration file: 

    $ oc create secret generic --from-file config.yaml=./config.yaml config-bundle-secret
    Copy to Clipboard Toggle word wrap

  3. Create a quayregistry.yaml file that sets the Redis component to unmanaged and references the created secret: 

    apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  configBundleSecret: config-bundle-secret
  components:
    - kind: redis
      managed: false
# ...
    Copy to Clipboard Toggle word wrap
  4. Deploy the Red Hat Quay registry.

6.2.2. Using unmanaged Horizontal Pod Autoscalers
Copy link

Horizontal Pod Autoscalers (HPAs) are now included with the Clair, Quay, and Mirror pods, so that they now automatically scale during load spikes.

As HPA is configured by default to be managed, the number of Clair, Quay, and Mirror pods is set to two. This facilitates the avoidance of downtime when updating or reconfiguring Red Hat Quay through the Operator or during rescheduling events.

6.2.2.1. Disabling the Horizontal Pod Autoscaler
Copy link

To disable autoscaling or create your own HorizontalPodAutoscaler, specify the component as unmanaged in the QuayRegistry instance. For example: 

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  components:
    - kind: horizontalpodautoscaler
      managed: false
# ...
Copy to Clipboard Toggle word wrap

6.2.3. Disabling the Route component
Copy link

Use the following procedure to prevent the Red Hat Quay Operator from creating a route.

Procedure

  1. Set the component as managed: false in the quayregistry.yaml file: 

    apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  components:
    - kind: route
      managed: false
    Copy to Clipboard Toggle word wrap

  2. Edit the config.yaml file to specify that Red Hat Quay handles SSL/TLS. For example: 

    # ...
EXTERNAL_TLS_TERMINATION: false
# ...
SERVER_HOSTNAME: example-registry-quay-quay-enterprise.apps.user1.example.com
# ...
PREFERRED_URL_SCHEME: https
# ...
    Copy to Clipboard Toggle word wrap

    If you do not configure the unmanaged route correctly, the following error is returned: 

    {
  {
    "kind":"QuayRegistry",
    "namespace":"quay-enterprise",
    "name":"example-registry",
    "uid":"d5879ba5-cc92-406c-ba62-8b19cf56d4aa",
    "apiVersion":"quay.redhat.com/v1",
    "resourceVersion":"2418527"
  },
  "reason":"ConfigInvalid",
  "message":"required component `route` marked as unmanaged, but `configBundleSecret` is missing necessary fields"
}
    Copy to Clipboard Toggle word wrap
Note

Disabling the default route means you are now responsible for creating a Route, Service, or Ingress in order to access the Red Hat Quay instance. Additionally, whatever DNS you use must match the SERVER_HOSTNAME in the Red Hat Quay config.

6.2.4. Disabling the monitoring component
Copy link

If you install the Red Hat Quay Operator in a single namespace, the monitoring component is automatically set to managed: false. Use the following reference to explicitly disable monitoring.

Unmanaged monitoring

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  components:
    - kind: monitoring
      managed: false
Copy to Clipboard Toggle word wrap

To enable monitoring in this scenario, see Enabling monitoring when the Red Hat Quay Operator is installed in a single namespace.

6.2.5. Disabling the mirroring component
Copy link

To disable mirroring, use the following YAML configuration:

Unmanaged mirroring example YAML configuration

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  components:
    - kind: mirroring
      managed: false
Copy to Clipboard Toggle word wrap

Red Hat Quay on OpenShift Container Platform can be deployed using command-line interface or from the OpenShift Container Platform console. The steps are fundamentally the same.

7.1. Deploying Red Hat Quay from the command line
Copy link

Use the following procedure to deploy Red Hat Quay from using the command-line interface (CLI).

Prerequisites

  • You have logged into OpenShift Container Platform using the CLI.

Procedure

  1. Create a namespace, for example, quay-enterprise, by entering the following command: 

    $ oc new-project quay-enterprise
    Copy to Clipboard Toggle word wrap

  2. Optional. If you want to pre-configure any aspects of your Red Hat Quay deployment, create a Secret for the config bundle: 

    $ oc create secret generic quay-enterprise-config-bundle --from-file=config-bundle.tar.gz=/path/to/config-bundle.tar.gz
    Copy to Clipboard Toggle word wrap

  3. Create a QuayRegistry custom resource in a file called quayregistry.yaml

    1. For a minimal deployment, using all the defaults:

      quayregistry.yaml:

      apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
      Copy to Clipboard Toggle word wrap

    2. Optional. If you want to have some components unmanaged, add this information in the spec field. A minimal deployment might look like the following example:

      Example quayregistry.yaml with unmanaged components

      apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  components:
    - kind: clair
      managed: false
    - kind: horizontalpodautoscaler
      managed: false
    - kind: mirror
      managed: false
    - kind: monitoring
      managed: false
      Copy to Clipboard Toggle word wrap

    3. Optional. If you have created a config bundle, for example, init-config-bundle-secret, reference it in the quayregistry.yaml file:

      Example quayregistry.yaml with a config bundle

      apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  configBundleSecret: init-config-bundle-secret
      Copy to Clipboard Toggle word wrap

    4. Optional. If you have a proxy configured, you can add the information using overrides for Red Hat Quay, Clair, and mirroring:

      Example quayregistry.yaml with proxy configured

        kind: QuayRegistry
  metadata:
    name: quay37
  spec:
    configBundleSecret: config-bundle-secret
    components:
      - kind: objectstorage
        managed: false
      - kind: route
        managed: true
      - kind: mirror
        managed: true
        overrides:
          env:
            - name: DEBUGLOG
              value: "true"
            - name: HTTP_PROXY
              value: quayproxy.qe.devcluster.openshift.com:3128
            - name: HTTPS_PROXY
              value: quayproxy.qe.devcluster.openshift.com:3128
            - name: NO_PROXY
              value: svc.cluster.local,localhost,quay370.apps.quayperf370.perfscale.devcluster.openshift.com
      - kind: tls
        managed: false
      - kind: clair
        managed: true
        overrides:
          env:
            - name: HTTP_PROXY
              value: quayproxy.qe.devcluster.openshift.com:3128
            - name: HTTPS_PROXY
              value: quayproxy.qe.devcluster.openshift.com:3128
            - name: NO_PROXY
              value: svc.cluster.local,localhost,quay370.apps.quayperf370.perfscale.devcluster.openshift.com
      - kind: quay
        managed: true
        overrides:
          env:
            - name: DEBUGLOG
              value: "true"
            - name: NO_PROXY
              value: svc.cluster.local,localhost,quay370.apps.quayperf370.perfscale.devcluster.openshift.com
            - name: HTTP_PROXY
              value: quayproxy.qe.devcluster.openshift.com:3128
            - name: HTTPS_PROXY
              value: quayproxy.qe.devcluster.openshift.com:3128
      Copy to Clipboard Toggle word wrap

  4. Create the QuayRegistry in the specified namespace by entering the following command: 

    $ oc create -n quay-enterprise -f quayregistry.yaml
    Copy to Clipboard Toggle word wrap

  5. Enter the following command to see when the status.registryEndpoint is populated: 

    $ oc get quayregistry -n quay-enterprise example-registry -o jsonpath="{.status.registryEndpoint}" -w
    Copy to Clipboard Toggle word wrap

Additional resources

7.1.1. Using the API to create the first user
Copy link

Use the following procedure to create the first user in your Red Hat Quay organization.

Prerequisites

  • The config option FEATURE_USER_INITIALIZE must be set to True.
  • No users can already exist in the database.
Procedure

This procedure requests an OAuth token by specifying "access_token": true.

  1. Open your Red Hat Quay configuration file and update the following configuration fields: 

    FEATURE_USER_INITIALIZE: true
SUPER_USERS:
     -  quayadmin
    Copy to Clipboard Toggle word wrap

  2. Stop the Red Hat Quay service by entering the following command: 

    $ sudo podman stop quay
    Copy to Clipboard Toggle word wrap

  3. Start the Red Hat Quay service by entering the following command: 

    $ sudo podman run -d -p 80:8080 -p 443:8443 --name=quay -v $QUAY/config:/conf/stack:Z  -v $QUAY/storage:/datastorage:Z {productrepo}/{quayimage}:{productminv}
    Copy to Clipboard Toggle word wrap

  4. Run the following CURL command to generate a new user with a username, password, email, and access token: 

    $ curl -X POST -k  http://quay-server.example.com/api/v1/user/initialize --header 'Content-Type: application/json' --data '{ "username": "quayadmin", "password":"quaypass12345", "email": "quayadmin@example.com", "access_token": true}'
    Copy to Clipboard Toggle word wrap

    If successful, the command returns an object with the username, email, and encrypted password. For example: 

    {"access_token":"6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED", "email":"quayadmin@example.com","encrypted_password":"1nZMLH57RIE5UGdL/yYpDOHLqiNCgimb6W9kfF8MjZ1xrfDpRyRs9NUnUuNuAitW","username":"quayadmin"} # gitleaks:allow
    Copy to Clipboard Toggle word wrap

    If a user already exists in the database, an error is returned: 

    {"message":"Cannot initialize user in a non-empty database"}
    Copy to Clipboard Toggle word wrap

    If your password is not at least eight characters or contains whitespace, an error is returned: 

    {"message":"Failed to initialize user: Invalid password, password must be at least 8 characters and contain no whitespace."}
    Copy to Clipboard Toggle word wrap

  5. Log in to your Red Hat Quay deployment by entering the following command: 

    $ sudo podman login -u quayadmin -p quaypass12345 http://quay-server.example.com --tls-verify=false
    Copy to Clipboard Toggle word wrap

    Example output

    Login Succeeded!
    Copy to Clipboard Toggle word wrap

Use the following procedure to view deployed Red Hat Quay components.

Prerequisites

  • You have deployed Red Hat Quay on OpenShift Container Platform.

Procedure

  1. Enter the following command to view the deployed components: 

    $ oc get pods -n quay-enterprise
    Copy to Clipboard Toggle word wrap

    Example output

    NAME                                                   READY   STATUS      RESTARTS   AGE
example-registry-clair-app-5ffc9f77d6-jwr9s            1/1     Running     0          3m42s
example-registry-clair-app-5ffc9f77d6-wgp7d            1/1     Running     0          3m41s
example-registry-clair-postgres-54956d6d9c-rgs8l       1/1     Running     0          3m5s
example-registry-quay-app-79c6b86c7b-8qnr2             1/1     Running     4          3m42s
example-registry-quay-app-79c6b86c7b-xk85f             1/1     Running     4          3m41s
example-registry-quay-app-upgrade-5kl5r                0/1     Completed   4          3m50s
example-registry-quay-database-b466fc4d7-tfrnx         1/1     Running     2          3m42s
example-registry-quay-mirror-6d9bd78756-6lj6p          1/1     Running     0          2m58s
example-registry-quay-mirror-6d9bd78756-bv6gq          1/1     Running     0          2m58s
example-registry-quay-postgres-init-dzbmx              0/1     Completed   0          3m43s
example-registry-quay-redis-8bd67b647-skgqx            1/1     Running     0          3m42s
    Copy to Clipboard Toggle word wrap

7.1.3. Horizontal Pod Autoscaling
Copy link

A default deployment shows the following running pods:

  • Two pods for the Red Hat Quay application itself (example-registry-quay-app-*`)
  • One Redis pod for Red Hat Quay logging (example-registry-quay-redis-*)
  • One database pod for PostgreSQL used by Red Hat Quay for metadata storage (example-registry-quay-database-*)
  • Two Quay mirroring pods (example-registry-quay-mirror-*)
  • Two pods for the Clair application (example-registry-clair-app-*)
  • One PostgreSQL pod for Clair (example-registry-clair-postgres-*)

Horizontal PPod Autoscaling is configured by default to be managed, and the number of pods for Quay, Clair and repository mirroring is set to two. This facilitates the avoidance of downtime when updating or reconfiguring Red Hat Quay through the Red Hat Quay Operator or during rescheduling events. You can enter the following command to view information about HPA objects: 

$ oc get hpa -n quay-enterprise
Copy to Clipboard Toggle word wrap

Example output

NAME                           REFERENCE                                 TARGETS           MINPODS   MAXPODS   REPLICAS   AGE
example-registry-clair-app     Deployment/example-registry-clair-app     16%/90%, 0%/90%   2         10        2          13d
example-registry-quay-app      Deployment/example-registry-quay-app      31%/90%, 1%/90%   2         20        2          13d
example-registry-quay-mirror   Deployment/example-registry-quay-mirror   27%/90%, 0%/90%   2         20        2          13d
Copy to Clipboard Toggle word wrap

By default, all quay-related pods are scheduled on available worker nodes in your OpenShift Container Platform cluster. In some environments, you might want to dedicate certain nodes specifically for infrastructure workloads—such as registry, database, and monitoring pods—to improve performance, isolate critical components, or simplify maintenance.

OpenShift Container Platform supports this approach using infrastructure machine sets, which automatically create and manage nodes reserved for infrastructure.

As an OpenShift Container Platform administrator, you can achieve the same result by labeling and tainting worker nodes. This ensures that only infrastructure workloads, like quay pods, are scheduled on these nodes. After your infrastructure nodes are configured, you can control where quay pods run using node selectors and tolerations.

The following procedures is intended for new deployments that install the Red Hat Quay Operator in a single namespace and provide their own backend storage. The procedure shows you how to prepare nodes and deploy Red Hat Quay on dedicated infrastructure nodes. In this procedure, all quay-related pods are placed on dedicated infrastructure nodes.

Use the following procedure to label and taint nodes for infrastructure use.

Note

The following procedure labels three worker nodes with the infra label. Depending on the resources relevant to your environment, you might have to label more than three worker nodes with the infra label.

  1. Obtain a list of worker nodes in your deployment by entering the following command: 

    $ oc get nodes | grep worker
    Copy to Clipboard Toggle word wrap

    Example output

    NAME                                                              STATUS   ROLES                  AGE    VERSION
---
example-cluster-new-c5qqp-worker-b-4zxx5.c.quay-devel.internal   Ready    worker                 401d   v1.31.11
example-cluster-new-c5qqp-worker-b-kz6jn.c.quay-devel.internal   Ready    worker                 402d   v1.31.11
example-cluster-new-c5qqp-worker-b-wrhw4.c.quay-devel.internal   Ready    worker                 401d   v1.31.11
---
    Copy to Clipboard Toggle word wrap

  2. Add the node-role.kubernetes.io/infra= label to the worker nodes by entering the following command. The number of infrastructure nodes required depends on your environment. Production environments should provision enough infra nodes to ensure high availability and sufficient resources for all quay-related components. Monitor CPU, memory, and storage utilization to determine if additional infra nodes are required. 

    $ oc label node --overwrite <infra_node_one> <infra_node_two> <infra_node_three> node-role.kubernetes.io/infra=
    Copy to Clipboard Toggle word wrap

  3. Confirm that the node-role.kubernetes.io/infra= label has been added to the proper nodes by entering the following command: 

    $ oc get node | grep infra
    Copy to Clipboard Toggle word wrap 
    ---
example-cluster-new-c5qqp-worker-b-4zxx5.c.quay-devel.internal   Ready    infra,worker           405d   v1.32.8
example-cluster-new-c5qqp-worker-b-kz6jn.c.quay-devel.internal   Ready    infra,worker           406d   v1.32.8
example-cluster-new-c5qqp-worker-b-wrhw4.c.quay-devel.internal   Ready    infra,worker           405d   v1.32.8
---
    Copy to Clipboard Toggle word wrap

  4. When a worker node is assigned the infra role, there is a chance that user workloads could get inadvertently assigned to an infra node. To avoid this, you can apply a taint to the infra node, and then add tolerations for the pods that you want to control. Taint the worker nodes with the infra label by entering the following command: 

    $ oc adm taint nodes -l node-role.kubernetes.io/infra \
  node-role.kubernetes.io/infra=reserved:NoSchedule --overwrite
    Copy to Clipboard Toggle word wrap

    Example output

    node/example-cluster-new-c5qqp-worker-b-4zxx5.c.quay-devel.internal modified
node/example-cluster-new-c5qqp-worker-b-kz6jn.c.quay-devel.internal modified
node/example-cluster-new-c5qqp-worker-b-wrhw4.c.quay-devel.internal modified
    Copy to Clipboard Toggle word wrap

Use the following procedure to create a project with the node-selector and tolerations annotations.

Procedure

  1. Add the node-selector annotation to the namespace by entering the following command: 

    $ oc annotate namespace <namespace> openshift.io/node-selector='node-role.kubernetes.io/infra='
    Copy to Clipboard Toggle word wrap

    Example output

    namespace/<namespace> annotated
    Copy to Clipboard Toggle word wrap

  2. Add the tolerations annotation to the namespace by entering the following command: 

    $ oc annotate namespace <namespace> scheduler.alpha.kubernetes.io/defaultTolerations='[{"operator":"Equal","value":"reserved","effect":"NoSchedule","key":"node-role.kubernetes.io/infra"},{"operator":"Equal","value":"reserved","effect":"NoExecute","key":"node-role.kubernetes.io/infra"}]' --overwrite
    Copy to Clipboard Toggle word wrap

    Example output

    namespace/<namespace> annotated
    Copy to Clipboard Toggle word wrap

    Important

    The tolerations in this example are specific to two taints commonly applied to infra nodes. The taints configured in your environment might differ. You must set the tolerations accordingly to match the taints applied to your infra nodes.

After you have added the node-role.kubernetes.io/infra= label to worker nodes and added the node-selector and tolerations annotations to the namespace, you must download the Red Hat Quay Operator in that namespace.

The following procedure shows you how to download the Red Hat Quay Operator on the annotated namespace and how to update the subscription to ensure successful installation.

Procedure

  1. On the OpenShift Container Platform web console, click Operators → OperatorHub.
  2. In the search box, type Red Hat Quay.
  3. Click Red Hat Quay → Install.
  4. Select the update channel, for example, stable-3.11 and the version.
  5. Click A specific namespace on the cluster for the installation mode, and then select the namespace that you applied the node-selector and tolerations annotations to.
  6. Click Install.

  1. Confirm that the Operator is installed by entering the following command: 

    $ oc get pods -n <annotated_namespace> -o wide | grep quay-operator
    Copy to Clipboard Toggle word wrap

    Example output

    quay-operator.v3.15.1-858b5c5fdc-lf5kj   1/1     Running   0          29m   10.130.6.18   example-cluster-new-c5qqp-worker-f-mhngl.c.quay-devel.internal   <none>           <none>
    Copy to Clipboard Toggle word wrap

8.4. Creating the Red Hat Quay registry
Copy link

After you have downloaded the Red Hat Quay Operator, you must create the Red Hat Quay registry. The registry’s components, for example, clair, postgres, redis, and so on, must be patched with the toleration annotation so that they can schedule onto the infra worker nodes.

The following procedure shows you how to create a Red Hat Quay registry that runs on infrastructure nodes.

Procedure

  1. On the OpenShift Container Platform web console, click Operators → Installed Operators → Red Hat Quay.
  2. On the Red Hat Quay Operator details page, click Quay Registry → Create QuayRegistry.

  3. On the Create QuayRegistry page, set the monitoring and objectstorage fields to false. The monitoring component cannot be enabled when Red Hat Quay is installed in a single namespace. For example: 

    # ...
    - kind: monitoring
      managed: false
    - kind: objectstorage
      managed: false
# ...
    Copy to Clipboard Toggle word wrap
  4. Click Create.

  1. Optional: Confirm that the pods are running on infra nodes.

    1. List all Quay-related pods along with the nodes that they are scheduled on by entering the following command: 

      $ oc get pods -n <annotated_namespace> -o wide | grep example-registry
      Copy to Clipboard Toggle word wrap

      Example output

      ...
NAME                                               READY   STATUS      RESTARTS   AGE   IP             NODE                                                              NOMINATED NODE   READINESS GATES
example-registry-clair-app-5f95d685bd-dgjf6        1/1     Running     0          52m   10.128.4.12    example-cluster-new-c5qqp-worker-b-wrhw4.c.quay-devel.internal   <none>           <none>
...
      Copy to Clipboard Toggle word wrap

    2. Confirm that the nodes listed include only nodes labeled infra by running the following command: 

      $ oc get nodes -l node-role.kubernetes.io/infra -o name
      Copy to Clipboard Toggle word wrap

      Example output

      node/example-cluster-new-c5qqp-worker-b-4zxx5.c.quay-devel.internal modified
node/example-cluster-new-c5qqp-worker-b-kz6jn.c.quay-devel.internal modified
node/example-cluster-new-c5qqp-worker-b-wrhw4.c.quay-devel.internal modified
      Copy to Clipboard Toggle word wrap

      Note

      If any pod appears on a non-infra node, revisit your namespace annotations and deployment patching.

  2. Restart all pods for the Red Hat Quay registry by entering the following command: 

    $ oc delete pod -n <annotated_namespace> --all
    Copy to Clipboard Toggle word wrap

  3. Check the status of the pods by entering the following command: 

    $ oc get pods -n <annotated_namespace>
    Copy to Clipboard Toggle word wrap

    Example output

    ...
NAME                                               READY   STATUS      RESTARTS   AGE
example-registry-clair-app-5f95d685bd-dgjf6        1/1     Running     0          5m4s
...
    Copy to Clipboard Toggle word wrap

Users can now troubleshoot problems during the deployment phase. The status in the QuayRegistry object can help you monitor the health of the components during the deployment an help you debug any problems that may arise.

Procedure

  1. Enter the following command to check the status of your deployment: 

    $ oc get quayregistry -n quay-enterprise -o yaml
    Copy to Clipboard Toggle word wrap

    Example output

    Immediately after deployment, the QuayRegistry object will show the basic configuration: 

    apiVersion: v1
items:
- apiVersion: quay.redhat.com/v1
  kind: QuayRegistry
  metadata:
    creationTimestamp: "2021-09-14T10:51:22Z"
    generation: 3
    name: example-registry
    namespace: quay-enterprise
    resourceVersion: "50147"
    selfLink: /apis/quay.redhat.com/v1/namespaces/quay-enterprise/quayregistries/example-registry
    uid: e3fc82ba-e716-4646-bb0f-63c26d05e00e
  spec:
    components:
    - kind: postgres
      managed: true
    - kind: clair
      managed: true
    - kind: redis
      managed: true
    - kind: horizontalpodautoscaler
      managed: true
    - kind: objectstorage
      managed: true
    - kind: route
      managed: true
    - kind: mirror
      managed: true
    - kind: monitoring
      managed: true
    - kind: tls
      managed: true
    - kind: clairpostgres
      managed: true
    configBundleSecret: example-registry-config-bundle-kt55s
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""
    Copy to Clipboard Toggle word wrap

  2. Use the oc get pods command to view the current state of the deployed components: 

    $ oc get pods -n quay-enterprise
    Copy to Clipboard Toggle word wrap

    Example output

    NAME                                                   READY   STATUS              RESTARTS   AGE
example-registry-clair-app-86554c6b49-ds7bl            0/1     ContainerCreating   0          2s
example-registry-clair-app-86554c6b49-hxp5s            0/1     Running             1          17s
example-registry-clair-postgres-68d8857899-lbc5n       0/1     ContainerCreating   0          17s
example-registry-quay-app-upgrade-h2v7h                0/1     ContainerCreating   0          9s
example-registry-quay-database-66f495c9bc-wqsjf        0/1     ContainerCreating   0          17s
example-registry-quay-mirror-854c88457b-d845g          0/1     Init:0/1            0          2s
example-registry-quay-mirror-854c88457b-fghxv          0/1     Init:0/1            0          17s
example-registry-quay-postgres-init-bktdt              0/1     Terminating         0          17s
example-registry-quay-redis-f9b9d44bf-4htpz            0/1     ContainerCreating   0          17s
    Copy to Clipboard Toggle word wrap

  3. While the deployment is in progress, the QuayRegistry object will show the current status. In this instance, database migrations are taking place, and other components are waiting until completion: 

      status:
    conditions:
    - lastTransitionTime: "2021-09-14T10:52:04Z"
      lastUpdateTime: "2021-09-14T10:52:04Z"
      message: all objects created/updated successfully
      reason: ComponentsCreationSuccess
      status: "False"
      type: RolloutBlocked
    - lastTransitionTime: "2021-09-14T10:52:05Z"
      lastUpdateTime: "2021-09-14T10:52:05Z"
      message: running database migrations
      reason: MigrationsInProgress
      status: "False"
      type: Available
    lastUpdated: 2021-09-14 10:52:05.371425635 +0000 UTC
    unhealthyComponents:
      clair:
      - lastTransitionTime: "2021-09-14T10:51:32Z"
        lastUpdateTime: "2021-09-14T10:51:32Z"
        message: 'Deployment example-registry-clair-postgres: Deployment does not have minimum availability.'
        reason: MinimumReplicasUnavailable
        status: "False"
        type: Available
      - lastTransitionTime: "2021-09-14T10:51:32Z"
        lastUpdateTime: "2021-09-14T10:51:32Z"
        message: 'Deployment example-registry-clair-app: Deployment does not have minimum availability.'
        reason: MinimumReplicasUnavailable
        status: "False"
        type: Available
      mirror:
      - lastTransitionTime: "2021-09-14T10:51:32Z"
        lastUpdateTime: "2021-09-14T10:51:32Z"
        message: 'Deployment example-registry-quay-mirror: Deployment does not have minimum availability.'
        reason: MinimumReplicasUnavailable
        status: "False"
        type: Available
    Copy to Clipboard Toggle word wrap

  4. When the deployment process finishes successfully, the status in the QuayRegistry object shows no unhealthy components: 

      status:
    conditions:
    - lastTransitionTime: "2021-09-14T10:52:36Z"
      lastUpdateTime: "2021-09-14T10:52:36Z"
      message: all registry component healthchecks passing
      reason: HealthChecksPassing
      status: "True"
      type: Available
    - lastTransitionTime: "2021-09-14T10:52:46Z"
      lastUpdateTime: "2021-09-14T10:52:46Z"
      message: all objects created/updated successfully
      reason: ComponentsCreationSuccess
      status: "False"
      type: RolloutBlocked
    currentVersion: {producty}
    lastUpdated: 2021-09-14 10:52:46.104181633 +0000 UTC
    registryEndpoint: https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org
    unhealthyComponents: {}
    Copy to Clipboard Toggle word wrap
  1. Create a namespace, for example, quay-enterprise.
  2. Select Operators → Installed Operators, then select the Quay Operator to navigate to the Operator detail view.
  3. Click 'Create Instance' on the 'Quay Registry' tile under 'Provided APIs'.
  4. Optionally change the 'Name' of the QuayRegistry. This will affect the hostname of the registry. All other fields have been populated with defaults.
  5. Click 'Create' to submit the QuayRegistry to be deployed by the Quay Operator.
  6. You should be redirected to the QuayRegistry list view. Click on the QuayRegistry you just created to see the details view.
  7. Once the 'Registry Endpoint' has a value, click it to access your new Quay registry via the UI. You can now select 'Create Account' to create a user and sign in.

Use the following procedure to create the first user by the Red Hat Quay UI.

Note

This procedure assumes that the FEATURE_USER_CREATION config option has not been set to false. If it is False, the Create Account functionality on the UI will be disabled, and you will have to use the API to create the first user.

Procedure

  1. In the OpenShift Container Platform console, navigate to Operators → Installed Operators, with the appropriate namespace / project.

  2. Click on the newly installed QuayRegistry object to view the details. For example:

    QuayRegistry details

  3. After the Registry Endpoint has a value, navigate to this URL in your browser.

  4. Select Create Account in the Red Hat Quay registry UI to create a user. For example:

    Create Account

  5. Enter the details for Username, Password, Email, and then click Create Account. For example:

    Enter account details

After creating the first user, you are automatically logged in to the Red Hat Quay registry. For example:

Initial log in

Lifecycle observability for a given Red Hat Quay deployment is reported in the status section of the corresponding QuayRegistry object. The Red Hat Quay Operator constantly updates this section, and this should be the first place to look for any problems or state changes in Red Hat Quay or its managed dependencies.

10.1. Viewing the registry endpoint
Copy link

Once Red Hat Quay is ready to be used, the status.registryEndpoint field will be populated with the publicly available hostname of the registry.

10.2. Viewing the version of Red Hat Quay in use
Copy link

The current version of Red Hat Quay that is running will be reported in status.currentVersion.

Certain conditions will be reported in status.conditions.

After deployment, you can customize the Red Hat Quay application by editing the Red Hat Quay configuration bundle secret spec.configBundleSecret. You can also change the managed status of components and configure resource requests for some components in the spec.components object of the QuayRegistry resource.

Use the following procedure to edit the config bundle secret in the OpenShift Container Platform console.

Procedure

  1. On the Red Hat Quay Registry overview screen, click the link for the Config Bundle Secret.

    Red Hat Quay Registry overview

  2. To edit the secret, click Actions → Edit Secret.

    Edit secret

  3. Modify the configuration and save the changes.

    Save changes

  4. Monitor the deployment to ensure successful completion and that the configuration changes have taken effect.

Use the following procedure to find QuayRegistry endpoints and secrets.

Procedure

  1. You can examine the QuayRegistry resource, using oc describe quayregistry or oc get quayregistry -o yaml, to find the current endpoints and secrets by entering the following command: 

    $ oc get quayregistry example-registry -n quay-enterprise -o yaml
    Copy to Clipboard Toggle word wrap

    Example output

    apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  ...
  name: example-registry
  namespace: quay-enterprise
  ...
spec:
  components:
  - kind: quay
    managed: true
  ...
  - kind: clairpostgres
    managed: true
  configBundleSecret: init-config-bundle-secret
    1 
    
status:
  currentVersion: 3.7.0
  lastUpdated: 2022-05-11 13:28:38.199476938 +0000 UTC
  registryEndpoint: https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org
    2
    Copy to Clipboard Toggle word wrap

    1
    The config bundle secret, containing the config.yaml file and any SSL/TLS certificates.
    2
    The URL for your registry, for browser access to the registry UI, and for the registry API endpoint.

11.3. Downloading the existing configuration
Copy link

The following procedures detail how to download the existing configuration using different strategies.

You can use the config bundle secret to download the existing configuration.

Procedure

  1. Obtain the secret data by entering the following command: 

    $ oc get secret -n quay-enterprise init-config-bundle-secret -o jsonpath='{.data}'
    Copy to Clipboard Toggle word wrap

    Example output

    {
    "config.yaml": "RkVBVFVSRV9VU0 ... MDAwMAo="
}
    Copy to Clipboard Toggle word wrap

  2. Enter the following command to decode the data: 

    $ echo 'RkVBVFVSRV9VU0 ... MDAwMAo=' | base64 --decode
    Copy to Clipboard Toggle word wrap

    Example output

    FEATURE_USER_INITIALIZE: true
BROWSER_API_CALLS_XHR_ONLY: false
SUPER_USERS:
- quayadmin
FEATURE_USER_CREATION: false
FEATURE_QUOTA_MANAGEMENT: true
FEATURE_PROXY_CACHE: true
FEATURE_BUILD_SUPPORT: true
DEFAULT_SYSTEM_REJECT_QUOTA_BYTES: 102400000
    Copy to Clipboard Toggle word wrap

You can configure custom SSL/TLS certificates before the initial deployment, or after Red Hat Quay is deployed on OpenShift Container Platform. This is done by creating or updating the config bundle secret.

If you are adding the certificates to an existing deployment, you must include the existing config.yaml file in the new config bundle secret, even if you are not making any configuration changes.

Use the following procedure to add custom SSL/TLS certificates.

Procedure

  1. In your QuayRegistry YAML file, set kind: tls to managed:false, for example: 

      - kind: tls
    managed: false
    Copy to Clipboard Toggle word wrap

  2. Navigate to the Events page, which should reveal that the change is blocked until you set up the appropriate config. For example: 

        - lastTransitionTime: '2022-03-28T12:56:49Z'
      lastUpdateTime: '2022-03-28T12:56:49Z'
      message: >-
        required component `tls` marked as unmanaged, but `configBundleSecret`
        is missing necessary fields
      reason: ConfigInvalid
      status: 'True'
    Copy to Clipboard Toggle word wrap

  3. Create the secret using embedded data or by using files.

    1. Embed the configuration details directly in the Secret resource YAML file. For example:

      custom-ssl-config-bundle.yaml

      apiVersion: v1
kind: Secret
metadata:
  name: custom-ssl-config-bundle-secret
  namespace: quay-enterprise
data:
  config.yaml: |
    FEATURE_USER_INITIALIZE: true
    BROWSER_API_CALLS_XHR_ONLY: false
    SUPER_USERS:
    - quayadmin
    FEATURE_USER_CREATION: false
    FEATURE_QUOTA_MANAGEMENT: true
    FEATURE_PROXY_CACHE: true
    FEATURE_BUILD_SUPPORT: true
    DEFAULT_SYSTEM_REJECT_QUOTA_BYTES: 102400000
  extra_ca_cert_my-custom-ssl.crt: |
    -----BEGIN CERTIFICATE-----
    MIIDsDCCApigAwIBAgIUCqlzkHjF5i5TXLFy+sepFrZr/UswDQYJKoZIhvcNAQEL
    BQAwbzELMAkGA1UEBhMCSUUxDzANBgNVBAgMBkdBTFdBWTEPMA0GA1UEBwwGR0FM
    ....
    -----END CERTIFICATE-----
      Copy to Clipboard Toggle word wrap

    2. Create the secret from the YAML file: 

      $ oc create  -f custom-ssl-config-bundle.yaml
      Copy to Clipboard Toggle word wrap

      ..

  4. Alternatively, you can create files containing the desired information, and then create the secret from those files.

    1. Enter the following command to create a generic Secret object that contains the config.yaml file and a custom-ssl.crt file: 

      $ oc create secret generic custom-ssl-config-bundle-secret \
  --from-file=config.yaml \
  --from-file=extra_ca_cert_my-custom-ssl.crt=my-custom-ssl.crt
      Copy to Clipboard Toggle word wrap

    2. Create or update the QuayRegistry YAML file, referencing the created Secret, for example:

      Example QuayRegistry YAML file

      apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  configBundleSecret: custom-ssl-config-bundle-secret
      Copy to Clipboard Toggle word wrap

    3. Deploy or update the registry using the YAML file by entering the following command: 

      $ oc apply -f quayregistry.yaml
      Copy to Clipboard Toggle word wrap

Next steps

Legal Notice
Copy link

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat