Red Hat Quay Operator features

Procedure

1. Pull a sample image by entering the following command:

   $ podman pull ubuntu:20.04

2. Tag the image to your registry by entering the following command:

   $ sudo podman tag docker.io/library/ubuntu:20.04 <quay-server.example.com>/<user-name>/ubuntu:20.04

3. Push the image to your Red Hat Quay registry by entering the following command:

   $ sudo podman push --tls-verify=false quay-server.example.com/quayadmin/ubuntu:20.04

4. Log in to your Red Hat Quay deployment through the UI.
5. Click the repository name, for example, quayadmin/ubuntu.

6. In the navigation pane, click Tags.

   Report summary

   

7. Click the image report, for example, 45 medium, to show a more detailed report:

   Report details

   

   Note

   In some cases, Clair shows duplicate reports on images, for example, ubi8/nodejs-12 or ubi8/nodejs-16. This occurs because vulnerabilities with same name are for different packages. This behavior is expected with Clair vulnerability reporting and will not be addressed as a bug.

1. Enter the following command to reveal the master and worker nodes. In this example, there are three master nodes and six worker nodes.

   $ oc get nodes

   Example output

   NAME                                               STATUS   ROLES    AGE     VERSION
   user1-jcnp6-master-0.c.quay-devel.internal         Ready    master   3h30m   v1.20.0+ba45583
   user1-jcnp6-master-1.c.quay-devel.internal         Ready    master   3h30m   v1.20.0+ba45583
   user1-jcnp6-master-2.c.quay-devel.internal         Ready    master   3h30m   v1.20.0+ba45583
   user1-jcnp6-worker-b-65plj.c.quay-devel.internal   Ready    worker   3h21m   v1.20.0+ba45583
   user1-jcnp6-worker-b-jr7hc.c.quay-devel.internal   Ready    worker   3h21m   v1.20.0+ba45583
   user1-jcnp6-worker-c-jrq4v.c.quay-devel.internal   Ready    worker   3h21m   v1.20.0+ba45583
   user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal   Ready    worker   3h21m   v1.20.0+ba45583
   user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal   Ready    worker   3h22m   v1.20.0+ba45583
   user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal   Ready    worker   3h21m   v1.20.0+ba45583

2. Enter the following commands to label the three worker nodes for infrastructure use:

   $ oc label node --overwrite user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal node-role.kubernetes.io/infra=

   $ oc label node --overwrite user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal node-role.kubernetes.io/infra=

   $ oc label node --overwrite user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal node-role.kubernetes.io/infra=

3. Now, when listing the nodes in the cluster, the last three worker nodes have the infra role. For example:

   $ oc get nodes

   Example

   NAME                                               STATUS   ROLES          AGE     VERSION
   user1-jcnp6-master-0.c.quay-devel.internal         Ready    master         4h14m   v1.20.0+ba45583
   user1-jcnp6-master-1.c.quay-devel.internal         Ready    master         4h15m   v1.20.0+ba45583
   user1-jcnp6-master-2.c.quay-devel.internal         Ready    master         4h14m   v1.20.0+ba45583
   user1-jcnp6-worker-b-65plj.c.quay-devel.internal   Ready    worker         4h6m    v1.20.0+ba45583
   user1-jcnp6-worker-b-jr7hc.c.quay-devel.internal   Ready    worker         4h5m    v1.20.0+ba45583
   user1-jcnp6-worker-c-jrq4v.c.quay-devel.internal   Ready    worker         4h5m    v1.20.0+ba45583
   user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal   Ready    infra,worker   4h6m    v1.20.0+ba45583
   user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal   Ready    infra,worker   4h6m    v1.20.0+ba45583
   user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal   Ready    infra,worker   4h6m    v1.20.0+ba4558

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. For example:

   $ oc adm taint nodes user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal node-role.kubernetes.io/infra:NoSchedule

   $ oc adm taint nodes user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal node-role.kubernetes.io/infra:NoSchedule

   $ oc adm taint nodes user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal node-role.kubernetes.io/infra:NoSchedule

