红帽全球峰会此内容没有您所选择的语言版本。
Chapter 5. Customizing your Red Hat Quay cluster
Although you can run a default Red Hat Quay setup by simply creating a secret and the QuayEcosystem custom resource, the following sections describe how you can modify the default setup. Some of those modifications must be made when you deploy the QuayEcosystem, while others can be done after the cluster is running.
5.1. Changing your Red Hat Quay credentials
The Red Hat Quay Setup Operator sets up default administrative credentials. Review the default superuser and configuration credentials and change as needed.
5.1.1. Red Hat Quay superuser credentials
The Red Hat Quay superuser credentials let you manage the users, projects and other components of your Red Hat Quay deployment. Here’s how superuser credentials are set by default:
-
Username:
quay -
Password:
password -
Email:
quay@redhat.com
To change the superuser credentials, create a new secret:
$ oc create secret generic <secret_name> \
--from-literal=superuser-username=<username> \
--from-literal=superuser-password=<password> \
--from-literal=superuser-email=<email>The superuser password must be at least 8 characters.
5.1.2. Red Hat Quay configuration credentials
A dedicated Red Hat Quay deployment runs to manage Red Hat Quay configuration settings. Using the route to that configuration, you log in with the following credentials:
-
Username:
quayconfig -
Password:
quay
You cannot change the username, but you can change the password as follows:
$ oc create secret generic quay-config-app \
--from-literal=config-app-password=<password>
The PostgreSQL relational database is used by default as the persistent store for Red Hat Quay. PostgreSQL can either be deployed by the Operator within the namespace or leverage an existing instance. The determination of whether to provision an instance or not within the current namespace depends on whether the server property within the QuayEcosystem is defined.
The following options are a portion of the available options to configure the PostgreSQL database:
| Property | Description |
| image | Location of the database image |
| volumeSize | Size of the volume in Kubernetes capacity units |
It is important to note that persistent storage for the database will only be provisioned if the volumeSize property is specified when provisioned by the operator.
Define the values as shown below:
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
imagePullSecretName: redhat-pull-secret
database:
volumeSize: 10Gi5.3. Specifying database credentials
The credentials for accessing the server can be specified through a Secret or when being provisioned by the operator, leverage the following default values:
-
Username:
quay -
Password:
quay -
Root Password:
quayAdmin -
Database Name:
quay
To define alternate values, create a secret as shown below:
oc create secret generic <secret_name> \
--from-literal=database-username=<username> \
--from-literal=database-password=<password> \
--from-literal=database-root-password=<root-password> \
--from-literal=database-name=<database-name>
Reference the name of the secret in the QuayEcosystem custom resource as shown below:
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
imagePullSecretName: redhat-pull-secret
database:
credentialsSecretName: <secret_name>5.3.1. Using an existing PostgreSQL database instance
Instead of having the operator deploy an instance of PostgreSQL in the project, an existing instance can be leveraged by specifying the location in the server field along with the credentials for access as described in the previous section. The following is an example of how to specify connecting to a remote PostgreSQL instance:
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
imagePullSecretName: redhat-pull-secret
database:
credentialsSecretName: <secret_name>
server: postgresql.databases.example.com5.4. Choosing a registry storage backend
Red Hat Quay supports multiple backends for the purpose of image storage and consist of a variety of local and cloud storage options. The following sections provide an overview how to configure the Red Hat Quay Setup Operator to make use of these backends.
5.4.1. Overview of storage backends
Storage for Red Hat Quay can be configured using the registryBackend field within the quay property in the QuayEcosystem resource which contain an array of backends. The ability to define multiple backends enables replication and high availability of images.
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadaLocalStorageta:
name: example-quayecosystem
spec:
quay:
registryBackends:
- name: backend1
s3:
...
The definition of a registryBackend is an optional field, and if omitted, LocalStorage will be configured (ephemeral, through the use of a PersistentVolume, can be enabled if desired).
5.4.2. Sensitive storage values
In many cases, access to storage requires the use of sensitive values. Each backend that requires such configuration can be included in a Secret and defined within the credentialsSecretName property of the backend.
Instead of declaring the registry backend properties within the specific backend, the values can be added to a secret as shown below:
oc create secret generic s3-credentials \
--from-literal=accessKey=<accessKey> \
--from-literal=secretKey=<secretKey>With the values now present in the secret, the properties explicitly declared in the backend can be removed.
Specific details on the types of properties supported for each backend are found in the registry backend details below.
5.4.3. Storage replication
Support is available to replicate the registry storage to multiple backends. To activate storage replication, set the enableStorageReplication property to the value of true. Individual registry backends can also be configured to be replicated by default by setting the replicateByDefault property to the value of true. A full configuration demonstrating the replication options available is shown below:
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
enableStorageReplication: true
registryBackends:
- name: azure-ussouthcentral
credentialsSecretName: azure-ussouthcentral-registry
replicateByDefault: true
azure:
containerName: quay
- name: azure-seasia
credentialsSecretName: azure-seasia-registry
replicateByDefault: true
azure:
containerName: quaySupport for replicated storage is not available for the local registry backend and will result in an error during the verification phase.
5.4.4. Registry storage backend types
One or more of the following registry storage backends can be defined to specify the underlying storage for the Red Hat Quay registry:
5.4.4.1. Local Storage
The following is an example for configuring the registry to make use of local storage:
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
registryBackends:
- name: local
local:
storagePath: /opt/quayregistry
The following is a comprehensive list of properties for the local registry backend:
| Property | Description | Credential Secret Supported | Required |
| storagePath | Storage Directory | No | No |
5.4.4.2. Configuring persistent local storage
By default, Red Hat Quay uses an ephemeral volume for local storage. In order to avoid data loss, persistent storage is required. To enable the use of a PersistentVolume to store images, specify the registryStorage parameter underneath the quay property.
The following example will cause a PersistentVolumeClaim to be created within the project requesting storage of 10Gi and an access mode of ReadWriteOnce. The default value is ReadWriteMany.
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
imagePullSecretName: redhat-pull-secret
registryStorage:
persistentVolumeAccessModes:
- ReadWriteOnce
persistentVolumeSize: 10Gi
A Storage Class can also be provided using the persistentVolumeStorageClassName property.
5.4.4.3. Amazon Web Services (S3)
The following is an example for configuring the registry to make use of S3 storage on Amazon Web Services.
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
registryBackends:
- name: s3
s3:
accessKey: <accessKey>
bucketName: <bucketName>
secretKey: <secretKey
host: <host>
The following is a comprehensive list of properties for the s3 registry backend:
| Property | Description | Credential Secret Supported | Required |
| storagePath | Storage Directory | No | No |
| bucketName | S3 Bucket | No | Yes |
| accessKey | AWS Access Key | Yes | Yes |
| secretKey | AWS Secret Key | Yes | Yes |
| host | S3 Host | No | No |
| port | S3 Port | No | No |
5.4.4.4. Microsoft Azure storage
The following is an example for configuring the registry to make use of Blob storage on the Microsoft Azure platform.
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
registryBackends:
- name: azure
azure:
containerName: <containerName>
accountName: <accountName>
accountKey: <accountKey>
The following is a comprehensive list of properties for the azure registry backend:
| Property | Description | Credential Secret Suppazureorted | Required |
| storagePath | Storage Directory | No | No |
| containerName | Azure Storage Container | No | Yes |
| accountName | Azure Account Name | No | Yes |
| accountKey | Azure Account Key | No | Yes |
| sas_token | Azure SAS Token | No | No |
5.4.4.5. Google Cloud storage
The following is an example for configuring the registry to make use of Blob storage on the Google Cloud Platform.
apiVersion: redhatcop.redhat.io/v1alpha1azure
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
registryBackends:
- name: googleCloud
googleCloud:
accessKey: <accessKey>
secretKey: <secretKey>
bucketName: <bucketName>
The following is a comprehensive list of properties for the googlecloud registry backend:
| Property | Description | Credential Secret Supported | Required |
| storagePath | Storage Directory | No | No |
| accessKey | Cloud Access Key | Yes | Yes |
| secretKey | Cloud Secret Key | Yes | Yes |
| bucketName | GCS Bucket | No | Yes |
5.4.4.6. NooBaa (RHOCS) storage
The following is an example for configuring the registry to make use of NooBaa (Red Hat OpenShift Container Storage) storage.
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
registryBackends:
- name: rhocs
rhocs:
hostname: <hostname>
secure: <secure>
accessKey: <accessKey>
secretKey: <secretKey>
bucketName: <bucketName>
The following is a comprehensive list of properties for the rhocs registry backend:
| Property | Description | Credential Secret Supported | Required |
| storagePath | Storage Directory | No | No |
| hostname | NooBaa Server Hostname | No | Yes |
| port | Custom Port | No | No |
| secure | Is Secure | No | No |
| secretKey | Secret Key | Yes | Yes |
| bucketName | Bucket Name | No | Yes |
5.4.4.7. RADOS storage
The following is an example for configuring the registry to make use of RADOS storage.
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
registryBackends:
- name: rados
rhocs:
hostname: <hostname>
secure: <is_secure>
accessKey: <accessKey>
secretKey: <secretKey>
bucketName: <bucketName>
The following is a comprehensive list of properties for the rados registry backend:
| Property | Description | Credential Secret Supported | Required |
| storagePath | Storage Directory | No | No |
| hostname | Rados Server Hostname | No | Yes |
| port | Custom Port | No | No |
| secure | Is Secure | No | No |
| accessKey | Access Key | Yes | Yes |
| secretKey | Secret Key | Yes | Yes |
| bucketName | Bucket Name | No | Yes |
5.4.4.8. Swift (OpenStack) storage
The following is an example for configuring the registry to make use of Swift storage.
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
registryBackends:
- name: swift
rhocs:
authVersion: <authVersion>
authURL: <authURL>
container: <container>
user: <user>
password: <password>
caCertPath: <caCertPath>
osOptions:
object_storage_url: <object_storage_url>
user_domain_name: <user_domain_name>
project_id: <project_id>
The following is a comprehensive list of properties for the swift registry backend:
| Property | Description | Credential Secret Supported | Required |
| storagePath | Storage Directory | No | No |
| authVersion | Swift Auth Version | No | Yes |
| authURL | Swift Auth URL | No | Yes |
| container | Swift Container Name | No | Yes |
| user | Username | Yes | Yes |
| password | Key/Password | Yes | Yes |
| caCertPath | CA Cert Filename | No | No |
| tempURLKey | Temp URL Key | No | No |
| osOptions | OS Options | No | No |
5.4.4.9. CloudFront (S3) storage
The following is an example for configuring the registry to make use of S3 storage on Amazon Web Services.
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
registryBackends:
- name: s3
s3:
accessKey: <accessKey>
bucketName: <bucketName>
secretKey: <secretKey>
host: <host>
distributionDomain: <distributionDomain>
key_ID: <key_ID>
privateKeyFilename: <privateKeyFilename>
The following is a comprehensive list of properties for the cloudfrontS3 registry backend:
| Property | Description | Credential Secret Supported | Required |
| storagePath | Storage Directory | No | No |
| bucketName | S3 Bucket | No | Yes |
| accessKey | AWS Access Key | Yes | Yes |
| secretKey | AWS Secret Key | Yes | Yes |
| host | S3 Host | No | No |
| port | S3 Port | No | No |
| distributionDomain | CloudFront Distribution Domain Name | No | Yes |
| keyID | CloudFront Key ID | No | Yes |
| privateKeyFilename | CloudFront Private Key | No | Yes |
5.5. Injecting configuration files
Files related to the configuration of Red Hat Quay are located in the /conf/stack directory. There are situations for which additional user-defined configuration files need to be added to this directory (such as certificates and private keys). For Red Hat Quay deployments not managed by the Operator, these files are managed by the Red Hat Quay config tool.
The Red Hat Quay Setup Operator supports the injection of these assets within the configFiles property in the quay property of the QuayEcosystem object where one or more assets can be specified.
Two types of configuration files can be specified by the type property:
-
config: Configuration files that will be added to the
/conf/stackdirectory - extraCaCerts: Certificates to be trusted by the quay container
Configuration files are stored as values within Secrets. The first step is to create a secret containing these files. The following command illustrates how a private key can be added:
$ oc create secret generic quayconfigfile --from-file=<path_to_file>
With the secret created, the secret containing the configuration file can be referenced in the QuayEcosystem object as shown below:
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
configFiles:
- secretName: quayconfigfile
By default, the config type is assumed. If the contents of the secret contains certificates that should be added to the extra_ca_certs directory, specify the type as extraCaCert as shown below:
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
configFiles:
- secretName: quayconfigfile
type: extraCaCert
Individual keys within a secret can be referenced to fine tune the resources that are added to the configuration using the files property as shown below:
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
configFiles:
- secretName: quayconfigfile
files:
- key: myprivatekey.pem
filename: cloudfront.pemQuay
- key: myExtraCaCert.crt
type: extraCaCert
The example above assumes that two files have been added to a secret called quayconfigfile. The file myprivatekey.pem that was added to the secret will be mounted in the quay pod at the path /conf/stack/cloudfront.pem since it is a config file type and specifies a custom filename that should be projected into the pod. The myExtraCaCert.crt file will be added to the Quay pod within at the path /conf/stack/extra_certs/myExtraCert.crt
The type property within files property overrides the value in the configFiles property.
5.6. Skipping automated setup
The operator by default is configured to complete the automated setup process for Red Hat Quay. This can be bypassed by setting the skipSetup field to true as shown below:
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
imagePullSecretName: redhat-pull-secret
skipSetup: true5.7. Providing SSL certificates
Red Hat Quay, as a secure registry, makes use of SSL certificates to secure communication between the various components within the ecosystem. Transport to the Quay user interface and container registry is secured via SSL certificates. These certificates are generated at startup with the OpenShift route being configured with a TLS termination type of Passthrough.
5.7.1. User provided certificates
SSL certificates can be provided and used instead of having the operator generate certificates. Certificates can be provided in a secret which is then referenced in the QuayEcosystem custom resource.
The secret containing custom certificates must define the following keys:
- ssl.cert: All of the certificates (root, intermediate, certificate) concatinated into a single file
- ssl.key: Private key as for the SSL certificate
Create a secret containing the certificate and private key:
oc create secret generic custom-quay-ssl \
--from-file=ssl.key=<ssl_private_key> \
--from-file=ssl.cert=<ssl_certificate>
The secret containing the certificates are referenced using the sslCertificatesSecretName property as shown below:
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
imagePullSecretName: redhat-pull-secret
sslCertificatesSecretName: custom-quay-ssl5.8. Specifying the Red Hat Quay route
Red Hat Quay makes use of an OpenShift route to enable ingress. The hostname for this route is automatically generated as per the configuration of the OpenShift cluster. Alternatively, the hostname for this route can be explicitly specified using the hostname property under the quay field as shown below:
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
hostname: example-quayecosystem-quay-quay-enterprise.apps.openshift.example.com
imagePullSecretName: redhat-pull-secret5.9. Specifying a Red Hat Quay configuration route
During the development process, you may want to test the provisioning and setup of Red Hat Quay. By default, the Operator will use the internal service to communicate with the configuration pod. However, when running external to the cluster, you will need to specify the ingress location for which the setup process can use.
Specify the configHostname as shown below:
apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
name: example-quayecosystem
spec:
quay:
configHostname: example-quayecosystem-quay-config-quay-enterprise.apps.openshift.example.com
imagePullSecretName: redhat-pull-secret
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}