Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

9.3. Comprendre la mise en miroir du référentiel de registre d’images

La mise en place d’un référentiel de registre de conteneurs vous permet d’effectuer les tâches suivantes:

  • Configurez votre Red Hat OpenShift Service sur AWS cluster pour rediriger les requêtes pour extraire des images d’un référentiel sur un registre d’images source et le faire résoudre par un référentiel sur un registre d’images en miroir.
  • Identifiez plusieurs référentiels miroirs pour chaque référentiel cible, pour vous assurer que si un miroir est en panne, un autre peut être utilisé.

La mise en miroir du référentiel dans Red Hat OpenShift Service sur AWS inclut les attributs suivants:

  • Les tirages d’image sont résilients aux temps d’arrêt du registre.
  • Les clusters dans des environnements déconnectés peuvent tirer des images à partir d’emplacements critiques, tels que quay.io, et avoir des registres derrière un pare-feu d’entreprise fournissent les images demandées.
  • L’ordre particulier des registres est essayé lorsqu’une demande de tirage d’image est faite, le registre permanent étant généralement le dernier essayé.
  • Les informations de miroir que vous entrez sont ajoutées au fichier /etc/containers/registries.conf sur chaque nœud du service OpenShift Red Hat sur AWS cluster.
  • Lorsqu’un nœud fait une demande pour une image à partir du référentiel source, il essaie chaque référentiel miroir à son tour jusqu’à ce qu’il trouve le contenu demandé. En cas d’échec de tous les miroirs, le cluster essaie le référentiel source. En cas de succès, l’image est tirée vers le nœud.

La mise en place d’un référentiel de miroir peut se faire de la manière suivante:

  • Chez Red Hat OpenShift Service sur l’installation AWS:

    En tirant les images conteneur nécessaires par Red Hat OpenShift Service sur AWS, puis en apportant ces images derrière le pare-feu de votre entreprise, vous pouvez installer Red Hat OpenShift Service sur AWS dans un centre de données qui se trouve dans un environnement déconnecté.

  • Après Red Hat OpenShift Service sur l’installation AWS:

    Lorsque vous n’avez pas configuré de miroir pendant Red Hat OpenShift Service sur l’installation AWS, vous pouvez le faire en utilisant l’un des objets de ressource personnalisée (CR) suivants:

    • ImageDigestMirrorSet (IDMS). Cet objet vous permet de tirer des images d’un registre en miroir en utilisant des spécifications de digestion. L’IDMS CR vous permet de définir une stratégie de recul qui permet ou arrête les tentatives continues de tirer du registre source si l’image échoue.
    • ImageTagMirrorSet (ITMS). Cet objet vous permet de tirer des images d’un registre en miroir en utilisant des balises d’image. L’ITMS CR vous permet de définir une stratégie de recul qui permet ou arrête les tentatives continues de tirer du registre source si l’image échoue.
    • ImageContentSourcePolicy (ICSP). Cet objet vous permet de tirer des images d’un registre en miroir en utilisant des spécifications de digestion. L’ICSP CR revient toujours au registre source si les miroirs ne fonctionnent pas.
    Important

    À l’aide d’un objet ImageContentSourcePolicy (ICSP) pour configurer la mise en miroir de référentiels est une fonctionnalité obsolète. La fonctionnalité obsolète est toujours incluse dans Red Hat OpenShift Service sur AWS et continue d’être prise en charge; cependant, il sera supprimé dans une future version de ce produit et n’est pas recommandé pour de nouveaux déploiements. Lorsque vous avez des fichiers YAML existants que vous avez utilisés pour créer des objets ImageContentSourcePolicy, vous pouvez utiliser la commande oc adm migration icsp pour convertir ces fichiers en un fichier ImageDigestMirrorSet YAML. Consultez la section « Convertir les fichiers ImageContentSourcePolicy (ICSP) pour la mise en miroir du référentiel de registre d’images » dans la section suivante.