Procedure

1. Enter the following command to edit the namespace where Red Hat Quay is deployed, and the following annotation:

   $ oc annotate namespace <namespace> openshift.io/node-selector='node-role.kubernetes.io/infra='

   Example output

   namespace/<namespace> annotated

2. Obtain a list of available pods by entering the following command:

   $ oc get pods -o wide

   Example output

   NAME                                               READY   STATUS      RESTARTS        AGE     IP            NODE                                         NOMINATED NODE   READINESS GATES
   example-registry-clair-app-5744dd64c9-9d5jt        1/1     Running     0               173m    10.130.4.13   stevsmit-quay-ocp-tes-5gwws-worker-c-6xkn7   <none>           <none>
   example-registry-clair-app-5744dd64c9-fg86n        1/1     Running     6 (3h21m ago)   3h24m   10.131.0.91   stevsmit-quay-ocp-tes-5gwws-worker-c-dnhdp   <none>           <none>
   example-registry-clair-postgres-845b47cd88-vdchz   1/1     Running     0               3h21m   10.130.4.10   stevsmit-quay-ocp-tes-5gwws-worker-c-6xkn7   <none>           <none>
   example-registry-quay-app-64cbc5bcf-8zvgc          1/1     Running     1 (3h24m ago)   3h24m   10.130.2.12   stevsmit-quay-ocp-tes-5gwws-worker-a-tk8dx   <none>           <none>
   example-registry-quay-app-64cbc5bcf-pvlz6          1/1     Running     0               3h24m   10.129.4.10   stevsmit-quay-ocp-tes-5gwws-worker-b-fjhz4   <none>           <none>
   example-registry-quay-app-upgrade-8gspn            0/1     Completed   0               3h24m   10.130.2.10   stevsmit-quay-ocp-tes-5gwws-worker-a-tk8dx   <none>           <none>
   example-registry-quay-database-784d78b6f8-2vkml    1/1     Running     0               3h24m   10.131.4.10   stevsmit-quay-ocp-tes-5gwws-worker-c-2frtg   <none>           <none>
   example-registry-quay-mirror-d5874d8dc-fmknp       1/1     Running     0               3h24m   10.129.4.9    stevsmit-quay-ocp-tes-5gwws-worker-b-fjhz4   <none>           <none>
   example-registry-quay-mirror-d5874d8dc-t4mff       1/1     Running     0               3h24m   10.129.2.19   stevsmit-quay-ocp-tes-5gwws-worker-a-k7w86   <none>           <none>
   example-registry-quay-redis-79848898cb-6qf5x       1/1     Running     0               3h24m   10.130.2.11   stevsmit-quay-ocp-tes-5gwws-worker-a-tk8dx   <none>           <none>

3. Enter the following command to delete the available pods:

   $ oc delete pods --selector quay-operator/quayregistry=example-registry -n quay-enterprise

   Example output

   pod "example-registry-clair-app-5744dd64c9-9d5jt" deleted
   pod "example-registry-clair-app-5744dd64c9-fg86n" deleted
   pod "example-registry-clair-postgres-845b47cd88-vdchz" deleted
   pod "example-registry-quay-app-64cbc5bcf-8zvgc" deleted
   pod "example-registry-quay-app-64cbc5bcf-pvlz6" deleted
   pod "example-registry-quay-app-upgrade-8gspn" deleted
   pod "example-registry-quay-database-784d78b6f8-2vkml" deleted
   pod "example-registry-quay-mirror-d5874d8dc-fmknp" deleted
   pod "example-registry-quay-mirror-d5874d8dc-t4mff" deleted
   pod "example-registry-quay-redis-79848898cb-6qf5x" deleted

   After the pods have been deleted, they automatically cycle back up and should be scheduled on the dedicated infrastructure nodes.

