홈
제품
Red Hat Quay
3.14
Configure Red Hat Quay
Chapter 5. Red Hat Quay on OpenShift Container Platform configuration overview

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 5. Red Hat Quay on OpenShift Container Platform configuration overview

When deploying Red Hat Quay using the Operator on OpenShift Container Platform, configuration is managed declaratively through the QuayRegistry custom resource (CR). This model allows cluster administrators to define the desired state of the Red Hat Quay deployment, including which components are enabled, storage backends, SSL/TLS configuration, and other core features.

After deploying Red Hat Quay on OpenShift Container Platform with the Operator, administrators can further customize their registry by updating the config.yaml file and referencing it in a Kubernetes secret. This configuration bundle is linked to the QuayRegistry CR through the configBundleSecret field.

The Operator reconciles the state defined in the QuayRegistry CR and its associated configuration, automatically deploying or updating registry components as needed.

This guide covers the basic concepts behind the QuayRegistry CR and modifying your config.yaml file on Red Hat Quay on OpenShift Container Platform deployments. More advanced topics, such as using unmanaged components within the QuayRegistry CR, can be found in Deploying Red Hat Quay Operator on OpenShift Container Platform.

5.1. Understanding the QuayRegistry CR

By default, the QuayRegistry CR contains the following key fields:

configBundleSecret: The name of a Kubernetes Secret containing the config.yaml file which defines additional configuration parameters.
name: The name of your Red Hat Quay registry.
namespace: The namespace, or project, in which the registry was created.
spec.components: A list of component that the Operator automatically manages. Each spec.component field contains two fields:
- kind: The name of the component
- managed: A boolean that addresses whether the component lifecycle is handled by the Red Hat Quay Operator. Setting managed: true to a component in the QuayRegistry CR means that the Operator manages the component.

All QuayRegistry components are automatically managed and auto-filled upon reconciliation for visibility unless specified otherwise. The following sections highlight the major QuayRegistry components and provide an example YAML file that shows the default settings.

5.2. Managed components

By default, the Operator handles all required configuration and installation needed for Red Hat Quay’s 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 Using unmanaged components.

Table 5.1. QuayRegistry required fields
Field	Type	Description
`quay`	Boolean	Holds overrides for deployment of Red Hat Quay on OpenShift Container Platform, such as environment variables and number of replicas. This component cannot be set to unmanaged (`managed: false`).
`postgres`	Boolean	Used for storing registry metadata. Currently, PostgreSQL version 13 is used.
`clair`	Boolean	Provides image vulnerability scanning.
`redis`	Boolean	Storage live builder logs and the locking mechanism that is required for garbage collection.
`horizontalpodautoscaler`	Boolean	Adjusts the number of `quay` pods depending on your memory and CPU consumption.
`objectstorage`	Boolean	Stores image layer blobs. When set to `managed: true`, utilizes the `ObjectBucketClaim` Kubernetes API which is provided by NooBaa or Red Hat OpenShift Data Foundation. Setting this field to `managed: false` requires you to provide your own object storage.
`route`	Boolean	Provides an external entrypoint to the Red Hat Quay registry from outside of OpenShift Container Platform.
`mirror`	Boolean	Configures repository mirror workers to support optional repository mirroring.
`monitoring`	Boolean	Features include a Grafana dashboard, access to individual metrics, and notifications for frequently restarting `quay` pods.
`tls`	Boolean	Configures whether SSL/TLS is automatically handled.
`clairpostgres`	Boolean	Configures a managed Clair database. This is a separate database than the PostgreSQL database that is used to deploy Red Hat Quay.

The following example shows you the default configuration for the QuayRegistry custom resource provided by the Red Hat Quay Operator. It is available on the OpenShift Container Platform web console.

Example QuayRegistry custom resource

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: <example_registry>
  namespace: <namespace>
  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

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: <example_registry>
  namespace: <namespace>
  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

5.3. Modifying the QuayRegistry CR after deployment

After you have installed the Red Hat Quay Operator and created an initial deployment, you can modify the QuayRegistry custom resource (CR) to customize or reconfigure aspects of the Red Hat Quay environment.

Red Hat Quay administrators might modify the QuayRegistry CR for the following reasons:

