Actualización - ABBYY Documentation

Las actualizaciones de Vantage 3.0 autoalojado las gestiona el operador. Actualice los releases de Helm vantage-operator y vantage-selfhosted a la misma versión nueva. El nuevo chart vantage-selfhosted hace referencia a un ConfigMap con cargas de trabajo versionadas, lo que hace que el operador vuelva a procesar el recurso Vantage y reconciliar el release de Vantage correspondiente. Las actualizaciones automáticas todavía no están implementadas.

Flujo de actualización

El operador y los charts de Vantage se publican juntos y deben mantenerse alineados en versión. Al instalar el nuevo operador, se prepara el controlador compatible y la CRD; al instalar el chart vantage-selfhosted correspondiente, se actualiza la referencia al ConfigMap de las cargas de trabajo versionadas y se desencadena la actualización in situ. Para realizar la actualización:

Comprobar la versión instalada

Confirme la versión que se está ejecutando actualmente comprobando status.installedVantageVersion en el recurso Vantage:

kubectl -n $install_namespace get vantages.vantage.abbyy.com $release_name -o yaml

Actualizar ambos charts

Actualice primero el operador y, a continuación, actualice la release de vantage-selfhosted a esa misma versión.

helm upgrade --install vantage-operator $charts_uri/vantage-operator \
  --version $new_version \
  --namespace $operator_namespace \
  --wait

helm upgrade --install $release_name $chart_uri/vantage-selfhosted \
  --version $new_version \
  --namespace $install_namespace \
  --values <your-values-file> \
  --wait

Si usa GitOps, actualice ambas revisiones de chart a la misma versión y deje que su controlador las renderice con su origen de valores actual.

Esperar a que el recurso se reconcilie

Espere a que el recurso Vantage alcance el estado Ready:

kubectl -n $install_namespace wait \
  --for=condition=Ready vantages.vantage.abbyy.com/$release_name \
  --timeout=30m

Para una visibilidad más detallada, supervise el trabajo de migración de OCI y el estado de sincronización de la aplicación de ArgoCD. La instalación del skill se ejecuta como un trabajo independiente que ArgoCD no rastrea; consulte Lifecycle. Si un chart no logra reconciliarse, el operador muestra la causa en status.degradationReasons[].

Qué diferencias hay con respecto a Vantage 2.7

En Vantage 2.7 autoalojado, una actualización implicaba ejecutar el contenedor del instalador de Ansible con un archivo de valores actualizado y dejar que helm upgrade actualizara cada chart en secuencia, una operación que afectaba tanto a la infraestructura como a la configuración de la aplicación en un solo paso. En 3.0, la actualización de la aplicación está desacoplada de los cambios de infraestructura:

Step	2.7	3.0
Iniciar una actualización	Volver a ejecutar el contenedor del instalador de Ansible	Instalar nuevas versiones compatibles de los charts del operador y de Vantage
Aplicar cambios por componente	Ansible ejecuta `helm upgrade` para cada chart	El operador genera manifiestos `Application` de ArgoCD; ArgoCD los reconcilia

El modelo de instalador de 2.7 no es compatible con 3.0 y no existe una actualización directa desde 2.7. Pasar de 2.7 es una migración; consulte Migrar desde Vantage 2.7. Las actualizaciones del chart de Vantage cubren solo Vantage Core: el software que instaló por separado, como su pila de monitorización, debe actualizarlo usted según su propio calendario.

Qué sigue

Arquitectura

Qué hace el operador en cada reconciliación.

Limitaciones conocidas

Restricciones que debe tener en cuenta antes de planificar una ventana de actualización.

​Flujo de actualización

​Qué diferencias hay con respecto a Vantage 2.7

​Qué sigue

Arquitectura

Limitaciones conocidas

Flujo de actualización

Qué diferencias hay con respecto a Vantage 2.7

Qué sigue