Chapter 2. Red Hat Quay configuration disclaimer With Red Hat Quay enterprise, certain features and configuration parameters are not actively used or implemented. As a result, feature flags, such as those that enable or disable certain features, and configuration parameters that are not explicitly documented or requested for documentation by Red Hat Support should only be modified with caution. Unused features or parameters might not be fully tested, supported, or compatible with Red Hat Quay, and modifying them could lead to unexpected issues or disruptions with your deployment. 2.1. Configuration updates for Red Hat Quay 3.9 The following sections detail new configuration fields added in Red Hat Quay 3.9. 2.1.1. Action log audit configuration With Red Hat Quay 3.9, audit logins are tracked by default. Table 2.1. Audit logs configuration field Field Type Description ACTION_LOG_AUDIT_LOGINS Boolean When set to True , tracks advanced events such as logging into, and out of, the UI, and logging in using Docker for regular users, robot accounts, and for application-specific token accounts. Default: True 2.1.2. Addition of Splunk action logs With Red Hat Quay 3.9, Splunk can be configured under the LOGS_MODEL parameter. Table 2.2. Splunk configuration fields Field Type Description LOGS_MODEL String Specifies the preferred method for handling log data. Values: One of database , transition_reads_both_writes_es , elasticsearch , splunk Default: database 2.1.2.1. LOGS_MODEL_CONFIG additions The following LOGS_MODEL_CONFIG options are available when configuring Splunk. LOGS_MODEL_CONFIG [object]: Logs model config for action logs producer [string]: splunk splunk_config [object]: Logs model configuration for Splunk action logs or the Splunk cluster configuration host [string]: Splunk cluster endpoint. port [integer]: Splunk management cluster endpoint port. bearer_token [string]: The bearer token for Splunk. verify_ssl [boolean]: Enable ( True ) or disable ( False ) TLS/SSL verification for HTTPS connections. index_prefix [string]: Splunk's index prefix. ssl_ca_path [string]: The relative container path to a single .pem file containing a certificate authority (CA) for SSL validation. 2.1.2.2. Example configuration for Splunk The following YAML entry provides an example configuration for Splunk. Splunk config.yaml example --- LOGS_MODEL: splunk LOGS_MODEL_CONFIG: producer: splunk splunk_config: host: http://<user_name>.remote.csb port: 8089 bearer_token: <bearer_token> url_scheme: <http/https> verify_ssl: False index_prefix: <splunk_log_index_name> ssl_ca_path: <location_to_ssl-ca-cert.pem> --- 2.1.3. Quota management configuration fields The following configuration fields have been added to enhance the Red Hat Quay quota management feature. Table 2.3. Red Hat Quay 3.9 quota management configuration fields Field Type Description QUOTA_BACKFILL Boolean Enables the quota backfill worker to calculate the size of pre-existing blobs. Default : True QUOTA_TOTAL_DELAY_SECONDS String The time delay for starting the quota backfill. Rolling deployments can cause incorrect totals. This field must be set to a time longer than it takes for the rolling deployment to complete. Default : 1800 PERMANENTLY_DELETE_TAGS Boolean Enables functionality related to the removal of tags from the time machine window. Default : False RESET_CHILD_MANIFEST_EXPIRATION Boolean Resets the expirations of temporary tags targeting the child manifests. With this feature set to True , child manifests are immediately garbage collected. Default : False 2.1.3.1. Possible quota management configuration settings The following table explains possible quota management configuration settings in Red Hat Quay 3.9. Table 2.4. Quota management configuration options FEATURE_QUOTA_MANAGEMENT QUOTA_BACKFILL OUTCOME true true With these features configured as true , quota management is enabled and working for Red Hat Quay 3.9. For more information about configuring quota management for Red Hat Quay 3.9, see "Quota management for Red Hat Quay 3.9". true false With FEATURE_QUOTA_MANAGEMENT set to true , and QUOTA_BACKFILL set to false , the quota management feature has been enabled. However, pre-existing images from a prior (N-1) y-stream version of Red Hat Quay (for example, 3.8), must be backfilled before quota calculation can continue. To backfill image sizes, set QUOTA_BACKFILL to true . false false With these features configured as false , the quota management feature is disabled. false true With FEATURE_QUOTA_MANAGEMENT set to false , and QUOTA_BACKFILL set to true , the quota management feature is disabled. 2.1.3.2. Suggested quota management configuration settings The following YAML is the suggested configuration when enabling quota management. Suggested quota management configuration FEATURE_QUOTA_MANAGEMENT: true FEATURE_GARBAGE_COLLECTION: true PERMANENTLY_DELETE_TAGS: true QUOTA_TOTAL_DELAY_SECONDS: 1800 RESET_CHILD_MANIFEST_EXPIRATION: true 2.1.4. PostgreSQL PVC backup environment variable The following environment variable has been added to configure whether Red Hat Quay automatically removes old persistent volume claims (PVCs) when upgrading from version 3.8 3.9: Table 2.5. Red Hat Quay 3.9 PostgreSQL backup environment variable Field Type Description POSTGRES_UPGRADE_RETAIN_BACKUP Boolean When set to True , persistent volume claims from PostgreSQL 10 are backed up. + Default : False 2.1.4.1. Example configuration for PostgreSQL PVC backup The following Subscription object provides an example configuration for backing up PostgreSQL 10 PVCs. Subscription object for PostgreSQL 10 PVCs apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: quay-operator namespace: quay-enterprise spec: channel: stable-3.8 name: quay-operator source: redhat-operators sourceNamespace: openshift-marketplace config: env: - name: POSTGRES_UPGRADE_RETAIN_BACKUP value: "true" 2.2. Editing the configuration file To deploy a standalone instance of Red Hat Quay, you must provide the minimal configuration information. The requirements for a minimal configuration can be found in "Red Hat Quay minimal configuration." After supplying the required fields, you can validate your configuration. If there are any issues, they will be highlighted. Note It is possible to use the configuration API to validate the configuration, but this requires starting the Quay container in configuration mode. For more information, see "Using the configuration tool." For changes to take effect, the registry must be restarted. 2.3. Location of configuration file in a standalone deployment For standalone deployments of Red Hat Quay, the config.yaml file must be specified when starting the Red Hat Quay registry. This file is located in the configuration volume. For example, the configuration file is located at USDQUAY/config/config.yaml when deploying Red Hat Quay by the following command: 2.4. Minimal configuration The following configuration options are required for a standalone deployment of Red Hat Quay: Server hostname HTTP or HTTPS Authentication type, for example, Database or Lightweight Directory Access Protocol (LDAP) Secret keys for encrypting data Storage for images Database for metadata Redis for build logs and user events Tag expiration options 2.4.1. Sample minimal configuration file The following example shows a sample minimal configuration file that uses local storage for images: 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 Note The SETUP_COMPLETE field indicates that the configuration has been validated. You should use the configuration editor tool to validate your configuration before starting the registry. 2.4.2. Local storage Using local storage for images is only recommended when deploying a registry for proof of concept purposes. When configuring local storage, storage is specified on the command line when starting the registry. The following command maps a local directory, USDQUAY/storage to the datastorage path in the container: 2.4.3. Cloud storage Storage configuration is detailed in the Image storage section. For some users, it might be useful to compare the difference between Google Cloud Platform and local storage configurations. For example, the following YAML presents a Google Cloud Platform storage configuration: USDQUAY/config/config.yaml DISTRIBUTED_STORAGE_CONFIG: default: - GoogleCloudStorage - access_key: GOOGQIMFB3ABCDEFGHIJKLMN bucket_name: quay_bucket secret_key: FhDAYe2HeuAKfvZCAGyOioNaaRABCDEFGHIJKLMN storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - default When starting the registry using cloud storage, no configuration is required on the command line. For example:

