Choix d'une solution de registre d'images

Vos images de conteneurs doivent être stockées dans un registre de conteneurs accessible à votre cluster afin de pouvoir y déployer des applications. Vous pouvez choisir d'utiliser le registre intégré de votre cluster Red Hat OpenShift, un registre privé avec accès réservé à des utilisateurs sélectionnés ou un registre public. Consultez le tableau suivant afin de choisir la meilleure option pour votre cas d'utilisation.

Registre Red Hat OpenShift Container Registry (OCR) interne

Votre cluster est configuré avec le registre d'images Red Hat OpenShift Container Registry interne pour qu'Red Hat OpenShift puisse générer, déployer et gérer automatiquement le cycle de vie de vos applications depuis le cluster. Les images sont stockées dans une unité de stockage de fichiers IBM Cloud classique qui est mise à disposition lors de la phase de création du cluster. Si vous avez besoin de plus de stockage, vous pouvez redimensionner cette unité. Cas d'utilisation :

• Flux d'images Red Hat OpenShift natives, génération et déploiement d'application traités par cluster.
• Partage possible des images entre tous les projets au sein du cluster, avec accès contrôlé via des rôles RBAC.
• Intégration du registre interne à d'autres produits Red Hat, tels que CloudForms pour obtenir des fonctions étendues, comme par exemple l'analyse de vulnérabilité.
• Option permettant d'exposer le registre interne avec une route afin que les utilisateurs puissent extraire des images du registre sur le réseau public.
• Option permettant de configurer le registre interne en vue d'extraire des images d'un registre privé tel qu'IBM Cloud Container Registry ou d'envoyer des images vers ce dernier.

Pour plus d'informations, voir Utilisation du registre interne.

Registre privé

Les registres privés sont un bon choix pour protéger vos images contre les utilisateurs non autorisés. Les registres privés peuvent être configurés par l'administrateur du cluster pour garantir que l'accès, les quotas de stockage, la sécurisation des images et d'autres fonctions fonctionnent comme prévu. Par défaut, votre cluster Red Hat OpenShift est intégré à la propriété IBM Cloud Container Registry privée via des secrets d'extraction d'image dans le projet default. IBM Cloud Container Registry est un registre privé multi-locataires hautement disponible pour stocker vos propres images. Vous pouvez également extraire des images fournies par IBM dans le registre icr.io global, ainsi que des logiciels sous licence depuis le registre habilité. IBM Cloud Container Registry vous permet de gérer des images pour plusieurs clusters grâce à l'intégration à IBM Cloud IAM et à la facturation. Avantages liés à l'utilisation d'IBM Cloud Container Registry avec le registre interne :

• Mise en cache d'images locales pour des générations plus rapides via le registre interne.
• Le flux d'images est visible pour les déploiements dans d'autres projets, si bien que vous n'avez pas à copier les secrets d'extraction dans chaque projet.
• Partage des images entre plusieurs clusters sans avoir à insérer ces images dans plusieurs registres.
• Analyse automatique de vulnérabilité des images.
• Contrôle d'accès via des règles IBM Cloud IAM et des registres régionaux distincts.
• Conservation des images sans nécessiter d'espace de stockage dans votre cluster ou d'unité de stockage associée. Vous pouvez également définir des règles pour gérer la quantité d'images afin d'éviter qu'elles n'occupent trop d'espace.
• Infrastructure VPC : utilisation du point de terminaison du service de registre privé afin que les clusters qui utilisent uniquement un point de terminaison de service de cloud privé puissent toujours accéder au registre.
• Définition de quotas de stockage et de trafic d'extraction d'images pour mieux contrôler le stockage, l'utilisation et la facturation des images.
• Extraction de contenu IBM sous licence à partir du registre autorisé.

Pour commencer, consultez les rubriques suivantes :

• Initiation à IBM Cloud Container Registry.
• Importation d'images depuis IBM Cloud Container Registry vers le flux d'images du registre interne.
• Utilisation d'IBM Cloud Container Registry.

Registre public

Les registres publics tels que Docker Hub constituent un moyen de partager des images entre les équipes, les entreprises, les clusters ou les fournisseurs de cloud. Certains registres publics peuvent également offrir un composant de registre privé. Cas d'utilisation :

• Insertion et extraction d'images sur le réseau public.
• Test rapide d'un conteneur entre les fournisseurs de cloud.
• Disparition du besoin de fonctionnalités de niveau entreprise telles que l'évaluation des vulnérabilités ou la gestion des accès.

Pour plus d'informations, consultez la documentation relative aux registres publics, comme Quay ou Docker Hub.

Stockage d'images dans les registres internes

Les clusters Red Hat OpenShift ont par défaut un registre interne. Les images contenues dans le registre interne sont sauvegardées, mais elles varient en fonction du fournisseur d'infrastructure de votre cluster Red Hat OpenShift on IBM Cloud.

Clusters classiques

Votre cluster Red Hat OpenShift est configuré par défaut avec un registre interne qui utilise File Storage for Classic comme stockage sous-jacent. Lorsque vous supprimez le cluster, le registre interne et ses images sont également supprimés. Si vous voulez conserver vos images, pensez à utiliser un registre privé, tel qu'IBM Cloud Container Registry, à sauvegarder vos images dans un stockage persistant, par exemple, Object Storage, ou à créer un cluster OCR (Red Hat OpenShift Container Registry) autonome distinct. Pour plus d'informations, voir la documentationRed Hat OpenShift.

Clusters de VPC

Le registre interne de votre cluster Red Hat OpenShift sauvegarde vos images dans un compartiment créé automatiquement au sein d'une instance IBM Cloud Object Storage de votre compte. Les données stockées dans le compartiment de stockage d'objets sont conservées même si vous supprimez le cluster. Une fois le cluster créé, vous ne pouvez plus supprimer ni dissocier le compartiment « IBM Cloud Object Storage » du cluster. Si vous prévoyez de créer un cluster sans registre interne s'appuyant sur COS, par exemple pour les environnements Financial Services Cloud d' IBM, vous devez omettre l'instance COS lors de la création du cluster. Pour plus d'informations, consultez la section « Création d'un cluster VPC sans compartiment Object Storage ».

