Atualizar implantações do Omnissa Access Control Plane

Este tópico descreve o procedimento recomendado para atualizar uma implantação existente do Omnissa Access com base no Control Plane. Ele aborda a atualização dos pacotes do sistema operacional, do pacote de ativos do Control Plane, dos serviços do Access e da VM de bootstrap.

Importante: estas instruções de atualização não se aplicam ao upgrade das versões 2412 ou anteriores.

Pré-requisitos

• Execute todos os comandos na VM de bootstrap, a menos que especificado de outra forma.
• A implantação existente deve estar em bom estado de funcionamento. Execute wso healthcheck e wso access check-service-readiness para confirmar a integridade do sistema antes de começar.
• O pacote de ativos offline para a versão de destino é baixado e disponibilizado na VM de bootstrap.
• O RPM de segurança do SO será baixado e disponibilizado na VM de bootstrap, caso essa atualização incluir atualizações de pacote do SO.

Fluxo de trabalho de atualização

Uma atualização consiste nas seguintes fases:

1. Fase 1 – Configure o repositório local para atualizações do sistema operacional (somente quando forem necessárias atualizações de pacotes do sistema operacional).
2. Fase 2 – Baixe e configure o novo pacote de ativos do Control Plane.
3. Fase 3 – Atualize o Control Plane, incluindo, opcionalmente, atualizações de pacotes do sistema operacional.
4. Fase 4 – Atualize os serviços do Access e valide o status dos serviços.
5. Fase 5 – Se a fase 1 for aplicável, atualize o sistema operacional da VM de bootstrap.

Fase 1 – Configurar o repositório local para atualizações do sistema operacional

Notas:

• Se esta atualização não incluir atualizações de pacotes do sistema operacional, pule para a Fase 2 — Configurar o novo pacote de recursos.

• Se você estiver implantando seu próprio AlmaLinux 9.6, a Fase 1 não se aplica. Pule para a Fase 2 — Configurar o novo pacote de recursos.

Procedimento:

1. Execute o script de atualização do repositório DNF na VM de bootstrap:

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

2. Defina as seguintes variáveis no seu shell para uso nas etapas 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. Ative o repositório local na VM de bootstrap e prepara seu certificado de CA para distribuição aos nós do 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. Envie a configuração do repositório local para os nós do cluster:

   1. Crie o diretório de certificados nos nós do cluster:

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

   2. Copie o certificado da CA raiz para os nós do 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. Direcione os nós do cluster para o repositório HTTPS de bootstrap:

      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. Recompile o cache DNF nos nós do cluster somente a partir do repositório local. Esta etapa deverá ser repetida se você estiver aplicando várias atualizações sobre a versão lançada.

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

Fase 2 – Configurar o novo pacote de ativos

Procedimento:

1. Crie um diretório para o novo pacote de ativos e baixe-o:

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

   Importante: baixe o pacote de ativos que corresponde à sua versão do de destino. Não reutilize um pacote de uma versão mais antiga.

2. Extraia o pacote e adicione a CLI ao seu caminho:

   # 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. Configure a CLI para usar o novo pacote:

   cd ${WORKDIR}
   wso configure ${ASSET_DIR}
   

Fase 3 – Atualizar o Control Plane

Procedimento:

1. Implante o Control Plane com o novo pacote de ativos. Inclua -u se essa atualização também atualizar pacotes do sistema operacional nos nós do cluster:

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

2. Verifique a implantação:

   wso version
   wso healthcheck
   

3. Se você implantou com -u, desbloqueie o cluster:

   Nota: você poderá pular esta etapa se tiver implantado sem -u

   wso cp unseal
   

Fase 4 – Atualizar os serviços do Access

Procedimento:

1. Ajuste a configuração do Access para a atualização:

   wso access update-config set
   

2. Se existir um diretório services no diretório de trabalho proveniente de uma substituição manual anterior, mova-o para que a implantação utilize as imagens do novo pacote:

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

3. Implante todos os serviços do Access:

   nohup wso services deploy --type full &
   

4. Verifique a integridade dos serviços:

   wso access check-service-readiness
   

5. Depois que todos os serviços relatarem integridade, saia do modo de atualização:

   wso access update-config reset
   

6. Limpe os ativos da versão anterior:

   wso cp reset-assets
   

Fase 5 – Atualizar o sistema operacional da VM de bootstrap

Realize essa fase somente depois que a atualização do cluster for concluída com êxito. Essa fase não requer nenhum tempo de inatividade do cluster. Você poderá realizar suas operações de cluster depois de concluir a Fase 4.

Para esta fase, escolha entre realizar uma atualização no local ou substituir a VM.

Atualização no local

1. Atualize os pacotes e reinicie a VM de bootstrap:

   dnf update -y
   reboot
   

2. Depois que a VM de bootstrap voltar a ficar online, valide o cluster:

   wso healthcheck
   wso access check-service-readiness
   

Substituir a VM

Use essa opção quando quiser implantar uma nova VM de bootstrap do OVA mais recente da Omnissa em vez de aplicar patches na VM de bootstrap existente. Esta abordagem é recomendada para grandes atualizações do sistema operacional.

Etapa 1 – Criar um pacote de migração a partir da VM de bootstrap existente

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

Etapa 2 – Copiar o pacote de migração para a nova VM de bootstrap

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

Etapa 3 – Restaurar a configuração na nova VM de bootstrap

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

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

A nova VM de bootstrap agora contém a mesma configuração de implantação que a VM de bootstrap anterior.

Etapa 4 – Configurar o pacote de ativos

Copie o pacote de ativos usado com a VM de bootstrap existente para a nova VM de bootstrap e execute as etapas a seguir.

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

Etapa 5 - Validar a nova VM de bootstrap

wso version
wso healthcheck
wso access check-service-readiness

Verifique se a versão da CLI, a versão da imagem do Control Plane, a versão da imagem do CPS, a integridade do cluster e a prontidão do serviço do Access estão corretas. Todos os serviços do Access devem apresentar um status de READY.