Commands:
--- LOGS_MODEL: splunk LOGS_MODEL_CONFIG: producer: splunk splunk_config: host: http://<user_name>.remote.csb port: 8089 bearer_token: <bearer_token> url_scheme: <http/https> verify_ssl: False index_prefix: <splunk_log_index_name> ssl_ca_path: <location_to_ssl-ca-cert.pem> ---
FEATURE_QUOTA_MANAGEMENT: true FEATURE_GARBAGE_COLLECTION: true PERMANENTLY_DELETE_TAGS: true QUOTA_TOTAL_DELAY_SECONDS: 1800 RESET_CHILD_MANIFEST_EXPIRATION: true
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: quay-operator namespace: quay-enterprise spec: channel: stable-3.8 name: quay-operator source: redhat-operators sourceNamespace: openshift-marketplace config: env: - name: POSTGRES_UPGRADE_RETAIN_BACKUP value: "true"
sudo podman run -d --rm -p 80:8080 -p 443:8443 --name=quay -v USDQUAY/config:/conf/stack:Z -v USDQUAY/storage:/datastorage:Z registry.redhat.io/quay/quay-rhel8:v3.9.10
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
sudo podman run -d --rm -p 80:8080 -p 443:8443 --name=quay -v USDQUAY/config:/conf/stack:Z -v USDQUAY/storage:/datastorage:Z registry.redhat.io/quay/quay-rhel8:v3.9.10
DISTRIBUTED_STORAGE_CONFIG: default: - GoogleCloudStorage - access_key: GOOGQIMFB3ABCDEFGHIJKLMN bucket_name: quay_bucket secret_key: FhDAYe2HeuAKfvZCAGyOioNaaRABCDEFGHIJKLMN storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - default
sudo podman run -d --rm -p 80:8080 -p 443:8443 --name=quay -v USDQUAY/config:/conf/stack:Z registry.redhat.io/quay/quay-rhel8:v3.9.10