Clusters Classic, VPC ou Satellite

Vous pouvez, si vous le souhaitez, configurer le registre interne pour qu’il stocke les données dans le répertoire « emptyDir » du nœud de travail sur lequel s’exécute le pod du registre interne. N'oubliez pas que ces données ne sont pas persistantes et qu'en cas de redémarrage du pod ou du noeud worker, les données stockées sont supprimées et irrécupérables. Vous pouvez stocker les images en local dans emptyDir afin d'améliorer les performances si vous générez régulièrement des conteneurs à partir d'images volumineuses.

oc describe pvc -n openshift-image-registry image-registry-storage

Suppression du registre d'images interne

Cloud privé virtuel

Les déploiements d'opérateurs de registre d'images ne sont présents que dans les Red Hat OpenShift on IBM Cloud clusters gérés par Toolkit. HyperShift Les clusters gérés exécutent l'opérateur du registre d'images dans le plan de contrôle.

Si vous ne souhaitez pas utiliser le registre d'images interne, vous pouvez effectuer les étapes suivantes pour le supprimer.

1. Sauvegardez une copie de vos configurations de registre interne.

   oc get configs.imageregistry.operator.openshift.io cluster -o yaml > configs.yaml
   

2. Exécutez la commande de correctif suivante pour remplacer l'état de gestion du registre d'images par Removed.

   kubectl patch configs.imageregistry.operator.openshift.io cluster -p '{"spec":{"managementState":"Removed"}}' --type='merge'
   

3. Une fois l'état de gestion modifié, le service de registre d'images et le déploiement sont supprimés de l'espace de nom openshift-image-registry dans votre cluster. Vous pouvez exécuter les commandes suivantes pour vérifier qu'elles ont été supprimées. Notez que seuls le déploiement et le service du registre d'images sont supprimés. Le déploiement et le service de l'opérateur du registre d'images sont conservés.

   oc get deployment -n openshift-image-registry
   

   oc get svc -n openshift-image-registry
   

Configuration d'une route externe sécurisée pour le registre interne

Par défaut, votre cluster Red Hat OpenShift dispose d'un registre interne disponible via un service avec une adresse IP interne. Si vous souhaitez rendre le registre interne disponible sur le réseau public, vous pouvez configurer une route de nouveau chiffrement sécurisée. Par exemple, vous pouvez configurer le registre interne de votre cluster de sorte qu'il agisse en tant que registre public pour les déploiements dans d'autres projets ou clusters.

Avant de commencer :

• Vérifiez que vous disposez du rôle d'accès au service IAM « Manager » IBM Cloud pour le cluster.
• Assurez-vous que votre cluster dispose d'une connectivité au réseau public afin d'exposer le registre interne avec une route publique.
• Installez Docker sur votre machine locale.
• Accédez à votre cluster Red Hat OpenShift.

Pour utiliser le registre interne, configurez une route publique pour accéder au registre. Créez ensuite un secret d'extraction d'image incluant les données d'identification permettant d'accéder au registre de sorte que les déploiements dans d'autres projets puissent extraire des images de ce registre.

1. A partir du projet openshift-image-registry, assurez-vous que le service image-registry existe pour le registre interne.

   oc get svc -n openshift-image-registry
   

   Exemple de sortie

   NAME                      TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                      AGE
   image-registry            ClusterIP      172.21.xxx.xxx    <none>          5000/TCP                     36d
   image-registry-operator   ClusterIP      None             <none>          60000/TCP                     36d
   

2. Créez une route sécurisée pour le service image-registry qui utilise la terminaison TLS reencrypt. Grâce au nouveau chiffrement, le routeur arrête la connexion TLS associée à un certificat, puis chiffre à nouveau la connexion au registre interne avec un autre certificat. Avec cette approche, le chemin complet de la connexion entre l'utilisateur et le registre interne est chiffré. Pour utiliser votre propre nom de domaine personnalisé, activez l'option « --hostname ».

   oc create route reencrypt --service=image-registry -n openshift-image-registry
   

3. Extrayez le nom d'hôte (HOST/PORT) et le port (PORT) qui ont été affectés à la route image-registry.

   oc get route image-registry -n openshift-image-registry
   

   Exemple de sortie

   NAME              HOST/PORT                                                                                                  PATH      SERVICES          PORT       TERMINATION   WILDCARD
   image-registry   image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud             image-registry   5000-tcp   reencrypt     None
   

4. Modifiez la route afin de définir la stratégie d'équilibrage de charge sur « source » (transfert direct), de sorte que la même adresse IP client soit toujours dirigée vers le même serveur, comme dans une configuration de route de transfert direct. Vous pouvez définir la stratégie en ajoutant une annotation dans la section metadata.annotations : haproxy.router.openshift.io/balance: source. Vous pouvez éditer le fichier de configuration à partir de la console d'application Red Hat OpenShift ou de votre ligne de commande en exécutant la commande suivante :

   oc edit route image-registry -n openshift-image-registry
   

   Add the annotation.

   apiVersion: route.openshift.io/v1
   kind: Route
   metadata:
   annotations:
       haproxy.router.openshift.io/balance: source
   ...
   

5. Si les règles réseau de l'entreprise empêchent l'accès depuis votre système local à des noeuds finaux publics via des proxys ou des pare-feux, autorisez l'accès au sous-domaine de route que vous créez pour le registre interne dans les étapes ci-après.

6. Connectez-vous au registre interne en utilisant la route comme nom d'hôte.

   docker login -u $(oc whoami) -p $(oc whoami -t) image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud
   

