Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 7. Mirroring images with Red Hat Quay
To mirror images from external registries into your Red Hat Quay cluster and synchronize by repository or organization names and tags, you can repository mirroring.
From your Red Hat Quay cluster with mirroring enabled, you can perform the following:
- Choose a repository or organization from an external registry to mirror
- Add credentials to access the external registry
- Identify specific container image repository or organization names and tags to sync
- Set intervals at which a repository or organization is synced
- Check the current state of synchronization
- Filter the architectures that are mirrored
To use the mirroring functionality, you need to perform the following actions:
- Enable mirroring in the Red Hat Quay configuration file
- Run a mirroring worker
- Create mirrored repositories
All mirroring configurations can be performed by using the configuration tool UI or by the Red Hat Quay API.
7.1. Mirroring compared to geo-replication Link kopierenLink in die Zwischenablage kopiert!
To replicate your entire image storage backend data across multiple environments, configure Red Hat Quay geo-replication. Synchronizing different storage backends while sharing a central database ensures consistent, highly available access to your registry.
An example of Red Hat Quay geo-replication mirrors is where one Red Hat Quay registry has two different blob storage endpoints.
The primary use cases for geo-replication include the following:
- Speeding up access to the binary blobs for geographically dispersed setups
- Guaranteeing that the image content is the same across regions
Mirroring synchronizes selected repositories, or subsets of repositories, from one registry to another. The registries are distinct, with each registry having a separate database and separate image storage.
The primary use cases for mirroring include the following:
- Independent registry deployments in different data centers or regions, where a certain subset of the overall content is supposed to be shared across the data centers and regions
- Automatic synchronization or mirroring of selected (allowlisted) upstream repositories from external registries into a local Red Hat Quay deployment
Mirroring and geo-replication can be used simultaneously.
| Feature / Capability | Geo-replication | Mirroring |
|---|---|---|
| What is the feature designed to do? | A shared, global registry | Distinct, different registries |
| What happens if replication or mirroring has not been completed yet? | The remote copy is used (slower) | No image is served |
| Is access to all storage backends in both regions required? | Yes (all Red Hat Quay nodes) | No (distinct storage) |
| Can users push images from both sites to the same repository or organization? | Yes | No |
| Is all registry content and configuration identical across all regions (shared database)? | Yes | No |
| Can users select individual namespaces or repositories to be mirrored? | No | Yes |
| Can users apply filters to synchronization rules? | No | Yes |
| Are individual / different role-base access control configurations allowed in each region | No | Yes |
7.2. Using mirroring Link kopierenLink in die Zwischenablage kopiert!
To automatically synchronize container images across different environments, configure mirroring for your Red Hat Quay repository or organization. By reviewing the supported features and limitations of this capability, you can correctly plan your registry synchronization architecture.
The following list shows features and limitations of Red Hat Quay mirroring for a repository or organization.
The word entity is used in the mirroring documentation to refer to either a repository or organization.
- With mirroring, you can mirror an entire entity or selectively limit which images are synced. Filters can be based on a comma-separated list of tags, a range of tags, or other means of identifying tags through Unix shell-style wildcards. For more information, see the documentation for wildcards.
- After you set mirroring for an entity, you cannot manually add other images to that entity.
- Because the mirrored entity is based on the entity and the tags that you set, the entity holds only the content represented by the entity and tag pair. For example if you change the tag so that some images in the entity no longer match, those images will be deleted.
- Only the designated robot can push images to a mirrored entity, superseding any role-based access control permissions set on the entity.
- Mirroring can be configured to rollback on failure, or to run on a best-effort basis.
- With a mirrored entity, a user with read permissions can pull images from the entity but cannot push images to the entity.
- Changing settings on your mirrored entity can be performed in the Red Hat Quay user interface.
- Images are synced at set intervals, but can also be synced on demand.
7.3. Creating a mirroring worker worker Link kopierenLink in die Zwischenablage kopiert!
To use mirroring in a standalone deployment of Red Hat Quay, you must create a mirroring worker by running a Podman container with the repomirror option. Mount your /root/ca.crt CA bundle when you use TLS with that certificate.
Procedure
If you have not configured TLS communications using a
/root/ca.crtcertificate, enter the following command to start a mirroring worker:$ sudo podman run -d --name mirroring-worker \ -v $QUAY/config:/conf/stack:Z \ registry.redhat.io/quay/quay-rhel9:v3.17.0 repomirrorIf you have configured TLS communications using a
/root/ca.crtcertificate, enter the following command to start the repository mirroring worker:$ sudo podman run -d --name mirroring-worker \ -v $QUAY/config:/conf/stack:Z \ -v /root/ca.crt:/etc/pki/ca-trust/source/anchors/ca.crt:Z \ registry.redhat.io/quay/quay-rhel9:v3.17.0 repomirror
7.4. Enabling organization mirroring for Red Hat Quay Link kopierenLink in die Zwischenablage kopiert!
To use mirrored organizations, you can set FEATURE_ORG_MIRROR to true in your config.yaml file. Restart the registry after you update the configuration.
Procedure
To enable organization mirroring, set the following configuration fields in your
config.yamlfile:# ... FEATURE_PROXY_CACHE: true FEATURE_REPO_MIRROR: true FEATURE_ORG_MIRROR: true ORG_MIRROR_INTERVAL: 60 ORG_MIRROR_BATCH_SIZE: 100 ORG_MIRROR_MAX_SYNC_DURATION: 3600 ORG_MIRROR_DEFAULT_SKOPEO_TIMEOUT: 600 ORG_MIRROR_DISCOVERY_TIMEOUT: 600 ORG_MIRROR_MAX_REPOS_PER_ORG: 5000 ORG_MIRROR_MAX_RETRIES: 3 SSRF_ALLOWED_HOSTS: - harbor.example.lab # ...where:
FEATURE_PROXY_CACHE::Specifies whether to enable or disable proxy caching. This field must be set totrueto use the organization mirroring feature.FEATURE_REPO_MIRROR:: Specifies whether to enable or disable repository-level mirroring. This field must be set totrueto use the organization mirroring feature.FEATURE_ORG_MIRROR:: Specifies whether to enable or disable organization-level mirroring.ORG_MIRROR_INTERVAL:: Specifies the worker processing interval in seconds.ORG_MIRROR_BATCH_SIZE:: Specifies the number of organization mirrors to process for each iteration.ORG_MIRROR_MAX_SYNC_DURATION:: Specifies the maximum sync duration in seconds.ORG_MIRROR_DEFAULT_SKOPEO_TIMEOUT:: Specifies the default skopeo timeout in seconds.ORG_MIRROR_DISCOVERY_TIMEOUT:: Specifies the discovery timeout in seconds.ORG_MIRROR_MAX_REPOS_PER_ORG:: Specifies the maximum repositories to discover for each organization.ORG_MIRROR_MAX_RETRIES:: Specifies the maximum sync retries for a failure operation.SSRF_ALLOWED_HOSTS:: Specifies the allowed hosts for the Server Side Request Forgery (SSRF) protection. Use optional field to allow specific hosts to be accessed by the registry.- Restart your Red Hat Quay registry.
7.5. Creating a mirroring organization by using the UI Link kopierenLink in die Zwischenablage kopiert!
To automatically synchronize container images between registries, you can use the Red Hat Quay UI to create a mirroring organization. Configuring this automated synchronization ensures that your deployment always has access to the most up-to-date container files.
Organization-level mirroring cannot be configured on an existing organization that already contains repositories. A dedicated organization must be created specifically to serve as a mirror target, with all repositories within the organization managed exclusively by the mirroring configuration.
Prerequisites
- You have a Quay organization with sufficient permissions.
- You have created a robot account.
You have access to a source Harbor instance.
- You have Harbor credentials, such as a username and a password or an API token.
-
You have set
FEATURE_ORG_MIRROR: truein yourconfig.yamlfile. -
You have set
FEATURE_PROXY_CACHE: truein yourconfig.yamlfile. -
You have set
FEATURE_REPO_MIRROR: truein yourconfig.yamlfile. - For standalone Red Hat Quay deployments, you have created a mirroring worker.
If you are using an OAuth token to mirror from Quay to Quay, your token must have the following permission:
- Administer Repositories
- View all visible repositories
- Read/Write to any accessible repositories
- Administer User
Procedure
- On the Red Hat Quay v2 UI, click Organizations in the navigation pane.
- Find your organization listed under the Name column and then click on the name of the organization.
-
Click Settings
Organization state. - Click the Mirror radio button to set the organization state to mirroring.
- Click the Submit button. Completion of this step takes you to the Mirroring tab.
- Under the Source Registry section, complete the following settings:
- For Source Registry Type field, select Quay or Harbor.
-
In the Source Registry URL field, enter a valid URL, for example,
https://registry.example.com. -
For Source Namespace, enter the namespace or project name on the source registry. For example,
my-project. - Select Private or Public for Repository Visibility.
-
For Start Date, set the date in
yyyy-mm-ddformat and set the time. - Set the Sync interval. Set the integer in the box and select seconds, minutes, hours, days, or weeks from the drop-down menu.
- Set the Skopeo Timeout value for Skopeo operations.
- Select a Robot User from the drop-down menu.
- Set any desired Filter Patterns.
In the Credentials section, do one of the following actions:
- If you specified Harbor for Source Registry Type, enter your username and password for the source registry.
-
If you specified Quay for Source Registry Type, you must specify
$oauthtokenfor the Username field andOAUTH_TOKENfor the Password field.
Optional: In Advanced Settings:
- For Verify TLS, click the checkbox to verify certificates.
- Set an HTTP Proxy URL.
- Set an HTTPS Proxy URL.
- Set a No Proxy URL.
- When you have configured the desired settings, click Enable Organization Mirror.
Verification
-
On the Red Hat Quay web console, click Organizations
the organization name Mirroring. - Scroll to the Status section to view the status and verify the connection.
7.6. Creating a mirrored organization by using the API Link kopierenLink in die Zwischenablage kopiert!
To create a mirrored organization in Red Hat Quay by using the API, you can send HTTP requests to the organization mirror API endpoints with curl and an OAuth bearer token. You can create and update mirror settings, read the configuration and mirrored repositories, start or cancel a sync, verify the external registry, and delete the setup.
Organization-level mirroring cannot be configured on an existing organization that already contains repositories. A dedicated organization must be created specifically to serve as a mirror target, with all repositories within the organization managed exclusively by the mirroring configuration.
Prerequisites
- You have generated an OAuth access token.
Procedure
Use the
POST /api/v1/organization/{orgname}/mirrorendpoint to create a new organization-level mirroring configuration:$ curl -X POST "https://<quay-server.example.com>/api/v1/organization/<orgname>/mirror" \ -H "Authorization: Bearer <access_token>" \ -H "Accept: application/json" \ -H "Content-Type: application/json" \ -d '{ "external_registry_type": "quay", "external_registry_url": "https://quay.io", "external_namespace": "<external_namespace>", "robot_username": "<orgname>+<robot_account>", "visibility": "private", "sync_interval": 3600, "sync_start_date": "2025-01-01T00:00:00Z", "is_enabled": true }'Use the
GET /api/v1/organization/{orgname}/mirrorendpoint to retrieve the organization-level mirroring configuration:$ curl -X GET \ -H "Authorization: Bearer <bearer_token>" \ -H "Accept: application/json" \ https://<quay-server.example.com>/api/v1/organization/<orgname>/mirrorExample output
{"is_enabled": true, "external_registry_type": "quay", "external_registry_url": "http://quay.io", "external_namespace": "test", "external_registry_username": null, "external_registry_config": {}, "repository_filters": [], "robot_username": "example+test", "visibility": "private", "sync_interval": 3600, "sync_start_date": "2025-01-01T00:00:00Z", "sync_expiration_date": null, "sync_status": "NEVER_RUN", "sync_retries_remaining": 3, "skopeo_timeout": 300, "creation_date": "2026-03-09T18:39:21.993431Z"}Use the
GET /api/v1/organization/{orgname}/mirror/repositoriesendpoint to obtain a list of repositories that are being mirrored in the organization:$ curl -X GET \ -H "Authorization: Bearer <bearer_token>" \ -H "Accept: application/json" \ "https://<quay-server.example.com>/api/v1/organization/<orgname>/mirror/repositories?page=1&limit=100"Example output
{"repositories": [], "page": 1, "limit": 100, "total": 0, "has_next": false}Use the
POST /api/v1/organization/{orgname}/mirror/sync-nowendpoint to trigger an immediate sync of all repositories in the organization:$ curl -X POST \ -H "Authorization: Bearer <bearer_token>" \ -H "Accept: application/json" \ https://<quay-server.example.com>/api/v1/organization/<orgname>/mirror/sync-nowThis command does not return output in the CLI.
Use the
POST /api/v1/organization/{orgname}/mirror/sync-cancelendpoint to cancel a pending sync of all repositories in the organization:$ curl -X POST \ -H "Authorization: Bearer <bearer_token>" \ -H "Accept: application/json" \ https://<quay-server.example.com>/api/v1/organization/<orgname>/mirror/sync-cancelThis command does not return output in the CLI.
Use the
PUT /api/v1/organization/{orgname}/mirrorendpoint to update the organization-level mirroring configuration:$ curl -X PUT \ -H "Authorization: Bearer <bearer_token>" \ -H "Accept: application/json" \ -H "Content-Type: application/json" \ -d '{"is_enabled": true, "sync_interval": 7200}' \ https://<quay-server.example.com>/api/v1/organization/<orgname>/mirrorExample output
" "Use the
POST /api/v1/organization/{orgname}/mirror/verifyendpoint to verify the connection to the external registry for the organization-level mirroring configuration:$ curl -X POST \ -H "Authorization: Bearer <bearer_token>" \ -H "Accept: application/json" \ https://<quay-server.example.com>/api/v1/organization/<orgname>/mirror/verifyExample output
{"success": false, "message": "Unexpected response: 301"}Use the
DELETE /api/v1/organization/{orgname}/mirrorendpoint to delete the organization-level mirroring configuration:$ curl -X DELETE \ -H "Authorization: Bearer <bearer_token>" \ -H "Accept: application/json" \ https://<quay-server.example.com>/api/v1/organization/<orgname>/mirrorThis command does not return output in the CLI.
7.7. Enabling repository mirroring for Red Hat Quay Link kopierenLink in die Zwischenablage kopiert!
To use mirrored repositories, you can set FEATURE_REPO_MIRROR to true in your config.yaml file. Restart the registry after you update the configuration.
Procedure
To enable mirroring for repositories, set
FEATURE_REPO_MIRROR: truein yourconfig.yamlfile:# ... FEATURE_REPO_MIRROR: true REPO_MIRROR_INTERVAL: 30 REPO_MIRROR_SERVER_HOSTNAME: "openshift-quay-service" REPO_MIRROR_TLS_VERIFY: true REPO_MIRROR_ROLLBACK: false FEATURE_SPARSE_INDEX: true REPO_MIRROR_MAX_MANIFEST_LIST_SIZE: 10485760 REPO_MIRROR_MAX_MANIFEST_ENTRIES: 1000 # ...where:
FEATURE_REPO_MIRROR- Specifies whether to enable or disable repository-level mirroring.
REPO_MIRROR_INTERVAL- Specifies the worker processing interval in seconds.
REPO_MIRROR_SERVER_HOSTNAME- Specifies the hostname of the server hosting the mirrored repository.
REPO_MIRROR_TLS_VERIFY- Specifies whether to verify the TLS certificate of the mirrored repository.
REPO_MIRROR_ROLLBACK- Specifies whether to rollback the repository if the mirroring fails.
FEATURE_SPARSE_INDEX- Specifies whether to allow sparse manifest indexes.
REPO_MIRROR_MAX_MANIFEST_LIST_SIZE- Specifies the maximum size of the manifest list in bytes.
REPO_MIRROR_MAX_MANIFEST_ENTRIES- Specifies the maximum number of manifest entries to process.
- Restart your Red Hat Quay registry.
7.8. Creating a mirrored repository by using the UI Link kopierenLink in die Zwischenablage kopiert!
When mirroring a repository from an external container registry, you must create a new private repository. Typically, the same name is used as the target repository, for example, quay-rhel9.
Prerequisites
-
You have set
FEATURE_REPO_MIRROR: truein yourconfig.yamlfile. - For standalone Red Hat Quay deployments, you have created a mirroring worker.
- You have created a robot account.
Procedure
- Navigate to the Repositories page of your registry and click the name of a repository, for example, test-mirror.
-
Click Settings
Repository state. - Click Mirror.
- Click the Mirroring tab and enter the details for connecting to the external registry, along with the tags, scheduling and access information:
Enter the details as required in the following fields:
-
Registry Location: The external repository you want to mirror, for example,
registry.redhat.io/quay/quay-rhel8. - Tags: Enter a comma-separated list of individual tags or tag patterns. (See Tag Patterns section for details.)
-
Architecture Filter: Select the architectures that you want to mirror. For example, select
AMD64 (x86_64)to mirror only thex86_64architecture. By default, all architectures are mirrored. - Start Date: The date on which mirroring begins. The current date and time is used by default.
- Sync Interval: Defaults to syncing every 24 hours. You can change that based on hours or days.
-
Skopeo timeout interval: Defaults to
300seconds (5 minutes). The maximum timeout length is43200seconds (12 hours). - Robot User: Create a new robot account or choose an existing robot account to do the mirroring.
- Username: The username for accessing the external registry holding the repository you are mirroring.
- Password: The password associated with the Username. Note that the password cannot include characters that require an escape character (\).
-
Registry Location: The external repository you want to mirror, for example,
In the Advanced Settings section, you can optionally configure SSL/TLS and proxy with the following options:
- Verify TLS: Select this option if you want to require HTTPS and to verify certificates when communicating with the target remote registry.
- Accept Unsigned Images: Selecting this option allows unsigned images to be mirrored.
- HTTP Proxy: Select this option if you want to require HTTPS and to verify certificates when communicating with the target remote registry.
- HTTPS PROXY: Identify the HTTPS proxy server needed to access the remote site, if a proxy server is needed.
- No Proxy: List of locations that do not require proxy.
- After filling out all information, click Enable Mirror.
7.9. Starting a mirroring synchronization Link kopierenLink in die Zwischenablage kopiert!
To initiate a mirroring sync, you can navigate to the Mirroring tab of your repository and press the Sync Now button.
Procedure
- Navigate to the Mirroring tab of your repository or organization.
- Press the Sync Now button.
Verification
- Click the Logs tab to view available logs.
- When mirroring is complete, the image appear in the Tags tab.
7.10. Event notifications for mirroring Link kopierenLink in die Zwischenablage kopiert!
There are three notification events for repository mirroring:
- Repository Mirror Started
- Repository Mirror Success
- Repository Mirror Unsuccessful
The events can be configured inside of the Settings tab for each repository, and all existing notification methods such as email, Slack, Quay UI, and webhooks are supported.
7.11. Mirroring tag patterns Link kopierenLink in die Zwischenablage kopiert!
At least one tag must be entered. The following table references possible image tag patterns.
7.11.1. Pattern syntax Link kopierenLink in die Zwischenablage kopiert!
| Pattern | Description |
| * | Matches all characters |
| ? | Matches any single character |
| [seq] | Matches any character in seq |
| [!seq] | Matches any character not in seq |
7.11.2. Example tag patterns Link kopierenLink in die Zwischenablage kopiert!
| Example Pattern | Example Matches |
| v3* | v32, v3.1, v3.2, v3.2-4beta, v3.3 |
| v3.* | v3.1, v3.2, v3.2-4beta |
| v3.? | v3.1, v3.2, v3.3 |
| v3.[12] | v3.1, v3.2 |
| v3.[12]* | v3.1, v3.2, v3.2-4beta |
| v3.[!1]* | v3.2, v3.2-4beta, v3.3 |
7.12. Working with mirrored repositories Link kopierenLink in die Zwischenablage kopiert!
After you have created a mirrored repository, there are several ways that you can work with that repository.
Select your mirrored repository from the Repositories page to do any of the following:
- Enable/disable the repository: Select the Mirroring button in the left column, then toggle the Enabled check box to enable or disable the repository temporarily.
- Check mirror logs: To make sure the mirrored repository is working properly, you can check the mirror logs. To do that, select the Usage Logs button in the left column. Here’s an example:
- Sync mirror now: To immediately sync the images in your repository, select the Sync Now button.
- Change credentials: To change the username and password, select DELETE from the Credentials line. Then select None and add the username and password needed to log into the external registry when prompted.
- Cancel mirroring: To stop mirroring, which keeps the current images available but stops new ones from being synced, select the CANCEL button.
Set robot permissions: Red Hat Quay robot accounts are named tokens that hold credentials for accessing external repositories. By assigning credentials to a robot, that robot can be used across multiple mirrored repositories that need to access the same external registry.
You can assign an existing robot to a repository by navigating to Organizations
Robot accounts. On this page, you can view the following information: - Check which repositories are assigned to that robot.
-
Assign
Read,WriteorAdminprivileges to that robot from the PERMISSION field.
- Change robot credentials: Robots can hold credentials such as Kubernetes secrets, Docker login information, and Podman login information. To change robot credentials, select the Options gear on the robot’s account line on the Robot Accounts window and choose View Credentials. Add the appropriate credentials for the external repository the robot needs to access.
- Check and change general setting: Select the Settings button (gear icon) from the left column on the mirrored repository page. On the resulting page, you can change settings associated with the mirrored repository. In particular, you can change User and Robot Permissions, to specify exactly which users and robots can read from or write to the repo.
7.13. Repository mirroring recommendations Link kopierenLink in die Zwischenablage kopiert!
Best practices for repository mirroring include the following:
- Repository mirroring pods can run on any node. This means that you can run mirroring on nodes where Red Hat Quay is already running.
- Repository mirroring is scheduled in the database and runs in batches. As a result, repository workers check each repository mirror configuration file and reads when the next sync needs to be. More mirror workers means more repositories can be mirrored at the same time. For example, running 10 mirror workers means that a user can run 10 mirroring operators in parallel. If a user only has 2 workers with 10 mirror configurations, only 2 operators can be performed.
The optimal number of mirroring pods depends on the following conditions:
- The total number of repositories to be mirrored
- The number of images and tags in the repositories and the frequency of changes
Parallel batching
For example, if a user is mirroring a repository that has 100 tags, the mirror will be completed by one worker. Users must consider how many repositories one wants to mirror in parallel, and base the number of workers around that.
Multiple tags in the same repository cannot be mirrored in parallel.