Mettre à jour les déploiements d'Omnissa Access Control Plane

Cette rubrique décrit la procédure recommandée pour la mise à jour d'un déploiement d'Omnissa Access basé sur le plan de contrôle existant. Elle couvre la mise à jour des modules du système d'exploitation, le bundle de ressources du plan de contrôle, les services Access et la VM de démarrage.

Important : ces instructions de mise à jour ne s'appliquent pas à la mise à niveau des versions 2412 ou antérieures.

Conditions préalables

• Exécutez toutes les commandes à partir de la VM de démarrage, sauf indication contraire.
• Le déploiement existant doit être sain. Exécutez wso healthcheck et wso access check-service-readiness pour confirmer la santé du système avant de commencer.
• Le bundle de ressources hors ligne de la version cible est téléchargé et disponible dans la VM de démarrage.
• Le RPM de sécurité du système d'exploitation est téléchargé et disponible dans la VM de démarrage, si cette mise à jour inclut des mises à jour du module du système d'exploitation.

Workflow de mise à jour

Une mise à jour se compose des phases suivantes :

1. Phase 1 : Configurer le référentiel local pour les mises à jour du système d'exploitation (uniquement lorsque des mises à jour du module du système d'exploitation sont requises).
2. Phase 2 : Télécharger et configurer le nouveau bundle de ressources du plan de contrôle.
3. Phase 3 : Mise à jour du plan de contrôle, y compris les éventuelles mises à jour du module du système d'exploitation.
4. Phase 4 : Mise à jour des services Access et validation de l'état des services.
5. Phase 5 : Si la phase 1 était applicable, mettre à jour le système d'exploitation de la VM de démarrage.

Phase 1 : Configurer le référentiel local pour les mises à jour du système d'exploitation

Remarques :

• Si cette mise à jour n'inclut pas les mises à jour du module du système d'exploitation, passez à la phase 2 : Configurer le nouveau bundle de ressources.

• Si vous déployez votre propre instance d'AlmaLinux 9.6, la phase 1 n'est pas applicable. Passez à phase 2 : Configurer le nouveau bundle de ressources.

Procédure :

1. Exécutez le script de mise à jour du référentiel DNF sur la VM de démarrage :

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

2. Définissez les variables suivantes dans votre shell à utiliser dans les étapes restantes :

   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. Activez le référentiel local sur la VM de démarrage et transférez son certificat d'autorité de certification pour distribution aux nœuds de cluster :

   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. Transférez la configuration du référentiel local vers les nœuds de cluster :

   1. Créez le répertoire de certificats sur les nœuds de cluster :

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

   2. Copiez le certificat d'autorité de certification racine sur les nœuds de cluster :

      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. Pointez les nœuds de cluster vers le référentiel HTTPS de démarrage :

      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. Recréez le cache DNF sur les nœuds de cluster uniquement à partir du référentiel local. Cette étape doit être répétée pour l'application de plusieurs mises à jour au-dessus de la version publiée.

      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 : Configurer le nouveau bundle de ressources

Procédure :

1. Créez un répertoire pour le nouveau bundle de ressources et téléchargez-le :

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

   Important : téléchargez le bundle de ressources qui correspond à votre version cible. Ne réutilisez pas un bundle d'une version antérieure.

2. Extrayez le bundle et ajoutez la CLI à votre chemin d'accès :

   # 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. Configurez la CLI pour utiliser le nouveau bundle :

   cd ${WORKDIR}
   wso configure ${ASSET_DIR}
   

Phase 3 : Mise à jour du plan de contrôle

Procédure :

1. Déployez le plan de contrôle avec le nouveau bundle de ressources. Incluez -u si cette mise à jour met également à jour les modules du système d'exploitation sur les nœuds de cluster :

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

2. Vérifiez le déploiement :

   wso version
   wso healthcheck
   

3. Si vous avez effectué le déploiement avec -u, annulez le scellement du cluster :

   Remarque : vous pouvez ignorer cette étape si vous avez effectué le déploiement sans -u

   wso cp unseal
   

Phase 4 : Mise à jour des services Access

Procédure :

1. Rapprochez la configuration d'Access pour la mise à jour :

   wso access update-config set
   

2. Si un répertoire services existe dans le répertoire de travail à partir d'un remplacement manuel antérieur, déplacez-le afin que le déploiement utilise plutôt les images du nouveau bundle :

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

3. Déployez tous les services Access :

   nohup wso services deploy --type full &
   

4. Vérifiez la santé des services :

   wso access check-service-readiness
   

5. Une fois que tous les services signalent qu'ils sont sains, quittez le mode de mise à jour :

   wso access update-config reset
   

6. Nettoyez les ressources de la version précédente :

   wso cp reset-assets
   

Phase 5 : Mettre à jour du système d'exploitation de la VM de démarrage

Effectuez cette phase uniquement une fois la mise à jour du cluster terminée. Cette phase ne nécessite aucune interruption de service de votre cluster. Vous pouvez effectuer vos opérations de cluster une fois que vous avez terminé la phase 4.

Pour cette phase, choisissez d'effectuer une mise à jour sur place ou de remplacer la VM.

Mise à jour sur place

1. Mettez à jour les modules et redémarrez la VM de démarrage :

   dnf update -y
   reboot
   

2. Une fois la machine virtuelle de démarrage remise en ligne, validez le cluster :

   wso healthcheck
   wso access check-service-readiness
   

Remplacer la VM

Utilisez cette option lorsque vous souhaitez déployer une nouvelle VM de démarrage à partir du fichier OVA Omnissa le plus récent, plutôt que d'appliquer des correctifs à la VM de démarrage existante en place. Cette approche est recommandée pour les mises à jour majeures du système d'exploitation.

Étape 1 : Créer un module de migration à partir de la VM de démarrage existante

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

Étape 2 : Copier le module de migration vers la nouvelle VM de démarrage

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

Étape 3 : Restaurer la configuration sur la nouvelle VM de démarrage

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

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

La nouvelle VM de démarrage contient désormais la même configuration de déploiement que la VM de démarrage précédente.

Étape 4 : Configurer le bundle de ressources

Copiez le bundle de ressources utilisé avec la VM de démarrage existante sur la nouvelle VM de démarrage, puis exécutez les étapes suivantes.

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

Étape 5 : Valider la nouvelle VM de démarrage

wso version
wso healthcheck
wso access check-service-readiness

Vérifiez que la version de CLI, la version de l'image du plan de contrôle, la version de l'image CPS, la santé du cluster et la disponibilité du service Access sont tous corrects. Tous les services Access doivent signaler un état de READY.