Chapter 16. Geo-replication

1. Create the configBundleSecret by entering the following command:

   $ oc create secret generic --from-file config.yaml=./config.yaml georep-config-bundle

2. In each of the clusters, set the configBundleSecret and use the QUAY_DISTRIBUTED_STORAGE_PREFERENCE environmental variable override to configure the appropriate storage for that cluster. For example:

   Note

   The config.yaml file between both deployments must match. If making a change to one cluster, it must also be changed in the other.

   US cluster QuayRegistry example

   apiVersion: quay.redhat.com/v1
   kind: QuayRegistry
   metadata:
     name: example-registry
     namespace: quay-enterprise
   spec:
     configBundleSecret: georep-config-bundle
     components:
       - kind: objectstorage
         managed: false
       - kind: route
         managed: true
       - kind: tls
         managed: false
       - kind: postgres
         managed: false
       - kind: clairpostgres
         managed: false
       - kind: redis
         managed: false
       - kind: quay
         managed: true
         overrides:
           env:
           - name: QUAY_DISTRIBUTED_STORAGE_PREFERENCE
             value: usstorage
       - kind: mirror
         managed: true
         overrides:
           env:
           - name: QUAY_DISTRIBUTED_STORAGE_PREFERENCE
             value: usstorage

   Note

   <<<<<<< HEAD Because SSL/TLS is unmanaged, and the route is managed, you must supply the certificates directly in the config bundle. For more information, see Configuring TLS and routes.

Procedure

1. Sync the blobs between all of your defined sites by running the following command:

   $ python -m util.backfillreplication

1. In your Red Hat Quay config.yaml file for site usstorage, remove the DISTRIBUTED_STORAGE_CONFIG entry for the eustorage site.

2. Enter the following command to identify your Quay application pods:

   $ oc get pod -n <quay_namespace>

   Example output

   quay390usstorage-quay-app-5779ddc886-2drh2
   quay390eustorage-quay-app-66969cd859-n2ssm

3. Enter the following command to open an interactive shell session in the usstorage pod:

   $ oc rsh quay390usstorage-quay-app-5779ddc886-2drh2

4. Enter the following command to permanently remove the eustorage site:

Procedure

1. If your Red Hat Quay registry is readily available, you can generate service keys inside of the Quay registry container.

   1. Enter the following command to generate a key pair inside of the Quay container:

      $ podman exec quay python3 tools/generatekeypair.py quay-readonly

2. If your Red Hat Quay is not readily available, you must generate your service keys inside of a virtual environment.

   1. Change into the directory of your Red Hat Quay deployment and create a virtual environment inside of that directory:

      $ cd <$QUAY>/quay && virtualenv -v venv

   2. Activate the virtual environment by entering the following command:

      $ source venv/bin/activate

   3. Optional. Install the pip CLI tool if you do not have it installed:

      $ venv/bin/pip install --upgrade pip

   4. In your Red Hat Quay directory, create a requirements-generatekeys.txt file with the following content:

      $ cat << EOF > requirements-generatekeys.txt
      cryptography==3.4.7
      pycparser==2.19
      pycryptodome==3.9.4
      pycryptodomex==3.9.4
      pyjwkest==1.4.2
      PyJWT==1.7.1
      Authlib==1.0.0a2
      EOF

   5. Enter the following command to install the Python dependencies defined in the requirements-generatekeys.txt file:

      $ venv/bin/pip install -r requirements-generatekeys.txt

   6. Enter the following command to create the necessary service keys:

      $ PYTHONPATH=. venv/bin/python /<path_to_cloned_repo>/tools/generatekeypair.py quay-readonly

      Example output

      Writing public key to quay-readonly.jwk
      Writing key ID to quay-readonly.kid
      Writing private key to quay-readonly.pem

   7. Enter the following command to deactivate the virtual environment:

      $ deactivate

Procedure

1. Enter the following command to enter your Red Hat Quay database environment:

   $ podman exec -it postgresql-quay psql -U postgres -d quay

2. Display the approval types and associated notes of the servicekeyapproval by entering the following command:

   quay=# select * from servicekeyapproval;

   Example output

    id | approver_id |          approval_type           |       approved_date        | notes
   ----+-------------+----------------------------------+----------------------------+-------
     1 |             | ServiceKeyApprovalType.AUTOMATIC | 2024-05-07 03:47:48.181347 |
     2 |             | ServiceKeyApprovalType.AUTOMATIC | 2024-05-07 03:47:55.808087 |
     3 |             | ServiceKeyApprovalType.AUTOMATIC | 2024-05-07 03:49:04.27095  |
     4 |             | ServiceKeyApprovalType.AUTOMATIC | 2024-05-07 03:49:05.46235  |
     5 |           1 | ServiceKeyApprovalType.SUPERUSER | 2024-05-07 04:05:10.296796 |
   ...

