Rechercher
SupportConsoleDéveloppeursCommencer un essaiContact

10.4. Configuration de l'image

download PDF

Comprendre et configurer les paramètres du registre des images.

10.4.1. Paramètres de configuration du contrôleur d'images

La ressource image.config.openshift.io/cluster contient des informations à l'échelle du cluster sur la manière de gérer les images. Le nom canonique, et le seul valide, est cluster. La ressource spec offre les paramètres de configuration suivants.

Note

Les paramètres tels que DisableScheduledImport, MaxImagesBulkImportedPerRepository, MaxScheduledImportsPerMinute, ScheduledImageImportMinimumIntervalSeconds, InternalRegistryHostname ne sont pas configurables.

ParamètresDescription

allowedRegistriesForImport

Limite les registres d'images de conteneurs à partir desquels les utilisateurs normaux peuvent importer des images. Définissez cette liste en fonction des registres dont vous pensez qu'ils contiennent des images valides et à partir desquels vous souhaitez que les applications puissent importer des images. Les utilisateurs autorisés à créer des images ou ImageStreamMappings à partir de l'API ne sont pas concernés par cette politique. En général, seuls les administrateurs de clusters disposent des autorisations appropriées.

Chaque élément de cette liste contient un emplacement du registre spécifié par le nom de domaine du registre.

domainName: Spécifie un nom de domaine pour le registre. Si le registre utilise un port non standard 80 ou 443, le port doit également être inclus dans le nom de domaine.

insecure: Insécurisé indique si le registre est sécurisé ou non. Par défaut, si rien d'autre n'est spécifié, le registre est supposé être sécurisé.

additionalTrustedCA

Une référence à une carte de configuration contenant des autorités de certification supplémentaires qui doivent être approuvées pendant image stream import, pod image pull, openshift-image-registry pullthrough, et les constructions.

L'espace de noms de cette carte de configuration est openshift-config. Le format de la carte de configuration consiste à utiliser le nom d'hôte du registre comme clé et le certificat encodé PEM comme valeur, pour chaque autorité de certification de registre supplémentaire à laquelle il faut faire confiance.

externalRegistryHostnames

Fournit les noms d'hôtes pour le registre d'images externe par défaut. Le nom d'hôte externe ne doit être défini que lorsque le registre d'images est exposé à l'extérieur. La première valeur est utilisée dans le champ publicDockerImageRepository des flux d'images. La valeur doit être au format hostname[:port].

registrySources

Contient la configuration qui détermine comment le runtime du conteneur doit traiter les registres individuels lors de l'accès aux images pour les builds et les pods. Par exemple, l'autorisation ou non d'un accès non sécurisé. Il ne contient pas de configuration pour le registre interne du cluster.

insecureRegistries: Les registres qui n'ont pas de certificat TLS valide ou qui ne prennent en charge que les connexions HTTP. Pour spécifier tous les sous-domaines, ajoutez le caractère générique astérisque (*) comme préfixe au nom de domaine. Par exemple, *.example.com. Vous pouvez spécifier un dépôt individuel au sein d'un registre. Par exemple : reg1.io/myrepo/myapp:latest.

blockedRegistries: Registres pour lesquels les actions d'extraction et de poussée d'images sont refusées. Pour spécifier tous les sous-domaines, ajoutez le caractère générique astérisque (*) comme préfixe au nom de domaine. Par exemple, *.example.com. Vous pouvez spécifier un dépôt individuel au sein d'un registre. Par exemple : reg1.io/myrepo/myapp:latest. Tous les autres registres sont autorisés.

allowedRegistries: Registres pour lesquels les actions d'extraction et de poussée d'images sont autorisées. Pour spécifier tous les sous-domaines, ajoutez le caractère générique astérisque (*) comme préfixe au nom de domaine. Par exemple, *.example.com. Vous pouvez spécifier un dépôt individuel au sein d'un registre. Par exemple : reg1.io/myrepo/myapp:latest. Tous les autres registres sont bloqués.

containerRuntimeSearchRegistries: Registres pour lesquels les actions de traction et de poussée d'images sont autorisées à l'aide de noms courts d'images. Tous les autres registres sont bloqués.

Il est possible de définir soit blockedRegistries, soit allowedRegistries, mais pas les deux.

Avertissement