Procedure

1. Enter the following command to specify the registry key:

   $ oc create secret generic --from-file config.yaml=./config_awss3cloudfront.yaml --from-file default-cloudfront-signing-key.pem=./default-cloudfront-signing-key.pem test-config-bundle

1. On System B and System C, scale down your Red Hat Quay registry. This is done by disabling auto scaling and overriding the replica county for Red Hat Quay, mirror workers, and Clair if it is managed. Use the following quayregistry.yaml file as a reference:

   apiVersion: quay.redhat.com/v1
   kind: QuayRegistry
   metadata:
     name: registry
     namespace: ns
   spec:
     components:
       …
       - kind: horizontalpodautoscaler
         managed: false 1
       - kind: quay
         managed: true
         overrides: 2
           replicas: 0
       - kind: clair
         managed: true
         overrides:
           replicas: 0
       - kind: mirror
         managed: true
         overrides:
           replicas: 0
       …

   1

   Disable auto scaling of Quay, Clair and Mirroring workers

   2

   Set the replica count to 0 for components accessing the database and objectstorage

   Note

   You must keep the Red Hat Quay registry running on System A. Do not update the quayregistry.yaml file on System A.

2. Wait for the registry-quay-app, registry-quay-mirror, and registry-clair-app pods to disappear. Enter the following command to check their status:

   oc get pods -n <quay-namespace>

   Example output

   quay-operator.v3.7.1-6f9d859bd-p5ftc               1/1     Running     0             12m
   quayregistry-clair-postgres-7487f5bd86-xnxpr       1/1     Running     1 (12m ago)   12m
   quayregistry-quay-app-upgrade-xq2v6                0/1     Completed   0             12m
   quayregistry-quay-redis-84f888776f-hhgms           1/1     Running     0             12m

3. On System A, initiate a Red Hat Quay upgrade to the latest y-stream version. This is a manual process. For more information about upgrading installed Operators, see Upgrading installed Operators. For more information about Red Hat Quay upgrade paths, see Upgrading the Red Hat Quay Operator.
4. After the new Red Hat Quay registry is installed, the necessary upgrades on the cluster are automatically completed. Afterwards, new Red Hat Quay pods are started with the latest y-stream version. Additionally, new Quay pods are scheduled and started.

5. Confirm that the update has properly worked by navigating to the Red Hat Quay UI:

   1. In the OpenShift console, navigate to Operators → Installed Operators, and click the Registry Endpoint link.

      Important

      Do not execute the following step until the Red Hat Quay UI is available. Do not upgrade the Red Hat Quay registry on System B and on System C until the UI is available on System A.

6. Confirm that the update has properly worked on System A, initiate the Red Hat Quay upgrade on System B and on System C. The Operator upgrade results in an upgraded Red Hat Quay installation, and the pods are restarted.

   Note

   Because the database schema is correct for the new y-stream installation, the new pods on System B and on System C should quickly start.

7. After updating, revert the changes made in step 1 of this procedure by removing overrides for the components. For example:

   apiVersion: quay.redhat.com/v1
   kind: QuayRegistry
   metadata:
     name: registry
     namespace: ns
   spec:
     components:
       …
       - kind: horizontalpodautoscaler
         managed: true 1
       - kind: quay
         managed: true
       - kind: clair
         managed: true
       - kind: mirror
         managed: true
       …

   1

   If the horizontalpodautoscaler resource was set to true before the upgrade procedure, or if you want Red Hat Quay to scale in case of a resource shortage, set it to true.

Procedure

1. On the OpenShift Container Platform console page, select Operators → OperatorHub and search for Container Security Operator.
2. Select the Container Security Operator, then select Install to go to the Create Operator Subscription page.
3. Check the settings (all namespaces and automatic approval strategy, by default), and select Subscribe. The Container Security appears after a few moments on the Installed Operators screen.

