Images

L’opérateur d’échantillons de cluster est bootstrapped tel que géré par défaut ou si le proxy global est configuré. Dans l’état géré, l’opérateur d’échantillons de cluster gère activement ses ressources et maintient le composant actif afin de tirer des échantillons de flux d’images et d’images du registre et de s’assurer que les modèles d’échantillons requis sont installés.

Certaines circonstances entraînent le démarrage de l’opérateur d’échantillons de cluster lui-même tel qu’il a été supprimé, y compris:

Cependant, si l’opérateur d’échantillons de cluster détecte qu’il est sur un réseau IPv6 et qu’un Red Hat OpenShift Service sur le proxy global AWS est configuré, alors la vérification IPv6 remplace toutes les vérifications. En conséquence, le Cluster Samples Operator bootstraps lui-même comme supprimé.

Après la création ou la mise à jour d’un flux d’images d’échantillons, l’opérateur d’échantillons de cluster surveille l’avancement de l’importation d’image de chaque balise de flux d’images.

En cas d’échec d’une importation, l’opérateur d’échantillons de cluster réactive l’importation à travers l’API d’importation d’images du flux d’images, qui est la même API utilisée par la commande oc import-image, environ toutes les 15 minutes jusqu’à ce qu’elle voit l’importation réussir, ou si la configuration de l’opérateur d’échantillons de cluster est modifiée de telle sorte que le flux d’images soit ajouté à la liste des flux d’images

Ressources supplémentaires

Avant de créer le registre miroir, vous devez préparer l’hôte miroir.

Il est possible d’installer OpenShift CLI (oc) pour interagir avec ROSA à partir d’une interface de ligne de commande. Il est possible d’installer oc sous Linux, Windows ou macOS.

Installation du CLI OpenShift sur Linux

En utilisant la procédure suivante, vous pouvez installer le binaire OpenShift CLI (oc) sur Linux.

Installation du CLI OpenShift sur Windows

En utilisant la procédure suivante, vous pouvez installer le binaire OpenShift CLI (oc) sur Windows.

Installation de l’OpenShift CLI sur macOS

En utilisant la procédure suivante, vous pouvez installer le binaire OpenShift CLI (oc) sur macOS.

Lors de l’installation, Red Hat OpenShift Service sur AWS crée une carte de configuration nommée imagestreamtag-to-image dans l’espace de noms openshift-cluster-samples-operator. La carte de configuration imagestreamtag-to-image contient une entrée, l’image populante, pour chaque balise de flux d’image.

Le format de la clé pour chaque entrée dans le champ de données de la carte de configuration est <image_stream_name>_<image_stream_tag_name>.

Lors d’une installation déconnectée de Red Hat OpenShift Service sur AWS, l’état de l’opérateur d’échantillons de cluster est réglé sur Supprimer. Lorsque vous choisissez de le changer pour Géré, il installe des échantillons.

Cette carte de configuration peut être utilisée comme référence pour laquelle les images doivent être reflétées pour que vos flux d’images puissent être importés.

Consultez Utiliser les flux d’images de l’opérateur avec des registres alternatifs ou en miroir pour une procédure détaillée.

Les directives suivantes s’appliquent lors de la création d’une image de conteneur en général et sont indépendantes de l’utilisation ou non des images sur Red Hat OpenShift Service sur AWS.

La réutilisation des images

Dans la mesure du possible, basez votre image sur une image en amont appropriée à l’aide de l’instruction FROM. Cela garantit que votre image peut facilement récupérer des correctifs de sécurité à partir d’une image en amont lorsqu’elle est mise à jour, plutôt que de devoir mettre à jour vos dépendances directement.

De plus, utilisez des balises dans l’instruction FROM, par exemple rhel:rhel7, pour indiquer clairement aux utilisateurs la version d’une image sur laquelle votre image est basée. En utilisant une balise autre que la dernière, vous assurez que votre image n’est pas soumise à des changements qui pourraient entrer dans la dernière version d’une image en amont.

Conserver la compatibilité dans les balises

Lors du marquage de vos propres images, essayez de maintenir la compatibilité rétrograde dans une balise. Ainsi, si vous fournissez une image nommée image et qu’elle inclut actuellement la version 1.0, vous pouvez fournir une balise d’image:v1. Lorsque vous mettez à jour l’image, tant qu’elle continue d’être compatible avec l’image originale, vous pouvez continuer à marquer la nouvelle image:v1, et les consommateurs en aval de cette balise sont en mesure d’obtenir des mises à jour sans être cassés.

