Images

Le Cluster Samples Operator est démarré en tant que Managed par défaut ou si un proxy global est configuré. Dans l'état Managed, le Cluster Samples Operator gère activement ses ressources et maintient le composant actif afin d'extraire les flux d'images d'échantillons et les images du registre et de s'assurer que les modèles d'échantillons requis sont installés.

Dans certaines circonstances, l'opérateur d'échantillonnage en grappes s'amorce lui-même comme Removed, y compris :

Cependant, si le Cluster Samples Operator détecte qu'il est sur un réseau IPv6 et qu'un proxy global OpenShift Container Platform est configuré, alors la vérification IPv6 remplace toutes les vérifications. Par conséquent, le Cluster Samples Operator s'amorce lui-même en tant que Removed.

apiVersion: samples.operator.openshift.io/v1
kind: Config
metadata:
  name: cluster
spec:
  architectures:
  - x86_64
  managementState: Removed

Après la création ou la mise à jour d'un flux d'images d'échantillons, l'opérateur d'échantillons de grappes surveille la progression de l'importation d'images de chaque balise de flux d'images.

En cas d'échec de l'importation, l'opérateur d'échantillons en grappe retente l'importation par le biais de l'API d'importation d'images de flux d'images, qui est la même API que celle utilisée par la commande oc import-image, environ toutes les 15 minutes jusqu'à ce que l'importation réussisse ou que la configuration de l'opérateur d'échantillons en grappe soit modifiée de telle sorte que le flux d'images soit ajouté à la liste skippedImagestreams ou que l'état de gestion soit modifié en Removed.

Ressources complémentaires

Lors de l'installation, OpenShift Container Platform 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 de remplissage, pour chaque balise de flux d'images.

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 d'OpenShift Container Platform, le statut de l'opérateur Cluster Samples est défini sur Removed. Si vous choisissez de le changer en Managed, il installe les échantillons.

Vous pouvez utiliser cette carte de configuration comme référence pour savoir quelles images doivent être mises en miroir pour que vos flux d'images soient importés.

Pour une procédure détaillée, voir Utilisation des flux d'images de l'opérateur Cluster Samples avec des registres alternatifs ou en miroir.

Lorsque le Cluster Samples Operator commence à prendre en charge plusieurs architectures, la liste des architectures n'est pas autorisée à être modifiée lorsqu'elle se trouve à l'état Managed.

Pour modifier les valeurs des architectures, un administrateur de cluster doit :

L'opérateur d'échantillonnage en grappe continue de traiter les secrets lorsqu'il se trouve dans l'état Removed. Vous pouvez créer le secret avant de passer à Removed, pendant que vous êtes à Removed, avant de passer à Managed, ou après avoir passé à Managed. La création des échantillons est retardée jusqu'à ce que l'événement secret soit traité si vous créez le secret après avoir basculé sur Managed. Cela facilite la modification du registre, lorsque vous choisissez de supprimer tous les échantillons avant de basculer pour faire table rase. Il n'est pas nécessaire de supprimer tous les échantillons avant de basculer.

La ressource échantillons conserve les conditions suivantes dans son statut :

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

Vous pouvez installer l'OpenShift CLI (oc) pour interagir avec OpenShift Container Platform à partir d'une interface de ligne de commande. Vous pouvez installer oc sur Linux, Windows ou macOS.

Installation de la CLI OpenShift sur Linux

Vous pouvez installer le binaire OpenShift CLI (oc) sur Linux en utilisant la procédure suivante.

Après l'installation de la CLI OpenShift, elle est disponible à l'aide de la commande oc:

oc <command>

Installation de la CLI OpenShift sur Windows

Vous pouvez installer le binaire OpenShift CLI (oc) sur Windows en utilisant la procédure suivante.

Après l'installation de la CLI OpenShift, elle est disponible à l'aide de la commande oc:

C:\N> oc <command>

Installation de la CLI OpenShift sur macOS

Vous pouvez installer le binaire OpenShift CLI (oc) sur macOS en utilisant la procédure suivante.

Après l'installation de la CLI OpenShift, elle est disponible à l'aide de la commande oc:

oc <command>

Lors de l'installation, OpenShift Container Platform 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 de remplissage, pour chaque balise de flux d'images.

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 d'OpenShift Container Platform, le statut de l'opérateur Cluster Samples est défini sur Removed. Si vous choisissez de le changer en Managed, il installe les échantillons.

Vous pouvez utiliser cette carte de configuration comme référence pour savoir quelles images doivent être mises en miroir pour que vos flux d'images soient importés.

Pour une procédure détaillée, voir Utilisation des flux d'images de l'opérateur Cluster Samples avec des registres alternatifs ou en miroir.

Les directives suivantes s'appliquent à la création d'une image de conteneur en général, et sont indépendantes de l'utilisation des images sur OpenShift Container Platform.

Réutiliser les images

Dans la mesure du possible, basez votre image sur une image en amont appropriée en utilisant la déclaration FROM. Cela permet à votre image de récupérer facilement les correctifs de sécurité d'une image en amont lorsqu'elle est mise à jour, plutôt que d'avoir à mettre à jour vos dépendances directement.

