Pour un avenir plus sécurisé : gestion des installations déconnectées Red Hat OpenShift à l'aide d'un programme d'installation avec agent

Dans le paysage numérique actuel, il est plus important que jamais d'assurer la fiabilité et la conformité de la sécurité. Pour les entreprises qui ne tirent pas parti de connectivité Internet ou qui se contentent d'une connectivité limitée, le choix entre une installation Red Hat OpenShift standard et une installation déconnectée, ou air gap, peut s'avérer décisif. Une installation déconnectée permet d'établir et de gérer des clusters OpenShift dans des environnements isolés, axés sur la sécurité et autonomes, et ainsi de bénéficier de l'infrastructure robuste requise pour prospérer dans un monde de plus en plus complexe.

Cet article vous présente les avantages et les principaux aspects à prendre en compte pour ce modèle de déploiement et d'exploitation.

Méthodes d'installation

Explorons dans un premier temps chacune des méthodes d'installation disponibles pour les clusters OpenShift autogérés.

Image 1 : différentes méthodes d'installation

Installer-Provisioned Infrastructure (IPI)

L'infrastructure IPI est l'une des méthodes d'installation les plus simples. Elle convient aux utilisateurs qui souhaitent bénéficier d'une expérience d'installation guidée et automatisée. Dans le cadre de l'IPI, OpenShift provisionne l'infrastructure, notamment les machines virtuelles (VM) et le matériel physique. Cette option est généralement utilisée dans les environnements cloud, mais peut également être employée pour les installations sur site.

Assisted Installer (AI)

Assisted Installer est un outil interactif basé sur le web qui permet d'effectuer des installations OpenShift. Cette approche est idéale pour les clusters dont les réseaux sont connectés à Internet. AI fournit également une API RESTful pour les scénarios d'automatisation et de configuration avancés. Notez que cet outil est inclus dans la solution Red Hat Advanced Cluster Management.

Agent Based Installer (ABI)

Agent Based Installer comprend une image ISO amorçable qui contient l'agent de découverte assistée et le service Assisted Service. L'installation par agent est une sous-commande du programme d'installation d'OpenShift. L'ABI génère une image ISO amorçable contenant toutes les ressources requises pour déployer un cluster OpenShift, avec une image de version OpenShift disponible. Cette approche est idéale pour les environnements air gap, déconnectés ou restreints.

User-Provisioned Infrastructure (UPI)

La technologie UPI est une méthode d'installation flexible, adaptée aux utilisateurs qui préfèrent gérer leur propre infrastructure, que ce soit sur site, dans leurs propres datacenters ou dans un cloud public de fournisseurs. Dans une infrastructure UPI, les utilisateurs sont responsables du provisionnement des machines virtuelles, du stockage et des composants réseau tels que les équilibreurs de charge. Une fois l'infrastructure provisionnée, le programme d'installation d'OpenShift peut être utilisé pour déployer OpenShift.

Plan de contrôle hébergé (HCP)

Les clusters OpenShift peuvent être déployés à l'aide de deux configurations de plan de contrôle différentes : les plans de contrôle autonomes et les plans de contrôle hébergés. La configuration autonome utilise des machines virtuelles ou physiques dédiées pour héberger le plan de contrôle. Dans une configuration hébergée pour OpenShift, les plans de contrôle sont créés en tant que pods sur un cluster d'hébergement, ce qui élimine le besoin de machines virtuelles ou physiques dédiées pour chaque plan de contrôle. Reportez-vous à la documentation HCP officielle et à cet article pour plus d'informations.

Fonctionnement d'une installation déconnectée

Il existe plusieurs types d'installation pour différents scénarios. Il est important de choisir la méthode adaptée à votre cas d'utilisation. Une installation OpenShift déconnectée est la solution idéale pour les entreprises et les environnements dans lesquels la conformité, le contrôle et la fiabilité de la sécurité sont essentiels, et la connectivité Internet directe est par conséquent limitée, voire indésirable. Elle fournit l'infrastructure nécessaire à la gestion et à la maintenance des clusters OpenShift dans des réseaux isolés, autonomes et axés sur la sécurité.

Connectivité restreinte : environnement déconnecté