Lorsque vous publiez ultérieurement une mise à jour incompatible, puis passez à une nouvelle balise, par exemple image:v2. Cela permet aux consommateurs en aval de passer à la nouvelle version à volonté, mais ne sont pas brisés par inadvertance par la nouvelle image incompatible. Le consommateur en aval utilisant image:la plus longue prend le risque d’introduire des modifications incompatibles.

Évitez les processus multiples

Il ne faut pas démarrer plusieurs services, tels qu’une base de données et un SSHD, à l’intérieur d’un seul conteneur. Ce n’est pas nécessaire car les conteneurs sont légers et peuvent être facilement liés entre eux pour l’orchestration de multiples processus. Le service OpenShift Red Hat sur AWS vous permet de colocaliser et de co-gérer facilement les images associées en les regroupant en un seul pod.

Cette colocation assure que les conteneurs partagent un espace de noms réseau et un stockage pour la communication. Les mises à jour sont également moins perturbatrices car chaque image peut être mise à jour moins fréquemment et indépendamment. Les flux de gestion du signal sont également plus clairs avec un seul processus car vous n’avez pas à gérer les signaux de routage vers les processus engendrés.

Exec dans les scripts d’emballage

De nombreuses images utilisent des scripts d’emballage pour faire une certaine configuration avant de commencer un processus pour le logiciel en cours d’exécution. Lorsque votre image utilise un tel script, ce script utilise exec afin que le processus du script soit remplacé par votre logiciel. Lorsque vous n’utilisez pas exec, les signaux envoyés par votre conteneur vont dans votre script d’emballage au lieu du processus de votre logiciel. Ce n’est pas ce que vous voulez.

Lorsque vous avez un script d’emballage qui démarre un processus pour un serveur. Démarrez votre conteneur, par exemple, en utilisant podman run -i, qui exécute le script d’emballage, qui démarre à son tour votre processus. Lorsque vous souhaitez fermer votre conteneur avec CTRL+C. Lorsque votre script d’emballage utilisé exec pour démarrer le processus serveur, podman envoie SIGINT au processus serveur, et tout fonctionne comme vous l’attendez. Lorsque vous n’avez pas utilisé Exec dans votre script d’emballage, podman envoie SIGINT au processus pour le script d’emballage et votre processus continue de fonctionner comme si rien ne s’était passé.

Il est également à noter que votre processus s’exécute en tant que PID 1 lorsqu’il s’exécute dans un conteneur. Cela signifie que si votre processus principal se termine, l’ensemble du conteneur est arrêté, annulant tous les processus enfants que vous avez lancés à partir de votre processus PID 1.

Nettoyer les fichiers temporaires

Enlevez tous les fichiers temporaires que vous créez pendant le processus de construction. Cela inclut également tous les fichiers ajoutés avec la commande ADD. À titre d’exemple, exécutez la commande yum clean après avoir effectué des opérations d’installation yum.

Il est possible d’empêcher le cache yum de se retrouver dans une couche d’image en créant votre instruction RUN comme suit:

RUN yum -y install mypackage && yum -y install myotherpackage && yum clean all -y

RUN yum -y install mypackage && yum -y install myotherpackage && yum clean all -y

A noter que si vous écrivez plutôt:

RUN yum -y install mypackage
RUN yum -y install myotherpackage && yum clean all -y

RUN yum -y install mypackage
RUN yum -y install myotherpackage && yum clean all -y

Ensuite, la première invocation yum laisse des fichiers supplémentaires dans cette couche, et ces fichiers ne peuvent pas être supprimés lorsque l’opération de nettoyage yum est exécutée plus tard. Les fichiers supplémentaires ne sont pas visibles dans l’image finale, mais ils sont présents dans les couches sous-jacentes.

Le processus de construction du conteneur actuel ne permet pas qu’une commande s’exécute dans une couche ultérieure pour réduire l’espace utilisé par l’image lorsque quelque chose a été supprimé dans une couche antérieure. Cependant, cela pourrait changer à l’avenir. Cela signifie que si vous exécutez une commande rm dans une couche ultérieure, bien que les fichiers soient cachés, cela ne réduit pas la taille globale de l’image à télécharger. Donc, comme avec l’exemple yum clean, il est préférable de supprimer des fichiers dans la même commande qui les a créés, lorsque cela est possible, afin qu’ils ne finissent pas par écrire sur un calque.

