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

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
Note

Mirroring and geo-replication can be used simultaneously.

Expand
Table 7.1. Red Hat Quay mirroring and geo-replication comparison
Feature / CapabilityGeo-replicationMirroring

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

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.

Note

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

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.crt certificate, 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 repomirror
  • If you have configured TLS communications using a /root/ca.crt certificate, 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

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

  1. To enable organization mirroring, set the following configuration fields in your config.yaml file:

    # ...
    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 to true to use the organization mirroring feature. FEATURE_REPO_MIRROR:: Specifies whether to enable or disable repository-level mirroring. This field must be set to true to 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.

  2. Restart your Red Hat Quay registry.

7.5. Creating a mirroring organization by using the UI

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.

Note

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: true in your config.yaml file.
  • You have set FEATURE_PROXY_CACHE: true in your config.yaml file.
  • You have set FEATURE_REPO_MIRROR: true in your config.yaml file.
  • 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

  1. On the Red Hat Quay v2 UI, click Organizations in the navigation pane.
  2. Find your organization listed under the Name column and then click on the name of the organization.
  3. Click Settings Organization state.
  4. Click the Mirror radio button to set the organization state to mirroring.
  5. Click the Submit button. Completion of this step takes you to the Mirroring tab.
  6. Under the Source Registry section, complete the following settings:
  7. For Source Registry Type field, select Quay or Harbor.
  8. In the Source Registry URL field, enter a valid URL, for example, https://registry.example.com.
  9. For Source Namespace, enter the namespace or project name on the source registry. For example, my-project.
  10. Select Private or Public for Repository Visibility.
  11. For Start Date, set the date in yyyy-mm-dd format and set the time.
  12. Set the Sync interval. Set the integer in the box and select seconds, minutes, hours, days, or weeks from the drop-down menu.
  13. Set the Skopeo Timeout value for Skopeo operations.
  14. Select a Robot User from the drop-down menu.
  15. Set any desired Filter Patterns.
  16. In the Credentials section, do one of the following actions:

    1. If you specified Harbor for Source Registry Type, enter your username and password for the source registry.
    2. If you specified Quay for Source Registry Type, you must specify $oauthtoken for the Username field and OAUTH_TOKEN for the Password field.
  17. Optional: In Advanced Settings:

    1. For Verify TLS, click the checkbox to verify certificates.
    2. Set an HTTP Proxy URL.
    3. Set an HTTPS Proxy URL.
    4. Set a No Proxy URL.
  18. When you have configured the desired settings, click Enable Organization Mirror.

Verification

  1. On the Red Hat Quay web console, click Organizations the organization name Mirroring.
  2. Scroll to the Status section to view the status and verify the connection.

7.6. Creating a mirrored organization by using the API

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.

Note

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

  1. Use the POST /api/v1/organization/{orgname}/mirror endpoint 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
      }'
  2. Use the GET /api/v1/organization/{orgname}/mirror endpoint 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>/mirror

    Example 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"}

  3. Use the GET /api/v1/organization/{orgname}/mirror/repositories endpoint 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}

  4. Use the POST /api/v1/organization/{orgname}/mirror/sync-now endpoint 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-now

    This command does not return output in the CLI.

  5. Use the POST /api/v1/organization/{orgname}/mirror/sync-cancel endpoint 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-cancel

    This command does not return output in the CLI.

  6. Use the PUT /api/v1/organization/{orgname}/mirror endpoint 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>/mirror

    Example output

    " "

  7. Use the POST /api/v1/organization/{orgname}/mirror/verify endpoint 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/verify

    Example output

    {"success": false, "message": "Unexpected response: 301"}

  8. Use the DELETE /api/v1/organization/{orgname}/mirror endpoint 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>/mirror

    This command does not return output in the CLI.

7.7. Enabling repository mirroring for Red Hat Quay

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

  1. To enable mirroring for repositories, set FEATURE_REPO_MIRROR: true in your config.yaml file:

    # ...
    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.
  2. Restart your Red Hat Quay registry.

7.8. Creating a mirrored repository by using the UI

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: true in your config.yaml file.
  • For standalone Red Hat Quay deployments, you have created a mirroring worker.
  • You have created a robot account.

Procedure

  1. Navigate to the Repositories page of your registry and click the name of a repository, for example, test-mirror.
  2. Click Settings Repository state.
  3. Click Mirror.
  4. Click the Mirroring tab and enter the details for connecting to the external registry, along with the tags, scheduling and access information:
  5. 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 the x86_64 architecture. 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 300 seconds (5 minutes). The maximum timeout length is 43200 seconds (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 (\).
  6. 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.
  7. After filling out all information, click Enable Mirror.

7.9. Starting a mirroring synchronization

To initiate a mirroring sync, you can navigate to the Mirroring tab of your repository and press the Sync Now button.

Procedure

  1. Navigate to the Mirroring tab of your repository or organization.
  2. Press the Sync Now button.

Verification

  1. Click the Logs tab to view available logs.
  2. When mirroring is complete, the image appear in the Tags tab.

7.10. Event notifications for mirroring

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

At least one tag must be entered. The following table references possible image tag patterns.

7.11.1. Pattern syntax

Expand

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

Expand

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

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, Write or Admin privileges 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

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.

Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat Dokumentation

Legal Notice

Theme

© 2026 Red Hat
Nach oben