En outre, 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. L'utilisation d'une balise autre que latest permet de s'assurer que votre image n'est pas soumise à des modifications qui pourraient être apportées à la version latest d'une image en amont.

Maintenir la compatibilité entre les balises

Lorsque vous marquez vos propres images, essayez de maintenir la compatibilité ascendante au sein d'une balise. Par exemple, si vous fournissez une image nommée foo et qu'elle inclut actuellement la version 1.0, vous pouvez fournir une balise foo:v1. Lorsque vous mettez à jour l'image, tant qu'elle reste compatible avec l'image originale, vous pouvez continuer à baliser la nouvelle image foo:v1, et les consommateurs en aval de cette balise sont en mesure d'obtenir des mises à jour sans être interrompus.

Si vous publiez ultérieurement une mise à jour incompatible, passez à une nouvelle balise, par exemple foo:v2. Cela permet aux consommateurs en aval de passer à la nouvelle version à leur guise, sans être interrompus par inadvertance par la nouvelle image incompatible. Tout consommateur en aval qui utilise foo:latest prend le risque que des changements incompatibles soient introduits.

Éviter les processus multiples

Ne démarrez pas plusieurs services, tels qu'une base de données et SSHD, à l'intérieur d'un même conteneur. Cela n'est pas nécessaire car les conteneurs sont légers et peuvent être facilement reliés entre eux pour orchestrer plusieurs processus. OpenShift Container Platform vous permet de colocaliser et de cogérer facilement des images connexes en les regroupant dans un seul pod.

Cette colocation garantit que les conteneurs partagent un espace de noms réseau et un espace de stockage pour la communication. Les mises à jour sont également moins perturbantes, car chaque image peut être mise à jour moins fréquemment et indépendamment. Les flux de traitement des signaux sont également plus clairs avec un processus unique, car il n'est pas nécessaire de gérer l'acheminement des signaux vers les processus créés.

Utiliser exec dans les scripts d'accompagnement

De nombreuses images utilisent des scripts enveloppants pour effectuer certaines configurations avant de lancer un processus pour le logiciel en cours d'exécution. Si votre image utilise un tel script, celui-ci utilise exec afin que le processus du script soit remplacé par votre logiciel. Si vous n'utilisez pas exec, les signaux envoyés par le moteur d'exécution de votre conteneur sont transmis à votre script d'encapsulation au lieu du processus de votre logiciel. Ce n'est pas ce que vous souhaitez.

Si vous avez un script wrapper qui démarre un processus pour un serveur. Vous démarrez votre conteneur, par exemple, à l'aide de podman run -i, qui exécute le script wrapper, lequel démarre à son tour votre processus. Si vous souhaitez fermer votre conteneur à l'aide de CTRL C, si votre script wrapper a utilisé exec pour démarrer le processus du serveur, podman envoie SIGINT au processus du serveur et tout se passe comme prévu. Si vous n'avez pas utilisé exec dans votre script wrapper, podman envoie SIGINT au processus du script wrapper et votre processus continue à fonctionner comme si de rien n'était.

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

Nettoyer les fichiers temporaires

Supprimez tous les fichiers temporaires créés au cours du processus de construction. Cela inclut également tous les fichiers ajoutés avec la commande ADD. Par exemple, exécutez la commande yum clean après avoir effectué les opérations yum install.

Vous pouvez éviter que le cache yum ne se retrouve dans une couche d'image en créant votre déclaration RUN de la manière suivante :

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

Notez que si vous écrivez à la place :

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

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

Le processus actuel de construction des conteneurs ne permet pas à une commande exécutée dans une couche ultérieure de réduire l'espace utilisé par l'image lorsque quelque chose a été supprimé dans une couche antérieure. Toutefois, 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. Par conséquent, comme dans l'exemple yum clean, il est préférable de supprimer les fichiers dans la même commande que celle qui les a créés, dans la mesure du possible, afin qu'ils ne finissent pas par être écrits dans un calque.

En outre, l'exécution de plusieurs commandes dans une seule déclaration RUN réduit le nombre de couches de votre image, ce qui améliore le temps de téléchargement et d'extraction.

Placez les instructions dans l'ordre approprié

Le constructeur de conteneurs lit le site Dockerfile et exécute les instructions de haut en bas. Chaque instruction exécutée avec succès crée une couche qui peut être réutilisée lors de la prochaine construction de cette image ou d'une autre. Il est très important de placer les instructions qui changent rarement au sommet de votre Dockerfile. Cela garantit que les prochaines constructions de la même image seront très rapides, car le cache n'est pas invalidé par les modifications des couches supérieures.

Par exemple, si vous travaillez sur un site Dockerfile qui contient une commande ADD pour installer un fichier sur lequel vous êtes en train d'itérer, et une commande RUN pour yum install un paquet, il est préférable de placer la commande ADD en dernier :

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

Ainsi, chaque fois que vous modifiez myfile et que vous exécutez à nouveau podman build ou docker build, le système réutilise la couche mise en cache pour la commande yum et ne génère la nouvelle couche que pour l'opération ADD.

Si, au lieu de cela, vous écriviez Dockerfile comme suit :

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

Ensuite, chaque fois que vous modifiez myfile et que vous exécutez à nouveau podman build ou docker build, l'opération ADD invalide le cache de la couche RUN, de sorte que l'opération yum doit également être exécutée à nouveau.