Lorsque le paramètre allowedRegistries est défini, tous les registres, y compris les registres registry.redhat.io et quay.io et le registre d'image OpenShift par défaut, sont bloqués sauf s'ils sont explicitement listés. Lors de l'utilisation du paramètre, pour éviter un échec du pod, ajoutez tous les registres, y compris les registres registry.redhat.io et quay.io et la liste internalRegistryHostname à allowedRegistries, car ils sont requis par les images de charge utile dans votre environnement. Pour les clusters déconnectés, les registres miroirs doivent également être ajoutés.

Le champ status de la ressource image.config.openshift.io/cluster contient les valeurs observées de la grappe.

ParamètresDescription

internalRegistryHostname

Défini par l'opérateur de registre d'images, qui contrôle le registre d'images internalRegistryHostname. Il définit le nom d'hôte pour le registre d'images par défaut d'OpenShift. La valeur doit être au format hostname[:port]. Pour une compatibilité ascendante, vous pouvez toujours utiliser la variable d'environnement OPENSHIFT_DEFAULT_REGISTRY, mais ce paramètre remplace la variable d'environnement.

externalRegistryHostnames

Défini par l'opérateur du registre d'images, il fournit les noms d'hôtes externes pour le registre d'images lorsqu'il est exposé à l'extérieur. La première valeur est utilisée dans le champ publicDockerImageRepository des flux d'images. Les valeurs doivent être au format hostname[:port].

10.4.2. Configuration des paramètres du registre des images

Vous pouvez configurer les paramètres du registre d'images en modifiant la ressource personnalisée (CR) image.config.openshift.io/cluster. Lorsque les modifications apportées au registre sont appliquées à la CR image.config.openshift.io/cluster, l'opérateur de configuration de la machine (MCO) effectue les actions séquentielles suivantes :

  1. Cordons du nœud
  2. Applique les modifications en redémarrant CRI-O

  3. Uncordons le nœud

    Note

    Le MCO ne redémarre pas les nœuds lorsqu'il détecte des changements.

Procédure

  1. Modifiez la ressource personnalisée image.config.openshift.io/cluster: 

    $ oc edit image.config.openshift.io/cluster

    Voici un exemple de image.config.openshift.io/cluster CR : 

    apiVersion: config.openshift.io/v1
kind: Image 1
metadata:
  annotations:
    release.openshift.io/create-only: "true"
  creationTimestamp: "2019-05-17T13:44:26Z"
  generation: 1
  name: cluster
  resourceVersion: "8302"
  selfLink: /apis/config.openshift.io/v1/images/cluster
  uid: e34555da-78a9-11e9-b92b-06d6c7da38dc
spec:
  allowedRegistriesForImport: 2
    - domainName: quay.io
      insecure: false
  additionalTrustedCA: 3
    name: myconfigmap
  registrySources: 4
    allowedRegistries:
    - example.com
    - quay.io
    - registry.redhat.io
    - image-registry.openshift-image-registry.svc:5000
    - reg1.io/myrepo/myapp:latest
    insecureRegistries:
    - insecure.com
status:
  internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
    1
    Image: Contient des informations à l'échelle du cluster sur la manière de gérer les images. Le nom canonique, et le seul valide, est cluster.
    2
    allowedRegistriesForImport: Limite les registres d'images de conteneurs à partir desquels les utilisateurs normaux peuvent importer des images. Définissez cette liste en fonction des registres dont vous pensez qu'ils contiennent des images valides et à partir desquels vous souhaitez que les applications puissent importer des images. Les utilisateurs autorisés à créer des images ou ImageStreamMappings à partir de l'API ne sont pas concernés par cette politique. En général, seuls les administrateurs de clusters disposent des autorisations appropriées.
    3
    additionalTrustedCA: Une référence à une carte de configuration contenant des autorités de certification (AC) supplémentaires qui sont approuvées lors de l'importation de flux d'images, de l'extraction d'images de pods, de l'extraction de openshift-image-registry et des constructions. L'espace de noms pour cette carte de configuration est openshift-config. Le format de la carte de configuration consiste à utiliser le nom d'hôte du registre comme clé et le certificat PEM comme valeur, pour chaque autorité de certification de registre supplémentaire à laquelle il faut faire confiance.
    4
    registrySources: Contient la configuration qui détermine si le runtime du conteneur autorise ou bloque les registres individuels lors de l'accès aux images pour les builds et les pods. Le paramètre allowedRegistries ou le paramètre blockedRegistries peut être défini, mais pas les deux. Vous pouvez également définir s'il faut ou non autoriser l'accès aux registres non sécurisés ou aux registres qui autorisent les registres utilisant des noms courts d'images. Cet exemple utilise le paramètre allowedRegistries, qui définit les registres dont l'utilisation est autorisée. Le registre non sécurisé insecure.com est également autorisé. Le paramètre registrySources ne contient pas de configuration pour le registre interne du cluster.
    Note

    Lorsque le paramètre allowedRegistries est défini, tous les registres, y compris les registres registry.redhat.io et quay.io et le registre d'image OpenShift par défaut, sont bloqués sauf s'ils sont explicitement répertoriés. Si vous utilisez ce paramètre, pour éviter une défaillance du pod, vous devez ajouter les registres registry.redhat.io et quay.io et la liste internalRegistryHostname à allowedRegistries, car ils sont requis par les images de charge utile dans votre environnement. N'ajoutez pas les registres registry.redhat.io et quay.io à la liste blockedRegistries.

    En utilisant les paramètres allowedRegistries, blockedRegistries ou insecureRegistries, vous pouvez spécifier un référentiel individuel au sein d'un registre. Par exemple : reg1.io/myrepo/myapp:latest.

    Les registres externes non sécurisés doivent être évités afin de réduire les risques éventuels pour la sécurité.

  2. Pour vérifier que les modifications ont été appliquées, dressez la liste de vos nœuds : 

    $ oc get nodes

    Exemple de sortie

    NAME                                         STATUS                     ROLES                  AGE   VERSION