Lorsqu'ils fonctionnent dans un environnement déconnecté, les clusters OpenShift ne disposent pas de connexion Internet directe, pas même via un proxy. Tout le contenu requis pour prendre en charge l'environnement doit être mis en miroir localement. La machine qui exécute le jeu d'outils oc doit avoir accès à Internet, directement ou indirectement via un proxy, ainsi qu'à un registre d'images et à l'API OpenShift.

Image 2 : restreint – déconnecté

Dans cet article, nous nous concentrons sur la méthode d'installation par agent (ABI) pour les réseaux déconnectés ou restreints, où la connectivité Internet est possible via l'hôte bastion.

Connectivité restreinte : environnement air gap

Selon le glossaire RFC 4949, un « air gap » se produit lorsque deux systèmes ne sont pas connectés physiquement et qu'aucune connexion logique n'est automatisée. Les données sont transférées manuellement, au moyen d'une intervention humaine.

Image 3 : connectivité restreinte – environnement air gap

Dans ce cas, le cluster OpenShift ne dispose pas de connexion Internet directe, pas même via un proxy. Tout le contenu requis pour prendre en charge l'environnement est mis en miroir localement. La machine qui exécute l'installation a accès au registre miroir ainsi qu'à l'API OpenShift, mais elle n'a PAS accès à Internet sous quelque forme que ce soit. Tout le contenu doit être transféré sur une clé USB, un support optique ou par un autre moyen « hors ligne ».

Si l'hôte bastion ne dispose pas de connexion Internet, reportez-vous à cette section de la documentation officielle pour connaître les procédures complémentaires (non couvertes par cet article) de mise en miroir d'un ensemble d'images vers un disque, puis du fichier obtenu vers un miroir.

Outils requis pour l'installation déconnectée

Avant de passer à l'installation à l'aide d'Agent Based Installer, passons en revue les outils nécessaires.

Registre miroir pour RedHat OpenShift

Une option consiste à mettre en miroir les images requises pour prendre en charge l'installation d'OpenShift et les mises à jour ultérieures du produit dans un registre miroir de conteneur compatible avec Docker v2-2, tel que Red Hat Quay. Lorsque vous ne disposez pas de registre de conteneurs à grande échelle, il est possible d'utiliser le registre miroir de Red Hat OpenShift, un registre de conteneurs à petite échelle inclus dans les souscriptions OpenShift.

Plug-in miroir OpenShift Client (oc)

La commande oc-mirror est un plug-in de l'interface en ligne de commande OpenShift (oc) qui peut être utilisé pour mettre en miroir des images. Elle doit être exécutée à partir d'un système connecté à Internet pour télécharger le contenu requis à partir de la source d'origine.

Prérequis à la création d'un registre miroir

• Une souscription OpenShift
• Red Hat Enterprise Linux (RHEL) 8 ou 9, avec Podman 3.4.2 ou version ultérieure et OpenSSL installé
• Nom de domaine complet pour le service Red Hat Quay, qui doit être résolu via un serveur DNS
• Au moins deux processeurs virtuels
• 8 Go de RAM
• Environ 17 Go pour les images de version OpenShift 4.13, ou environ 358 Go pour les images de version OpenShift 4.13 et les images Red Hat Operator OpenShift 4.13 Jusqu'à 1 To ou plus recommandé pour chaque flux

Tâches d'installation

Une fois que la machine virtuelle RHEL de base a été installée, téléchargez les outils suivants sur l'hôte bastion :

• Podman 3.4.2 ou version ultérieure

$ sudo dnf install -y podman

• Client OpenShift (CLI oc) 

$ wget https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/openshift-client-linux.tar.gz
$ tar --extract --file openshift-client-linux.tar.gz
$ chmod +x oc
$ sudo mv oc /usr/local/bin/

• Registre miroir

$ wget https://developers.redhat.com/content-gateway/rest/mirror/pub/openshift-v4/clients/mirror-registry/latest/mirror-registry.tar.gz
$ tar --extract --file mirror-registry.tar.gz
$ chmod +x mirror-registry

• oc mirror

$ wget https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/oc-mirror.tar.gz
$ tar --extract --file oc-mirror.tar.gz
$ chmod +x oc-mirror
$ sudo mv oc-mirror /usr/local/bin/