4. Optional: you can add custom certificates to the CSO. In this example, create a certificate named quay.crt in the current directory. Then, run the following command to add the certificate to the CSO:

   $ oc create secret generic container-security-operator-extra-certs --from-file=quay.crt -n openshift-operators

   Note

   You must restart the Operator pod for the new certificates to take effect.

5. Navigate to Home → Overview. A link to Image Vulnerabilities appears under the status section, with a listing of the number of vulnerabilities found so far. Select the link to see a security breakdown, as shown in the following image:

   

   Important

   The Container Security Operator currently provides broken links for Red Hat Security advisories. For example, the following link might be provided: https://access.redhat.com/errata/RHSA-2023:1842%20https://access.redhat.com/security/cve/CVE-2023-23916. The %20 in the URL represents a space character, however it currently results in the combination of the two URLs into one incomplete URL, for example, https://access.redhat.com/errata/RHSA-2023:1842 and https://access.redhat.com/security/cve/CVE-2023-23916. As a temporary workaround, you can copy each URL into your browser to navigate to the proper page. This is a known issue and will be fixed in a future version of Red Hat Quay.

6. You can do one of two things at this point to follow up on any detected vulnerabilities:

   1. Select the link to the vulnerability. You are taken to the container registry, Red Hat Quay or other registry where the container came from, where you can see information about the vulnerability. The following figure shows an example of detected vulnerabilities from a Quay.io registry:

      

   2. Select the namespaces link to go to the Image Manifest Vulnerabilities page, where you can see the name of the selected image and all namespaces where that image is running. The following figure indicates that a particular vulnerable image is running in two namespaces:

      

Procedure

1. Enter the following command to query for detected vulnerabilities:

   $ oc get vuln --all-namespaces

   Example output

   NAMESPACE     NAME              AGE
   default       sha256.ca90...    6m56s
   skynet        sha256.ca90...    9m37s

2. Optional. To display details for a particular vulnerability, identify a specific vulnerability and its namespace, and use the oc describe command. The following example shows an active container whose image includes an RPM package with a vulnerability:

   $ oc describe vuln --namespace <namespace> sha256.ac50e3752...

   Example output

   Name:         sha256.ac50e3752...
   Namespace:    quay-enterprise
   ...
   Spec:
     Features:
       Name:            nss-util
       Namespace Name:  centos:7
       Version:         3.44.0-3.el7
       Versionformat:   rpm
       Vulnerabilities:
         Description: Network Security Services (NSS) is a set of libraries...

Procedure

1. On the OpenShift Container Platform web console, click Operators → Installed Operators.
2. Click the menu kebab of the Container Security Operator.
3. Click Uninstall Operator. Confirm your decision by clicking Uninstall in the popup window.

4. Remove the imagemanifestvulns.secscan.quay.redhat.com custom resource definition by entering the following command:

   $ oc delete customresourcedefinition imagemanifestvulns.secscan.quay.redhat.com

   Example output

   customresourcedefinition.apiextensions.k8s.io "imagemanifestvulns.secscan.quay.redhat.com" deleted

Procedure

1. Log in to the Amazon Web Services (AWS) console and navigate to the Identity and Access Management (IAM) console.
2. In the navigation pane, under Access management click Users.

3. Click Create User and enter the following information:

   1. Enter a valid username, for example, quay-user.
   2. For Permissions options, click Add user to group.
4. On the review and create page, click Create user. You are redirected to the Users page.
5. Click the username, for example, quay-user.
6. Copy the ARN of the user, for example, arn:aws:iam::123492922789:user/quay-user.
7. On the same page, click the Security credentials tab.
8. Navigate to Access keys.
9. Click Create access key.
10. On the Access key best practices & alternatives page, click Command Line Interface (CLI), then, check the confirmation box. Then click Next.
11. Optional. On the Set description tag - optional page, enter a description.
12. Click Create access key.