To change component management: Switch components from managed: true to managed: false in order to bring your own infrastructure. For example, you might set kind: objectstorage to unmanaged to integrate external object storage platforms such as Google Cloud Storage or Nutanix.
To apply custom configuration: Update or replace the configBundleSecret to apply new configuration settings, for example, authentication providers, external SSL/TLS settings, feature flags.
To enable or disable features: Toggle features like repository mirroring, Clair scanning, or horizontal pod autoscaling by modifying the spec.components list.
To scale the deployment: Adjust environment variables or replica counts for the Quay application.
To integrate with external services: Provide configuration for external PostgreSQL, Redis, or Clair databases, and update endpoints or credentials.

5.3.1. Modifying the QuayRegistry CR by using the OpenShift Container Platform web console

The QuayRegistry can be modified by using the OpenShift Container Platform web console. This allows you to set managed components to unamanged (managed: false) and use your own infrastructure.

Prerequisites

You are logged into OpenShift Container Platform as a user with admin privileges.
You have installed the Red Hat Quay Operator.

Procedure

On the OpenShift Container Platform web console, click Operators Installed Operators.
Click Red Hat Quay.
Click Quay Registry.
Click the name of your Red Hat Quay registry, for example, example-registry.
Click YAML.
Adjust the managed field of the desired component to either true or false.
Click Save.
Note
Setting a component to unmanaged (managed: false) might require additional configuration. For more information about setting unmanaged components in the QuayRegistry CR, see Using unmanaged components for dependencies.

5.3.2. Modifying the QuayRegistry CR by using the CLI

The QuayRegistry CR can be modified by using the CLI. This allows you to set managed components to unamanged (managed: false) and use your own infrastructure.

Prerequisites

You are logged in to your OpenShift Container Platform cluster as a user with admin privileges.

Procedure

Edit the QuayRegistry CR by entering the following command:

oc edit quayregistry <registry_name> -n <namespace>

$ oc edit quayregistry <registry_name> -n <namespace>

Copy to Clipboard

Make the desired changes to the QuayRegistry CR.
Note
Setting a component to unmanaged (managed: false) might require additional configuration. For more information about setting unmanaged components in the QuayRegistry CR, see Using unmanaged components for dependencies.
Save the changes.

5.3.3. Understanding the configBundleSecret

The spec.configBundleSecret field is an optional reference to the name of a Secret in the same namespace as the QuayRegistry resource. This Secret must contain a config.yaml key/value pair, where the value is a Red Hat Quay configuration file.

The configBundleSecret stores the config.yaml file. Red Hat Quay administrators can define the following settings through the config.yaml file:

Authentication backends (for example, OIDC, LDAP)
External TLS termination settings
Repository creation policies
Feature flags
Notification settings

Red Hat Quay might update this secret for the following reasons:

Enable a new authentication method
Add custom SSL/TLS certificates
Enable features
Modify security scanning settings

If this field is omitted, the Red Hat Quay Operator automatically generates a configuration secret based on default values and managed component settings. If the field is provided, the contents of the config.yaml are used as the base configuration and are merged with values from managed components to form the final configuration, which is mounted into the quay application pods.