Installation du registre miroir

Le registre miroir peut être installé à l'aide d'une seule commande :

$ ./mirror-registry install --quayHostname<hostname fqdn> \
--quayRoot /root/ocpmirror

Par exemple :

$ sudo mirror-registry install \
--quayHostname bastion.j9287.dynamic.opentlc.com \
--quayRoot /root/ocpmirror

Une installation réussie du registre miroir renvoie une sortie similaire à ce qui suit :

[...]
INFO[2023-10-31 11:17:28] Quay installed successfully, config data is stored in /root/ocpmirror
INFO[2023-10-31 11:17:28] Quay is available at https://bastion.j9287.dynamic.opentlc.com:8443 with credentials (init, 7HFdq385A9EG0ngVWo4cKeDtxRzp621N)

Vérifiez que le registre miroir est accessible via l'URL à l'aide des informations d'identification fournies :

$ podman login -u init -p <password generated by installer> \
https://<hostname fqdn>:8443 \
--tls-verify=false

Par exemple :

$ podman login -u init \
-p 7HFdq385A9EG0ngVWo4cKeDtxRzp621N \ https://bastion.j9287.dynamic.opentlc.com:8443 \
--tls-verify=false

Dans la mesure où le registre miroir est fourni avec une autorité de certification personnalisée, vous pouvez exporter la variable ci-dessous pour accéder au registre de manière sécurisée :

$ export SSL_CERT_DIR=/root/ocpmirror/quay-rootCA/
$ podman login -u init \
-p 7HFdq385A9EG0ngVWo4cKeDtxRzp621N \
https://bastion.j9287.dynamic.opentlc.com:8443

Téléchargez votre secret d'extraction OpenShift à l'adresse https://console.redhat.com/openshift/downloads, et enregistrez le fichier téléchargé en tant que pull-secret.

Exécutez les commandes suivantes à partir de votre répertoire personnel pour configurer l'authentification du registre :

$ cat pull-secret | jq . > pull-secret.json
$ mkdir .docker ; cp pull-secret.json ~/.docker/config.json
$ echo -n 'init:7HFdq385A9EG0ngVWo4cKeDtxRzp621N' | \
base64 -w0

À l'aide de la sortie de la commande précédente, modifiez le fichier de façon à inclure l'authentification du miroir local dans ~/.docker/config.json :

