Aktualisieren der Omnissa Access Control Plane-Bereitstellungen

In diesem Thema wird die empfohlene Vorgehensweise zur Aktualisierung einer bestehenden, auf der Steuerungsebene basierenden Omnissa Access-Bereitstellung beschrieben. Es behandelt die Aktualisierung von Betriebssystempaketen, des Asset-Pakets der Steuerungsebene, der Access-Dienste und der Bootstrap-VM.

Wichtig: Diese Anweisungen zur Aktualisierung gelten nicht für das Upgrade von Version 2412 oder früheren Versionen.

Voraussetzungen

• Führen Sie alle Befehle von der Bootstrap-VM aus, sofern nicht anders angegeben.
• Die vorhandene Bereitstellung muss fehlerfrei sein. Führen Sie wso healthcheck und wso access check-service-readiness aus, um den Systemzustand zu überprüfen, bevor Sie beginnen.
• Das Offline-Asset-Paket für die Zielversion wird heruntergeladen und ist in der Bootstrap-VM verfügbar.
• Das RPM für die Betriebssystemsicherheit wird heruntergeladen und steht in der Bootstrap-VM zur Verfügung, sofern dieses Update Betriebssystempaket-Updates enthält.

Update-Workflow

Ein Update besteht aus den folgenden Phasen:

1. Phase 1: Konfigurieren des lokalen Repositorys für Betriebssystem-Updates (nur wenn Betriebssystempaket-Updates erforderlich sind).
2. Phase 2: Herunterladen und Konfigurieren des neuen Asset-Pakets für die Steuerungsebene.
3. Phase 3: Aktualisieren der Steuerungsebene, optional einschließlich Betriebssystempaket-Updates.
4. Phase 4: Aktualisieren der Access-Dienste und Validieren des Dienststatus.
5. Phase 5: Falls Phase 1 zutraf, das Betriebssystem der Bootstrap-VM aktualisieren.

Phase 1: Konfigurieren des lokalen Repositorys für Betriebssystem-Updates

Hinweise:

• Wenn dieses Update keine Betriebssystempaket-Updates enthält, fahren Sie mit Phase 2 – Konfigurieren des neuen Asset-Pakets fort.

• Wenn Sie Ihr eigenes AlmaLinux 9.6 bereitstellen, ist Phase 1 nicht anwendbar. Wechseln Sie zu Phase 2 – Konfigurieren des neuen Asset-Pakets.

Vorgehensweise:

1. Führen Sie das Aktualisierungsskript für das DNF-Repository auf der Bootstrap-VM aus:

   sh /usr/local/sbin/update-dnf-repo.sh /root/security-rpms.tar.gz
   

2. Legen Sie in Ihrer Shell die folgenden Variablen fest, die Sie in den folgenden Schritten benötigen:

   export WORKDIR="/root/<cluster_name>"
   export BOOTSTRAP_IP="<bootstrap-node-ip>"
   export TARGETS="general_compute_linux:general_compute_access_linux"
   export ASSET_DIR="${WORKDIR}/assets-<version>"
   

3. Aktivieren Sie das lokale Repository auf der Bootstrap-VM und stellen Sie das CA-Zertifikat für die Verteilung an die Clusterknoten bereit:

   sed -i 's/enabled=0/enabled=1/' /etc/yum.repos.d/localrepo.repo
   mkdir -p ${WORKDIR}/access/localrepo_ca_path
   cp -f /etc/nginx/localrepo-certs/root-ca.crt \
     ${WORKDIR}/access/localrepo_ca_path/root-ca.crt
   

4. Übertragen Sie die Konfiguration des lokalen Repositorys an die Clusterknoten:

   1. Erstellen Sie das Zertifikatsverzeichnis auf den Clusterknoten:

      wso control-plane ansible -- -b -m file \
        -a "path=/etc/nginx/localrepo-certs state=directory owner=root group=root mode=0755" \
        "${TARGETS}"
      

   2. Kopieren Sie das Stamm-CA-Zertifikat auf die Clusterknoten:

      wso control-plane ansible -- -b -m copy \
        -a "src=/workdir/access/localrepo_ca_path/root-ca.crt dest=/etc/nginx/localrepo-certs/root-ca.crt owner=root group=root mode=0644 force=yes" \
        "${TARGETS}"
      

   3. Verweisen Sie die Clusterknoten auf das Bootstrap-HTTPS-Repository:

      wso control-plane ansible -- -b -m ini_file \
        -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=baseurl value=https://${BOOTSTRAP_IP}/" \
        "${TARGETS}"
      wso control-plane ansible -- -b -m ini_file \
        -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=sslverify value=1" \
        "${TARGETS}"
      wso control-plane ansible -- -b -m ini_file \
        -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=sslcacert value=/etc/nginx/localrepo-certs/root-ca.crt" \
        "${TARGETS}"
      wso control-plane ansible -- -b -m ini_file \
        -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=enabled value=1" \
        "${TARGETS}"
      

   4. Erstellen Sie den DNF-Cache auf den Clusterknoten nur aus dem lokalen Repository neu. Dieser Schritt muss wiederholt werden, wenn Sie mehrere Updates zusätzlich zur veröffentlichten Version installieren.

      wso control-plane ansible -- -b -m shell \
        -a "dnf clean all && rm -rf /var/cache/dnf/* && dnf --refresh makecache --disablerepo='*' --enablerepo=localrepo && dnf --refresh --disablerepo='*' --enablerepo=localrepo list available" \
        "${TARGETS}"
      

Phase 2: Konfigurieren des neuen Asset-Pakets

Vorgehensweise:

1. Erstellen Sie ein Verzeichnis für das neue Asset-Paket und laden Sie es herunter:

   mkdir -p ${ASSET_DIR}
   cd ${ASSET_DIR}
   # Copy the target release asset bundle to this location ${ASSET_DIR}
   

   Wichtig: Laden Sie das Asset-Paket herunter, das Ihrer Zielversion entspricht. Verwenden Sie kein Paket aus einer älteren Version erneut.

2. Extrahieren Sie das Paket und fügen Sie die CLI zu Ihrem Pfad hinzu:

   # Ensure that you are in ${ASSET_DIR} before you unzip the asset bundle
   unzip asset-bundle.zip
   cp cli-distribution/linux/wso /usr/bin/
   cp: overwrite '/usr/bin/wso'? y # It will prompt for overwrite
   wso eula
   Do you agree to these terms ? [y/n]: y
   

3. Konfigurieren Sie die CLI für die Verwendung des neuen Pakets:

   cd ${WORKDIR}
   wso configure ${ASSET_DIR}
   

Phase 3: Aktualisieren der Steuerungsebene

Vorgehensweise:

1. Stellen Sie die Steuerungsebene mit dem neuen Asset-Paket bereit. Fügen Sie -u hinzu, wenn dieses Update auch Betriebssystempakete auf den Clusterknoten aktualisiert:

   #  To update without OS packages update
   nohup wso cp deploy &
   # To update with OS packages update
   nohup wso cp deploy  -u &
   

2. Überprüfen Sie die Bereitstellung.

   wso version
   wso healthcheck
   

3. Wenn Sie die Bereitstellung mit -u durchgeführt haben, heben Sie die Sperre des Clusters auf:

   Hinweis: Sie können diesen Schritt überspringen, wenn Sie die Bereitstellung ohne -u durchgeführt haben

   wso cp unseal
   

Phase 4: Aktualisieren der Access-Dienste

Vorgehensweise:

1. Passen Sie die Access-Konfiguration für das Update an:

   wso access update-config set
   

2. Falls im Arbeitsverzeichnis ein Verzeichnis services aus einer früheren manuellen Außerkraftsetzung vorhanden ist, verschieben Sie es, damit die Bereitstellung stattdessen die Images aus dem neuen Paket verwendet:

   mv ${WORKDIR}/services to ${WORKDIR}/services.bk
   

3. Stellen Sie alle Access-Dienste bereit:

   nohup wso services deploy --type full &
   

4. Überprüfen Sie die Integrität der Dienste:

   wso access check-service-readiness
   

5. Nachdem alle Dienste den fehlerfreien Zustand gemeldet haben, beenden Sie den Update-Modus:

   wso access update-config reset
   

6. Beseitigen Sie Assets aus der vorherigen Version:

   wso cp reset-assets
   

Phase 5: Aktualisieren des Bootstrap-VM-Betriebssystems

Führen Sie diese Phase erst aus, nachdem das Cluster-Update erfolgreich abgeschlossen wurde. Diese Phase erfordert keine Ausfallzeit Ihres Clusters. Sie können Ihre Clustervorgänge durchführen, nachdem Sie Phase 4 abgeschlossen haben.

Wählen Sie für diese Phase aus, ob ein direktes Update durchgeführt oder die VM ersetzt werden soll.

Direktes Update

1. Aktualisieren Sie die Pakete und starten Sie die Bootstrap-VM neu:

   dnf update -y
   reboot
   

2. Nachdem die Bootstrap-VM wieder online geschaltet wurde, validieren Sie den Cluster:

   wso healthcheck
   wso access check-service-readiness
   

Ersetzen der VM

Verwenden Sie diese Option, wenn Sie eine neue Bootstrap-VM aus der neuesten Omnissa-OVA bereitstellen möchten, anstatt die vorhandene Bootstrap-VM vor Ort zu patchen. Dieser Ansatz wird für größere Betriebssystem-Updates empfohlen.

Schritt 1: Erstellen eines Migrationspakets aus der vorhandenen Bootstrap-VM

cd /root/<cluster_name>

tar czpvf /root/<cluster_name>-migration-$(date +%Y%m%d).tar.gz \
  profile.yml \
  logging \
  telegraf_plugin \
  ansible_extra_vars.yml \
  access \
  cp-cluster \
  additional_env_vars.env \
  deploy_services.log \
  deployment-config.yml

Schritt 2: Kopieren des Migrationspakets auf die neue Bootstrap-VM

scp /root/<cluster_name>-migration-*.tar.gz configuser@<new-bootstrap-machine>:/home/configuser/

Schritt 3: Wiederherstellen der Konfiguration auf der neuen Bootstrap-VM

mkdir -p /root/<cluster_name>
cd /root/<cluster_name>

tar xzpvf /home/configuser/cp-cluster-migration-*.tar.gz

Die neue Bootstrap-VM enthält jetzt dieselbe Bereitstellungskonfiguration wie die vorherige Bootstrap-VM.

Schritt 4: Konfigurieren des Asset-Pakets

Kopieren Sie das mit der vorhandenen Bootstrap-VM verwendete Asset-Paket auf die neue Bootstrap-VM und führen Sie dann die folgenden Schritte aus.

mkdir -p assets
cd assets
# COPY asset bundle at this path.
unzip asset-bundle.zip
cp cli-distribution/linux/wso /usr/bin/
wso eula
wso configure /root/<cluster_name>/assets/
cd ..

Schritt 5: Validieren der neuen Bootstrap-VM

wso version
wso healthcheck
wso access check-service-readiness

Stellen Sie sicher, dass die CLI-Version, die Image-Version der Steuerungsebene, die CPS-Image-Version, der Zustand des Clusters und die Betriebsbereitschaft des Access-Diensts korrekt sind. Alle Access-Dienste sollten den Status READY melden.