Chacun de ces objets de ressource personnalisés identifie les informations suivantes:

  • La source du référentiel d’image de conteneur que vous souhaitez refléter.
  • Entrée séparée pour chaque référentiel miroir que vous souhaitez offrir le contenu demandé dans le référentiel source.

Dans le cas des nouveaux clusters, vous pouvez utiliser les objets IDMS, ITMS et ICSP CRs au besoin. Cependant, il est recommandé d’utiliser IDMS et ITMS.

Lorsque vous avez mis à niveau un cluster, tous les objets ICSP existants restent stables, et les objets IDMS et ICSP sont pris en charge. Les charges de travail utilisant des objets ICSP continuent de fonctionner comme prévu. Cependant, si vous voulez tirer parti des stratégies de repli introduites dans les CR IDMS, vous pouvez migrer les charges de travail actuelles vers des objets IDMS en utilisant la commande oc adm migration icsp comme indiqué dans la section Convertir ImageContentSourcePolicy (ICSP) pour la section de miroir de référentiel de registre d’images qui suit. La migration vers les objets IDMS ne nécessite pas de redémarrage de cluster.

Note

Lorsque votre cluster utilise un objet ImageDigestMirrorSet, ImageTagMirrorSet ou ImageContentSourcePolicy pour configurer la mise en miroir de référentiels, vous pouvez utiliser uniquement des secrets de traction globaux pour les registres miroirs. Il est impossible d’ajouter un secret d’attraction à un projet.

9.3.1. Configuration du référentiel de registre d’images
Copier lien

Il est possible de créer des ressources personnalisées de configuration de miroir de postinstallation (CR) pour rediriger les requêtes de tirage d’images d’un registre d’images source vers un registre d’images en miroir.

Conditions préalables

  • Accès au cluster en tant qu’utilisateur avec le rôle dédié-admin.

Procédure

  1. Configurez les référentiels miroirs, par l’un ou l’autre:

    • Configuration d’un référentiel miroir avec Red Hat Quay, comme décrit dans Red Hat Quay Repository Mirroring. En utilisant Red Hat Quay, vous pouvez copier des images d’un référentiel à un autre et synchroniser automatiquement ces référentiels à plusieurs reprises au fil du temps.

    • En utilisant un outil tel que skopeo pour copier des images manuellement à partir du référentiel source vers le référentiel miroir.

      Après avoir installé le package Skopeo RPM sur un système Red Hat Enterprise Linux (RHEL) 7 ou RHEL 8, utilisez la commande skopeo comme indiqué dans cet exemple: 

      $ skopeo copy --all \
docker://registry.access.redhat.com/ubi9/ubi-minimal:latest@sha256:5cf... \
docker://example.io/example/ubi-minimal
      Copy to Clipboard Toggle word wrap

      Dans cet exemple, vous avez un registre d’images de conteneur nommé example.io avec un référentiel d’images nommé exemple auquel vous souhaitez copier l’image ubi9/ubi-minimal de register.access.redhat.com. Après avoir créé le registre en miroir, vous pouvez configurer votre Red Hat OpenShift Service sur AWS cluster pour rediriger les requêtes du référentiel source vers le référentiel miroir.

  2. Créer une configuration miroir de postinstallation CR, en utilisant l’un des exemples suivants:

    • Créez un ImageDigestMirrorSet ou ImageTagMirrorSet CR, au besoin, en remplaçant la source et les miroirs par vos propres paires de registre et de référentiels et images: 

      apiVersion: config.openshift.io/v1
      1 
      
kind: ImageDigestMirrorSet
      2 
      
metadata:
  name: ubi9repo