"auths": {
 "bastion.j9287.dynamic.opentlc.com:8443": {
   "auth": "aW5pdDo3SEZkcTM3NUE5RUcwbmdWV280Y0tlRHR4UnpwNjIxTg==",
   "email": "[email protected]"
 },

À ce stade, un registre miroir est installé et configuré. Pour plus d'informations, reportez-vous à la documentation officielle.

Mise en miroir d'images

Cette section présente la procédure de mise en miroir du contenu requis dans le registre miroir à l'aide du plug-in oc mirror .

Dans un environnement déconnecté, vous pouvez mettre en miroir un ensemble d'images directement dans le registre de miroir cible.

Dans un environnement air gap, vous devez d'abord mettre en miroir l'ensemble d'images sur le disque, puis mettre en miroir le fichier de l'ensemble d'images dans le registre miroir.

Créez d'abord un fichier pour ImageSetConfiguration :

kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
 registry:
   imageURL: bastion.j9287.dynamic.opentlc.com:8443/mirror/oc-mirror-metadata # Local mirror registry URL
   skipTLS: false
mirror:
 platform:
   channels:
   - name: stable-4.13    # Version of OpenShift to be mirrored
     minVersion: 4.13.17  # Minimum version of OpenShift to be mirrored
     maxVersion: 4.13.18  # Maximum version of OpenShift to be mirrored
     shortestPath: true
     type: ocp
   graph: true   # Useful when updating in disconnected setup with OSUS operator
 operators:
 - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.13 # Operators catalog to mirror
 additionalImages:
 - name: registry.redhat.io/ubi8/ubi:latest
 helm: {}

Un modèle de fichier est fourni dans ce référentiel. Pour une liste complète des options permettant de l'adapter à vos besoins, reportez-vous à la documentation officielle.
 

Dans cet exemple, le fichier ImageSetConfiguration utilise un back-end de stockage de registre (bastion.j9287.dynamic.opentlc.com:8443/mirror/oc-mirror-metadata) et inclut toutes les versions d'OpenShift de la version minimale 4.13.17 à la dernière version du canal, ici 4.13.18. À chaque invocation de la commande oc-mirror avec cette configuration d'ensemble d'images, la dernière version du canal stable-4.13 est évaluée. Ainsi, l'exécution régulière de oc-mirror garantit de recevoir automatiquement les dernières versions des images OpenShift.

Une fois que le fichier ImageSetConfiguration est prêt, exécutez la commande suivante pour mettre en miroir le contenu dans le registre. Le temps requis pour ce processus varie en fonction de la configuration et de la vitesse de connexion.

$ oc mirror --config=imageset-config.yaml \
docker://<hostname fqdn>:8443 

Par exemple :

$ oc mirror --config=imageset-config.yaml \  docker://bastion.j9287.dynamic.opentlc.com:8443

Les paramètres facultatifs --continue-on-error et --skip-missing peuvent être utiles si vous devez ignorer des erreurs.

Une exécution réussie de la commande précédente retourne la sortie suivante :

[...]
bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images:4.13.17-x86_64
bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images:4.13.18-x86_64
Writing image mapping to oc-mirror-workspace/results-1698872844/mapping.txt
Writing UpdateService manifests to oc-mirror-workspace/results-1698872844
Writing CatalogSource manifests to oc-mirror-workspace/results-1698872844
Writing ICSP manifests to oc-mirror-workspace/results-1698872844

Certains fichiers sont générés par oc-mirror. Cela inclut updateService :

apiVersion: updateservice.operator.openshift.io/v1
kind: UpdateService
metadata:
 name: update-service-oc-mirror
spec:
 graphDataImage: bastion.j9287.dynamic.opentlc.com:8443/openshift/graph-image@sha256:a8730004abd6a4c1d02f52d8052a69a014a4e3de677135b2dfe50259fb6b63fa
 releases: bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
 replicas: 2

Le fichier ImageContentSourcePolicy:

apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
 name: release-0
spec:
 repositoryDigestMirrors:
 - mirrors:
   - bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
   source: quay.io/openshift-release-dev/ocp-release
 - mirrors:
   - bastion.j9287.dynamic.opentlc.com:8443/openshift/release
   source: quay.io/openshift-release-dev/ocp-v4.0-art-dev

Et enfin, CatalogSource:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
 name: redhat-operator-index
 namespace: openshift-marketplace
spec:
 image: bastion.j9287.dynamic.opentlc.com:8443/redhat/redhat-operator-index:v4.13
 sourceType: grpc

Ces fichiers sont requis ultérieurement pour configurer le registre miroir en vue de l'installation, et pour indiquer aux opérateurs et au service de mise à jour d'utiliser le registre local.

Vous pouvez également accéder à https://:8443 pour vous connecter à l'interface utilisateur du registre miroir.

Installation avec agent

Une fois le registre miroir local installé et configuré, il est possible de passer à l'installation d'OpenShift à l'aide d'Agent Based Installer. Au moment de la rédaction de ce document, Agent Based Installer prend en charge les plateformes suivantes :

• bare metal
• vSphere
• aucune

L'installation basée sur un agent utilise une image ISO amorçable contenant l'agent Assisted Discovery Agent et le service Assisted Service. Ces deux éléments sont requis pour procéder à l'installation du cluster, mais ce dernier s'exécute sur un seul des hôtes. La sous-commande openshift-install agent create image génère une image ISO éphémère en fonction des entrées fournies.

Dans le fichier install-config.yaml , vous devez inclure le secret d'extraction et l'ensemble de certificats de confiance supplémentaire du registre miroir local et des ImageContentSources pointant vers le miroir local.

Dans le fichier agent-config.yaml , il convient d'inclure le paramètre « rendezvousIP », à savoir l'adresse IP de l'hôte qui deviendra le nœud d'amorçage temporaire lors de l'installation. Cette adresse IP doit correspondre à l'un des nœuds.

Pour une liste complète des étapes de préparation de l'installation à l'aide d'Agent Based Installer, consultez ce lien. Des exemples de fichiers install-config.yaml et agent-config.yaml se trouvent dans ce référentiel.

Création de l'ISO

Une fois les fichiers install-config.yaml et agent-config.yaml modifiés selon vos besoins, il est temps de créer l'image ISO.

Tout d'abord, installez le paquet nmstate :

$ sudo dnf install /usr/bin/nmstatectl

Téléchargez ensuite le programme d'installation d'OpenShift. Sélectionnez la version qui correspond à celle du cluster que vous avez l'intention d'installer. Dans cet article, nous utilisons OpenShift 4.13.17. Nous allons donc l'installer dans un premier temps, puis mettre à jour le cluster vers la version 4.13.18.

$ wget https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/4.13.17/openshift-install-linux.tar.gz
$ tar --extract --file openshift-install-linux.tar.gz
$ chmod +x openshift-install
$ sudo mv openshift-install /usr/local/bin/

Pour terminer, créez l'ISO :

$ openshift-install agent create image --dir <directory>

La sortie devrait être similaire à ce qui suit :

INFO Configuration has 3 master replicas and 3 worker replicas
INFO The rendezvous host IP (node0 IP) is 192.168.94.21
INFO Extracting base ISO from release payload    
INFO Base ISO obtained from release and cached at [/root/.cache/agent/image_cache/coreos-x86_64.iso]
INFO Consuming Install Config from target directory
INFO Consuming Agent Config from target directory

Selon votre plateforme, vous devez préparer les nœuds (bare metal ou de VM) pour le plan de contrôle et les nœuds de calcul. Assurez-vous que tous les nœuds du cluster démarrent à partir de l'image ISO générée.

Création des enregistrements DNS

Vous devez créer des enregistrements DNS pour deux adresses IP statiques dans le DNS. Dans chaque enregistrement, <cluster_name> est le nom du cluster et <base_domain> est le domaine de base que vous spécifiez lors de l'installation du cluster. Un enregistrement DNS complet prend la forme suivante : <component>.<cluster_name>.<base_domain>

API VIP - api.<cluster_name>.<base_domain>

Ingress VIP - *.apps.<cluster_name>.<base_domain>

Création d'un cluster OpenShift

Vous allez démarrer l'image ISO sur chaque hôte de cluster, y compris votre support virtuel, votre clé USB et votre DVD de démarrage.

Configurez les nœuds pour qu'ils démarrent à partir de l'image ISO que vous avez créée. Une fois que tous les nœuds ont démarré à partir de l'image ISO, vous pouvez surveiller l'installation à l'aide de la commande ci-dessous :

$ openshift-install agent wait-for bootstrap-complete \
--dir <directory> --log-level=debug
[...]
INFO Cluster is ready for install                
INFO Cluster validation: All hosts in the cluster are ready to install.
INFO Preparing cluster for installation
INFO Cluster installation in progress
INFO Bootstrap configMap status is complete      
INFO cluster bootstrap is complete

Une fois le processus d'amorçage terminé, vous pouvez exécuter la commande suivante pour surveiller la progression :

$ openshift-install agent wait-for install-complete \
--dir <directory> --log-level=debug
[...]
INFO Cluster is installed                        
INFO Install complete!                           
INFO To access the cluster as the system:admin user when using 'oc', run
INFO     export KUBECONFIG=/root/auth/kubeconfig 
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.j9287.dynamic.opentlc.com
INFO Login to the console with user: "kubeadmin", and password: "HR377-xxxxx-yyyyy-ynxGC"

Un message indiquant que l'installation est terminée devrait s'afficher. Vous pouvez ensuite vous connecter au cluster à l'aide de la commande oc et vérifier la version du cluster OpenShift.

$ oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.13.17   True        False         11m     Cluster version is 4.13.17

Pour plus d'informations sur Agent Based Installer, consultez la documentation OpenShift officielle.

Vous pouvez vérifier la politique ImageContentSourcePolicy pour confirmer que le cluster OpenShift reçoit des images du registre miroir local :

$ oc get imagecontentsourcepolicy
NAME             AGE
image-policy-0   18h
image-policy-1   18h
$ oc describe imagecontentsourcepolicy image-policy-0 |grep -A4 Spec:
Spec:
 Repository Digest Mirrors:
   Mirrors:
     bastion.j9287.dynamic.opentlc.com:8443/openshift/release
   Source:  quay.io/openshift-release-dev/ocp-v4.0-art-dev
$ oc describe imagecontentsourcepolicy image-policy-1 |grep -A4 Spec:
Spec:
 Repository Digest Mirrors:
   Mirrors:
     bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
   Source:  quay.io/openshift-release-dev/ocp-release

Vous devez exécuter une configuration supplémentaire pour supprimer toutes les sources de catalogue par défaut, car votre cluster n'est pas connecté à Internet. Utilisez les commandes suivantes pour corriger la ressource OperatorHub afin de désactiver les CatalogSources par défaut :

$ oc get catsrc -A
NAMESPACE               NAME                  DISPLAY               TYPE   PUBLISHER   AGE
openshift-marketplace   certified-operators   Certified Operators   grpc   Red Hat     32m
openshift-marketplace   community-operators   Community Operators   grpc   Red Hat     32m
openshift-marketplace   redhat-marketplace    Red Hat Marketplace   grpc   Red Hat     32m
openshift-marketplace   redhat-operators      Red Hat Operators     grpc   Red Hat     32m
$ oc patch OperatorHub cluster --type json \
-p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
operatorhub.config.openshift.io/cluster patched
$ oc get catsrc -A
No resources found

Créez une ressource CatalogSource pointant vers le registre miroir local en appliquant le fichier CatalogSource.yaml (cf. section Mise en miroir d'images).

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
 name: redhat-operator-index
 namespace: openshift-marketplace
spec:
 image: bastion.j9287.dynamic.opentlc.com:8443/redhat/redhat-operator-index:v4.13
 sourceType: grpc
 
$ oc apply -f ./oc-mirror-workspace/results-1698872844/
$ oc apply -f ./oc-mirror-workspace/results-1698872844/release-signatures/

Une fois le fichier appliqué, exécutez à nouveau les étapes de vérification :

$ oc get po -n openshift-marketplace
NAME                                    READY   STATUS    RESTARTS   AGE
marketplace-operator-7bc7549555-4ckdm   1/1     Running   0          48m
redhat-operator-index-t4cgd             1/1     Running   0          75s
$ oc get catsrc -A
NAMESPACE               NAME                    DISPLAY   TYPE   PUBLISHER   AGE
openshift-marketplace   redhat-operator-index             grpc               82s

À ce stade, les étapes suivantes ont été réalisées :

• Un nouveau cluster OpenShift a été installé à l'aide de la méthode d'installation par agent.
• Les images d'installation ont été extraites du registre miroir local au lieu d'Internet.
• Operator Hub a été configuré pour utiliser le registre miroir local.

Mises à jour d'OpenShift dans des environnements déconnectés

Dans la première partie de cet article, nous avons mis en miroir un registre local avec deux versions d'OpenShift (4.13.17 et 4.13.18, cf. le contenu du fichier ImageSetConfiguration ). Pour les clusters disposant d'un accès à Internet, nous fournissons des mises à jour à distance à l'aide d'OpenShift Update Service (OSUS) en tant que service hébergé derrière des API publiques. Cependant, dans cet exemple, nous nous concentrons sur le mode déconnecté. OSUS a été abordé plus en détail dans ce guide sur la mise à jour d'OpenShift pour l'administration de clusters.

Il existe deux méthodes pour effectuer la mise à jour d'OpenShift dans des environnements déconnectés/air gap : avec ou sans OpenShift Update Service Operator (OSUS).

Sans OpenShift Update Service Operator (OSUS)

Voyons d'abord l'option la plus simple, qui consiste à mettre à jour le cluster OpenShift de la version 4.13.17 à la version 4.13.18. Exécutez les commandes ci-dessous à partir d'un ordinateur portable ou d'un système disposant de la commande oc et d'une connexion Internet active :

$ export OCP_RELEASE_VERSION=4.13.18
$ export ARCHITECTURE=x86_64
$ oc adm release info -o 'jsonpath={.digest}{"\n"}' quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_VERSION}-${ARCHITECTURE}
sha256:d0fd9d3ab8690605f816c879d74f4e6d6d9f72982f63a3e0ef3e027ecc512e1c

Utilisez la sortie de la commande précédente et utilisez-la pour mettre à niveau le cluster OpenShift à partir du nœud bastion où vous pouvez accéder au cluster OpenShift :

$ oc adm upgrade --allow-explicit-upgrade \
--to-image quay.io/openshift-release-dev/ocp-release@sha256:d0fd9d3ab8690605f816c879d74f4e6d6d9f72982f63a3e0ef3e027ecc512e1c
Requested update to 4.13.18
$ oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.13.17   True        True          78m     Working towards 4.13.18: 106 of 843 done (12% complete), waiting up to 40 minutes on etcd, kube-apiserver
$ oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.13.18   True        False         5m25s   Cluster version is 4.13.18

Pour plus d'informations sur la mise à jour d'OpenShift, reportez-vous à la documentation officielle.

Avec OpenShift Update Service Operator (OSUS)

Pour utiliser l'opérateur OSUS (OpenShift Update Service Operator), vous devez configurer l'accès à un registre sécurisé, si le registre est différent de celui utilisé pour l'installation. Cela ne s'applique pas à cet article, car nous avons utilisé un registre miroir local.

Vous devez également mettre à jour le secret d'extraction du cluster global pour accéder à votre registre miroir si le registre est différent de celui utilisé pour l'installation. Cela ne s'applique pas à cet article, car nous avons utilisé un registre miroir local.

Pour utiliser OSUS, vous devez d'abord installer l'opérateur OSUS à partir d'Operator Hub.

Créez ensuite une image de conteneur de données graphiques pour OpenShift Update Service. Cette étape n'est pas requise pour l'exemple de cet article, car nous avons utilisé oc miroir pour mettre en miroir les images et inclus graph: true dans le fichier ImageSetConfiguration lors de la mise en miroir.

Ensuite, installez l'application OSUS et configurez vos clusters afin qu'ils utilisent le service OpenShift Update Service local. Utilisez UpdateService.yaml pour appliquer la configuration nécessaire. Par exemple :

apiVersion: updateservice.operator.openshift.io/v1
kind: UpdateService
metadata:
 name: update-service-oc-mirror
spec:
 graphDataImage: bastion.j9287.dynamic.opentlc.com:8443/openshift/graph-image@sha256:a8730004abd6a4c1d02f52d8052a69a014a4e3de677135b2dfe50259fb6b63fa
 releases: bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
 replicas: 2

Une fois l'application OSUS installée, exécutez les commandes suivantes pour que le CVO (Cluster Version Operator) extraie les données graphiques de l'OSUS installé localement au lieu d'Internet.

$ export NAMESPACE=openshift-update-service
$ export NAME=update-service-oc-mirror
$ export POLICY_ENGINE_GRAPH_URI="$(oc -n "${NAMESPACE}" get -o jsonpath='{.status.policyEngineURI}/api/upgrades_info/v1/graph{"\n"}' updateservice "${NAME}")"
$ export PATCH="{\"spec\":{\"upstream\":\"${POLICY_ENGINE_GRAPH_URI}\"}}"
$ oc patch clusterversion version -p $PATCH --type merge

Si des erreurs de certificat sont renvoyées lors de l'exécution de la commande oc adm upgrade, assurez-vous qu'un proxy est activé à l'échelle du cluster, puis configurez l'autorité de certification pour qu'elle approuve le serveur de mise à jour.

Enfin, effectuez la procédure de mise à jour telle que décrite dans la section précédente. Reportez-vous à la documentation pour en savoir plus sur OpenShift Update Service Operator.

Conclusion

Cet article vous a présenté de façon détaillée comment configurer, à l'aide d'outils comme un registre miroir et la commande oc mirror, un référentiel local pour les installations déconnectées/air gap. Avec ces connaissances, un administrateur OpenShift peut utiliser des images mises en miroir localement, non seulement pour installer un cluster OpenShift, mais également pour le mettre à niveau et à jour.