Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 6. Configuration deployment after initial setup

By default, the Red Hat Quay Config Tool pod is left running even after the initial setup process. To configure the Config Tool pod to be removed after setup, the keepConfigDeployment property within the Red Hat Quay object can can be set as false as shown below: 

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    keepConfigDeployment: false
Copy to Clipboard Toggle word wrap

6.1. Superusers
Copy link

Superusers in Quay have elevated rights and the ability to administer the server. By default, a superuser with the username quay will be created. Additional superusers may be desired in order to aid in managing the server. The full list of superusers can be specifed in the superusers field of the quay object as shown below: 

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    superusers:
      - jim
      - joe
Copy to Clipboard Toggle word wrap

If multiple superusers are specified, during the initial setup of Red Hat Quay, the first user specified will be configured unless specified within a secret as described earlier. After the initial setup, passwords are managed within Red Hat Quay itself and not using either the default value or the value provided in the secret.

6.2. Setting Redis password
Copy link

By default, the operator-managed Redis instance is deployed without a password. A password can be specified by creating a secret containing the password in the key password. The following command can be used to create the secret: 

$ oc create secret generic <secret_name> \
   --from-literal=password=<password>
Copy to Clipboard Toggle word wrap

The secret can then be specified within the redis section using the credentialsSecretName as shown below: 

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  redis:
    credentialsSecretName: <secret_name>
Copy to Clipboard Toggle word wrap

6.3. Enabling Clair image scanning
Copy link

Clair is a vulnerability assessment tool for application containers. Support is available to automatically provision and configure both Clair and its integration with Red Hat Quay. A property called clair can be specified in the QuayEcosystem object along with enabled: true within this field in order to deploy Clair. An example is shown below: 

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay: {}
  clair:
    enabled: true
Copy to Clipboard Toggle word wrap

The Red Hat Quay Operator sets the Clair database connection string with the parameter sslmode=disable if no parameters are specified in the QuayEcosystem custom resource. In case you have SSL enabled Postgres database, or want to add other parameters, provide key: value pairs as strings (for example, connect_timeout: '10') under connectionParameters object.

For example: 

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay: {}
  clair:
    enabled: true
    database:
      connectionParameters:
        sslmode: require
        connect_timeout: '10'
Copy to Clipboard Toggle word wrap

Supported connection string parameters:

  • sslmode - Whether or not to use SSL (default is disable, this is not the default for libpq)
  • connect_timeout - Maximum wait for connection, in seconds. Zero or not specified means wait indefinitely.
  • sslcert - Cert file location. The file must contain PEM encoded data.
  • sslkey - Key file location. The file must contain PEM encoded data.
  • sslrootcert - The location of the root certificate file. The file must contain PEM encoded data.

Valid values for sslmode are:

  • disable - No SSL
  • require - Always SSL (skip verification)
  • verify-ca - Always SSL (verify that the certificate presented by the server was signed by a trusted CA)
  • verify-full - Always SSL (verify that the certification presented by the server was signed by a trusted CA and the server host name matches the one in the certificate)

6.3.1. Clair update interval
Copy link

Clair routinely queries CVE databases in order to build its own internal database. By default, this value is set at 500m. You can modify the time interval between checks by setting the updateInterval property as shown below: 

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay: {}
  clair:
    enabled: true
    updateInterval: "60m"
Copy to Clipboard Toggle word wrap

The above configuration would have Clair update every 60 minutes.

6.4. Setting common attributes
Copy link

Each of the following components expose a set of similar properties that can be specified in order to customize the runtime execution:

  • Red Hat Quay
  • Red Hat Quay Configuration
  • Red Hat Quay PostgreSQL
  • Redis
  • Clair
  • Clair PostgreSQL

6.4.1. Image pull secret
Copy link

As referenced in prior sections, an Image Pull Secret can specify the name of the secret containing credentials to an image from a protected registry using the property imagePullSecret.

6.4.2. Image
Copy link

There may be a desire to make use of an alternate image or source location for each of the components in the Quay ecosystem. The most common use case is to make use of an image registry that contains all of the needed images instead of being sourced from the public internet. Each component has a property called image where the location of the related image can be referenced from.

The following is an example of how a customized image location can be specified: 

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    image: myregistry.example.com/quay/quay:v99.1.0
Copy to Clipboard Toggle word wrap

6.4.3. Compute resources
Copy link

Compute Resources such as memory and CPU can be specified in the same form as any other value in a PodTemplate. CPU and Memory values for requests and limits can be specified under a property called resources.

Note

In the case of the QuayConfiguration deployment, configResources is the property which should be referenced underneath the quay property.

The following is an example of how compute resources can be specified: 

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    resources:
      requests:
        memory: 512Mi
Copy to Clipboard Toggle word wrap

6.4.4. Probes
Copy link

Readiness and Liveness Probes can be specified in the same form as any other value in a PodTemplate.

The following is how a readinessProbe and livenessProbe can be specified: 

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    livenessProbe:
      initialDelaySeconds: 120
      httpGet:
        path: /health/instance
        port: 8443
        scheme: HTTPS
    readinessProbe:
      initialDelaySeconds: 10
      httpGet:
        path: /health/instance
        port: 8443
        scheme: HTTPS
Copy to Clipboard Toggle word wrap
Note

If a value for either property is not specified, an opinionated default value is applied.

6.4.5. Node Selector
Copy link

Components of the QuayEcosystem may need to be deployed to only a subset of available nodes in a Kubernetes cluster. This functionality can be set on each of the resources using the nodeSelector property as shown below: 

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    nodeSelector:
      node-role.kubernetes.io/infra: true
Copy to Clipboard Toggle word wrap

6.4.6. Deployment strategy
Copy link

Each of the core components consist of Kubernetes Deployments. This resource supports the method in which new versions are released. This operator supports making use of the RollingUpdate and Recreate strategies. Either value can be defined by using the deploymentStrategy property on the desired resource as shown below: 

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    deploymentStrategy: RollingUpdate
Copy to Clipboard Toggle word wrap
Note

The absence of a defined value will make use of the RollingUpdate strategy.

6.4.7. Environment Variables
Copy link

In addition to environment variables that are automatically configured by the operator, users can define their own set of environment variables in order to customize the managed resources. Each core component includes a property called envVars where environment variables can be defined. An example is shown below: 

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    envVars:
      - name: FOO
        value: bar
Copy to Clipboard Toggle word wrap
Note

Environment variables for the Quay configuration pod can be managed by specifying the configEnvVars property on the quay resource.

Warning

User defined environment variables are given precedence over those managed by the operator. Undesirable results may occur if conflicting keys are used.

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