spec:
  imageDigestMirrors:
      3 
      
  - mirrors:
    - example.io/example/ubi-minimal
      4 
      
    - example.com/example/ubi-minimal
      5 
      
    source: registry.access.redhat.com/ubi9/ubi-minimal
      6 
      
    mirrorSourcePolicy: AllowContactingSource
      7 
      
  - mirrors:
    - mirror.example.com/redhat
    source: registry.example.com/redhat
      8 
      
    mirrorSourcePolicy: AllowContactingSource
  - mirrors:
    - mirror.example.com
    source: registry.example.com
      9 
      
    mirrorSourcePolicy: AllowContactingSource
  - mirrors:
    - mirror.example.net/image
    source: registry.example.com/example/myimage
      10 
      
    mirrorSourcePolicy: AllowContactingSource
  - mirrors:
    - mirror.example.net
    source: registry.example.com/example
      11 
      
    mirrorSourcePolicy: AllowContactingSource
  - mirrors:
    - mirror.example.net/registry-example-com
    source: registry.example.com
      12 
      
    mirrorSourcePolicy: AllowContactingSource
      Copy to Clipboard Toggle word wrap
      1
      Indique l’API à utiliser avec ce CR. Cela doit être config.openshift.io/v1.
      2
      Indique le type d’objet selon le type de traction:
      • ImageDigestMirrorSet: Pulls une image de référence digeste.
      • ImageTagMirrorSet: Pulls une image de référence de balise.
      3
      Indique le type de méthode d’extraction d’image, soit:
      • imageDigestMirrors: Utilisez pour un ImageDigestMirrorSet CR.
      • imageTagMirrors: Utilisez pour un ImageTagMirrorSet CR.
      4
      Indique le nom du registre et du référentiel d’images en miroir.
      5
      Facultatif : Indique un référentiel miroir secondaire pour chaque référentiel cible. Lorsqu’un miroir est en panne, le référentiel cible peut utiliser le miroir secondaire.
      6
      Indique la source du registre et du référentiel, qui est le référentiel auquel il est fait référence dans une spécification de tirage d’image.
      7
      Facultatif: Indique la politique de repli si l’image tire échoue:
      • AllowContactingSource: Permet de poursuivre les tentatives de tirer l’image du référentiel source. C’est la valeur par défaut.
      • JamaisContactSource: empêche les tentatives continues de tirer l’image du référentiel source.
      8
      Facultatif: Indique un espace de noms à l’intérieur d’un registre, ce qui vous permet d’utiliser n’importe quelle image dans cet espace de noms. Lorsque vous utilisez un domaine de registre comme source, l’objet est appliqué à tous les référentiels du registre.
      9
      Facultatif: Indique un registre, qui vous permet d’utiliser n’importe quelle image dans ce registre. Lorsque vous spécifiez un nom de registre, l’objet est appliqué à tous les référentiels d’un registre source à un registre miroir.
      10
      Extrait de l’image Registry.example.com/example/myimage@sha256:…​à partir du miroir miroir.example.net/image@sha256:...
      11
      Extrait l’image Registry.example.com/example/image@sha256:…​​ dans l’espace de noms du registre source à partir du miroir mirror.example.net/image@sha256:…​​.
      12
      Extrait l’image Registry.example.com/myimage@sha256 de l’exemple de registre miroir example.net/registry-example-com/myimage@sha256:…​​.

    • Créez une ressource personnalisée ImageContentSourcePolicy, remplaçant la source et les miroirs par vos propres paires et images de registre et de référentiel: 

      apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: mirror-ocp