De plus, l’exécution de commandes multiples dans une seule instruction RUN réduit le nombre de couches de votre image, ce qui améliore le temps de téléchargement et d’extraction.

Placer les instructions dans l’ordre approprié

Le constructeur de conteneurs lit le Dockerfile et exécute les instructions de haut en bas. Chaque instruction exécutée avec succès crée un calque qui peut être réutilisé la prochaine fois que cette ou une autre image est construite. Il est très important de placer des instructions qui changent rarement en haut de votre Dockerfile. Cela garantit que les prochaines versions de la même image sont très rapides car le cache n’est pas invalidé par des changements de couche supérieure.

À titre d’exemple, si vous travaillez sur un Dockerfile contenant une commande ADD pour installer un fichier sur lequel vous itérez, et une commande RUN pour yum installer un paquet, il est préférable de mettre la commande ADD en dernier:

FROM foo
RUN yum -y install mypackage && yum clean all -y
ADD myfile /test/myfile

FROM foo
RUN yum -y install mypackage && yum clean all -y
ADD myfile /test/myfile

De cette façon, chaque fois que vous modifiez myfile et redémarrez podman build ou docker build, le système réutilise le calque mis en cache pour la commande yum et génère uniquement le nouveau calque pour l’opération ADD.

Au lieu de cela, vous avez écrit le Dockerfile comme suit:

FROM foo
ADD myfile /test/myfile
RUN yum -y install mypackage && yum clean all -y

FROM foo
ADD myfile /test/myfile
RUN yum -y install mypackage && yum clean all -y

Ensuite, chaque fois que vous avez changé myfile et reran podman build ou docker build, l’opération ADD invaliderait le cache de couche RUN, de sorte que l’opération yum doit également être redémarrée.

Marquer les ports importants

L’instruction EXPOSE met un port dans le conteneur à la disposition du système hôte et d’autres conteneurs. Bien qu’il soit possible de spécifier qu’un port doit être exposé avec une invocation podman run, l’utilisation de l’instruction EXPOSE dans un Dockerfile facilite l’utilisation de votre image pour les humains et les logiciels en déclarant explicitement les ports que votre logiciel doit exécuter:

Définir les variables d’environnement

C’est une bonne pratique de définir des variables d’environnement avec l’instruction ENV. Il s’agit par exemple de définir la version de votre projet. Cela permet aux gens de trouver facilement la version sans regarder le Dockerfile. Autre exemple, la publicité d’un chemin sur le système qui pourrait être utilisé par un autre processus, tel que JAVA_HOME.

Évitez les mots de passe par défaut

Évitez de définir les mots de passe par défaut. Beaucoup de gens étendent l’image et oublient de supprimer ou de modifier le mot de passe par défaut. Cela peut entraîner des problèmes de sécurité si un utilisateur en production se voit attribuer un mot de passe bien connu. Les mots de passe sont paramétrables à l’aide d’une variable d’environnement à la place.

Lorsque vous choisissez de définir un mot de passe par défaut, assurez-vous qu’un message d’avertissement approprié est affiché lors du démarrage du conteneur. Le message doit informer l’utilisateur de la valeur du mot de passe par défaut et expliquer comment le modifier, comme quelle variable d’environnement à définir.

Évitez le sshd

Il est préférable d’éviter de courir sshd dans votre image. La commande podman exec ou docker exec permet d’accéder aux conteneurs qui s’exécutent sur l’hôte local. Alternativement, vous pouvez utiliser la commande oc exec ou la commande oc rsh pour accéder aux conteneurs qui s’exécutent sur le service OpenShift Red Hat sur le cluster AWS. L’installation et l’exécution de sshd dans votre image ouvrent des vecteurs supplémentaires pour les attaques et les exigences pour le correctif de sécurité.

Les volumes utilisés pour les données persistantes

Les images utilisent un volume pour les données persistantes. De cette façon, Red Hat OpenShift Service sur AWS monte le stockage réseau sur le nœud exécutant le conteneur, et si le conteneur se déplace vers un nouveau nœud, le stockage est réattaché à ce nœud. En utilisant le volume pour tous les besoins de stockage persistants, le contenu est conservé même si le conteneur est redémarré ou déplacé. Lorsque votre image écrit des données à des endroits arbitraires dans le conteneur, ce contenu n’a pas pu être préservé.