ip-10-0-137-182.us-east-2.compute.internal   Ready,SchedulingDisabled   worker                 65m   v1.25.4+77bec7a
ip-10-0-139-120.us-east-2.compute.internal   Ready,SchedulingDisabled   control-plane          74m   v1.25.4+77bec7a
ip-10-0-176-102.us-east-2.compute.internal   Ready                      control-plane          75m   v1.25.4+77bec7a
ip-10-0-188-96.us-east-2.compute.internal    Ready                      worker                 65m   v1.25.4+77bec7a
ip-10-0-200-59.us-east-2.compute.internal    Ready                      worker                 63m   v1.25.4+77bec7a
ip-10-0-223-123.us-east-2.compute.internal   Ready                      control-plane          73m   v1.25.4+77bec7a

Pour plus d'informations sur les paramètres de registre autorisés, bloqués et non sécurisés, voir Configuration des paramètres du registre des images.

10.4.2.1. Configuration de magasins de confiance supplémentaires pour l'accès au registre d'images

La ressource personnalisée image.config.openshift.io/cluster peut contenir une référence à une carte de configuration qui contient des autorités de certification supplémentaires à approuver lors de l'accès au registre d'images.

Conditions préalables

  • Les autorités de certification (CA) doivent être codées en PEM.

Procédure

Vous pouvez créer une carte de configuration dans l'espace de noms openshift-config et utiliser son nom dans AdditionalTrustedCA dans la ressource personnalisée image.config.openshift.io pour fournir des autorités de certification supplémentaires qui doivent être approuvées lorsqu'elles contactent des registres externes.

La clé de configuration est le nom d'hôte d'un registre avec le port pour lequel cette autorité de certification doit être approuvée, et le contenu du certificat PEM est la valeur, pour chaque autorité de certification de registre supplémentaire à approuver.

Registre d'images Exemple de carte de configuration de l'autorité de certification

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-registry-ca
data:
  registry.example.com: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  registry-with-port.example.com..5000: | 1
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

1
Si le registre comporte le port, tel que registry-with-port.example.com:5000, : doit être remplacé par ...

Vous pouvez configurer des autorités de certification supplémentaires en suivant la procédure suivante.

  1. Pour configurer une autorité de certification supplémentaire : 

    $ oc create configmap registry-config --from-file=<external_registry_address>=ca.crt -n openshift-config
    $ oc edit image.config.openshift.io cluster
    spec:
  additionalTrustedCA:
    name: registry-config

10.4.2.2. Configuration de la mise en miroir du référentiel du registre d'images

La configuration de la mise en miroir du référentiel du registre des conteneurs vous permet d'effectuer les opérations suivantes :

  • Configurez votre cluster OpenShift Container Platform pour rediriger les demandes d'extraction d'images à partir d'un dépôt sur un registre d'images source et les faire résoudre par un dépôt sur un registre d'images miroir.
  • Identifier plusieurs référentiels miroirs pour chaque référentiel cible, afin de s'assurer que si un miroir est en panne, un autre peut être utilisé.