7. Maintenant que vous êtes connecté, essayez d'envoyer un exemple d'application hello-world au registre interne.

   1. Extrayez l'image hello-world de DockerHub, ou générez une image sur votre machine locale.

       docker pull hello-world
       ```
   1. Attribuez à l'image locale une étiquette comportant le nom d'hôte de votre registre interne, le projet sur lequel vous souhaitez déployer l'image ainsi que le nom et l'étiquette d'image.
   
   ```sh {: pre}
       docker tag hello-world:latest image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud/<project>/<image_name>:<tag>
       ```
   1. Envoyez l'image au registre interne de votre cluster.
   
   ```sh {: pre}
       docker push image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud/<project>/<image_name>:<tag>
       ```
   4. Vérifiez que l'image est ajoutée au flux d'images Red Hat OpenShift.
   
   ```sh {: pre}
       oc get imagestream
       ```
       Exemple de sortie
   
       ```sh {: screen}
       NAME          DOCKER REPO                                                            TAGS      UPDATED
       hello-world   image-registry-openshift-image-registry.svc:5000/default/hello-world   latest    7 hours ago
       ```
   

8. Pour permettre aux déploiements de votre projet d'extraire des images du registre interne, créez un secret d'extraction d'image dans votre projet qui détient les données d'identification permettant d'accéder à votre registre interne. Ajoutez ensuite le secret d'extraction d'image au compte de service par défaut pour chaque projet.

   1. Répertoriez les secrets d'extraction d'image utilisés par le compte de service par défaut et notez le secret qui commence par default-dockercfg.

       oc describe sa default
       ```
       Exemple de sortie
   
       ```sh {: screen}
       ...
       Image pull secrets:
       all-icr-io
       default-dockercfg-mpcn4
       ...
       ```
   1. Obtenez les informations sur le secret codé dans la zone `data` du fichier de configuration.
   
   ```sh {: pre}
       oc get secret <default-dockercfg-name> -o yaml
       ```
       Exemple de sortie
   
       ```yaml {: screen}
       apiVersion: v1
       data:
         .dockercfg: ey...=
       ```
   1. Décodez la valeur de la zone `data`.
   
   ```sh {: pre}
       echo "<ey...=>" | base64 -D
       ```
       Exemple de sortie
   
       ```sh {: screen}
       {"172.21.xxx.xxx:5000":{"username":"serviceaccount","password":"eyJ...
       ```
   4. Créez un nouveau secret d'extraction d'image pour le registre interne.
   
       - `secret_name` : donnez un nom à votre secret d'extraction d'image, par exemple `internal-registry`.
       - `--namespace` : entrez le projet dans lequel créer le secret d'extraction d'image, par exemple `default`.
       - `--docker-server`: Au lieu de l'adresse IP du service interne (`172.21.xxx.xxx:5000`), entrez le nom d'hôte de la route `image-registry` avec le port (`image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud:5000`).
       - `--docker-username` : copiez la valeur `"username"` à partir du secret d'extraction d'image, par exemple `serviceaccount`.
       - `--docker-password` : copiez la valeur `"password"` à partir du secret d'extraction d'image précédent.
       - `--docker-email` : si vous possédez une adresse e-mail Docker, entrez-la. Dans le cas contraire, entrez une adresse e-mail fictive, telle que `a@b.c`. Cette adresse e-mail est obligatoire pour créer un secret Kubernetes, mais n'est plus utilisée une fois la valeur créée.
   
   ```sh {: pre}
       oc create secret docker-registry internal-registry --namespace default --docker-server image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud:5000 --docker-username serviceaccount --docker-password <eyJ...> --docker-email a@b.c
       ```
   5. Ajoutez le secret d'extraction d'image au compte de service par défaut pour votre projet.
   
   ```sh {: pre}
       oc patch -n <namespace_name> serviceaccount/default --type='json' -p='[{"op":"add","path":"/imagePullSecrets/-","value":{"name":"<image_pull_secret_name>"}}]'
       ```
   6. Répétez ces étapes pour chaque projet pour lequel vous souhaitez extraire des images à partir du registre interne.
   
   

Maintenant que vous avez configuré le registre interne avec une route accessible, vous pouvez vous connecter au registre et y insérer ou en extraire des images. Pour plus d'informations, voir la documentationRed Hat OpenShift.

Importation d'images à partir d'IBM Cloud Container Registry dans le flux d'images du registre interne

Par défaut, votre cluster Red Hat OpenShift on IBM Cloud est configuré pour extraire des images des domaines IBM Cloud Container Registry icr.io privés distants dans le projet default. Vous pouvez importer une image depuis IBM Cloud Container Registry dans le registre interne de votre cluster Red Hat OpenShift en associant un tag à cette image en tant que flux d'images. Avec cette configuration, vous pouvez déployer des applications à partir de l'image en utilisant le cache local du registre interne, ce qui permet d'accélérer la génération des déploiements. De plus, les déploiements dans d'autres projets peuvent se référer au flux d'images afin que vous n'ayez pas à créer des données d'identification de secret d'extraction d'image pour IBM Cloud Container Registry dans chaque projet.

Si vous mettez à jour votre image dans IBM Cloud Container Registry, l'image n'est pas automatiquement extraite dans le registre interne de votre cluster Red Hat OpenShift. Vous pouvez également configurer une importation périodique ou répéter ces étapes pour ajouter un tag à l'image. En fonction de la stratégie d'extraction d'image que vous utilisez dans votre déploiement, vous devrez peut-être redémarrer votre déploiement.

Vous voulez en savoir plus sur la façon dont les générations, les flux d'images et le registre interne fonctionnent conjointement ? Lisez la Red Hat OpenShift documentation ou consultez ce blog sur la gestion des images de conteneurs.

1. Accédez à votre cluster Red Hat OpenShift.

2. Passez au projet default pour extraire votre image et l'insérer dans le flux d'images. Le projet default est déjà configuré avec des données d'identification permettant d'accéder aux registres icr.io.

   oc project default
   

3. Répertoriez les images disponibles dans votre IBM Cloud Container Registry. Notez le référentiel et l'étiquette de l'image que vous souhaitez extraire dans le registre interne de votre cluster Red Hat OpenShift.

   ibmcloud cr images
   