13. Copy and store the access key and the secret access key.

    Important

    This is the only time that the secret access key can be viewed or downloaded. You cannot recover it later. However, you can create a new access key any time.

14. Click Done.

Procedure

1. If you are not already, navigate to the IAM dashboard by clicking Dashboard.
2. In the navigation pane, click Roles under Access management.

3. Click Create role.

   • Click Custom Trust Policy, which shows an editable JSON policy. By default, it shows the following information:

     {
     	"Version": "2012-10-17",
     	"Statement": [
     		{
     			"Sid": "Statement1",
     			"Effect": "Allow",
     			"Principal": {},
     			"Action": "sts:AssumeRole"
     		}
     	]
     }

4. Under the Principal configuration field, add your AWS ARN information. For example:

   {
       "Version": "2012-10-17",
       "Statement": [
      	 {
      		 "Sid": "Statement1",
      		 "Effect": "Allow",
      		 "Principal": {
      		 	"AWS": "arn:aws:iam::123492922789:user/quay-user"
      		 },
      		 "Action": "sts:AssumeRole"
      	 }
       ]
   }

5. Click Next.
6. On the Add permissions page, type AmazonS3FullAccess in the search box. Check the box to add that policy to the S3 role, then click Next.

7. On the Name, review, and create page, enter the following information:

   1. Enter a role name, for example, example-role.
   2. Optional. Add a description.
8. Click the Create role button. You are navigated to the Roles page. Under Role name, the newly created S3 should be available.

Procedure

1. On the Home page of your OpenShift Container Platform deployment, click Operators → Installed Operators.
2. Click Red Hat Quay.
3. Click Quay Registry and then the name of your Red Hat Quay registry.
4. Under Config Bundle Secret, click the name of your registry configuration bundle, for example, quay-registry-config-bundle-qet56.
5. On the configuration bundle page, click Actions to reveal a drop-down menu. Then click Edit Secret.

6. Update your the DISTRIBUTED_STORAGE_CONFIG fields of your config.yaml file with the following information:

   # ...
   DISTRIBUTED_STORAGE_CONFIG:
      default:
       - STSS3Storage
       - sts_role_arn: <role_arn> 1
         s3_bucket: <s3_bucket_name> 2
         storage_path: <storage_path> 3
         s3_region: <region> 4
         sts_user_access_key: <s3_user_access_key> 5
         sts_user_secret_key: <s3_user_secret_key> 6
   # ...

   1

   The unique Amazon Resource Name (ARN) required when configuring AWS STS

   2

   The name of your s3 bucket.

   3

   The storage path for data. Usually /datastorage.

   4

   Optional. The Amazon Web Services region. Defaults to us-east-1.

   5

   The generated AWS S3 user access key required when configuring AWS STS.

   6

   The generated AWS S3 user secret key required when configuring AWS STS.

7. Click Save.

Verification

1. Tag a sample image, for example, busybox, that will be pushed to the repository. For example:

   $ podman tag docker.io/library/busybox <quay-server.example.com>/<organization_name>/busybox:test

2. Push the sample image by running the following command:

   $ podman push <quay-server.example.com>/<organization_name>/busybox:test

3. Verify that the push was successful by navigating to the Organization that you pushed the image to in your Red Hat Quay registry → Tags.
4. Navigate to the Amazon Web Services (AWS) console and locate your s3 bucket.
5. Click the name of your s3 bucket.
6. On the Objects page, click datastorage/.

7. On the datastorage/ page, the following resources should seen:

   • sha256/

   • uploads/

     These resources indicate that the push was successful, and that AWS STS is properly configured.

Procedure

1. Log in to Red Hat Quay through the web UI.
2. Select the organization for which the external application will be configured.
3. On the navigation pane, select Applications.
4. Select Create New Application and enter a name for the new application, for example, openshift.
5. On the OAuth Applications page, select your application, for example, openshift.
6. On the navigation pane, select Generate Token.