3. Add the service key to your Red Hat Quay database by entering the following query:

   quay=# INSERT INTO servicekey
     (name, service, metadata, kid, jwk, created_date, expiration_date)
     VALUES ('quay-readonly',
              'quay',
              '{}',
              '{<contents_of_.kid_file>}',
              '{<contents_of_.jwk_file>}',
              '{<created_date_of_read-only>}',
              '{<expiration_date_of_read-only>}');

   Example output

   INSERT 0 1

4. Next, add the key approval with the following query:

   quay=# INSERT INTO servicekeyapproval ('approval_type', 'approved_date', 'notes')
     VALUES ("ServiceKeyApprovalType.SUPERUSER", "CURRENT_DATE",
              {include_notes_here_on_why_this_is_being_added});

   Example output

   INSERT 0 1

5. Set the approval_id field on the created service key row to the id field from the created service key approval. You can use the following SELECT statements to get the necessary IDs:

   UPDATE servicekey
   SET approval_id = (SELECT id FROM servicekeyapproval WHERE approval_type = 'ServiceKeyApprovalType.SUPERUSER')
   WHERE name = 'quay-readonly';

   UPDATE 1

Procedure

1. Shutdown all Red Hat Quay instances on all virtual machines. For example:

   $ podman stop <quay_container_name_on_virtual_machine_a>

   $ podman stop <quay_container_name_on_virtual_machine_b>

2. Enter the following command to copy the contents of the quay-readonly.kid file and the quay-readonly.pem file to the directory that holds your Red Hat Quay configuration bundle:

   $ cp quay-readonly.kid quay-readonly.pem $Quay/config