spec:
  repositoryDigestMirrors:
  - mirrors:
    - mirror.registry.com:443/ocp/release
      1 
      
    source: quay.io/openshift-release-dev/ocp-release
      2 
      
  - mirrors:
    - mirror.registry.com:443/ocp/release
    source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
      Copy to Clipboard Toggle word wrap
      1
      Indique le nom du registre et du référentiel d’images miroirs.
      2
      Indique le registre en ligne et le référentiel contenant le contenu qui est reflété.

  3. Créer le nouvel objet: 

    $ oc create -f registryrepomirror.yaml
    Copy to Clipboard Toggle word wrap

    Après la création de l’objet, l’opérateur de configuration de machine (MCO) draine uniquement les nœuds pour les objets ImageTagMirrorSet. L’AGC ne draine pas les nœuds pour les objets ImageDigestMirrorSet et ImageContentSourcePolicy.

  4. Afin de vérifier que les paramètres de configuration en miroir sont appliqués, faites ce qui suit sur l’un des nœuds.

    1. Liste de vos nœuds: 

      $ oc get node
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      NAME                           STATUS                     ROLES    AGE  VERSION
ip-10-0-137-44.ec2.internal    Ready                      worker   7m   v1.31.3
ip-10-0-138-148.ec2.internal   Ready                      master   11m  v1.31.3
ip-10-0-139-122.ec2.internal   Ready                      master   11m  v1.31.3
ip-10-0-147-35.ec2.internal    Ready                      worker   7m   v1.31.3
ip-10-0-153-12.ec2.internal    Ready                      worker   7m   v1.31.3
ip-10-0-154-10.ec2.internal    Ready                      master   11m  v1.31.3
      Copy to Clipboard Toggle word wrap

    2. Démarrez le processus de débogage pour accéder au nœud: 

      $ oc debug node/ip-10-0-147-35.ec2.internal
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      Starting pod/ip-10-0-147-35ec2internal-debug ...
To use host binaries, run `chroot /host`
      Copy to Clipboard Toggle word wrap

    3. Changez votre répertoire root en /host: 

      sh-4.2# chroot /host
      Copy to Clipboard Toggle word wrap

    4. Consultez le fichier /etc/containers/registries.conf pour vous assurer que les modifications ont été apportées: 

      sh-4.2# cat /etc/containers/registries.conf
      Copy to Clipboard Toggle word wrap

      La sortie suivante représente un fichier registries.conf où des CR de configuration miroir post-installation ont été appliqués. Les deux dernières entrées sont marquées seulement digest-seulement et tag-seulement respectivement.

      Exemple de sortie

      unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
short-name-mode = ""

[[registry]]
  prefix = ""
  location = "registry.access.redhat.com/ubi9/ubi-minimal"
      1 
      

  [[registry.mirror]]
    location = "example.io/example/ubi-minimal"
      2 
      
    pull-from-mirror = "digest-only"
      3 
      

  [[registry.mirror]]
    location = "example.com/example/ubi-minimal"
    pull-from-mirror = "digest-only"

[[registry]]
  prefix = ""
  location = "registry.example.com"

  [[registry.mirror]]
    location = "mirror.example.net/registry-example-com"
    pull-from-mirror = "digest-only"

[[registry]]
  prefix = ""
  location = "registry.example.com/example"

  [[registry.mirror]]
    location = "mirror.example.net"
    pull-from-mirror = "digest-only"

[[registry]]
  prefix = ""
  location = "registry.example.com/example/myimage"

  [[registry.mirror]]
    location = "mirror.example.net/image"
    pull-from-mirror = "digest-only"

[[registry]]
  prefix = ""
  location = "registry.example.com"

  [[registry.mirror]]
    location = "mirror.example.com"
    pull-from-mirror = "digest-only"

[[registry]]
  prefix = ""
  location = "registry.example.com/redhat"

  [[registry.mirror]]
    location = "mirror.example.com/redhat"
    pull-from-mirror = "digest-only"
[[registry]]
  prefix = ""
  location = "registry.access.redhat.com/ubi9/ubi-minimal"
  blocked = true
      4 
      

  [[registry.mirror]]
    location = "example.io/example/ubi-minimal-tag"
    pull-from-mirror = "tag-only"
      5
      Copy to Clipboard Toggle word wrap

      1
      Indique le référentiel auquel il est fait référence dans une spécification de traction.
      2
      Indique le miroir de ce référentiel.
      3
      Indique que l’image extraite du miroir est une image de référence digeste.
      4
      Indique que le paramètre NeverContactSource est défini pour ce référentiel.
      5
      Indique que l’image extraite du miroir est une image de référence de balise.

    5. Tirez une image sur le nœud de la source et vérifiez si elle est résolue par le miroir. 

      sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi9/ubi-minimal@sha256:5cf...
      Copy to Clipboard Toggle word wrap