Les données qui doivent être conservées même après la destruction du conteneur doivent être écrites sur un volume. Les moteurs de conteneurs prennent en charge un drapeau en lecture seule pour les conteneurs, qui peut être utilisé pour appliquer strictement les bonnes pratiques en matière de ne pas écrire de données pour le stockage éphémère dans un conteneur. Concevoir votre image autour de cette capacité rend maintenant plus facile d’en profiter plus tard.

Définir explicitement les volumes dans votre Dockerfile permet aux consommateurs de l’image de comprendre facilement quels volumes ils doivent définir lors de l’exécution de votre image.

Consultez la documentation Kubernetes pour plus d’informations sur la façon dont les volumes sont utilisés dans Red Hat OpenShift Service sur AWS.

Les lignes directrices suivantes s’appliquent lors de la création d’images de conteneurs spécifiquement destinées à être utilisées sur Red Hat OpenShift Service sur AWS.

RUN chgrp -R 0 /some/directory && \
    chmod -R g=u /some/directory

RUN chgrp -R 0 /some/directory && \
    chmod -R g=u /some/directory

Dans un Dockerfile, vous pouvez utiliser l’instruction LABEL pour définir les métadonnées d’image. Les étiquettes sont similaires aux variables d’environnement en ce qu’elles sont des paires de valeurs clés attachées à une image ou à un conteneur. Les étiquettes sont différentes de la variable d’environnement en ce sens qu’elles ne sont pas visibles pour l’application en cours d’exécution et qu’elles peuvent également être utilisées pour une recherche rapide des images et des conteneurs.

Documentation Docker pour plus d’informations sur l’instruction LABEL.

Les noms d’étiquettes sont généralement espacés. L’espace de noms est défini en conséquence pour refléter le projet qui va récupérer les étiquettes et les utiliser. Dans le cas de Red Hat OpenShift Service sur AWS, l’espace de noms est défini sur io.openshift et pour Kubernetes, l’espace de noms est io.k8s.

Consultez la documentation des métadonnées personnalisées Docker pour plus de détails sur le format.

LABEL io.openshift.tags   mongodb,mongodb24,nosql

LABEL io.openshift.tags   mongodb,mongodb24,nosql

LABEL io.openshift.wants   mongodb,redis

LABEL io.openshift.wants   mongodb,redis

LABEL io.k8s.description The MySQL 5.5 Server with master-slave replication support

LABEL io.k8s.description The MySQL 5.5 Server with master-slave replication support

LABEL io.openshift.non-scalable     true

LABEL io.openshift.non-scalable     true

LABEL io.openshift.min-memory 16Gi
LABEL io.openshift.min-cpu     4

LABEL io.openshift.min-memory 16Gi
LABEL io.openshift.min-cpu     4

Le processus de construction se compose des trois éléments fondamentaux suivants, qui sont combinés dans une image finale du conteneur:

Le S2I génère un Dockerfile avec l’image du constructeur comme première instruction FROM. Le Dockerfile généré par S2I est ensuite transmis à Buildah.

Il est possible d’écrire des scripts source à image (S2I) dans n’importe quel langage de programmation, tant que les scripts sont exécutables à l’intérieur de l’image du constructeur. Le S2I prend en charge plusieurs options fournissant des scripts assemble/run/save-artefacts. L’ensemble de ces emplacements sont vérifiés sur chaque construction dans l’ordre suivant:

L’étiquette io.openshift.s2i.scripts-url spécifiée dans l’image et le script spécifié dans une configuration de build peuvent prendre l’une des formes suivantes:

Exemples de scripts S2I

Les exemples de scripts S2I suivants sont écrits en Bash. Chaque exemple suppose que son contenu de goudron est déballé dans le répertoire /tmp/s2i.

restore build artifacts
move the application source
build application artifacts
install the artifacts

#!/bin/bash