3. Enter the following command to set file permissions on all files in your configuration bundle folder:

   $ setfacl -m user:1001:rw $Quay/config/*

4. Modify your Red Hat Quay config.yaml file and add the following information:

   # ...
   REGISTRY_STATE: readonly
   INSTANCE_SERVICE_KEY_KID_LOCATION: 'conf/stack/quay-readonly.kid'
   INSTANCE_SERVICE_KEY_LOCATION: 'conf/stack/quay-readonly.pem'
   # ...

5. Distribute the new configuration bundle to all Red Hat Quay instances.

6. Start Red Hat Quay by entering the following command:

   $ podman run -d --rm -p 80:8080 -p 443:8443  \
      --name=quay-main-app \
      -v $QUAY/config:/conf/stack:Z \
      -v $QUAY/storage:/datastorage:Z \
      {productrepo}/{quayimage}:{productminv}

7. After starting Red Hat Quay, a banner inside in your instance informs users that Red Hat Quay is running in read-only mode. Pushes should be rejected and a 405 error should be logged. You can test this by running the following command:

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

   Example output

   613be09ab3c0: Preparing
   denied: System is currently read-only. Pulls will succeed but all write operations are currently suspended.

   With your Red Hat Quay deployment on read-only mode, you can safely manage your registry’s operations and perform such actions as backup and restore.

8. Optional. After you are finished with read-only mode, you can return to normal operations by removing the following information from your config.yaml file. Then, restart your Red Hat Quay deployment:

   # ...
   REGISTRY_STATE: readonly
   INSTANCE_SERVICE_KEY_KID_LOCATION: 'conf/stack/quay-readonly.kid'
   INSTANCE_SERVICE_KEY_LOCATION: 'conf/stack/quay-readonly.pem'
   # ...

   $ podman restart <container_id>

Procedure

1. Create a temporary backup directory, for example, quay-backup:

   $ mkdir /tmp/quay-backup

2. The following example command denotes the local directory that the Red Hat Quay was started in, for example, /opt/quay-install:

   $ podman run --name quay-app \
      -v /opt/quay-install/config:/conf/stack:Z \
      -v /opt/quay-install/storage:/datastorage:Z \
      registry.redhat.io/quay/quay-rhel8:v3.12.15

   Change into the directory that bind-mounts to /conf/stack inside of the container, for example, /opt/quay-install, by running the following command:

   $ cd /opt/quay-install

3. Compress the contents of your Red Hat Quay deployment into an archive in the quay-backup directory by entering the following command:

   $ tar cvf /tmp/quay-backup/quay-backup.tar.gz *

   Example output:

   config.yaml
   config.yaml.bak
   extra_ca_certs/
   extra_ca_certs/ca.crt
   ssl.cert
   ssl.key

4. Back up the Quay container service by entering the following command:

   $ podman inspect quay-app | jq -r '.[0].Config.CreateCommand | .[]' | paste -s -d ' ' -
   
     /usr/bin/podman run --name quay-app \
     -v /opt/quay-install/config:/conf/stack:Z \
     -v /opt/quay-install/storage:/datastorage:Z \
     registry.redhat.io/quay/quay-rhel8:v3.12.15

5. Redirect the contents of your conf/stack/config.yaml file to your temporary quay-config.yaml file by entering the following command:

   $ podman exec -it quay cat /conf/stack/config.yaml > /tmp/quay-backup/quay-config.yaml

6. Obtain the DB_URI located in your temporary quay-config.yaml by entering the following command:

   $ grep DB_URI /tmp/quay-backup/quay-config.yaml

   Example output:

   $ postgresql://<username>:test123@172.24.10.50/quay

7. Extract the PostgreSQL contents to your temporary backup directory in a backup .sql file by entering the following command:

   $ pg_dump -h 172.24.10.50  -p 5432 -d quay  -U  <username>   -W -O > /tmp/quay-backup/quay-backup.sql

8. Print the contents of your DISTRIBUTED_STORAGE_CONFIG by entering the following command:

   DISTRIBUTED_STORAGE_CONFIG:
      default:
       - S3Storage
       - s3_bucket: <bucket_name>
         storage_path: /registry
         s3_access_key: <s3_access_key>
         s3_secret_key: <s3_secret_key>
         host: <host_name>
         s3_region: <region>

9. Export the AWS_ACCESS_KEY_ID by using the access_key credential obtained in Step 7:

   $ export AWS_ACCESS_KEY_ID=<access_key>

10. Export the AWS_SECRET_ACCESS_KEY by using the secret_key obtained in Step 7:

    $ export AWS_SECRET_ACCESS_KEY=<secret_key>

11. Sync the quay bucket to the /tmp/quay-backup/blob-backup/ directory from the hostname of your DISTRIBUTED_STORAGE_CONFIG:

    $ aws s3 sync s3://<bucket_name>  /tmp/quay-backup/blob-backup/ --source-region us-east-2

    Example output:

    download: s3://<user_name>/registry/sha256/9c/9c3181779a868e09698b567a3c42f3744584ddb1398efe2c4ba569a99b823f7a to registry/sha256/9c/9c3181779a868e09698b567a3c42f3744584ddb1398efe2c4ba569a99b823f7a
    download: s3://<user_name>/registry/sha256/e9/e9c5463f15f0fd62df3898b36ace8d15386a6813ffb470f332698ecb34af5b0d to registry/sha256/e9/e9c5463f15f0fd62df3898b36ace8d15386a6813ffb470f332698ecb34af5b0d

Procedure

1. Create a new directory that will bind-mount to /conf/stack inside of the Red Hat Quay container:

   $ mkdir /opt/new-quay-install

2. Copy the contents of your temporary backup directory created in Backing up Red Hat Quay on standalone deployments to the new-quay-install1 directory created in Step 1:

   $ cp /tmp/quay-backup/quay-backup.tar.gz /opt/new-quay-install/

3. Change into the new-quay-install directory by entering the following command:

   $ cd /opt/new-quay-install/

4. Extract the contents of your Red Hat Quay directory:

   $ tar xvf /tmp/quay-backup/quay-backup.tar.gz *

   Example output:

   config.yaml
   config.yaml.bak
   extra_ca_certs/
   extra_ca_certs/ca.crt
   ssl.cert
   ssl.key

5. Recall the DB_URI from your backed-up config.yaml file by entering the following command:

   $ grep DB_URI config.yaml

   Example output:

   postgresql://<username>:test123@172.24.10.50/quay

6. Run the following command to enter the PostgreSQL database server:

   $ sudo postgres

7. Enter psql and create a new database in 172.24.10.50 to restore the quay databases, for example, example_restore_registry_quay_database, by entering the following command:

   $ psql "host=172.24.10.50  port=5432 dbname=postgres user=<username>  password=test123"
   postgres=> CREATE DATABASE example_restore_registry_quay_database;

   Example output:

   CREATE DATABASE

8. Connect to the database by running the following command:

   postgres=# \c "example-restore-registry-quay-database";

   Example output:

   You are now connected to database "example-restore-registry-quay-database" as user "postgres".

9. Create a pg_trmg extension of your Quay database by running the following command:

   example_restore_registry_quay_database=> CREATE EXTENSION IF NOT EXISTS pg_trgm;

   Example output:

   CREATE EXTENSION

10. Exit the postgres CLI by entering the following command:

    \q

11. Import the database backup to your new database by running the following command:

    $ psql "host=172.24.10.50 port=5432 dbname=example_restore_registry_quay_database user=<username> password=test123"  -W <  /tmp/quay-backup/quay-backup.sql

    Example output:

    SET
    SET
    SET
    SET
    SET

    Update the value of DB_URI in your config.yaml from postgresql://<username>:test123@172.24.10.50/quay to postgresql://<username>:test123@172.24.10.50/example-restore-registry-quay-database before restarting the Red Hat Quay deployment.

1. In the /opt/new-quay-install directory, print the contents of your DISTRIBUTED_STORAGE_CONFIG bundle:

   $ cat config.yaml | grep DISTRIBUTED_STORAGE_CONFIG -A10

   Example output:

   DISTRIBUTED_STORAGE_CONFIG:
      default:
   DISTRIBUTED_STORAGE_CONFIG:
      default:
       - S3Storage
       - s3_bucket: <bucket_name>
         storage_path: /registry
         s3_access_key: <s3_access_key>
         s3_region: <region>
         s3_secret_key: <s3_secret_key>
         host: <host_name>

1. Export the AWS_ACCESS_KEY_ID by using the access_key credential obtained in Step 13:

   $ export AWS_ACCESS_KEY_ID=<access_key>

2. Export the AWS_SECRET_ACCESS_KEY by using the secret_key obtained in Step 13:

   $ export AWS_SECRET_ACCESS_KEY=<secret_key>

3. Create a new s3 bucket by entering the following command:

   $ aws s3 mb s3://<new_bucket_name>  --region us-east-2

   Example output:

   $ make_bucket: quay

4. Upload all blobs to the new s3 bucket by entering the following command:

   $ aws s3 sync --no-verify-ssl \
   --endpoint-url <example_endpoint_url> 

   1

   
   /tmp/quay-backup/blob-backup/. s3://quay/

   1

   The Red Hat Quay registry endpoint must be the same before backup and after restore.

   Example output:

   upload: ../../tmp/quay-backup/blob-backup/datastorage/registry/sha256/50/505edb46ea5d32b5cbe275eb766d960842a52ee77ac225e4dc8abb12f409a30d to s3://quay/datastorage/registry/sha256/50/505edb46ea5d32b5cbe275eb766d960842a52ee77ac225e4dc8abb12f409a30d
   upload: ../../tmp/quay-backup/blob-backup/datastorage/registry/sha256/27/27930dc06c2ee27ac6f543ba0e93640dd21eea458eac47355e8e5989dea087d0 to s3://quay/datastorage/registry/sha256/27/27930dc06c2ee27ac6f543ba0e93640dd21eea458eac47355e8e5989dea087d0
   upload: ../../tmp/quay-backup/blob-backup/datastorage/registry/sha256/8c/8c7daf5e20eee45ffe4b36761c4bb6729fb3ee60d4f588f712989939323110ec to s3://quay/datastorage/registry/sha256/8c/8c7daf5e20eee45ffe4b36761c4bb6729fb3ee60d4f588f712989939323110ec
   ...

5. Before restarting your Red Hat Quay deployment, update the storage settings in your config.yaml:

   DISTRIBUTED_STORAGE_CONFIG:
      default:
   DISTRIBUTED_STORAGE_CONFIG:
      default:
       - S3Storage
       - s3_bucket: <new_bucket_name>
         storage_path: /registry
         s3_access_key: <s3_access_key>
         s3_secret_key: <s3_secret_key>
         s3_region: <region>
         host: <host_name>

Procedure

1. Back up the config.yaml of your standalone Red Hat Quay deployment:

   $ mkdir /tmp/quay-backup
   $ cp /path/to/Quay/config/directory/config.yaml /tmp/quay-backup

2. Create a backup of the database that your standalone Red Hat Quay deployment is using:

   $ pg_dump -h DB_HOST -p 5432 -d QUAY_DATABASE_NAME -U QUAY_DATABASE_USER -W -O > /tmp/quay-backup/quay-database-backup.sql

3. Install the AWS CLI if you do not have it already.

4. Create an ~/.aws/ directory:

   $ mkdir ~/.aws/

5. Obtain the access_key and secret_key from the config.yaml of your standalone deployment:

   $ grep -i DISTRIBUTED_STORAGE_CONFIG -A10 /tmp/quay-backup/config.yaml

   Example output:

   DISTRIBUTED_STORAGE_CONFIG:
       minio-1:
           - RadosGWStorage
           - access_key: ##########
             bucket_name: quay
             hostname: 172.24.10.50
             is_secure: false
             port: "9000"
             secret_key: ##########
             storage_path: /datastorage/registry

6. Store the access_key and secret_key from the config.yaml file in your ~/.aws directory:

   $ touch ~/.aws/credentials

7. Optional: Check that your access_key and secret_key are stored:

   $ cat > ~/.aws/credentials << EOF
   [default]
   aws_access_key_id = ACCESS_KEY_FROM_QUAY_CONFIG
   aws_secret_access_key = SECRET_KEY_FROM_QUAY_CONFIG
   EOF

   Example output:

   aws_access_key_id = ACCESS_KEY_FROM_QUAY_CONFIG
   aws_secret_access_key = SECRET_KEY_FROM_QUAY_CONFIG

1. In your quay-backup directory, create a bucket_backup directory:

   $ mkdir /tmp/quay-backup/bucket-backup

2. Backup all blobs from the S3 storage:

   $ aws s3 sync --no-verify-ssl --endpoint-url https://PUBLIC_S3_ENDPOINT:PORT s3://QUAY_BUCKET/ /tmp/quay-backup/bucket-backup/

1. Scale down the Red Hat Quay Operator:

   $ oc scale --replicas=0 deployment quay-operator.v3.6.2 -n openshift-operators

2. Scale down the application and mirror deployments:

   $ oc scale --replicas=0 deployment QUAY_MAIN_APP_DEPLOYMENT QUAY_MIRROR_DEPLOYMENT

3. Copy the database SQL backup to the Quay PostgreSQL database instance:

   $ oc cp /tmp/user/quay-backup/quay-database-backup.sql quay-enterprise/quayregistry-quay-database-54956cdd54-p7b2w:/var/lib/pgsql/data/userdata

4. Obtain the database password from the Operator-created config.yaml file:

   $ oc get deployment quay-quay-app -o json | jq '.spec.template.spec.volumes[].projected.sources' | grep -i config-secret

   Example output:

         "name": "QUAY_CONFIG_SECRET_NAME"

   $ oc get secret quay-quay-config-secret-9t77hb84tb -o json | jq '.data."config.yaml"' | cut -d '"' -f2 | base64 -d -w0 > /tmp/quay-backup/operator-quay-config-yaml-backup.yaml

   cat /tmp/quay-backup/operator-quay-config-yaml-backup.yaml | grep -i DB_URI

   Example output:

   postgresql://QUAY_DATABASE_OWNER:PASSWORD@DATABASE_HOST/QUAY_DATABASE_NAME

5. Execute a shell inside of the database pod:

   # oc exec -it quay-postgresql-database-pod -- /bin/bash

6. Enter psql:

   bash-4.4$ psql

7. Drop the database:

   postgres=# DROP DATABASE "example-restore-registry-quay-database";

   Example output:

   DROP DATABASE

8. Create a new database and set the owner as the same name:

   postgres=# CREATE DATABASE "example-restore-registry-quay-database" OWNER "example-restore-registry-quay-database";

   Example output:

   CREATE DATABASE

9. Connect to the database:

   postgres=# \c "example-restore-registry-quay-database";

   Example output:

   You are now connected to database "example-restore-registry-quay-database" as user "postgres".

10. Create a pg_trmg extension of your Quay database:

    example-restore-registry-quay-database=# create extension pg_trgm ;

    Example output:

    CREATE EXTENSION

11. Exit the postgres CLI to re-enter bash-4.4:

    \q

12. Set the password for your PostgreSQL deployment:

    bash-4.4$ psql -h localhost -d "QUAY_DATABASE_NAME" -U QUAY_DATABASE_OWNER -W < /var/lib/pgsql/data/userdata/quay-database-backup.sql

    Example output:

    SET
    SET
    SET
    SET
    SET

13. Exit bash mode:

    bash-4.4$ exit

14. Create a new configuration bundle for the Red Hat Quay Operator.

    $ touch config-bundle.yaml

15. In your new config-bundle.yaml, include all of the information that the registry requires, such as LDAP configuration, keys, and other modifications that your old registry had. Run the following command to move the secret_key to your config-bundle.yaml:

    $ cat /tmp/quay-backup/config.yaml | grep SECRET_KEY > /tmp/quay-backup/config-bundle.yaml

1. Create a configuration bundle secret inside of your OpenShift cluster:

   $ oc create secret generic new-custom-config-bundle --from-file=config.yaml=/tmp/quay-backup/config-bundle.yaml

2. Scale up the Quay pods:

   $ oc scale --replicas=1 deployment quayregistry-quay-app
   deployment.apps/quayregistry-quay-app scaled

3. Scale up the mirror pods:

   $ oc scale --replicas=1  deployment quayregistry-quay-mirror
   deployment.apps/quayregistry-quay-mirror scaled

4. Patch the QuayRegistry CRD so that it contains the reference to the new custom configuration bundle:

   $ oc patch quayregistry QUAY_REGISTRY_NAME --type=merge -p '{"spec":{"configBundleSecret":"new-custom-config-bundle"}}'

1. Create a new AWS credentials.yaml in your /.aws/ directory and include the access_key and secret_key from the Operator-created config.yaml file:

   $ touch credentials.yaml

   $ grep -i DISTRIBUTED_STORAGE_CONFIG -A10 /tmp/quay-backup/operator-quay-config-yaml-backup.yaml

   $ cat > ~/.aws/credentials << EOF
   [default]
   aws_access_key_id = ACCESS_KEY_FROM_QUAY_CONFIG
   aws_secret_access_key = SECRET_KEY_FROM_QUAY_CONFIG
   EOF

1. Record the NooBaa’s publicly available endpoint:

   $ oc get route s3 -n openshift-storage -o yaml -o jsonpath="{.spec.host}{'\n'}"

2. Sync the backup data to the NooBaa backend storage:

   $ aws s3 sync --no-verify-ssl --endpoint-url https://NOOBAA_PUBLIC_S3_ROUTE /tmp/quay-backup/bucket-backup/* s3://QUAY_DATASTORE_BUCKET_NAME

3. Scale the Operator back up to 1 pod:

   $ oc scale –replicas=1 deployment quay-operator.v3.6.4 -n openshift-operators

Procedure

1. Add the IGNORE_UNKNOWN_MEDIATYPES configuration field to your Red Hat Quay config.yaml file:

   IGNORE_UNKNOWN_MEDIATYPES: true

   With this field enabled, your Red Hat Quay deployment accepts unknown and unrecognized artifact types.

Procedure

1. Enter the following command to ensure that garbage collection is properly working:

   $ sudo podman logs <container_id>

   Example output:

   gcworker stdout | 2022-11-14 18:46:52,458 [63] [INFO] [apscheduler.executors.default] Job "GarbageCollectionWorker._garbage_collection_repos (trigger: interval[0:00:30], next run at: 2022-11-14 18:47:22 UTC)" executed successfully

2. Delete an image tag.

3. Enter the following command to ensure that the tag was deleted:

   $ podman logs quay-app

   Example output:

   gunicorn-web stdout | 2022-11-14 19:23:44,574 [233] [INFO] [gunicorn.access] 192.168.0.38 - - [14/Nov/2022:19:23:44 +0000] "DELETE /api/v1/repository/quayadmin/busybox/tag/test HTTP/1.0" 204 0 "http://quay-server.example.com/repository/quayadmin/busybox?tab=tags" "Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0"

Procedure

1. Log in to your deployment.

2. In the navigation pane of your deployment, you are given the option to toggle between Current UI and New UI. Click the toggle button to set it to new UI, and then click Use Beta Environment, for example:

   

Procedure

1. Click Organization in the navigation pane.
2. Click Create Organization.
3. Enter an Organization Name, for example, testorg.
4. Click Create.

Procedure

1. On the Organizations page, select the name of the organization you want to delete, for example, testorg.
2. Click the More Actions drop down menu.
3. Click Delete.

1. Confirm that you want to permanently delete the organization by typing confirm in the box.

2. Click Delete.

   After deletion, you are returned to the Organizations page.

Procedure

1. Click Repositories on the navigation pane.
2. Click Create Repository.
3. Select a namespace, for example, quayadmin, and then enter a Repository name, for example, testrepo.

1. Click Create.

   Now, your example repository should populate under the Repositories page.

Procedure

1. On the Repositories page of the v2 UI, click the name of the image you want to delete, for example, quay/admin/busybox.
2. Click the More Actions drop-down menu.
3. Click Delete.

1. Type confirm in the box, and then click Delete.
2. After deletion, you are returned to the Repositories page.

Procedure

1. Pull a sample image from an external registry:

   $ podman pull busybox

2. Tag the image:

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

3. Push the image to your registry:

   $ podman push quay-server.example.com/quayadmin/busybox:test

4. Navigate to the Repositories page on the v2 UI and ensure that your image has been properly pushed.
5. You can check the security details by selecting your image tag, and then navigating to the Security Report page.

Procedure

1. On the Repositories page of the v2 UI, click the name of the image you want to delete, for example, quay/admin/busybox.
2. Click the More Actions drop-down menu.
3. Click Delete.

1. Type confirm in the box, and then click Delete.
2. After deletion, you are returned to the Repositories page.

Procedure

1. On the Red Hat Quay v2 UI, click the name of an organization.
2. On your organization’s page, click Teams and membership.
3. Click the Create new team box.
4. In the Create team popup window, provide a name for your new team.
5. Optional. Provide a description for your new team.
6. Click Proceed. A new popup window appears.
7. Optional. Add this team to a repository, and set the permissions to one of Read, Write, Admin, or None.
8. Optional. Add a team member or robot account. To add a team member, enter the name of their Red Hat Quay account.

9. Review and finish the information, then click Review and Finish. The new team appears under the Teams and membership page. From here, you can click the kebab menu, and select one of the following options:

   • Manage Team Members. On this page, you can view all members, team members, robot accounts, or users who have been invited. You can also add a new team member by clicking Add new member.
   • Set repository permissions. On this page, you can set the repository permissions to one of Read, Write, Admin, or None.
   • Delete. This popup windows allows you to delete the team by clicking Delete.

10. Optional. You can click the one of the following options to reveal more information about teams, members, and collaborators:

    • Team View. This menu shows all team names, the number of members, the number of repositories, and the role for each team.
    • Members View. This menu shows all usernames of team members, the teams that they are part of, the repository permissions of the user.
    • Collaborators View. This menu shows repository collaborators. Collaborators are users that do not belong to any team in the organization, but who have direct permissions on one or more repositories belonging to the organization.

Procedure

1. On the v2 UI, click Organizations.
2. Click the name of the organization that you will create the robot account for, for example, test-org.
3. Click the Robot accounts tab Create robot account.
4. In the Provide a name for your robot account box, enter a name, for example, robot1.

5. Optional. The following options are available if desired:

   1. Add the robot to a team.
   2. Add the robot to a repository.
   3. Adjust the robot’s permissions.

6. On the Review and finish page, review the information you have provided, then click Review and finish. The following alert appears: Successfully created robot account with robot name: <organization_name> + <robot_name>.

   Alternatively, if you tried to create a robot account with the same name as another robot account, you might receive the following error message: Error creating robot account.

7. Optional. You can click Expand or Collapse to reveal descriptive information about the robot account.
8. Optional. You can change permissions of the robot account by clicking the kebab menu Set repository permissions. The following message appears: Successfully updated repository permission.
9. Optional. To delete your robot account, check the box of the robot account and click the trash can icon. A popup box appears. Type confirm in the text box, then, click Delete. Alternatively, you can click the kebab menu Delete. The following message appears: Successfully deleted robot account.

Procedure

1. On the Red Hat Quay v2 UI landing page, click Organizations in the navigation pane.
2. On the Organizations page, select the name of the organization that has multiple repositories. The number of repositories under a single organization can be found under the Repo Count column.
3. On your organization’s page, click Robot accounts.
4. For the robot account that will be added to multiple repositories, click the kebab icon Set repository permissions.

5. On the Set repository permissions page, check the boxes of the repositories that the robot account will be added to. For example:

   

6. Set the permissions for the robot account, for example, None, Read, Write, Admin.
7. Click save. An alert that says Success alert: Successfully updated repository permission appears on the Set repository permissions page, confirming the changes.
8. Return to the Organizations Robot accounts page. Now, the Repositories column of your robot account shows the number of repositories that the robot account has been added to.

Procedure

1. Click the name of an organization.
2. Click Default permissions.
3. Click create default permissions. A toggle drawer appears.

4. Select either Anyone or Specific user to create a default permission when a repository is created.

   1. If selecting Anyone, the following information must be provided:

      • Applied to. Search, invite, or add a user/robot/team.
      • Permission. Set the permission to one of Read, Write, or Admin.

   2. If selecting Specific user, the following information must be provided:

      • Repository creator. Provide either a user or robot account.
      • Applied to. Provide a username, robot account, or team name.
      • Permission. Set the permission to one of Read, Write, or Admin.
5. Click Create default permission. A confirmation box appears, returning the following alert: Successfully created default permission for creator.

Procedure

1. On the v2 UI, click Organizations.
2. Click the name of the organization that you will create the robot account for, for example, test-org.
3. Click the Settings tab.
4. Optional. Enter the email address associated with the organization.

5. Optional. Set the allotted time for the Time Machine feature to one of the following:

   • 1 week
   • 1 month
   • 1 year
   • Never
6. Click Save.

Procedure

1. On the v2 UI, click Repositories.
2. Click the name of a repository, for example, quayadmin/busybox.

3. Click the name of the tag, for example, test. You are taken to the Details page of the tag. The page reveals the following information:

   • Name
   • Repository
   • Digest
   • Vulnerabilities
   • Creation
   • Modified
   • Size
   • Labels
   • How to fetch the image tag
4. Optional. Click Security Report to view the tag’s vulnerabilities. You can expand an advisory column to open up CVE data.
5. Optional. Click Packages to view the tag’s packages.
6. Click the name of the repository, for example, busybox, to return to the Tags page.
7. Optional. Hover over the Pull icon to reveal the ways to fetch the tag.
8. Check the box of the tag, or multiple tags, click the Actions drop down menu, and then Delete to delete the tag. Confirm deletion by clicking Delete in the popup box.

Procedure

1. On the v2 UI, click Repositories.
2. Click the name of a repository, for example, quayadmin/busybox.
3. Click the Settings tab.
4. Optional. Click User and robot permissions. You can adjust the settings for a user or robot account by clicking the dropdown menu option under Permissions. You can change the settings to Read, Write, or Admin.

5. Optional. Click Events and notifications. You can create an event and notification by clicking Create Notification. The following event options are available:

   • Push to Repository
   • Package Vulnerability Found
   • Image build failed
   • Image build queued
   • Image build started
   • Image build success

   • Image build cancelled

     Then, issue a notification. The following options are available:

   • Email Notification
   • Flowdock Team Notification
   • HipChat Room Notification
   • Slack Notification

   • Webhook POST

     After selecting an event option and the method of notification, include a Room ID #, a Room Notification Token, then, click Submit.

6. Optional. Click Repository visibility. You can make the repository private, or public, by clicking Make Public.
7. Optional. Click Delete repository. You can delete the repository by clicking Delete Repository.

Procedure

1. On the Red Hat Quay v2 UI dashboard, click Repositories in the navigation pane.
2. Click the name of a repository that has image tags.

3. Click Tag History. On this page, you can perform the following actions:

   • Search by tag name
   • Select a date range
   • View tag changes
   • View tag modification dates and the time at which they were changed

Procedure

1. On the Red Hat Quay v2 UI dashboard, click Repositories in the navigation pane.
2. Click the name of a repository that has image tags.
3. Click the menu kebab for an image and select Edit labels.
4. In the Edit labels window, click Add new label.
5. Enter a label for the image tag using the key=value format, for example, com.example.release-date=2023-11-14.

1. Click the whitespace of the box to add the label.
2. Optional. Add a second label.
3. Click Save labels to save the label to the image tag. The following notification is returned: Created labels successfully.
4. Optional. Click the same image tag’s menu kebab Edit labels X on the label to remove it; alternatively, you can edit the text. Click Save labels. The label is now removed or edited.

Procedure

1. On the Red Hat Quay v2 UI dashboard, click Repositories in the navigation pane.
2. Click the name of a repository that has image tags.
3. Click the menu kebab for an image and select Change expiration.
4. Optional. Alternatively, you can bulk add expiration dates by clicking the box of multiple tags, and then select Actions Set expiration.
5. In the Change Tags Expiration window, set an expiration date, specifying the day of the week, month, day of the month, and year. For example, Wednesday, November 15, 2023. Alternatively, you can click the calendar button and manually select the date.
6. Set the time, for example, 2:30 PM.
7. Click Change Expiration to confirm the date and time. The following notification is returned: Successfully set expiration for tag test to Nov 15, 2023, 2:26 PM.

8. On the Red Hat Quay v2 UI Tags page, you can see when the tag is set to expire. For example:

   

Procedure

1. Log in to your Red Hat Quay repository.
2. In the navigation pane, click your username, for example, quayadmin.
3. Under Appearance, select between Light theme, Dark theme, and Device-based theme. Device based theme sets the mode depending on your browser’s color preference.

Procedure

1. Log in to your Red Hat Quay registry.
2. Navigate to an Organization, repository, or namespace for which you are an administrator of.

3. Click Logs.

   

4. Optional. Set the date range for viewing log entries by adding dates to the From and To boxes.
5. Optional. Export the logs by clicking Export. You must enter an email address or a valid callback URL that starts with http:// or https://. This process can take an hour depending on how many logs there are.

1. In the navigation pane, you are given the option to toggle between Current UI and New UI. Click the toggle button to set it to Current UI.

   

Procedure

1. On your web browser, navigate to https://{quay-ip-endpoint}/health/instance.

2. You are taken to the health instance page, which returns information like the following:

   {"data":{"services":{"auth":true,"database":true,"disk_space":true,"registry_gunicorn":true,"service_key":true,"web_gunicorn":true}},"status_code":200}

   For Red Hat Quay, "status_code": 200 means that the instance is health. Conversely, if you receive "status_code": 503, there is an issue with your deployment.

Procedure

1. Update your Red Hat Quay config.yaml file to add the following parameters:

   BRANDING:
       logo: 

   1

   
       footer_img: 

   2

   
       footer_url: 

   3

   
   ---
   REGISTRY_TITLE: 

   4

   
   REGISTRY_TITLE_SHORT: 

   5

   1

   The URL of the image that will appear at the top of your Red Hat Quay deployment.

   2

   The URL of the image that will appear at the bottom of your Red Hat Quay deployment.

   3

   The URL of the website that users will be directed to when clicking the footer image.

   4

   The long-form title for the registry. This is displayed in frontend of your Red Hat Quay deployment, for example, at the sign in page of your organization.

   5

   The short-form title for the registry. The title is displayed on various pages of your organization, for example, as the title of the tutorial on your organization’s Tutorial page.

2. Restart your Red Hat Quay deployment. After restarting, your Red Hat Quay deployment is updated with a new logo, footer image, and footer image URL.