4. Balisez l'image pour l'extraire de votre espace de noms IBM Cloud Container Registry et l'insérer dans le registre interne en tant que flux d'images. Pour plus d'informations, consultez la documentation de Red Hat OpenShift ou exécutez oc tag --help.

   oc tag <region>.icr.io/<namespace>/<image>:<tag> default/<image>:<tag> --reference-policy=local [--scheduled]
   

   • <region>.icr.io/<namespace>/<image>:<tag>: Utilisez les informations relatives au référentiel et à la balise que vous avez précédemment récupérées pour renseigner les champs « IBM Cloud Container Registry » (région), « namespace » (espace de noms), « image » (image) et « tag name » (nom de la balise) correspondant à l'image que vous souhaitez récupérer.
   • default/<image>:<tag> : Entrez les informations relatives au flux d'images internes que vous créez à partir de l'image marquée IBM Cloud Container Registry. Ce flux d'images est à créer dans le projet default, qui est également le projet dans lequel le flux d'images est créé si vous ne spécifiez aucun projet. Les valeurs de : correspondent généralement à celles que vous avez récupérées précédemment.
   • --reference-policy=local : définissez cette valeur sur local pour qu'une copie de l'image provenant d'IBM Cloud Container Registry soit importée dans le cache local du registre interne et mise à la disposition des projets du cluster en tant que flux d'images. Si vous n'incluez pas cette valeur, le flux d'images se reporte à nouveau à IBM Cloud Container Registry lorsque vous l'utilisez dans vos déploiements et nécessite donc des données d'identification dans le projet.
   • --scheduled: Activez cette option facultative pour configurer l'importation périodique de l'image depuis IBM Cloud Container Registry vers le registre interne. La fréquence par défaut est de 15 minutes. Pour plus d'informations, voir la documentationRed Hat OpenShift.

5. Vérifiez que votre flux d'images a été créé.

   oc get imagestreams
   

6. Vérifiez que le flux d'images a réussi à extraire l'image d'IBM Cloud Container Registry. Dans la sortie, vérifiez que l'image de la dernière balise à partir de correspond à votre image * <region>.icr.io/<namespace>/<image>@<digest>.

   oc describe is/<imagestream>
   

   Exemple de sortie

   NAME:            <imagestream>
   Namespace:        default
   Created:        2 days ago
   Labels:            <none>
   Annotations:        openshift.io/image.dockerRepositoryCheck=2020-03-31T09:41:36Z
   Image Repository:    image-registry.openshift-image-registry.svc:5000/default/ant1
   Image Lookup:        local=false
   Unique Images:        1
   Tags:                1
   latest
       tagged from <region>.icr.io/<namespace>/<image>:<tag>
       * <region>.icr.io/<namespace>/<image>@<digest>
           2 days ago
   

Désormais, vos développeurs peuvent utiliser le flux d'images dans un déploiement d'application. L'image est générée à partir de l'image extraite localement dans le registre interne. Il n'est pas nécessaire de définir un secret d'extraction d'image dans le projet sur IBM Cloud Container Registry car le flux d'images est local pour le cluster.

Configuration de générations dans le registre interne pour envoyer des images vers IBM Cloud Container Registry

Lorsque vous créez une build dans votre Red Hat OpenShift on IBM Cloud cluster, vous pouvez configurer le registre interne pour pousser l'image vers votre référentiel externe dans IBM Cloud Container Registry. Par défaut, le secret d'extraction d'image dans le projet default de votre cluster ne dispose que d'un accès en lecture pour extraire des images depuis IBM Cloud Container Registry. Pour envoyer des images, vous devez ajouter un secret doté d'un accès en écriture.

1. Accédez à votre cluster Red Hat OpenShift.

2. Passez au projet default.

   oc project default
   

3. Suivez les étapes de configuration d'une clé d'API IBM Cloud IAM avec les rôles d'accès au service Reader et Writer pour extraire et envoyer des images depuis et vers vos registres icr.io.

   Gardez à l'esprit que tout utilisateur ayant accès au projet peut utiliser ce secret pour envoyer des images vers votre registre privé. Vous souhaiterez peut-être configurer les outils de journalisation et de surveillance afin de pouvoir observer qui effectue quelles actions dans votre cluster.

4. Répétez l'étape précédente pour chaque région icr.io vers laquelle vous souhaitez envoyer des images.