Marquer les ports importants

L'instruction EXPOSE rend un port du conteneur accessible au système hôte et aux 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 par les humains et les logiciels en déclarant explicitement les ports dont votre logiciel a besoin pour fonctionner :

Définir les variables d'environnement

Il est conseillé de définir des variables d'environnement à l'aide de l'instruction ENV. Un exemple est la définition de la version de votre projet. Cela permet aux gens de trouver facilement la version sans avoir à consulter l'instruction Dockerfile. Un autre exemple consiste à annoncer un chemin sur le système qui pourrait être utilisé par un autre processus, tel que JAVA_HOME.

Éviter les mots de passe par défaut

Évitez de définir des mots de passe par défaut. De nombreuses personnes é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 peuvent être configurés à l'aide d'une variable d'environnement.

Si vous choisissez de définir un mot de passe par défaut, veillez à ce qu'un message d'avertissement approprié s'affiche au démarrage du conteneur. Ce message doit informer l'utilisateur de la valeur du mot de passe par défaut et lui expliquer comment le modifier, par exemple en lui indiquant la variable d'environnement à définir.

Éviter sshd

Il est préférable d'éviter d'exécuter sshd dans votre image. Vous pouvez utiliser la commande podman exec ou docker exec pour accéder aux conteneurs qui s'exécutent sur l'hôte local. Vous pouvez également utiliser la commande oc exec ou la commande oc rsh pour accéder aux conteneurs qui s'exécutent sur le cluster OpenShift Container Platform. L'installation et l'exécution de sshd dans votre image ouvre des vecteurs d'attaque supplémentaires et des exigences en matière de correctifs de sécurité.

Utiliser des volumes pour les données persistantes

Les images utilisent un volume pour les données persistantes. De cette façon, OpenShift Container Platform monte le stockage réseau sur le nœud qui exécute le conteneur, et si le conteneur est déplacé vers un nouveau nœud, le stockage est rattaché à ce nœud. En utilisant le volume pour tous les besoins de stockage persistant, le contenu est préservé même si le conteneur est redémarré ou déplacé. Si votre image écrit des données à des emplacements arbitraires dans le conteneur, ce contenu ne pourra pas être préservé.

Toutes 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 indicateur readonly pour les conteneurs, qui peut être utilisé pour appliquer strictement les bonnes pratiques concernant l'absence d'écriture de données sur un stockage éphémère dans un conteneur. En concevant votre image autour de cette capacité dès maintenant, il sera plus facile d'en tirer parti ultérieurement.

La définition explicite des volumes dans votre site Dockerfile permet aux utilisateurs de l'image de comprendre facilement quels volumes ils doivent définir lors de l'exécution de votre image.

Voir la documentation Kubernetes pour plus d'informations sur l'utilisation des volumes dans OpenShift Container Platform.

Les directives suivantes s'appliquent lors de la création d'images de conteneurs spécifiquement destinées à être utilisées sur OpenShift Container Platform.

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

Vous pouvez utiliser l'instruction LABEL dans une page Dockerfile pour définir les métadonnées de l'image. Les étiquettes sont similaires aux variables d'environnement en ce sens qu'il s'agit de paires clé-valeur attachées à une image ou à un conteneur. Les étiquettes sont différentes des variables d'environnement en ce sens qu'elles ne sont pas visibles par l'application en cours d'exécution et qu'elles peuvent également être utilisées pour la recherche rapide d'images et de conteneurs.

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

Les noms des étiquettes sont généralement associés à un espace de noms. 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. Pour OpenShift Container Platform, l'espace de noms est défini sur io.openshift et pour Kubernetes, l'espace de noms est io.k8s.

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

LABEL io.openshift.tags   mongodb,mongodb24,nosql

LABEL io.openshift.wants   mongodb,redis

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

LABEL io.openshift.non-scalable     true

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 pour former une image finale du conteneur :

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

Vous pouvez écrire des scripts source-image (S2I) dans n'importe quel langage de programmation, à condition que les scripts soient exécutables dans l'image du constructeur. S2I prend en charge plusieurs options fournissant des scripts assemble/run/save-artifacts. Tous ces emplacements sont vérifiés lors de chaque compilation 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 compilation peuvent prendre l'une des formes suivantes :

Example S2I scripts

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

#!/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

#!/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

# 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 test est test/run. Ce script est invoqué par le constructeur d'images S2I de OpenShift Container Platform et peut être un simple script Bash ou un binaire Go statique.

Le script test/run effectue la construction de S2I, vous devez donc avoir le binaire S2I disponible dans votre site $PATH. Si nécessaire, suivez les instructions d'installation dans le README de S2I.

S2I combine le code source de l'application et l'image du constructeur. Pour le tester, vous avez donc besoin d'un exemple de source d'application afin de vérifier que la source se transforme avec succès en une image de conteneur exécutable. L'exemple d'application doit être simple, mais il doit permettre d'exercer les étapes cruciales des scripts assemble et run.

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

$ s2i create _<image nom>_ _<destination répertoire>_

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

La manière la plus simple d'exécuter localement les tests d'image S2I est d'utiliser la version générée de Makefile.