# restore build artifacts
if [ "$(ls /tmp/s2i/artifacts/ 2>/dev/null)" ]; then
    mv /tmp/s2i/artifacts/* $HOME/.
fi

# move the application source
mv /tmp/s2i/src $HOME/src

# build application artifacts
pushd ${HOME}
make all

# install the artifacts
make install
popd

run the application

#!/bin/bash

# run the application
/opt/application/run.sh

#!/bin/bash

pushd ${HOME}
if [ -d deps ]; then
    # all deps contents to tar stream
    tar cf - deps
fi
popd

#!/bin/bash

pushd ${HOME}
if [ -d deps ]; then
    # all deps contents to tar stream
    tar cf - deps
fi
popd

inform the user how to use the image

#!/bin/bash

# inform the user how to use the image
cat <<EOF
This is a S2I sample builder image, to use it, install
https://github.com/openshift/source-to-image
EOF

L’emplacement standard du script de test est test/run. Ce script est invoqué par le Red Hat OpenShift Service sur le constructeur d’images AWS S2I et il pourrait s’agir d’un simple script Bash ou d’un binaire Go statique.

Le script test/exécution effectue la construction S2I, vous devez donc avoir le binaire S2I disponible dans votre $PATH. Au besoin, suivez les instructions d’installation dans le README S2I.

Le S2I combine le code source de l’application et l’image du constructeur, de sorte que pour le tester, vous avez besoin d’un exemple de source d’application pour vérifier que la source se transforme avec succès en une image de conteneur exécutable. L’exemple d’application devrait être simple, mais il devrait exercer les étapes cruciales de l’assemblage et de l’exécution des scripts.

L’outillage S2I est livré avec des outils de génération puissants pour accélérer le processus de création d’une nouvelle image S2I. La commande s2i create produit tous les scripts S2I nécessaires et les outils de test avec le Makefile:

s2i create <image_name> <destination_directory>

$ s2i create <image_name> <destination_directory>

Le script de test/exécution généré doit être ajusté pour être utile, mais il fournit un bon point de départ pour commencer à développer.

Le moyen le plus simple d’exécuter les tests d’image S2I localement est d’utiliser le Makefile généré.

Lorsque vous n’avez pas utilisé la commande création s2i, vous pouvez copier le modèle Makefile suivant et remplacer le paramètre IMAGE_NAME par le nom de votre image.

IMAGE_NAME = openshift/ruby-20-centos7
CONTAINER_ENGINE := $(shell command -v podman 2> /dev/null | echo docker)

build:
	${CONTAINER_ENGINE} build -t $(IMAGE_NAME) .

.PHONY: test
test:
	${CONTAINER_ENGINE} build -t $(IMAGE_NAME)-candidate .
	IMAGE_NAME=$(IMAGE_NAME)-candidate test/run

IMAGE_NAME = openshift/ruby-20-centos7
CONTAINER_ENGINE := $(shell command -v podman 2> /dev/null | echo docker)

build:
	${CONTAINER_ENGINE} build -t $(IMAGE_NAME) .

.PHONY: test
test:
	${CONTAINER_ENGINE} build -t $(IMAGE_NAME)-candidate .
	IMAGE_NAME=$(IMAGE_NAME)-candidate test/run

Le script de test suppose que vous avez déjà construit l’image que vous souhaitez tester. Au besoin, construisez d’abord l’image S2I. Exécutez l’une des commandes suivantes:

Les étapes suivantes décrivent le flux de travail par défaut pour tester les constructeurs d’images S2I:

L’exécution de ces étapes est généralement suffisante pour dire si l’image du constructeur fonctionne comme prévu.

Lorsque vous avez un Dockerfile et les autres artefacts qui composent votre nouvelle image de constructeur S2I, vous pouvez les mettre dans un référentiel git et utiliser Red Hat OpenShift Service sur AWS pour construire et pousser l’image. Définissez une construction Docker qui pointe vers votre référentiel.

Lorsque votre instance Red Hat OpenShift sur AWS est hébergée sur une adresse IP publique, la construction peut être déclenchée chaque fois que vous appuyez dans votre référentiel GitHub image du constructeur S2I.

Il est également possible d’utiliser ImageChangeTrigger pour déclencher une reconstruction de vos applications basées sur l’image du constructeur S2I que vous avez mise à jour.

Le flux d’images comprend n’importe quel nombre d’images de conteneur identifiées par des balises. Il présente une seule vue virtuelle d’images connexes, similaire à un référentiel d’image conteneur.

En regardant un flux d’images, les builds et les déploiements peuvent recevoir des notifications lorsque de nouvelles images sont ajoutées ou modifiées et réagissent en effectuant une compilation ou un déploiement, respectivement.

La balise image est une étiquette appliquée à une image conteneur dans un référentiel qui distingue une image spécifique des autres images d’un flux d’images. Généralement, le tag représente un numéro de version d’une sorte. Ici :v3.11.59-2 est le tag:

registry.access.redhat.com/openshift3/jenkins-2-rhel7:v3.11.59-2

registry.access.redhat.com/openshift3/jenkins-2-rhel7:v3.11.59-2

Il est possible d’ajouter des balises supplémentaires à une image. À titre d’exemple, une image peut se voir attribuer les balises :v3.11.59-2 et :dernières.

Le service OpenShift Red Hat sur AWS fournit la commande oc tag, qui est similaire à la commande docker tag, mais fonctionne sur les flux d’images au lieu de directement sur les images.

Les images évoluent au fil du temps et leurs balises le reflètent. Généralement, une balise d’image pointe toujours vers la dernière image construite.

Lorsqu’il y a trop d’informations intégrées dans un nom de balise, comme v2.0.1-may-2019, le tag pointe vers une seule révision d’une image et n’est jamais mis à jour. En utilisant les options d’élagage par défaut, une telle image n’est jamais supprimée.

Lorsque la balise est nommée v2.0, les révisions d’image sont plus probables. Cela se traduit par une histoire plus longue des balises et, par conséquent, l’élageur d’image est plus susceptible de supprimer des images anciennes et inutilisées.

Bien que la convention de dénomination des balises dépend de vous, voici quelques exemples dans le format <image_name>:<image_tag>:

Lorsque vous avez besoin de dates dans les noms de balises, inspectez périodiquement les images anciennes et non prises en charge et les supprimez. Dans le cas contraire, vous pouvez faire l’expérience d’une utilisation croissante des ressources causée par la conservation d’anciennes images.

Le flux d’images dans Red Hat OpenShift Service sur AWS comprend zéro ou plus d’images de conteneur identifiées par des balises.

Il existe différents types de balises disponibles. Le comportement par défaut utilise une balise permanente, qui pointe vers une image spécifique dans le temps. Lorsque la balise permanente est en cours d’utilisation et que la source change, la balise ne change pas pour la destination.

La balise de suivi signifie que les métadonnées de la balise de destination sont mises à jour lors de l’importation de la balise source.

Il est possible de supprimer les balises d’un flux d’images.

Il est possible d’utiliser des balises pour référencer des images dans les flux d’images à l’aide des types de référence suivants.

Lorsque vous affichez des définitions de flux d’images d’exemples, vous pouvez remarquer qu’elles contiennent des définitions de ImageStreamTag et des références à DockerImage, mais rien n’a trait à ImageStreamImage.

C’est parce que les objets ImageStreamImage sont automatiquement créés dans Red Hat OpenShift Service sur AWS lorsque vous importez ou marquez une image dans le flux d’images. Il ne faut jamais avoir à définir explicitement un objet ImageStreamImage dans une définition de flux d’images que vous utilisez pour créer des flux d’images.

Lorsque Red Hat OpenShift Service sur AWS crée des conteneurs, il utilise l’image du conteneurPullPolicy pour déterminer si l’image doit être tirée avant de démarrer le conteneur. Il existe trois valeurs possibles pour imagePullPolicy:

Lorsqu’un paramètre de conteneur imagePullPolicy n’est pas spécifié, Red Hat OpenShift Service sur AWS le définit en fonction de la balise image:

Lors de l’utilisation du registre d’images OpenShift, pour permettre aux pods dans le projet-a de référencer des images dans le projet-b, un compte de service dans le projet-a doit être lié au rôle système: image-puller dans le projet-b.

Afin de tirer un conteneur sécurisé à partir d’autres registres privés ou sécurisés, vous devez créer un secret de traction à partir des informations d’identification client de votre conteneur, tels que Docker ou Podman, et l’ajouter à votre compte de service.

Docker et Podman utilisent un fichier de configuration pour stocker les détails d’authentification pour se connecter à un registre sécurisé ou non sécurisé:

Ces fichiers stockent vos informations d’authentification si vous vous êtes déjà connecté à un registre sécurisé ou non sécurisé.

{
   "auths":{
      "cloud.openshift.com":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      },
      "quay.io":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      },
      "quay.io/repository-main":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      }
   }
}

{
   "auths":{
      "cloud.openshift.com":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      },
      "quay.io":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      },
      "quay.io/repository-main":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      }
   }
}

apiVersion: v1
data:
  .dockerconfigjson: ewogICAiYXV0aHMiOnsKICAgICAgIm0iOnsKICAgICAgIsKICAgICAgICAgImF1dGgiOiJiM0JsYj0iLAogICAgICAgICAiZW1haWwiOiJ5b3VAZXhhbXBsZS5jb20iCiAgICAgIH0KICAgfQp9Cg==
kind: Secret
metadata:
  creationTimestamp: "2021-09-09T19:10:11Z"
  name: pull-secret
  namespace: default
  resourceVersion: "37676"
  uid: e2851531-01bc-48ba-878c-de96cfe31020
type: Opaque

apiVersion: v1
data:
  .dockerconfigjson: ewogICAiYXV0aHMiOnsKICAgICAgIm0iOnsKICAgICAgIsKICAgICAgICAgImF1dGgiOiJiM0JsYj0iLAogICAgICAgICAiZW1haWwiOiJ5b3VAZXhhbXBsZS5jb20iCiAgICAgIH0KICAgfQp9Cg==
kind: Secret
metadata:
  creationTimestamp: "2021-09-09T19:10:11Z"
  name: pull-secret
  namespace: default
  resourceVersion: "37676"
  uid: e2851531-01bc-48ba-878c-de96cfe31020
type: Opaque

Il est possible d’obtenir des informations générales sur le flux d’images et des informations détaillées sur toutes les balises qu’il pointe.

Il est possible d’ajouter des balises supplémentaires aux flux d’images.

Ajoutez des tags pour des images externes.

Il est possible de mettre à jour une balise pour refléter une autre balise dans un flux d’images.

Il est possible de supprimer les anciennes balises d’un flux d’images.

Consultez Supprimer les balises de flux d’images obsolètes de l’opérateur d’échantillons de cluster pour plus d’informations sur la façon dont l’opérateur d’échantillons de cluster gère les balises de flux d’images dépréciées.

Lorsque vous travaillez avec un registre d’images de conteneur externe, pour réimporter périodiquement une image, par exemple pour obtenir les dernières mises à jour de sécurité, vous pouvez utiliser le drapeau --scheduled.

Le flux d’images peut être configuré pour importer des balises et des métadonnées d’image à partir de registres d’images privés nécessitant une authentification. Cette procédure s’applique si vous modifiez le registre que l’opérateur d’échantillons de cluster utilise pour extraire du contenu à autre chose que Registry.redhat.io.

Il est possible d’importer un seul sous-manifeste, ou tous les manifestes, d’une liste de manifestes lors de l’utilisation des commandes oc import-image ou oc tag CLI en ajoutant le drapeau --import-mode.

Consultez les commandes ci-dessous pour créer un flux d’images qui comprend un seul sous-manifeste ou des images multi-architecture.

Limites

Le fait de travailler avec des listes de manifestes présente les limites suivantes:

Il est possible d’échanger votre flux d’images importé entre multi-architecture et architecture unique en excluant ou en incluant le drapeau --import-mode=

Le tableau suivant décrit les options disponibles pour le drapeau --import-mode=:

Il est possible d’ajouter une liste d’enregistrements, et éventuellement un référentiel individuel au sein d’un registre, qui sont autorisés pour les actions d’extraction et de poussée d’image en modifiant la ressource personnalisée image.config.openshift.io/cluster (CR). Le service Red Hat OpenShift sur AWS applique les modifications apportées à ce CR à tous les nœuds du cluster.

Lorsque vous tirez ou poussez des images, le temps d’exécution du conteneur recherche les registres listés sous le paramètre RegistrySources dans l’image.config.openshift.io/cluster CR. Lorsque vous avez créé une liste d’enregistrements sous le paramètre d’enregistrement autorisé, le temps d’exécution du conteneur ne recherche que ces registres. Les registres qui ne figurent pas dans la liste sont bloqués.

spec:
  registrySources:
    insecureRegistries:
    - insecure.com
    allowedRegistries:
    - example.com
    - quay.io
    - registry.redhat.io
    - insecure.com
    - image-registry.openshift-image-registry.svc:5000

spec:
  registrySources:
    insecureRegistries:
    - insecure.com
    allowedRegistries:
    - example.com
    - quay.io
    - registry.redhat.io
    - insecure.com
    - image-registry.openshift-image-registry.svc:5000