5. Ajoutez le secret au compte de service de génération et faites référence aux secrets dans le fichier de configuration de génération. Pour plus d'informations, voir la documentationRed Hat OpenShift.

   1. Ajoutez le secret au compte de service de génération en liant le secret que vous venez de créer au rôle builder qui est utilisé par toutes les générations du cluster.

       oc secrets link builder <secret_name>
       ```
   1. Répertoriez les configurations de génération et notez celles auxquelles vous souhaitez octroyer un accès d'envoi et d'extraction à IBM Cloud Container Registry.
   
   ```sh {: pre}
       oc get bc
       ```
   1. Définissez le secret d'envoi d'image pour que la configuration de génération utilise le secret que vous venez de créer avec l'accès au service `Writer` à IBM Cloud Container Registry.
   
   ```sh {: pre}
       oc set build-secret --push bc/<build_config_name> <secret_name>
       ```
   4. Définissez le secret d'extraction d'image pour que la configuration de génération soit extraite du registre à partir duquel vous souhaitez extraire l'image de génération initiale. Par exemple, vous pouvez utiliser le secret que vous venez de créer avec l'accès au service `Reader` à IBM Cloud Container Registry si l'image source se trouve dans un référentiel IBM Cloud Container Registry.
   
   ```sh {: pre}
       oc set build-secret --pull bc/<build_config_name> <secret_name>
       ```
   

6. Après avoir mis à jour le compte de service de génération et le fichier de configuration de génération à envoyer à IBM Cloud Container Registry, redémarrez votre génération.

   oc start-build <build_name>
   

7. Obtenez le nom de votre pod de génération, tel que <build>-2-build.

   oc get pods
   

8. Consultez les journaux de la génération et notez l'emplacement où l'image a été envoyée.

   oc logs <build_pod>
   

   Exemple de journal lorsqu'un envoi d'image aboutit.

   ...
   Successfully pushed <region>.icr.io/<namespace>/<build_name>@sha256:<hash>
   Push successful
   

9. Vérifiez vos images dans votre registre privé pour confirmer que l'image a été créée.

   ibmcloud cr image list
   

   Exemple de sortie

   Repository                                Tag       Digest     Namespace     Created         Size     Security status   
   <region>.icr.io/<namespace>/<build_name>  latest    <digest>   <namespace>   2 minutes ago   182 MB   33 Issues  
   

Votre génération Red Hat OpenShift peut désormais extraire et envoyer des images depuis et vers IBM Cloud Container Registry.

Utilisation d'IBM Cloud Container Registry

Par défaut, votre cluster Red Hat OpenShift on IBM Cloud est configuré pour extraire des images des domaines IBM Cloud Container Registry icr.io privés distants dans le projet default. Si vous souhaitez utiliser des images qui sont stockées dans IBM Cloud Container Registry pour d'autres projets, vous pouvez extraire l'image sur le registre interne d'un flux d'images ou créer des secrets d'extraction d'image pour chaque registre global et régional dans chaque projet.

Pour importer des images dans le registre interne, voir Importation d'images à partir d'IBM Cloud Container Registry dans le flux d'images de registre interne.

Pour extraire des images directement à partir d'IBM Cloud Container Registry externe, voir les rubriques ci-après.

• Comment autoriser votre cluster à extraire des images d'un registre ?
• Copie du secret all-icr-io du projet default vers le projet d'où vous souhaitez extraire des images.
• Création de votre propre secret d'extraction d'image.
• Ajout du secret d'extraction d'image à votre configuration de déploiement ou au compte de service du projet.

Comment autoriser votre cluster à extraire des images d'un registre privé ?

Pour extraire des images d'un registre, votre cluster Red Hat OpenShift on IBM Cloud utilise un type spécial de secret Kubernetes, imagePullSecret. Ce secret d'extraction d'image stocke les données d'identification permettant d'accéder à un registre de conteneur.

Le registre de conteneur peut être :

• Un espace de noms privé dans votre propre IBM Cloud Container Registry.
• Un espace de noms privé dans IBM Cloud Container Registry qui appartient à un autre compte IBM Cloud.
• N'importe quel autre registre privé, tel que Docker.

Toutefois, par défaut, votre cluster est configuré pour extraire des images des espaces de nom de votre compte dans IBM Cloud Container Registryet déployer des conteneurs à partir de ces images vers le projet default Red Hat OpenShift de votre cluster. Si vous devez extraire des images dans d'autres projets du cluster ou à partir d'autres registres de conteneur, vous devez configurer vos propres secrets d'extraction d'image.

Mise à jour de clusters existants pour utiliser le secret d'extraction d'image de la clé d'API

Les nouveaux clusters Red Hat OpenShift on IBM Cloud stockent une clé d'API dans des secrets d'extraction d'image pour autoriser l'accès à IBM Cloud Container Registry. Avec ces secrets d'extraction d'image, vous pouvez déployer des conteneurs à partir d'images stockées dans les domaines de registre icr.io. Vous pouvez ajouter les secrets d'extraction d'image à votre cluster si celui-ci n'a pas été créé avec les secrets.

Avant de commencer

1. Accédez à votre cluster Red Hat OpenShift.

2. Vérifiez que vous disposez des droits suivants : rôle d'accès à la plateforme IBM Cloud IAM Opérateur ou Administrateur pour Red Hat OpenShift on IBM Cloud. Le propriétaire de compte peut vous octroyer le rôle en exécutant la commande ci-après.

   ibmcloud iam user-policy-create EMAIL --service-name containers-kubernetes --roles "Administrator,Operator"
   

3. Rôle d'accès à la plateforme IBM Cloud IAM Administrateur pour IBM Cloud Container Registry, sur toutes les régions et tous les groupes de ressources. La portée de la règle ne peut pas être définie pour une région ou un groupe de ressources particulier. Le propriétaire de compte peut vous octroyer le rôle en exécutant la commande ci-après.

   Vérifiez que la clé secrète a bien été créée

   ibmcloud iam user-policy-create YOUR_USER_EMAIL --service-name container-registry --roles Administrator
   

4. Si votre compte limite la création d'ID de service, ajoutez le rôle Créateur d'ID de service à la gestion des identités et des accès (IAM) dans la console (iam-identity dans l'API ou l'interface de ligne de commande).

5. Si votre compte limite la création de clé d'API, ajoutez le rôle Créateur de clé d'API d'utilisateur à la gestion des identités et des accès (IAM) dans la console (iam-identity dans l'API ou l'interface de ligne de commande).

Utilisation d'un secret de récupération d'images pour accéder aux images stockées dans des registres privés externes

Configurez votre propre secret d'extraction d'image dans votre cluster pour déployer des conteneurs dans d'autres projets Red Hat OpenShift que default, utiliser des images stockées dans d'autres comptes IBM Cloud ou dans des registres privés externes. Par ailleurs, vous pouvez créer votre propre secret d'extraction d'image pour appliquer des règles d'accès IAM limitant les droits à des espaces de noms d'image de registre ou des actions (telles que push ou pull) spécifiques.

Une fois que vous avez créé le secret d'extraction d'image, vous conteneurs doivent utiliser le secret pour être autorisés à extraire une image du registre. Vous pouvez ajouter le secret d'extraction d'image au compte de service correspondant au projet ou faire référence au secret dans chaque déploiement. Pour obtenir des instructions, voir Utilisation de secret d'extraction d'image pour déployer des conteneurs.

Les secrets d'extraction d'image sont valides uniquement pour les projets Red Hat OpenShift pour lesquels ils ont été créés. Répétez ces étapes pour chaque espace de noms dans lequel vous désirez déployer des conteneurs.

Avant de commencer :

1. Configurez un espace de noms dans IBM Cloud Container Registry et envoyez des images dans cet espace de noms.
2. Créez un cluster.
3. Accédez à votre cluster Red Hat OpenShift.

Pour utiliser votre propre secret d'extraction d'image, choisissez parmi les options suivantes :

• Copier le secret d'extraction d'image du projet Red Hat OpenShift "default" dans d'autres projets de votre cluster.
• Créer de nouvelles données d'identification de clé d'API IAM et les stocker dans un secret d'extraction d'image pour accéder à des images dans d'autres comptes IBM Cloud ou pour appliquer des règles IAM limitant l'accès à certains domaines ou espaces de noms de registre.
• Créer un secret d'extraction d'image pour accéder aux images dans des registres privés externes.

Si vous avez déjà créé un secret d'extraction d'image dans votre projet et que vous voulez utiliser cette valeur dans votre déploiement, voir Déploiement de conteneurs en utilisant le secret imagePullSecret créé.

Utilisation de secret d'extraction d'image pour déployer des conteneurs

Vous pouvez définir une image de retrait d'image dans votre déploiement de pod ou stocker le secret d'extraction d'image dans votre compte de service Kubernetes de sorte qu'il soit disponible pour tous les déploiements qui ne spécifient pas de compte de service Kubernetes dans le projet.

Pour planifier l'utilisation des secrets d'extraction d'image dans votre cluster, choisissez l'une des options suivantes :

• En vous référant au secret d'extraction de l'image dans votre déploiement de pod : utilisez cette option si vous ne souhaitez pas accorder l'accès à votre registre pour tous les pods de votre projet par défaut. Les développeurs peuvent inclure le secret d'extraction d'image dans chaque déploiement de pod qui doit accéder à votre registre.
• Stocker le secret d'extraction d'image dans le compte de service Kubernetes : utilisez cette option pour octroyer l'accès aux images de votre registre pour tous les déploiements dans les projets Red Hat OpenShift sélectionnés. Pour stocker un secret d'extraction d'image dans le compte de service Kubernetes, suivez les étapes décrites ci-après.

Configuration d'un cluster pour extraire un logiciel autorisé

Vous pouvez configurer votre cluster Red Hat OpenShift on IBM Cloud pour extraire un logiciel autorisé, collection d'images de conteneur protégées mises en package dans des chartes Helm qu'IBM vous autorise à utiliser au moyen d'une licence. Le logiciel autorisé est stocké dans un domaine IBM Cloud Container Registry spécial, nommé cp.icr.io. Pour accéder à ce domaine, vous devez créer un secret d'extraction d'image avec une clé d'autorisation pour votre cluster et ajouter ce secret au compte de service Kubernetes de chaque projet dans lequel vous souhaitez déployer ce logiciel autorisé.

Avant de commencer : accédez à votre cluster Red Hat OpenShift.

1. Procurez-vous la clé d'autorisation pour votre bibliothèque de logiciels autorisés.

   1. Connectez-vous à MyIBM.com et faites défiler la page jusqu'à la section « Bibliothèque de logiciels pour conteneurs ». Cliquez sur Afficher la bibliothèque.
   2. Sur la page « Accéder à votre logiciel de conteneurs > Clés d'autorisation », cliquez sur « Copier la clé ». Cette clé autorise l'accès à tous les logiciels autorisés de votre bibliothèque de logiciels de conteneur.

2. Dans le projet où vous souhaitez déployer vos conteneurs autorisés, créez un secret d'extraction d'image afin de pouvoir accéder au registre autorisé cp.icr.io. Utilisez la clé d'autorisation que vous avez précédemment extraite comme valeur --docker-password. Pour plus d'informations, voir Accès aux images stockées dans d'autres registres privés.

   oc create secret docker-registry entitled-cp-icr-io --docker-server=cp.icr.io --docker-username=cp --docker-password=<entitlement_key> --docker-email=<docker_email> -n <project>
   

3. Ajoutez le secret d'extraction d'image au compte de service de l'espace de noms de sorte que tous les conteneurs du projet puissent utiliser la clé d'autorisation afin d'extraire les images autorisées. Pour plus d'informations, voir Utilisation du secret d'extraction d'image pour déployer des conteneurs.

   oc patch -n <project> serviceaccount/default --type='json' -p='[{"op":"add","path":"/imagePullSecrets/-","value":{"name":"entitled-cp-icr-io"}}]'
   

4. Créez un pod dans le projet qui génère un conteneur à partir d'une image dans le registre autorisé.

   oc run <pod_name> --image=cp.icr.io/<image_name> -n <project> --generator=run-pod/v1
   

5. Vérifiez que votre conteneur a pu être correctement généré à partir de l'image autorisée en vérifiant que le pod est à l'état En cours d'exécution (Running).

   oc get pod <pod_name> -n <project>
   

Que faire ensuite ? Vous pouvez configurer le référentiel de chartes Helm entitled, où sont stockées les chartes Helm qui intègrent les logiciels autorisés. Si Helm est déjà installé dans votre cluster, exécutez helm repo add entitled https://raw.githubusercontent.com/IBM/charts/master/repo/entitled.

Ajout d'un registre privé au secret d'extraction global

Nœuds de travail RHEL

Dans les clusters qui utilisent exclusivement des nœuds de travail RHEL, vous pouvez configurer un secret global de récupération d'images que chaque nœud de travail du cluster peut utiliser pour récupérer des images depuis un registre privé.

Par défaut, votre cluster Red Hat OpenShift on IBM Cloud comporte un secret d'extraction d'image global pour les registres suivants, de sorte que les composants Red Hat OpenShift par défaut puissent être déployés :

• cloud.openshift.com
• quay.io
• registry.connect.redhat.com
• registry.redhat.io

Ne remplacez pas le secret d'extraction global par un secret d'extraction qui ne possède pas de données d'identification permettant d'accéder aux registres Red Hat par défaut. Si vous le faites, les composants Red Hat OpenShift par défaut qui sont installés dans votre cluster, tel que OperatorHub, peuvent échouer car ils ne peuvent pas extraire des images de ces registres.

Avant de commencer :

• Téléchargez le package de ligne de commande du processeur JSON « jq ». Vous utilisez jq pour combiner la valeur JSON du secret d'extraction global par défaut avec le secret d'extraction de registre privé que vous souhaitez ajouter.
• Accédez à votre cluster Red Hat OpenShift.

Pour ajouter des registre privés, éditez l'élément pull-secret global dans le projet openshift-config.

1. Créez une valeur de secret qui contient les données d'identification permettant d'accéder à votre registre privé et de stocker la valeur de secret décodée dans un fichier JSON. Lorsque vous créez la valeur de secret, les données d'identification sont automatiquement codées en base64. Si vous utilisez --dry-run, seule la valeur de secret est créée et aucun objet secret n'est créé dans votre cluster. La valeur de secret décodée est ensuite stockée dans un fichier JSON afin d'être utilisée ultérieurement dans votre secret d'extraction global.

   oc create secret docker-registry <secret_name> --docker-server=<registry_URL> --docker-username=<docker_username> --docker-password=<docker_password> --docker-email=<docker_email> --dry-run=true --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode > myregistryconfigjson
   

   --namespace <project>

   Obligatoire. Projet Red Hat OpenShift de votre cluster dans lequel vous désirez utiliser le secret et déployer des conteneurs. Pour afficher la liste des projets disponibles dans votre cluster, exécutez la commande oc get ns.

   <secret_name>

   Obligatoire. Nom que vous désirez utiliser comme secret d'extraction d'image.

   --docker-server <registry_URL>

   Obligatoire. URL du registre dans lequel sont stockées vos images privées.

   --docker-username <docker_username>

   Obligatoire. Nom d'utilisateur pour vous connecter à votre registre privé.

   --docker-password <token_value>

   Obligatoire. Mot de passe pour vous connecter à votre registre privé, par exemple, une valeur de jeton.

   --docker-email <docker-email>

   Obligatoire. Si vous en avez une, entrez votre adresse e-mail Docker. Si vous n'en avez pas, entrez une adresse e-mail fictive, telle que a@b.c. Cette adresse e-mail est obligatoire pour créer un secret Kubernetes, mais n'est plus utilisée une fois la valeur créée.

   --dry-run=true

   Sélectionnez cette option pour créer uniquement la valeur du secret, sans créer ni stocker l'objet secret dans votre cluster.

   --output="jsonpath={.data.\.dockerconfigjson}"

   Obtenez uniquement la valeur .dockerconfigjson à partir de la section data du secret Kubernetes.

   | base64 --decode > myregistryconfigjson

   Téléchargez les données de secret décodées dans un fichier myregistryconfigjson local.

2. Extrayez la valeur de secret décodée du secret d'extraction global par défaut et stockez la valeur dans un fichier dockerconfigjson.

   oc get secret pull-secret -n openshift-config --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode > dockerconfigjson
   

3. Combinez le fichier myregistryconfigjson du secret d'extraction de registre privé téléchargé au fichier dockerconfigjson du secret d'extraction global par défaut.

   jq -s '.[0] * .[1]' dockerconfigjson myregistryconfigjson > dockerconfigjson-merged
   

4. Mettez à jour le secret d'extraction global avec le fichier dockerconfigjson-merged combiné.

   oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=dockerconfigjson-merged
   

5. Vérifiez que le secret d'extraction global a été mis à jour. Assurez-vous que votre registre privé et chacun des registres Red Hat par défaut figurent dans la sortie de la commande ci-après.

   oc get secret pull-secret -n openshift-config --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode
   

   Exemple de sortie

   {
       "auths": {
           "cloud.openshift.com": {
               "auth": "<encoded_string>",
               "email": "email@example.com"
           },
           "quay.io": {
               "auth": "<encoded_string>",
               "email": "email@example.com"
           },
           "registry.connect.redhat.com": {
               "auth": "<encoded_string>",
               "email": "email@example.com"
           },
           "registry.redhat.io": {
               "auth": "<encoded_string>",
               "email": "email@example.com"
           },
           "<private_registry>": {
               "username": "iamapikey",
               "password": "<encoded_string>",
               "email": "email@example.com",
               "auth": "<encoded_string>"
           }
       }
   }
   

6. Pour sélectionner les modifications de configuration globales, rechargez tous les nœuds worker de votre cluster.

   1. Notez l'ID des noeuds worker de votre cluster.

       ibmcloud oc worker ls -c <cluster_name_or_ID>
       ```
   1. **Pour les clusters classiques** Rechargez chaque noeud worker. Vous pouvez recharger plusieurs nœuds de travail en spécifiant plusieurs options « `-w` », mais veillez à laisser suffisamment de nœuds de travail en cours d'exécution simultanément pour vos applications afin d'éviter toute interruption de service.
   
   ```sh {: pre}
       ibmcloud oc worker reload -c <cluster_name_or_ID> -w <workerID_1> -w <workerID_2>
       ```
   1. **Pour les clusters de VPC** Remplacez chaque noeud worker. Avant de commencer, vérifiez votre cluster dispose de suffisamment d'autres noeuds worker pour que vos pods puissent être replanifiés et continuent à s'exécuter.
   
   ```sh {: pre}
       ibmcloud oc worker replace --cluster <cluster_name_or_ID> --worker <worker_node_ID>
       ```
   
   