Si vous n'avez pas utilisé la commande s2i create, vous pouvez copier le modèle suivant Makefile 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

Le script test suppose que vous avez déjà créé l'image que vous souhaitez tester. Si nécessaire, 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 suffit généralement à déterminer si l'image du constructeur fonctionne comme prévu.

Une fois que vous avez Dockerfile et les autres artefacts qui composent votre nouvelle image S2I builder, vous pouvez les mettre dans un dépôt git et utiliser OpenShift Container Platform pour construire et pousser l'image. Définissez un build Docker qui pointe vers votre dépôt.

Si votre instance OpenShift Container Platform est hébergée sur une adresse IP publique, le build peut être déclenché à chaque fois que vous poussez dans votre dépôt GitHub S2I builder image.

Vous pouvez également utiliser le site ImageChangeTrigger pour déclencher une reconstruction de vos applications basées sur l'image du constructeur S2I que vous avez mise à jour.

Un flux d'images comprend un nombre quelconque d'images de conteneurs identifiées par des balises. Il présente une vue virtuelle unique des images associées, similaire à un référentiel d'images de conteneurs.

En observant un flux d'images, les constructions et les déploiements peuvent recevoir des notifications lorsque de nouvelles images sont ajoutées ou modifiées et réagir en effectuant une construction ou un déploiement, respectivement.

Une balise d'image est une étiquette appliquée à une image conteneur dans un référentiel qui distingue une image spécifique des autres images dans un flux d'images. Généralement, la balise représente une sorte de numéro de version. Par exemple, ici :v3.11.59-2 est la balise :

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

Vous pouvez ajouter des balises supplémentaires à une image. Par exemple, une image peut se voir attribuer les balises :v3.11.59-2 et :latest.

OpenShift Container Platform propose la commande oc tag, qui est similaire à la commande docker tag, mais qui opère sur les flux d'images au lieu d'agir directement sur les images.

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

Si le nom d'une balise contient trop d'informations, comme v2.0.1-may-2019, la balise pointe vers une seule révision de l'image et n'est jamais mise à jour. En utilisant les options d'élagage par défaut, une telle image n'est jamais supprimée. Dans les très grands clusters, le schéma de création de nouvelles balises pour chaque image révisée pourrait éventuellement remplir le datastore etcd avec des métadonnées de balises excédentaires pour des images qui sont dépassées depuis longtemps.

Si la balise est nommée v2.0, les révisions d'images sont plus probables. L'historique de la balise est donc plus long et, par conséquent, l'élagueur d'images est plus enclin à supprimer les images anciennes et inutilisées.

Bien que la convention de dénomination des balises soit laissée à votre discrétion, voici quelques exemples au format <image_name>:<image_tag>:

Si vous avez besoin de dates dans les noms de balises, inspectez périodiquement les images anciennes et non prises en charge, ainsi que istags, et supprimez-les. Dans le cas contraire, vous risquez d'être confronté à une utilisation accrue des ressources en raison de la conservation d'anciennes images.

Un flux d'images dans OpenShift Container Platform comprend zéro ou plusieurs images de conteneurs identifiées par des balises.

Il existe différents types de balises. Le comportement par défaut utilise une balise permanent, qui pointe vers une image spécifique dans le temps. Si la balise permanent est utilisée et que la source change, la balise ne change pas pour la destination.

Une balise tracking signifie que les métadonnées de la balise de destination sont mises à jour lors de l'importation de la balise source.

Vous pouvez supprimer les balises d'un flux d'images.

Vous pouvez utiliser des balises pour référencer des images dans des flux d'images à l'aide des types de référence suivants.

Lorsque vous consultez des exemples de définitions de flux d'images, vous pouvez remarquer qu'ils contiennent des définitions de ImageStreamTag et des références à DockerImage, mais rien concernant ImageStreamImage.

En effet, les objets ImageStreamImage sont automatiquement créés dans OpenShift Container Platform lorsque vous importez ou marquez une image dans le flux d'images. Vous ne devriez 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 OpenShift Container Platform crée des conteneurs, il utilise le conteneur imagePullPolicy pour déterminer si l'image doit être extraite avant de démarrer le conteneur. Il existe trois valeurs possibles pour imagePullPolicy:

Si le paramètre imagePullPolicy n'est pas spécifié, OpenShift Container Platform le définit en fonction de la balise de l'image :

Lors de l'utilisation du registre d'images OpenShift, pour permettre aux pods de project-a de référencer les images de project-b, un compte de service de project-a doit être lié au rôle de system:image-puller de project-b.

Le fichier .dockercfg $HOME/.docker/config.json pour les clients Docker est un fichier d'informations d'identification Docker qui stocke vos informations d'authentification si vous vous êtes précédemment connecté à un registre sécurisé ou non.

Pour extraire une image de conteneur sécurisée qui ne provient pas du registre d'images d'OpenShift, vous devez créer un secret d'extraction à partir de vos informations d'identification Docker et l'ajouter à votre compte de service.

Le fichier d'informations d'identification Docker et le secret d'extraction associé peuvent contenir plusieurs références au même registre, chacune avec son propre ensemble d'informations d'identification.