7. Select the following fields:

   • Administer Organization
   • Administer Repositories
   • Create Repositories
   • View all visible repositories
   • Read/Write to any accessible repositories
   • Administer User
   • Read User Information
8. Review the assigned permissions.
9. Select Authorize Application and then confirm confirm the authorization by selecting Authorize Application.

10. Save the generated access token.

    Important

    Red Hat Quay does not offer token management. You cannot list tokens, delete tokens, or modify tokens. The generated access token is only shown once and cannot be re-obtained after closing the page.

Procedure

1. Open the Administrator perspective of the web console and navigate to Operators → OperatorHub on the navigation pane.
2. Search for Quay Bridge Operator, click the Quay Bridge Operator title, and then click Install.
3. Select the version to install, for example, stable-3.7, and then click Install.
4. Click View Operator when the installation finishes to go to the Quay Bridge Operator’s Details page. Alternatively, you can click Installed Operators → Red Hat Quay Bridge Operator to go to the Details page.

Procedure

1. Enter the following command to create a new OpenShift Container Platform project called e2e-demo:

   $ oc new-project e2e-demo

2. After you have created a new project, a new Organization is created in Red Hat Quay. Navigate to the Red Hat Quay registry and confirm that you have created a new Organization named openshift_e2e-demo.

   Note

   The openshift value of the Organization might different if the clusterID in your QuayIntegration resource used a different value.

3. On the Red Hat Quay UI, click the name of the new Organization, for example, openshift_e2e-demo.

4. Click Robot Accounts in the navigation pane. As part of new project, the following Robot Accounts should have been created:

   • openshift_e2e-demo+deployer
   • openshift_e2e-demo+default
   • openshift_e2e-demo+builder

5. Enter the following command to confirm three secrets containing Docker configuration associated with the applicable Robot Accounts were created:

   $ oc get secrets builder-quay-openshift deployer-quay-openshift default-quay-openshift

   Example output

   stevsmit@stevsmit ocp-quay $ oc get secrets builder-quay-openshift deployer-quay-openshift default-quay-openshift
   NAME                      TYPE                             DATA   AGE
   builder-quay-openshift    kubernetes.io/dockerconfigjson   1      77m
   deployer-quay-openshift   kubernetes.io/dockerconfigjson   1      77m
   default-quay-openshift    kubernetes.io/dockerconfigjson   1      77m

6. Enter the following command to display detailed information about builder ServiceAccount (SA), including its secrets, token expiration, and associated roles and role bindings. This ensures that the project is integrated via the Quay Bridge Operator.

   $ oc describe sa builder default deployer

   Example output

   ...
   Name:                builder
   Namespace:           e2e-demo
   Labels:              <none>
   Annotations:         <none>
   Image pull secrets:  builder-dockercfg-12345
                        builder-quay-openshift
   Mountable secrets:   builder-dockercfg-12345
                        builder-quay-openshift
   Tokens:              builder-token-12345
   Events:              <none>
   ...

7. Enter the following command to create and deploy a new application called httpd-template:

   $ oc new-app --template=httpd-example

   Example output

   --> Deploying template "e2e-demo/httpd-example" to project e2e-demo
   ...
   --> Creating resources ...
       service "httpd-example" created
       route.route.openshift.io "httpd-example" created
       imagestream.image.openshift.io "httpd-example" created
       buildconfig.build.openshift.io "httpd-example" created
       deploymentconfig.apps.openshift.io "httpd-example" created
   --> Success
       Access your application via route 'httpd-example-e2e-demo.apps.quay-ocp.gcp.quaydev.org'
       Build scheduled, use 'oc logs -f buildconfig/httpd-example' to track its progress.
       Run 'oc status' to view your app.

   After running this command, BuildConfig, ImageStream, Service, Route, and DeploymentConfig resources are created. When the ImageStream resource is created, an associated repository is created in Red Hat Quay. For example:

   