Dépannage du référentiel miroir

Lorsque la procédure de mise en miroir du référentiel ne fonctionne pas comme décrit, utilisez les informations suivantes sur le fonctionnement du référentiel de miroir pour aider à résoudre le problème.

  • Le premier miroir de travail est utilisé pour fournir l’image tirée.
  • Le registre principal n’est utilisé que si aucun autre miroir ne fonctionne.
  • À partir du contexte système, les drapeaux Insecurity sont utilisés comme repli.
  • Le format du fichier /etc/containers/registries.conf a récemment changé. Il est maintenant version 2 et au format TOML.

À l’aide d’un objet ImageContentSourcePolicy (ICSP) pour configurer la mise en miroir de référentiels est une fonctionnalité obsolète. Cette fonctionnalité est toujours incluse dans Red Hat OpenShift Service sur AWS et continue d’être prise en charge; cependant, elle sera supprimée dans une future version de ce produit et n’est pas recommandée pour de nouveaux déploiements.

Les objets ICSP sont remplacés par des objets ImageDigestMirrorSet et ImageTagMirrorSet pour configurer la mise en miroir du référentiel. Lorsque vous avez des fichiers YAML existants que vous avez utilisés pour créer des objets ImageContentSourcePolicy, vous pouvez utiliser la commande oc adm migration icsp pour convertir ces fichiers en un fichier ImageDigestMirrorSet YAML. La commande met à jour l’API vers la version actuelle, modifie la valeur type à ImageDigestMirrorSet, et change spec.repositoryDigestMirrors en spec.imageDigestMirrors. Le reste du fichier n’est pas modifié.

Comme la migration ne modifie pas le fichier registries.conf, le cluster n’a pas besoin de redémarrer.

En savoir plus sur les objets ImageDigestMirrorSet ou ImageTagMirrorSet, voir "Configurer le référentiel de registre d’images" dans la section précédente.

Conditions préalables

  • Accès au cluster en tant qu’utilisateur avec le rôle dédié-admin.
  • Assurez-vous d’avoir des objets ImageContentSourcePolicy sur votre cluster.

Procédure

  1. Il suffit d’utiliser la commande suivante pour convertir un ou plusieurs fichiers ImageContentSourcePolicy YAML en fichier ImageDigestMirrorSet YAML: 

    $ oc adm migrate icsp <file_name>.yaml <file_name>.yaml <file_name>.yaml --dest-dir <path_to_the_directory>
    Copy to Clipboard Toggle word wrap

    là où:

    &lt;file_name&gt;
    Indique le nom de la source ImageContentSourcePolicy YAML. Il est possible de répertorier plusieurs noms de fichiers.
    --dest-dir
    Facultatif: Spécifie un répertoire pour la sortie ImageDigestMirrorSet YAML. En cas de désinitialisation, le fichier est écrit dans le répertoire courant.

    À titre d’exemple, la commande suivante convertit les fichiers icsp.yaml et icsp-2.yaml et enregistre les nouveaux fichiers YAML dans le répertoire idms-files. 

    $ oc adm migrate icsp icsp.yaml icsp-2.yaml --dest-dir idms-files
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    wrote ImageDigestMirrorSet to idms-files/imagedigestmirrorset_ubi8repo.5911620242173376087.yaml
wrote ImageDigestMirrorSet to idms-files/imagedigestmirrorset_ubi9repo.6456931852378115011.yaml
    Copy to Clipboard Toggle word wrap

  2. Créez l’objet CR en exécutant la commande suivante: 

    $ oc create -f <path_to_the_directory>/<file-name>.yaml
    Copy to Clipboard Toggle word wrap

    là où:

    &lt;path_to_the_directory&gt;
    Indique le chemin vers le répertoire, si vous avez utilisé le drapeau --dest-dir.
    &lt;file_name&gt;
    Indique le nom de l’ImageDigestMirrorSet YAML.
  3. Enlevez les objets ICSP après le déploiement des objets IDMS.
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat