Proteggi il futuro: guida alle installazioni disconnesse di Red Hat OpenShift con il programma di installazione basato su agenti

Nell'odierno panorama digitale, affidabilità e conformità alla sicurezza sono più importanti che mai. Per un'organizzazione con una connessione a Internet limitata o non ottimale, scegliere un'installazione standard e una versione disconnessa di  Red Hat OpenShift può essere una svolta. Un'installazione disconnessa consente alle aziende di creare e gestire cluster OpenShift in ambienti isolati, incentrati sulla sicurezza e autonomi, offrendo un'infrastruttura solida, necessaria per il successo in un mondo sempre più complesso.

In questo articolo analizzeremo i vantaggi e le considerazioni chiave di questo paradigma operativo e di deployment essenziale.

Metodi di installazione

Innanzitutto, esaminiamo i diversi metodi di installazione disponibili per i cluster OpenShift autogestiti.

Immagine 1: i diversi metodi di installazione

Infrastruttura IPI (Installer-Provisioned Infrastructure)

Il metodo di installazione IPI è uno dei più semplici ed è adatto per gli utenti che desiderano un'installazione guidata e automatizzata. Nell'installazione IPI, OpenShift è responsabile del provisioning dell'infrastruttura, incluse macchine virtuali o hardware fisico. In genere viene utilizzata con i provider di servizi cloud, ma può essere impiegata anche per le installazioni on premise.

Assisted Installer (AI)

Assisted Installer è uno strumento interattivo basato sul web utilizzato per eseguire le installazioni di OpenShift. È l'ideale per i cluster con reti connesse a Internet e fornisce inoltre un'API RESTful per scenari in cui sono richieste automazione e configurazione avanzate. Anche AI fa parte di Red Hat Advanced Cluster Management.

Installazione basata su agenti (Agent Based Installer, ABI)

L'installazione basata su agenti comprende una ISO di avvio che include agente di rilevamento assistito e servizio assistito ed è un sottocomando del programma di installazione di OpenShift. Genera un'immagine ISO di avvio contenente tutte le risorse necessarie per il deployment di un cluster OpenShift, con un'immagine di rilascio di OpenShift. Questo approccio è ideale per gli ambienti isolati, disconnessi o limitati.

Infrastruttura UPI (User-Provisioned Infrastructure, UPI)

Il metodo UPI è flessibile ed è adatto agli utenti che preferiscono gestire la propria infrastruttura, che sia on premise, nei propri datacenter o su provider di cloud pubblico. Con questa modalità, gli utenti sono responsabili del provisioning delle macchine virtuali, dello storage e dei componenti di rete, come un sistema di bilanciamento del carico. Una volta eseguito il provisioning dell'infrastruttura, puoi utilizzare il programma di installazione di OpenShift per eseguire il deployment di OpenShift sull'infrastruttura prescelta.

Piano di controllo in hosting (Hosted Control Plane, HCP)

I cluster OpenShift possono essere distribuiti utilizzando due diverse configurazioni del piano di controllo: standalone o in hosting. La configurazione standalone ospita il piano di controllo su macchine virtuali dedicate o macchine fisiche, mentre la configurazione in hosting consente di creare piani di controllo come pod su un cluster di hosting, senza la necessità di macchine virtuali o fisiche dedicate. Per ulteriori informazioni, consulta la documentazione ufficiale per HCP e  questo articolo.

Cosa si intende per installazione disconnessa?

Esistono diversi tipi di installazione che si adattano a scenari diversi, per questo è importante scegliere quello più adatto al proprio sistema. Un'installazione disconnessa di OpenShift è una soluzione fondamentale per le organizzazioni e gli ambienti in cui la conformità, il controllo e la massima sicurezza sono fondamentali e dove la connessione a Internet è limitata o non eccelsa. Fornisce l'infrastruttura necessaria per gestire e mantenere i cluster OpenShift in reti isolate, incentrate sulla sicurezza e autonome.

Accesso con restrizioni: sistema disconnesso

Quando opera in un ambiente disconnesso, il cluster OpenShift non dispone di una connessione Internet diretta, nemmeno tramite proxy. È quindi necessario eseguire il mirroring di tutti i contenuti che servono a supportare l'ambiente anche in locale. Il computer che esegue il set di strumenti oc deve avere accesso a Internet, direttamente o indirettamente tramite un proxy, nonché a un registro delle immagini e all'API OpenShift.

Immagine 2: Accesso limitato: sistema disconnesso

In questo post ci concentreremo sul metodo di installazione basata sugli agenti per le reti disconnesse/limitate, in cui  la connettività Internet è consentita dal bastion host.

Con restrizioni: ambiente isolato

Nel glossario RFC 4949 un "airgap" viene definito come un ambiente in cui due sistemi non sono collegati fisicamente e non è automatizzata alcuna connessione logica. I dati vengono trasferiti manualmente, per intervento umano.

Immagine 3: Con restrizioni: ambiente isolato

In questo caso, il cluster OpenShift non ha una connessione Internet diretta, nemmeno tramite proxy. Deve essere eseguito il mirroring di tutti i contenuti che supportano l'ambiente anche in locale e il computer che esegue l'installazione ha accesso al mirror registry e all'API OpenShift, ma NON ha in alcun modo accesso a Internet. Tutti i contenuti devono essere spostati tramite una chiavetta USB, su un supporto ottico o altri mezzi "offline".

Se il bastion host non dispone di una connessione Internet, consulta questa sezione della  documentazione ufficiale per eseguire i passaggi aggiuntivi del mirroring dell'immagine impostata su disco; la replica del file del set di immagini su disco su un mirror non rientra nell'ambito di questo articolo.

Cosa serve per eseguire un'installazione disconnessa

Prima di passare alla procedura vera e propria con il programma dedicato basato sugli agenti, esaminiamo gli strumenti necessari per eseguire l'installazione disconnessa.

Mirror registry per Red Hat OpenShift

È possibile eseguire il mirroring delle immagini necessarie per l'installazione di OpenShift e i successivi aggiornamenti su un mirror registry dei container che supporta Docker v2-2, come Red Hat Quay. Se non hai accesso a un registro dei container su larga scala, è possibile utilizzare il mirror registry per Red Hat OpenShift, un registro dei container su piccola scala incluso nelle sottoscrizioni OpenShift.

Plugin di mirroring OpenShift Client (oc)

Il comando oc-mirror è un plugin OpenShift CLI (oc) che può essere utilizzato per eseguire il mirroring delle immagini. Devi eseguirlo da un sistema connesso a Internet e scaricare il contenuto dall'origine.

Prerequisiti per utilizzare il mirror registry

• Una sottoscrizione a OpenShift.
• Red Hat Enterprise Linux (RHEL) 8 o 9 con Podman 3.4.2 o versioni successive e OpenSSL installato.
• Nome di dominio completo per il servizio Red Hat Quay, che deve essere modificato tramite un server DNS.
• 2 o più vCPU.
• 8 GB di RAM.
• Circa 17 GB per le immagini della versione 4.13 di OpenShift, oppure circa 358 GB per le immagini della versione 4.13 di OpenShift e le immagini di OpenShift 4.13 Red Hat Operator. Si consiglia di utilizzare fino a 1 TB o più per ogni flusso.

Procedura di installazione

Dopo aver installato la VM RHEL di base, scarica i seguenti strumenti sul bastion host:

• Podman 3.4.2 o versioni successive

$ sudo dnf install -y podman

• OpenShift Client (oc CLI) 

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

• Mirror registry

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

Installazione del mirror registry

Il mirror registry può essere installato con un unico comando:

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

Ad esempio:

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

Se installato correttamente, il mirror registry restituisce un output simile al seguente:

[...]
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)

Verifica che sia possibile accedere al mirror registry utilizzando l'URL e le credenziali fornite:

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

Ad esempio:

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

Il mirror registry viene fornito con un'autorità di certificazione personalizzata, quindi per accedere al registro in modo sicuro puoi esportare la variabile seguente:

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

Scarica il segreto di pull per OpenShift da https://console.redhat.com/openshift/downloads e salva il file scaricato come pull-secret.

Esegui i comandi seguenti dalla directory home per configurare l'autenticazione del registro:

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

Utilizzando l'output del comando precedente, modifica il file per includere l'autenticazione del mirror locale in  ~/.docker/config.json:

"auths": {
 "bastion.j9287.dynamic.opentlc.com:8443": {
   "auth": "aW5pdDo3SEZkcTM3NUE5RUcwbmdWV280Y0tlRHR4UnpwNjIxTg==",
   "email": "email@example.com"
 },

A questo punto il mirror registry viene installato e configurato. Per ulteriori informazioni, consulta la documentazione ufficiale.

Mirroring delle immagini

In questa sezione il plug-in OpenShift CLI  oc mirror  verrà utilizzato per eseguire il mirroring del contenuto richiesto nel mirror registry.

In un ambiente disconnesso, puoi eseguire il mirroring di un set di immagini direttamente nel mirror registry di destinazione.

In un ambiente isolato, invece, devi prima eseguire il mirroring del set di immagini su disco, quindi eseguire il mirroring del file del set di immagini su disco su un mirror.

Innanzitutto, crea un nuovo file 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: {}

In questo repository viene fornito un file di esempio. Per un elenco completo delle opzioni per adattare questo file alle tue esigenze, consulta la documentazione ufficiale.
 

Per questo esempio, il file ImageSetConfiguration utilizza un backend di storage del registro (bastion.j9287.dynamic.opentlc.com:8443/mirror/oc-mirror-metadata) e include tutte le versioni di OpenShift a partire dalla 4.13. 17 fino alla versione più recente disponibile nel canale, qui la 4.13.18. Ogni volta che viene chiamato il comando oc-mirror con questa configurazione del set di immagini, è valutata l'ultima versione del canale stable-4.13, quindi l'esecuzione di oc-mirror a intervalli regolari garantisce che vengano ricevute le ultime versioni di immagini di OpenShift.

Quando il file ImageSetConfiguration è pronto, esegui il comando riportato sotto per avviare il mirroring del contenuto nel registro. Il tempo necessario per il mirroring dipende dalla configurazione e dalla velocità di connessione.

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

Ad esempio:

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

I parametri facoltativi --continue-on-error e --skip-missing  possono essere utili per ignorare gli errori.

Se il comando precedente è stato eseguito correttamente, viene visualizzato un output simile al seguente:

[...]
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

Il comando oc-mirror genera alcuni file, come il file 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

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

E, infine, il file 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

Si tratta di file che in seguito saranno utili per configurare il mirror registry e installare e indirizzare gli operatori e il servizio di aggiornamento nell'utilizzo del registro locale.

Puoi anche accedere all'interfaccia utente del mirror registry dall'indirizzo https://:8443.

Installazione basata su agenti

Dopo aver installato e configurato il mirror registry locale, possiamo esaminare l'installazione di OpenShift utilizzando il programma di installazione basato sugli agenti. Al momento della stesura dell'articolo, il programma di installazione basato su agenti supporta le seguenti piattaforme:

• baremetal
• vsphere
• nessuna

L'installazione basata su agenti comprende una ISO di avvio che include agente di rilevamento assistito e servizio assistito; elementi entrambi necessari per eseguire l'installazione del cluster, ma il servizio viene eseguito solo su uno degli host. Il sottocomando openshift-install agent create image genera un'immagine ISO temporanea basata sugli input forniti.

Nel file install-config.yaml  è necessario includere il segreto di pull e il pacchetto di attendibilità del certificato aggiuntivo del mirror registry locale e di ImageContentSources che puntano al mirror locale.

Nel file agent-config.yaml  è invece necessario includere il parametro "rendezvousIP", ovvero l'indirizzo IP dell'host che durante l'installazione diventerà il nodo di bootstrap temporaneo. Questo indirizzo IP deve corrispondere a uno dei nodi.

Per un elenco completo delle fasi necessarie in vista dell'installazione con il programma basato su agenti, consulta questo link. Un esempio di install-config.yaml e agent-config.yaml è disponibile in questo repository.

Creazione dell'ISO

Dopo aver modificato i file install-config.yaml e agent-config.yaml, è il momento di creare l'immagine ISO.

Per prima cosa, installa il pacchetto nmstate:

$ sudo dnf install /usr/bin/nmstatectl

Quindi, scarica il programma di installazione di OpenShift. La versione del programma di installazione di OpenShift deve essere scaricata in modo che sia compatibile con la versione del cluster da installare. In questo articolo utilizziamo Openshift 4.13.17, quindi per prima cosa lo installeremo, quindi aggiorneremo il cluster alla versione 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/

Infine, crea l'immagine ISO:

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

Vedrai un output simile al seguente:

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

A seconda della piattaforma, per il piano di controllo e i nodi di elaborazione devi preparare i nodi (baremetal o VM). Assicurati che tutti i nodi del cluster siano avviati dall'immagine ISO generata.

Creazione dei record DNS

Per i due indirizzi IP statici in DNS devi creare altrettanti record DNS. In ogni record,<cluster_name> è il nome del cluster e<base_domain> è il dominio di base del cluster specificato al momento dell'installazione. Un record DNS completo ha il seguente formato:<component>.<cluster_name>.<base_domain>

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

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

Creazione di cluster OpenShift

L'immagine ISO viene avviata su ciascun host del cluster, inclusi il supporto virtuale, l'unità USB di avvio e l'unità DVD.

Configura i nodi in modo che vengano avviati dall'immagine ISO creata, dopo l'avvio, puoi monitorare l'installazione utilizzando il comando seguente:

$ 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

Una volta completato il processo di bootstrap, per monitorare l'avanzamento puoi eseguire il comando seguente.

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

Una volta ricevuto il messaggio di completamento dell'installazione, puoi accedere al cluster utilizzando il comando oc e verificare la versione del cluster OpenShift.

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

Per ulteriori informazioni sul programma di installazione basato su agenti, consulta la documentazione ufficiale di OpenShift.

Nella ImageContentSourcePolicy puoi verificare che il cluster OpenShift riceva immagini dal mirror registry locale utilizzando il comando:

$ 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

Per rimuovere tutte le origini del catalogo predefinite devi eseguire ancora altre configurazioni, perché il cluster non è connesso a Internet. Per applicare le patch alla risorsa OperatorHub e disabilitare l'impostazione predefinita CatalogSources esegui questi comandi:

$ 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

Crea una nuova risorsa CatalogSource che punta al mirror registry locale applicando il file di configurazione CatalogSource.yaml nella sezione Mirroring delle immagini.

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/

Una volta applicato, ripeti i passaggi di verifica eseguiti in precedenza:

$ 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

A questo punto, hai completato le seguenti operazioni:

• È stato installato un nuovo cluster OpenShift utilizzando il metodo basato sugli agenti.
• Sono state estratte, dal mirror registry locale anziché da Internet, e immagini di installazione.
• È stato configurato l'Operator Hub per utilizzare il mirror registry locale.

Aggiornamenti di OpenShift in ambienti disconnessi

Nella prima parte del post, abbiamo eseguito il mirroring di un registro locale con due versioni di OpenShift: 4.13.17 e 4.13.18 (vedi il contenuto del file ImageSetConfiguration ). Per i cluster con accesso a Internet, Red Hat fornisce aggiornamenti over the air utilizzando OpenShift Update Service (OSUS) come servizio in hosting basato su API pubbliche, ma per questo esempio ci concentreremo sulla modalità non connessa a Internet. Il servizio OSUS è stato trattato in dettaglio in questa  guida agli aggiornamenti per OpenShift nell'amministrazione del cluster.

Esistono due metodi per eseguire l'aggiornamento di OpenShift in ambienti disconnessi: con o senza OSUS.

Senza OSUS

Vediamo per prima l'opzione più semplice per aggiornare il cluster OpenShift dalla versione 4.13.17 alla versione 4.13.18. Esegui i comandi seguenti da un laptop o da un sistema in cui sia disponibile il comando oc e con connessione Internet attiva:

$ 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

Usa l'output del comando precedente per eseguire l'upgrade del cluster OpenShift dal nodo bastion da cui accedere al 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

Per ulteriori informazioni sull'aggiornamento di OpenShift, consulta la documentazione ufficiale.

Con OSUS

Per utilizzare OSUS è necessario configurare l'accesso a un registro protetto, se diverso da quello utilizzato per l'installazione. In questo articolo questo non si applica, perché abbiamo utilizzato un mirror registry locale.

Devi anche aggiornare il segreto di pull del cluster globale per accedere al mirror registry, se diverso da quello utilizzato per l'installazione. In questo articolo questo non si applica, perché abbiamo utilizzato un mirror registry locale.

Per utilizzare OSUS, devi prima installare l'operatore OSUS dall'Operator Hub.

Quindi, creare un'immagine del container di dati del grafico per OSUS. Questo passaggio non è necessario per l'esempio che abbiamo analizzato in questo articolo, perché abbiamo utilizzato il comando oc mirror per eseguire il mirroring delle immagini, che durante il mirroring includeva graph: true nel file ImageSetConfiguration.

Al termine, installa l'applicazione OSUS e configura i cluster per utilizzare il servizio di aggiornamento locale di OpenShift. Utilizza il file UpdateService.yaml per applicare la configurazione necessaria. Ad esempio:

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

Dopo aver installato l'applicazione OSUS, esegui i seguenti comandi per fare in modo che CVO (Cluster Version Operator) estragga i dati del grafico da qui anziché da 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

Se vengono restituiti errori di certificato durante l'esecuzione del comando oc adm upgrade, assicurati di aver abilitato un proxy a livello di cluster e configura l'autorità di certificazione per considerare attendibile il server di aggiornamento.

Infine, esegui la procedura di aggiornamento come descritto nella sezione precedente. Per ulteriori informazioni su OSUS, consulta la documentazione.

Considerazioni finali

Questo articolo fornisce istruzioni dettagliate per l'utilizzo di strumenti come mirror registry e oc mirror per configurare un repository locale per le installazioni disconnesse. Con queste conoscenze, un amministratore di OpenShift può utilizzare le immagini con mirroring locale non solo per  installare un cluster OpenShift, ma anche per eseguire l'upgrade e l'aggiornamento.