How the QuayRegistry CR is configured determines which fields must be included in the configBundleSecret’s `config.yaml file for Red Hat Quay on OpenShift Container Platform. The following example shows you a default config.yaml file when all components are managed by the Operator. Note that this example looks different depending on whether components are managed or unmanaged (managed: false).

Example YAML with all components managed by the Operator

ALLOW_PULLS_WITHOUT_STRICT_LOGGING: false
AUTHENTICATION_TYPE: Database
DEFAULT_TAG_EXPIRATION: 2w
ENTERPRISE_LOGO_URL: /static/img/RH_Logo_Quay_Black_UX-horizontal.svg
FEATURE_BUILD_SUPPORT: false
FEATURE_DIRECT_LOGIN: true
FEATURE_MAILING: false
REGISTRY_TITLE: Red Hat Quay
REGISTRY_TITLE_SHORT: Red Hat Quay
SETUP_COMPLETE: true
TAG_EXPIRATION_OPTIONS:
- 2w
TEAM_RESYNC_STALE_TIME: 60m
TESTING: false

ALLOW_PULLS_WITHOUT_STRICT_LOGGING: false
AUTHENTICATION_TYPE: Database
DEFAULT_TAG_EXPIRATION: 2w
ENTERPRISE_LOGO_URL: /static/img/RH_Logo_Quay_Black_UX-horizontal.svg
FEATURE_BUILD_SUPPORT: false
FEATURE_DIRECT_LOGIN: true
FEATURE_MAILING: false
REGISTRY_TITLE: Red Hat Quay
REGISTRY_TITLE_SHORT: Red Hat Quay
SETUP_COMPLETE: true
TAG_EXPIRATION_OPTIONS:
- 2w
TEAM_RESYNC_STALE_TIME: 60m
TESTING: false

Copy to Clipboard

In some cases, you might opt to manage certain components yourself, for example, object storage. In that scenario, you would modify the QuayRegistry CR as follows:

Unmanaged objectstorage component

# ...
    - kind: objectstorage
      managed: false
# ...

# ...
    - kind: objectstorage
      managed: false
# ...

Copy to Clipboard

If you are managing your own components, your deployment must be configured to include the necessary information or resources for that component. For example, if the objectstorage component is set to managed: false, you would include the relevant information depending on your storage provider inside of the config.yaml file. The following example shows you a distributed storage configuration using Google Cloud Storage:

Required information when objectstorage is unmanaged

# ...
DISTRIBUTED_STORAGE_CONFIG:
    default:
        - GoogleCloudStorage
        - access_key: <access_key>
          bucket_name: <bucket_name>
          secret_key: <secret_key>
          storage_path: /datastorage/registry
# ...

# ...
DISTRIBUTED_STORAGE_CONFIG:
    default:
        - GoogleCloudStorage
        - access_key: <access_key>
          bucket_name: <bucket_name>
          secret_key: <secret_key>
          storage_path: /datastorage/registry
# ...

Copy to Clipboard

Similarly, if you are managing the horizontalpodautoscaler component, you must create an accompanying HorizontalPodAutoscaler custom resource.

5.3.3.1. Modifying the configuration file by using the OpenShift Container Platform web console

Use the following procedure to modify the config.yaml file that is stored by the configBundleSecret by using the OpenShift Container Platform web console.

Prerequisites

You are logged in to the OpenShift Container Platform cluster as a user with admin privileges.

Procedure

On the OpenShift Container Platform web console, click Operators Installed Operators Red Hat Quay.
Click Quay Registry.
Click the name of your Red Hat Quay registry, for example, example-registry.
On the QuayRegistry details page, click the name of your Config Bundle Secret, for example, example-registry-config-bundle.
Click Actions Edit Secret.
In the Value box, add the desired key/value pair. For example, to add a superuser to your Red Hat Quay on OpenShift Container Platform deployment, add the following reference:
```
SUPER_USERS:
- quayadmin
```
```
SUPER_USERS:
- quayadmin
```
Copy to Clipboard
Click Save.

Verification

Verify that the changes have been accepted:
1. On the OpenShift Container Platform web console, click Operators Installed Operators Red Hat Quay.
2. Click Quay Registry.
3. Click the name of your Red Hat Quay registry, for example, example-registry.
4. Click Events. If successful, the following message is displayed:
  All objects created/updated successfully
  Copy to Clipboard

Note

You must base64 encode any updated config.yaml before placing it in the Secret. Ensure the Secret name matches the value specified in spec.configBundleSecret. Once the Secret is updated, the Operator detects the change and automatically rolls out updates to the Red Hat Quay pods.

For detailed steps, see "Updating configuration secrets through the Red Hat Quay UI."

5.3.3.2. Modifying the configuration file by using the CLI

You can modify the config.yaml file that is stored by the configBundleSecret by downloading the existing configuration using the CLI. After making changes, you can re-upload the configBundleSecret resource to make changes to the Red Hat Quay registry.

Note

Modifying the config.yaml file that is stored by the configBundleSecret resource is a multi-step procedure that requires base64 decoding the existing configuration file and then uploading the changes. For most cases, using the OpenShift Container Platform web console to make changes to the config.yaml file is simpler.

Prerequisites

You are logged in to the OpenShift Container Platform cluster as a user with admin privileges.

Procedure

Describe the QuayRegistry resource by entering the following command:

oc describe quayregistry -n <quay_namespace>

$ oc describe quayregistry -n <quay_namespace>

Copy to Clipboard

...
...

# ...
  Config Bundle Secret:  example-registry-config-bundle-v123x
# ...

Copy to Clipboard

Obtain the secret data by entering the following command:

oc get secret -n <quay_namespace> <example-registry-config-bundle-v123x> -o jsonpath='{.data}'

$ oc get secret -n <quay_namespace> <example-registry-config-bundle-v123x> -o jsonpath='{.data}'

Copy to Clipboard

Example output

{
    "config.yaml": "RkVBVFVSRV9VU0 ... MDAwMAo="
}

{
    "config.yaml": "RkVBVFVSRV9VU0 ... MDAwMAo="
}

Copy to Clipboard

Decode the data into a YAML file into the current directory by passing in the >> config.yaml flag. For example:

echo 'RkVBVFVSRV9VU0 ... MDAwMAo=' | base64 --decode >> config.yaml

$ echo 'RkVBVFVSRV9VU0 ... MDAwMAo=' | base64 --decode >> config.yaml

Copy to Clipboard

Make the desired changes to your config.yaml file, and then save the file as config.yaml.
Create a new configBundleSecret YAML by entering the following command.
```
touch <new_configBundleSecret_name>.yaml
```
```
$ touch <new_configBundleSecret_name>.yaml
```
Copy to Clipboard

Create the new configBundleSecret resource, passing in the config.yaml file` by entering the following command:

oc -n <namespace> create secret generic <secret_name> \
  --from-file=config.yaml=</path/to/config.yaml> \
  --dry-run=client -o yaml > <new_configBundleSecret_name>.yaml

$ oc -n <namespace> create secret generic <secret_name> \
  --from-file=config.yaml=</path/to/config.yaml> \


  --dry-run=client -o yaml > <new_configBundleSecret_name>.yaml

Copy to Clipboard

1: Where <config.yaml> is your base64 decoded config.yaml file.

Create the configBundleSecret resource by entering the following command:

oc create -n <namespace> -f <new_configBundleSecret_name>.yaml

$ oc create -n <namespace> -f <new_configBundleSecret_name>.yaml

Copy to Clipboard

Example output

secret/config-bundle created

secret/config-bundle created

Copy to Clipboard

Update the QuayRegistry YAML file to reference the new configBundleSecret object by entering the following command:

oc patch quayregistry <registry_name> -n <namespace> --type=merge -p '{"spec":{"configBundleSecret":"<new_configBundleSecret_name>"}}'

$ oc patch quayregistry <registry_name> -n <namespace> --type=merge -p '{"spec":{"configBundleSecret":"<new_configBundleSecret_name>"}}'

Copy to Clipboard

Example output

quayregistry.quay.redhat.com/example-registry patched

quayregistry.quay.redhat.com/example-registry patched

Copy to Clipboard

Verification

Verify that the QuayRegistry CR has been updated with the new configBundleSecret:
```
oc describe quayregistry -n <quay_namespace>
```
```
$ oc describe quayregistry -n <quay_namespace>
```
Copy to Clipboard
Example output
```
...
...
```
```
# ...
  Config Bundle Secret: <new_configBundleSecret_name>
# ...
```
Copy to Clipboard
After patching the registry, the Red Hat Quay Operator automatically reconciles the changes.

맨 위로 이동

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 5. Red Hat Quay on OpenShift Container Platform configuration overview

5.1. Understanding the QuayRegistry CR

5.2. Managed components

5.3. Modifying the QuayRegistry CR after deployment

5.3.1. Modifying the QuayRegistry CR by using the OpenShift Container Platform web console

5.3.2. Modifying the QuayRegistry CR by using the CLI

5.3.3. Understanding the configBundleSecret

5.3.3.1. Modifying the configuration file by using the OpenShift Container Platform web console

5.3.3.2. Modifying the configuration file by using the CLI

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 소개

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links