Les attributs de la mise en miroir de référentiel dans OpenShift Container Platform sont les suivants :

  • Les extractions d'images résistent aux interruptions du registre.
  • Les clusters situés dans des environnements déconnectés peuvent extraire des images de sites critiques, tels que quay.io, et demander aux registres situés derrière le pare-feu de l'entreprise de fournir les images demandées.
  • Un ordre particulier de registres est essayé lorsqu'une demande d'extraction d'image est faite, le registre permanent étant généralement le dernier essayé.
  • Les informations sur le miroir que vous saisissez sont ajoutées au fichier /etc/containers/registries.conf sur chaque nœud du cluster OpenShift Container Platform.
  • Lorsqu'un nœud demande une image à partir du référentiel source, il essaie chaque référentiel miroir à tour de rôle jusqu'à ce qu'il trouve le contenu demandé. Si tous les miroirs échouent, le cluster essaie le référentiel source. En cas de succès, l'image est transférée au nœud.

La configuration de la mise en miroir du référentiel peut se faire de la manière suivante :

  • A l'installation d'OpenShift Container Platform :

    En extrayant les images de conteneurs nécessaires à OpenShift Container Platform, puis en amenant ces images derrière le pare-feu de votre entreprise, vous pouvez installer OpenShift Container Platform dans un centre de données qui se trouve dans un environnement déconnecté.

  • Après l'installation d'OpenShift Container Platform :

    Même si vous ne configurez pas la mise en miroir lors de l'installation d'OpenShift Container Platform, vous pouvez le faire plus tard en utilisant l'objet ImageContentSourcePolicy.

La procédure suivante fournit une configuration miroir post-installation, dans laquelle vous créez un objet ImageContentSourcePolicy qui identifie :

  • La source du référentiel d'images de conteneurs que vous souhaitez mettre en miroir.
  • Une entrée distincte pour chaque référentiel miroir dans lequel vous souhaitez proposer le contenu demandé au référentiel source.
Note

Vous ne pouvez configurer des secrets de tirage globaux que pour les clusters qui ont un objet ImageContentSourcePolicy. Vous ne pouvez pas ajouter un secret d'extraction à un projet.

Conditions préalables

  • Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

  1. Configurer les référentiels miroirs, en utilisant l'un ou l'autre :

    • La configuration d'un référentiel miroir avec Red Hat Quay, comme décrit dans Red Hat Quay Repository Mirroring. L'utilisation de Red Hat Quay vous permet de copier des images d'un référentiel vers un autre et de synchroniser automatiquement ces référentiels de manière répétée au fil du temps.

    • Utilisation d'un outil tel que skopeo pour copier manuellement les images du répertoire source vers le référentiel miroir.

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

      $ skopeo copy \
docker://registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6 \
docker://example.io/example/ubi-minimal

      Dans cet exemple, vous avez un registre d'images de conteneurs nommé example.io avec un dépôt d'images nommé example dans lequel vous voulez copier l'image ubi8/ubi-minimal à partir de registry.access.redhat.com. Après avoir créé le registre, vous pouvez configurer votre cluster OpenShift Container Platform pour rediriger les requêtes faites sur le dépôt source vers le dépôt miroir.

  2. Connectez-vous à votre cluster OpenShift Container Platform.

  3. Créez un fichier ImageContentSourcePolicy (par exemple, registryrepomirror.yaml), en remplaçant la source et les miroirs par vos propres paires et images de registres et de référentiels : 

    apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: ubi8repo