7. Une fois les noeuds worker de nouveau à un état sain, vérifiez que le secret d'extraction global est mis à jour sur un noeud worker.

   1. Démarrez un pod de débogage pour vous connecter à un noeud worker. Utilisez l'IP privée que vous avez extrait précédemment pour <node_name>.

       oc debug node/<node_name>
       ```
   1. Remplacez le répertoire racine par l'hôte de manière à pouvoir visualiser les fichiers du noeud worker.
   
   ```sh {: pre}
       chroot /host
       ```
   1. Vérifiez que le fichier de configuration Docker comporte les données d'identification de registre correspondant au secret d'extraction global que vous avez défini.
   
   ```sh {: pre}
       vi /.docker/config.json
       ```
   

Mise à jour du secret global de récupération

Nœuds de travail RHCOS Nœuds de travail RHEL

Dans les clusters qui utilisent des travailleurs RHCOS ou une combinaison de travailleurs RHCOS et RHEL, vous pouvez suivre les étapes suivantes pour mettre à jour le secret d'extraction global dans votre cluster Red Hat OpenShift on IBM Cloud.

Par défaut, votre cluster Red Hat OpenShift on IBM Cloud comporte un secret d'extraction d'image global pour les registres suivants, de sorte que les composants Red Hat OpenShift par défaut puissent être déployés :

• cloud.openshift.com
• quay.io
• registry.connect.redhat.com
• registry.redhat.io

Ne remplacez pas le secret d'extraction global par un secret d'extraction qui ne possède pas de données d'identification permettant d'accéder aux registres Red Hat par défaut. Si vous le faites, les composants Red Hat OpenShift par défaut qui sont installés dans votre cluster, tel que OperatorHub, peuvent échouer car ils ne peuvent pas extraire des images de ces registres.

1. Créez un secret contenant les informations d'identification du registre que vous souhaitez utiliser.

   oc create secret docker-registry docker-auth-secret \
   --docker-server=REGISTRY \
   --docker-username=USERNAME \
   --docker-password=PASSWORD \
   --namespace kube-system
   

2. Créez un DaemonSet pour appliquer le secret à tous les nœuds de travail.

   ocp_release_pull_secret_image=$(oc get ds -n openshift-dns node-resolver -o jsonpath='{.spec.template.spec.containers[0].image}')
   cat << EOF | oc create -f -
   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
     name: update-docker-config
     namespace: kube-system
     labels:
       app: update-docker-config
   spec:
     selector:
       matchLabels:
         name: update-docker-config
     template:
       metadata:
         labels:
           name: update-docker-config
       spec:
         initContainers:
           - command: ["/bin/sh", "-c"]
             args:
               - >
                 echo "Checking if RHEL or RHCOS host";
                 [[ -s /docker-config/.docker/config.json  ]] && CONFIG_PATH=/docker-config/.docker || CONFIG_PATH=/docker-config/root/.docker;
                 echo "Backing up or restoring config.json";
                 [[ -s \$CONFIG_PATH/config.json ]] && cp \$CONFIG_PATH/config.json \$CONFIG_PATH/config.json.bak || cp \$CONFIG_PATH/config.json.bak \$CONFIG_PATH/config.json;
                 echo "Merging secret with config.json";
                 /host/usr/bin/jq -s '.[0] * .[1]' \$CONFIG_PATH/config.json /auth/.dockerconfigjson > \$CONFIG_PATH/config.tmp;
                 mv \$CONFIG_PATH/config.tmp \$CONFIG_PATH/config.json;
                 echo "Sending signal to reload crio config";
                 pidof crio;
                 kill -1 \$(pidof crio)
             image: ${ocp_release_pull_secret_image}
             imagePullPolicy: IfNotPresent
             name: updater
             resources: {}
             securityContext:
               privileged: true
             volumeMounts:
               - name: docker-auth-secret
                 mountPath: /auth
               - name: docker
                 mountPath: /docker-config
               - name: bin
                 mountPath: /host/usr/bin
               - name: lib64
                 mountPath: /lib64
         containers:
           - resources:
               requests:
                 cpu: 0.01
             image: ${ocp_release_pull_secret_image}
             name: sleepforever
             command: ["/bin/sh", "-c"]
             args:
               - >
                 while true; do
                   sleep 100000;
                 done
         hostPID: true
         volumes:
           - name: docker-auth-secret
             secret:
               secretName: docker-auth-secret
           - name: docker
             hostPath:
               path: /
           - name: bin
             hostPath:
               path: /usr/bin
           - name: lib64
             hostPath:
               path: /lib64
               hostPathType: Directory
   EOF
   

3. Vérifiez que les pods sont en cours d'exécution.

   oc get daemonset -n kube-system update-docker-config
   

Mise à jour d'une configuration de registre personnalisé containeurisé IBM Cloud Kubernetes Service

Avec Kubernetes version 1.22 ou ultérieure, vous pouvez utiliser des fichiers de configuration conteneurisé sur les nœuds worker pour configurer le retrait à partir d'un registre de conteneur. Vous pouvez utiliser une définition de démon pour mettre à jour les configurations sur tous les nœuds d'un cluster, ce qui empêche les configurations d'être supprimées lorsque des nœuds worker rechargent ou lorsque de nouveaux travailleurs sont ajoutés.

server = "https://docker.io"
[host."https://registry-1.docker.io"]
capabilities = ["pull", "resolve"]

apiVersion: apps/v1
kind: DaemonSet
metadata:
labels:
    name: containerd-dockerhub-registry-config
name: containerd-dockerhub-registry-config
namespace: kube-system
spec:
selector:
    matchLabels:
    name: containerd-dockerhub-registry-config
template:
    metadata:
    labels:
        name: containerd-dockerhub-registry-config
    spec:
    initContainers:
    - image: alpine:3.13.6
        name: containerd-dockerhub-registry-config
        command:
        - /bin/sh
        - -c
        - |
            #!/bin/sh
            set -uo pipefail
            cat << EOF > /etc/containerd/certs.d/docker.io/hosts.toml
            server = "https://docker.io"
            [host."https://registry-1.docker.io"]
            capabilities = ["pull", "resolve"]
            EOF
        volumeMounts:
        - mountPath: /etc/containerd/certs.d/docker.io/
        name: dockerhub-registry-config
    containers:
    - name: pause
        image: "us.icr.io/armada-master/pause:3.5"
        imagePullPolicy: IfNotPresent
    volumes:
    - name: dockerhub-registry-config
        hostPath:
        path: /etc/containerd/certs.d/docker.io/