8. The ImageChangeTrigger for the BuildConfig triggers a new Build when the Apache HTTPD image, located in the openshift namespace, is resolved. As the new Build is created, the MutatingWebhookConfiguration automatically rewriters the output to point at Red Hat Quay. You can confirm that the build is complete by querying the output field of the build by running the following command:

   $ oc get build httpd-example-1 --template='{{ .spec.output.to.name }}'

   Example output

   example-registry-quay-quay-enterprise.apps.quay-ocp.gcp.quaydev.org/openshift_e2e-demo/httpd-example:latest

9. On the Red Hat Quay UI, navigate to the openshift_e2e-demo Organization and select the httpd-example repository.
10. Click Tags in the navigation pane and confirm that the latest tag has been successfully pushed.

11. Enter the following command to ensure that the latest tag has been resolved:

    $ oc describe is httpd-example

    Example output

    Name:			httpd-example
    Namespace:		e2e-demo
    Created:		55 minutes ago
    Labels:			app=httpd-example
    			template=httpd-example
    Description:		Keeps track of changes in the application image
    Annotations:		openshift.io/generated-by=OpenShiftNewApp
    			openshift.io/image.dockerRepositoryCheck=2023-10-02T17:56:45Z
    Image Repository:	image-registry.openshift-image-registry.svc:5000/e2e-demo/httpd-example
    Image Lookup:		local=false
    Unique Images:		0
    Tags:			1
    
    latest
      tagged from example-registry-quay-quay-enterprise.apps.quay-ocp.gcp.quaydev.org/openshift_e2e-demo/httpd-example:latest

12. After the ImageStream is resolwillved, a new deployment should have been triggered. Enter the following command to generate a URL output:

    $ oc get route httpd-example --template='{{ .spec.host }}'

    Example output

    httpd-example-e2e-demo.apps.quay-ocp.gcp.quaydev.org

13. Navigate to the URL. If a sample webpage appears, the deployment was successful.

14. Enter the following command to delete the resources and clean up your Red Hat Quay repository:

    $ oc delete project e2e-demo

    Note

    The command waits until the project resources have been removed. This can be bypassed by adding the --wait=false to the above command

15. After the command completes, navigate to your Red Hat Quay repository and confirm that the openshift_e2e-demo Organization is no longer available.

Procedure

1. In your deployment’s config.yaml file, add the FEATURE_LISTEN_IP_VERSION parameter and set it to IPv6, for example:

   # ...
   FEATURE_GOOGLE_LOGIN: false
   FEATURE_INVITE_ONLY_USER_CREATION: false
   FEATURE_LISTEN_IP_VERSION: IPv6
   FEATURE_MAILING: false
   FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP: false
   # ...

2. Start, or restart, your Red Hat Quay deployment.

3. Check that your deployment is listening to IPv6 by entering the following command:

   $ curl <quay_endpoint>/health/instance
   {"data":{"services":{"auth":true,"database":true,"disk_space":true,"registry_gunicorn":true,"service_key":true,"web_gunicorn":true}},"status_code":200}

1. 3.0.5 → 3.1.3
2. 3.1.3 → 3.2.2
3. 3.2.2 → 3.3.4
4. 3.3.4 → 3.4.z
5. 3.4.z → 3.5.z

Procedure

1. Add "quay-operator/migrate": "true" to the metadata.labels of the QuayEcosystem.

   $ oc edit quayecosystem <quayecosystemname>

   metadata:
     labels:
       quay-operator/migrate: "true"

2. Wait for a QuayRegistry to be created with the same metadata.name as your QuayEcosystem. The QuayEcosystem will be marked with the label "quay-operator/migration-complete": "true".
3. After the status.registryEndpoint of the new QuayRegistry is set, access Red Hat Quay and confirm that all data and settings were migrated successfully.
4. If everything works correctly, you can delete the QuayEcosystem and Kubernetes garbage collection will clean up all old resources.