spec:
  repositoryDigestMirrors:
  - mirrors:
    - example.io/example/ubi-minimal 1
    - example.com/example/ubi-minimal 2
    source: registry.access.redhat.com/ubi8/ubi-minimal 3
  - mirrors:
    - mirror.example.com/redhat
    source: registry.redhat.io/openshift4 4
  - mirrors:
    - mirror.example.com
    source: registry.redhat.io 5
  - mirrors:
    - mirror.example.net/image
    source: registry.example.com/example/myimage 6
  - mirrors:
    - mirror.example.net
    source: registry.example.com/example 7
  - mirrors:
    - mirror.example.net/registry-example-com
    source: registry.example.com 8
    1
    Indique le nom du registre d'images et du référentiel.
    2
    Indique plusieurs référentiels miroirs pour chaque référentiel cible. Si un miroir est hors service, le référentiel cible peut utiliser un autre miroir.
    3
    Indique le registre et le référentiel contenant le contenu qui est mis en miroir.
    4
    Vous pouvez configurer un espace de noms à l'intérieur d'un registre pour utiliser n'importe quelle image dans cet espace de noms. Si vous utilisez un domaine de registre comme source, la ressource ImageContentSourcePolicy est appliquée à tous les référentiels du registre.
    5
    Si vous configurez le nom du registre, la ressource ImageContentSourcePolicy est appliquée à tous les référentiels, du registre source au registre miroir.
    6
    Tire l'image mirror.example.net/image@sha256:…​.
    7
    Extrait l'image myimage dans l'espace de noms du registre source à partir du miroir mirror.example.net/myimage@sha256:…​.
    8
    Extrait l'image registry.example.com/example/myimage du registre miroir mirror.example.net/registry-example-com/example/myimage@sha256:…​. La ressource ImageContentSourcePolicy est appliquée à tous les référentiels d'un registre source à un registre miroir mirror.example.net/registry-example-com.

  4. Créer le nouvel objet ImageContentSourcePolicy: 

    $ oc create -f registryrepomirror.yaml

    Une fois l'objet ImageContentSourcePolicy créé, les nouveaux paramètres sont déployés sur chaque nœud et le cluster commence à utiliser le référentiel miroir pour les requêtes vers le référentiel source.

  5. Pour vérifier que les paramètres de configuration en miroir sont appliqués, procédez comme suit sur l'un des nœuds.

    1. Dressez la liste de vos nœuds : 

      $ oc get node

      Exemple de sortie

      NAME                           STATUS                     ROLES    AGE  VERSION
ip-10-0-137-44.ec2.internal    Ready                      worker   7m   v1.25.0
ip-10-0-138-148.ec2.internal   Ready                      master   11m  v1.25.0
ip-10-0-139-122.ec2.internal   Ready                      master   11m  v1.25.0
ip-10-0-147-35.ec2.internal    Ready                      worker   7m   v1.25.0
ip-10-0-153-12.ec2.internal    Ready                      worker   7m   v1.25.0
ip-10-0-154-10.ec2.internal    Ready                      master   11m  v1.25.0

      La ressource Imagecontentsourcepolicy ne redémarre pas les nœuds.

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

      $ oc debug node/ip-10-0-147-35.ec2.internal

      Exemple de sortie

      Starting pod/ip-10-0-147-35ec2internal-debug ...
To use host binaries, run `chroot /host`

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

      sh-4.2# chroot /host

    4. Vérifiez le fichier /etc/containers/registries.conf pour vous assurer que les changements ont bien été effectués : 

      sh-4.2# cat /etc/containers/registries.conf

      Exemple de sortie

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

[[registry]]
  prefix = ""
  location = "registry.access.redhat.com/ubi8/ubi-minimal"
  mirror-by-digest-only = true

  [[registry.mirror]]
    location = "example.io/example/ubi-minimal"

  [[registry.mirror]]
    location = "example.com/example/ubi-minimal"

[[registry]]
  prefix = ""
  location = "registry.example.com"
  mirror-by-digest-only = true

  [[registry.mirror]]
    location = "mirror.example.net/registry-example-com"

[[registry]]
  prefix = ""
  location = "registry.example.com/example"
  mirror-by-digest-only = true

  [[registry.mirror]]
    location = "mirror.example.net"

[[registry]]
  prefix = ""
  location = "registry.example.com/example/myimage"
  mirror-by-digest-only = true

  [[registry.mirror]]
    location = "mirror.example.net/image"

[[registry]]
  prefix = ""
  location = "registry.redhat.io"
  mirror-by-digest-only = true

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

[[registry]]
  prefix = ""
  location = "registry.redhat.io/openshift4"
  mirror-by-digest-only = true

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

    5. Transmet un condensé d'image au nœud à partir de la source et vérifie s'il est résolu par le miroir. Les objets ImageContentSourcePolicy ne prennent en charge que les condensés d'image, et non les balises d'image. 

      sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6

Dépannage de la mise en miroir du référentiel

Si la procédure de mise en miroir du référentiel ne fonctionne pas comme décrit, utilisez les informations suivantes sur le fonctionnement de la mise en miroir du référentiel pour 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.
  • Dans le contexte du système, les drapeaux Insecure sont utilisés comme solution de repli.
  • Le format du fichier /etc/containers/registries.conf a récemment changé. Il s'agit désormais de la version 2 et du format TOML.
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.

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 leBlog 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.

© 2024 Red Hat, Inc.