{
   "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

Vous pouvez mettre à jour le secret d'extraction global pour votre cluster en remplaçant le secret d'extraction actuel ou en ajoutant un nouveau secret d'extraction.

Vous pouvez obtenir des informations générales sur le flux d'images et des informations détaillées sur toutes les balises vers lesquelles il pointe.

Vous pouvez ajouter des balises supplémentaires aux flux d'images.

Vous pouvez ajouter des balises pour les images externes.

Vous pouvez mettre à jour une balise pour refléter une autre balise dans un flux d'images.

Vous pouvez supprimer les anciennes étiquettes d'un flux d'images.

Voir Suppression des balises de flux d'images obsolètes de Cl uster Samples Operator pour plus d'informations sur la façon dont Cluster Samples Operator gère les balises de flux d'images obsolètes.

Lorsque vous travaillez avec un registre externe d'images de conteneurs, 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 fichier .dockercfg $HOME/.docker/config.json pour les clients Docker est un fichier d'informations d'identification Docker qui stocke vos informations d'authentification si vous vous êtes précédemment connecté à un registre sécurisé ou non.

Pour extraire une image de conteneur sécurisée qui ne provient pas du registre d'images d'OpenShift, vous devez créer un secret d'extraction à partir de vos informations d'identification Docker et l'ajouter à votre compte de service.

Le fichier d'informations d'identification Docker et le secret d'extraction associé peuvent contenir plusieurs références au même registre, chacune avec son propre ensemble d'informations d'identification.

{
   "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

Le tableau suivant décrit les champs de configuration disponibles pour la valeur importMode:

Vous pouvez ajouter une liste de registres, et éventuellement un référentiel individuel au sein d'un registre, qui sont autorisés pour les actions de traction et de poussée d'image en modifiant la ressource personnalisée (CR) image.config.openshift.io/cluster. OpenShift Container Platform applique les modifications de cette CR à tous les nœuds du cluster.

Lors de l'extraction ou de l'importation d'images, le moteur d'exécution du conteneur recherche les registres répertoriés sous le paramètre registrySources dans le CR image.config.openshift.io/cluster. Si vous avez créé une liste de registres sous le paramètre allowedRegistries, le moteur 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

Vous pouvez bloquer n'importe quel registre, et éventuellement un référentiel individuel au sein d'un registre, en modifiant la ressource personnalisée (CR) image.config.openshift.io/cluster. OpenShift Container Platform applique les modifications de cette CR à tous les nœuds du cluster.

Lors de l'extraction ou de l'importation d'images, le moteur d'exécution du conteneur recherche les registres répertoriés sous le paramètre registrySources dans le CR image.config.openshift.io/cluster. Si vous avez créé une liste de registres sous le paramètre blockedRegistries, le moteur d'exécution du conteneur ne recherche pas ces registres. Tous les autres registres sont autorisés.

Vous pouvez ajouter des registres non sécurisés, et éventuellement un référentiel individuel au sein d'un registre, en modifiant la ressource personnalisée (CR) image.config.openshift.io/cluster. OpenShift Container Platform applique les modifications de cette CR à tous les nœuds du cluster.

Les registres qui n'utilisent pas de certificats SSL valides ou qui n'exigent pas de connexions HTTPS sont considérés comme non sécurisés.

Vous pouvez ajouter des registres pour rechercher un nom court d'image en modifiant la ressource personnalisée (CR) image.config.openshift.io/cluster. OpenShift Container Platform applique les modifications de cette CR à tous les nœuds du cluster.

Un nom court d'image vous permet de rechercher des images sans inclure le nom de domaine complet dans la spécification d'extraction. Par exemple, vous pouvez utiliser rhel7/etcd au lieu de registry.access.redhat.com/rhe7/etcd.

Vous pouvez utiliser des noms courts dans des situations où l'utilisation du chemin complet n'est pas pratique. Par exemple, si votre cluster fait référence à plusieurs registres internes dont le DNS change fréquemment, vous devrez mettre à jour les noms de domaine pleinement qualifiés dans vos spécifications d'extraction à chaque changement. Dans ce cas, l'utilisation d'un nom court d'image peut s'avérer utile.

Lors de l'extraction ou de l'importation d'images, le moteur d'exécution du conteneur recherche les registres répertoriés sous le paramètre registrySources dans le CR image.config.openshift.io/cluster. Si vous avez créé une liste de registres sous le paramètre containerRuntimeSearchRegistries, lors de l'extraction d'une image avec un nom court, le moteur d'exécution du conteneur recherche ces registres.

L'opérateur de configuration de la machine (MCO) surveille la ressource image.config.openshift.io/cluster pour détecter toute modification des registres. Lorsque le MCO détecte une modification, il vide les nœuds, applique la modification et désenregistre les nœuds. Après le retour des nœuds à l'état Ready, si le paramètre containerRuntimeSearchRegistries est ajouté, le MCO crée un fichier dans le répertoire /etc/containers/registries.conf.d sur chaque nœud avec les registres répertoriés. Ce fichier remplace la liste par défaut des registres de recherche non qualifiés du fichier /host/etc/containers/registries.conf. Il n'existe aucun moyen de revenir à la liste par défaut des registres de recherche non qualifiés.

Le paramètre containerRuntimeSearchRegistries ne fonctionne qu'avec les moteurs de conteneurs Podman et CRI-O. Les registres de la liste ne peuvent être utilisés que dans les spécifications des pods, pas dans les builds et les flux 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.

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.

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

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

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

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

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

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

Les étiquettes sont utilisées pour gérer et organiser les objets générés, tels que les pods. Les étiquettes spécifiées dans le modèle sont appliquées à chaque objet généré à partir du modèle.

La liste des paramètres que vous pouvez modifier figure dans la section parameters du modèle.

À l'aide de l'interface de programmation, vous pouvez traiter un fichier définissant un modèle pour renvoyer la liste des objets sur la sortie standard.

Un modèle de démarrage rapide est un exemple de base d'une application fonctionnant sur OpenShift Container Platform. Les démarrages rapides sont disponibles dans une variété de langages et de cadres, et sont définis dans un modèle, qui est construit à partir d'un ensemble de services, de configurations de construction et de configurations de déploiement. Ce modèle référence les images et les dépôts de sources nécessaires pour construire et déployer l'application.

Pour explorer un démarrage rapide, créez une application à partir d'un modèle. Votre administrateur doit avoir déjà installé ces modèles dans votre cluster OpenShift Container Platform, auquel cas vous pouvez simplement le sélectionner à partir de la console web.

Les démarrages rapides font référence à un référentiel de sources qui contient le code source de l'application. Pour personnaliser le démarrage rapide, forker le référentiel et, lors de la création d'une application à partir du modèle, remplacer le nom du référentiel source par défaut par votre référentiel forké. Il en résulte que les constructions sont effectuées en utilisant votre code source au lieu du code source de l'exemple fourni. Vous pouvez ensuite mettre à jour le code dans votre dépôt de sources et lancer une nouvelle compilation pour voir les changements reflétés dans l'application déployée.

La description du modèle vous informe de ce que fait le modèle et vous aide à le trouver lors d'une recherche dans la console web. L'ajout de métadonnées autres que le nom du modèle est facultatif, mais utile. En plus des informations descriptives générales, les métadonnées comprennent également un ensemble de balises. Les balises utiles comprennent le nom du langage auquel le modèle est lié, par exemple Java, PHP, Ruby, etc.

Voici un exemple de métadonnées de description de modèle :

kind: Template
apiVersion: template.openshift.io/v1
metadata:
  name: cakephp-mysql-example 1
  annotations:
    openshift.io/display-name: "CakePHP MySQL Example (Ephemeral)" 2
    description: >-
      An example CakePHP application with a MySQL database. For more information
      about using this template, including OpenShift considerations, see
      https://github.com/sclorg/cakephp-ex/blob/master/README.md.


      WARNING: Any data stored will be lost upon pod destruction. Only use this
      template for testing." 3
    openshift.io/long-description: >-
      This template defines resources needed to develop a CakePHP application,
      including a build configuration, application DeploymentConfig, and
      database DeploymentConfig.  The database is stored in
      non-persistent storage, so this configuration should be used for
      experimental purposes only. 4
    tags: "quickstart,php,cakephp" 5
    iconClass: icon-php 6
    openshift.io/provider-display-name: "Red Hat, Inc." 7
    openshift.io/documentation-url: "https://github.com/sclorg/cakephp-ex" 8
    openshift.io/support-url: "https://access.redhat.com" 9
message: "Your admin credentials are ${ADMIN_USERNAME}:${ADMIN_PASSWORD}" 10

Les modèles peuvent inclure un ensemble d'étiquettes. Ces étiquettes sont ajoutées à chaque objet créé lorsque le modèle est instancié. La définition d'une étiquette de cette manière permet aux utilisateurs de trouver et de gérer facilement tous les objets créés à partir d'un modèle particulier.

Voici un exemple d'étiquettes d'objets de modèle :

kind: "Template"
apiVersion: "v1"
...
labels:
  template: "cakephp-mysql-example" 1
  app: "${NAME}" 2

Les paramètres permettent à une valeur d'être fournie par vous ou générée lors de l'instanciation du modèle. Cette valeur est ensuite substituée partout où le paramètre est référencé. Les références peuvent être définies dans n'importe quel champ de la liste des objets. Ceci est utile pour générer des mots de passe aléatoires ou pour vous permettre de fournir un nom d'hôte ou une autre valeur spécifique à l'utilisateur qui est nécessaire pour personnaliser le modèle. Les paramètres peuvent être référencés de deux manières :

En utilisant la syntaxe ${PARAMETER_NAME}, plusieurs références de paramètres peuvent être combinées dans un seul champ et la référence peut être intégrée dans des données fixes, telles que "http://${PARAMETER_1}${PARAMETER_2}". Les deux valeurs des paramètres sont substituées et la valeur résultante est une chaîne de caractères entre guillemets.

Lors de l'utilisation de la syntaxe ${{PARAMETER_NAME}}, une seule référence de paramètre est autorisée et les caractères de tête et de fin ne sont pas autorisés. La valeur résultante n'est pas mise entre guillemets, sauf si, après substitution, le résultat n'est pas un objet JSON valide. Si le résultat n'est pas une valeur JSON valide, la valeur résultante est citée et traitée comme une chaîne de caractères standard.

Un même paramètre peut être référencé plusieurs fois dans un modèle et il peut être référencé à l'aide des deux syntaxes de substitution dans un même modèle.

Une valeur par défaut peut être fournie, qui est utilisée si vous ne fournissez pas de valeur différente :

Voici un exemple de définition d'une valeur explicite comme valeur par défaut :

parameters:
  - name: USERNAME
    description: "The user name for Joe"
    value: joe

Les valeurs des paramètres peuvent également être générées sur la base de règles spécifiées dans la définition du paramètre, par exemple en générant une valeur de paramètre :

parameters:
  - name: PASSWORD
    description: "The random user password"
    generate: expression
    from: "[a-zA-Z0-9]{12}"

Dans l'exemple précédent, le traitement génère un mot de passe aléatoire de 12 caractères composé de toutes les lettres de l'alphabet, majuscules et minuscules, et de chiffres.

La syntaxe disponible n'est pas une syntaxe d'expression régulière complète. Cependant, vous pouvez utiliser les modificateurs \w, \d, \a, et \A:

  parameters:
  - name: singlequoted_example
    generate: expression
    from: '[\A]{10}'
  - name: doublequoted_example
    generate: expression
    from: "[\\A]{10}"

{
    "parameters": [
       {
        "name": "json_example",
        "generate": "expression",
        "from": "[\\A]{10}"
       }
    ]
}

Voici un exemple de modèle complet avec les définitions des paramètres et les références :

kind: Template
apiVersion: template.openshift.io/v1
metadata:
  name: my-template
objects:
  - kind: BuildConfig
    apiVersion: build.openshift.io/v1
    metadata:
      name: cakephp-mysql-example
      annotations:
        description: Defines how to build the application
    spec:
      source:
        type: Git
        git:
          uri: "${SOURCE_REPOSITORY_URL}" 1
          ref: "${SOURCE_REPOSITORY_REF}"
        contextDir: "${CONTEXT_DIR}"
  - kind: DeploymentConfig
    apiVersion: apps.openshift.io/v1
    metadata:
      name: frontend
    spec:
      replicas: "${{REPLICA_COUNT}}" 2
parameters:
  - name: SOURCE_REPOSITORY_URL 3
    displayName: Source Repository URL 4
    description: The URL of the repository with your application source code 5
    value: https://github.com/sclorg/cakephp-ex.git 6
    required: true 7
  - name: GITHUB_WEBHOOK_SECRET
    description: A secret string used to configure the GitHub webhook
    generate: expression 8
    from: "[a-zA-Z0-9]{40}" 9
  - name: REPLICA_COUNT
    description: Number of replicas to run
    value: "2"
    required: true
message: "... The GitHub webhook secret is ${GITHUB_WEBHOOK_SECRET} ..." 10

La partie principale du modèle est la liste des objets créés lors de l'instanciation du modèle. Il peut s'agir de n'importe quel objet API valide, tel qu'une configuration de construction, une configuration de déploiement ou un service. L'objet est créé exactement comme il est défini ici, les valeurs des paramètres étant substituées avant la création. La définition de ces objets peut faire référence à des paramètres définis précédemment.

Voici un exemple de liste d'objets :

kind: "Template"
apiVersion: "v1"
metadata:
  name: my-template
objects:
  - kind: "Service" 1
    apiVersion: "v1"
    metadata:
      name: "cakephp-mysql-example"
      annotations:
        description: "Exposes and load balances the application pods"
    spec:
      ports:
        - name: "web"
          port: 8080
          targetPort: 8080
      selector:
        name: "cakephp-mysql-example"

Le Template Service Broker annonce un service dans son catalogue pour chaque objet modèle dont il a connaissance. Par défaut, chacun de ces services est annoncé comme étant liant, ce qui signifie qu'un utilisateur final est autorisé à se lier au service fourni.

Les auteurs de modèles peuvent indiquer que les champs de certains objets d'un modèle doivent être exposés. Le Template Service Broker reconnaît les champs exposés sur les objets ConfigMap, Secret, Service, et Route, et renvoie les valeurs des champs exposés lorsqu'un utilisateur lie un service soutenu par le broker.

Pour exposer un ou plusieurs champs d'un objet, ajoutez des annotations préfixées par template.openshift.io/expose- ou template.openshift.io/base64-expose- à l'objet dans le modèle.

Chaque clé d'annotation, dont le préfixe a été supprimé, est transmise pour devenir une clé dans une réponse bind.

Chaque valeur d'annotation est une expression JSONPath de Kubernetes, qui est résolue au moment de la liaison pour indiquer le champ d'objet dont la valeur doit être renvoyée dans la réponse bind.

Voici un exemple d'exposition des champs de différents objets :

kind: Template
apiVersion: template.openshift.io/v1
metadata:
  name: my-template
objects:
- kind: ConfigMap
  apiVersion: v1
  metadata:
    name: my-template-config
    annotations:
      template.openshift.io/expose-username: "{.data['my\\.username']}"
  data:
    my.username: foo
- kind: Secret
  apiVersion: v1
  metadata:
    name: my-template-config-secret
    annotations:
      template.openshift.io/base64-expose-password: "{.data['password']}"
  stringData:
    password: bar
- kind: Service
  apiVersion: v1
  metadata:
    name: my-template-service
    annotations:
      template.openshift.io/expose-service_ip_port: "{.spec.clusterIP}:{.spec.ports[?(.name==\"web\")].port}"
  spec:
    ports:
    - name: "web"
      port: 8080
- kind: Route
  apiVersion: route.openshift.io/v1
  metadata:
    name: my-template-route
    annotations:
      template.openshift.io/expose-uri: "http://{.spec.host}{.spec.path}"
  spec:
    path: mypath

Voici un exemple de réponse à une opération bind à partir du modèle partiel ci-dessus :

{
  "credentials": {
    "username": "foo",
    "password": "YmFy",
    "service_ip_port": "172.30.12.34:8080",
    "uri": "http://route-test.router.default.svc.cluster.local/mypath"
  }
}

Les auteurs de modèles peuvent indiquer que certains objets d'un modèle doivent être attendus avant que l'instanciation d'un modèle par le catalogue de services, le Template Service Broker ou l'API TemplateInstance ne soit considérée comme terminée.

Pour utiliser cette fonctionnalité, marquez un ou plusieurs objets du type Build, BuildConfig, Deployment, DeploymentConfig, Job, ou StatefulSet dans un modèle avec l'annotation suivante :

"template.alpha.openshift.io/wait-for-ready": "true"

L'instanciation du modèle n'est pas terminée tant que tous les objets marqués par l'annotation ne sont pas prêts. De même, si l'un des objets annotés signale un échec ou si le modèle n'est pas prêt dans un délai fixe d'une heure, l'instanciation du modèle échoue.

Pour les besoins de l'instanciation, la disponibilité et l'échec de chaque type d'objet sont définis comme suit :

Voici un exemple d'extrait de modèle qui utilise l'annotation wait-for-ready. D'autres exemples peuvent être trouvés dans les modèles de démarrage rapide de OpenShift Container Platform.

kind: Template
apiVersion: template.openshift.io/v1
metadata:
  name: my-template
objects:
- kind: BuildConfig
  apiVersion: build.openshift.io/v1
  metadata:
    name: ...
    annotations:
      # wait-for-ready used on BuildConfig ensures that template instantiation
      # will fail immediately if build fails
      template.alpha.openshift.io/wait-for-ready: "true"
  spec:
    ...
- kind: DeploymentConfig
  apiVersion: apps.openshift.io/v1
  metadata:
    name: ...
    annotations:
      template.alpha.openshift.io/wait-for-ready: "true"
  spec:
    ...
- kind: Service
  apiVersion: v1
  metadata:
    name: ...
  spec:
    ...

Plutôt que d'écrire un modèle complet à partir de zéro, vous pouvez exporter des objets existants de votre projet sous forme de YAML, puis modifier le YAML à partir de là en ajoutant des paramètres et d'autres personnalisations sous forme de modèle.

Étant donné que Rails 4 ne sert plus de page statique public/index.html en production, vous devez créer une nouvelle page racine.

Pour créer une page de bienvenue personnalisée, il faut suivre les étapes suivantes :

Rails propose un générateur qui réalise toutes les étapes nécessaires pour vous.

Pour que votre application communique avec le service de base de données PostgreSQL fonctionnant dans OpenShift Container Platform, vous devez modifier la section default dans votre config/database.yml pour utiliser les variables d'environnement, que vous devez définir plus tard, lors de la création du service de base de données.

La construction d'une application dans OpenShift Container Platform nécessite généralement que le code source soit stocké dans un dépôt git, vous devez donc installer git si vous ne l'avez pas déjà.

Votre application Rails s'attend à ce qu'un service de base de données soit en cours d'exécution. Pour ce service, utilisez l'image de la base de données PostgreSQL.

Pour créer le service de base de données, utilisez la commande oc new-app. À cette commande, vous devez transmettre certaines variables d'environnement nécessaires qui sont utilisées dans le conteneur de la base de données. Ces variables d'environnement sont nécessaires pour définir le nom d'utilisateur, le mot de passe et le nom de la base de données. Vous pouvez modifier les valeurs de ces variables d'environnement comme bon vous semble. Les variables sont les suivantes :

La définition de ces variables garantit :

Pour apporter votre application à OpenShift Container Platform, vous devez spécifier un dépôt dans lequel votre application vit.

Vous pouvez exposer un service pour créer une route pour votre application.

Source-to-image (S2I) produit des images prêtes à être exécutées en injectant du code source dans un conteneur qui prépare ce code source à être exécuté. Il exécute les étapes suivantes :

Buildah crée ensuite l'image du conteneur.

Les images de construction fournissent leur propre version des scripts source-image (S2I) qui couvrent les cas d'utilisation les plus courants. Si ces scripts ne répondent pas à vos besoins, S2I permet de les remplacer en ajoutant des scripts personnalisés dans le répertoire .s2i/bin. Toutefois, ce faisant, vous remplacez complètement les scripts standard. Dans certains cas, le remplacement des scripts est acceptable, mais, dans d'autres scénarios, vous pouvez exécuter quelques commandes avant ou après les scripts tout en conservant la logique du script fourni dans l'image. Pour réutiliser les scripts standard, vous pouvez créer un script enveloppant qui exécute une logique personnalisée et délègue la suite du travail aux scripts par défaut de l'image.