Actualizar desde versiones 1.2 a 1.3

Consideraciones

Esta guía lo lleva en el proceso de actualizar una instalación pre-existente de EEI. Tenga en cuenta que:

• la versión requerida de EEI en ejecución es la v1.2.x (última al generar esta guía, no se probaron versiones previas)
• se actualiza toda la solución EEI que se despliega con Docker

Arai-Usuarios

Se generó una versión menor para corrección de errores. Solo es necesario correr el deploy para que detecte los cambios.

2. Desplegar las nuevas versiones

cd prod/arai
docker stack deploy --with-registry-auth -c usuarios.yml usuarios

Sudocu

Antes de actualizar

IMPORTANTE: En las actualizaciones es posible que se incluyan nuevos parámetros en los archivos de configuración del api-server y los distintos modulos de SUDOCU. Por lo tanto, es necesario en cada actualización comparar los archivos de configuración desplegados localmente con el archivo config-default.json ubicado en la raíz de cada módulo, y agregar los parámetros que no se encuentren en el archivo local.

Antes de actualizar es necesario realizar un backup de la base de datos.

pg_dump -h DB_HOST -U DB_USER -p DB_PORT sudocu > sudocu.$(date -I).sql

Borrar el stack actual:

docker stack rm sudocu

Nota: esto elimina tanto los servicios del stack como los configs (que levantan los archivos .json de configuración). Si necesita, puede actualizarlos en este punto.

Actualizar base PostgreSQL

Finalmente, ejecutamos el proceso de migración de la base de datos.

docker run --rm \
  --env SUDOCU_DB_HOST=ip-host-db-sudocu \
  --env SUDOCU_DB_NAME=sudocu \
  --env SUDOCU_DB_PORT=5432 \
  --env SUDOCU_DB_USER=postgres \
  --env SUDOCU_DB_PASSWORD=postgres \
  ungs/sudocu-db-instalador:1.3.2

Nota: Tener en cuenta que SUDOCU_DB_HOST debe apuntar al host donde corre el PostgreSQL que contiene dicha base.

Desplegar la nueva versión

Realizar nuevo deploy:

docker stack deploy --with-registry-auth --compose-file sudocu.yml sudocu

Configuracion hora Stamper (opcional)

Previamente, el contenedor docker del stamper no tenía configurada la hora por defecto en UTC y esto afectaba el horario de la estampa de los PDF. A partir de esta versión, eso se encuentra solucionado.

Si se desplegó la versión previa del Stamper, para aplicar los cambios simplemente debe redeployear el stack ejecutando:

docker config create docs_stamper_entrypoint docs_stamper_entrypoint.sh

Finalmente, para aplicar los cambios, debe redeployear el stack con docker stack rm docs y posterior a esto, docker stack deploy --with-registry-auth -c docs.yml docs

Loki (opcional)

La versión 1.3 propone una actualización del servicio de Loki desde la version 1.6.0 a 2.3.0. Entre algunos de los cambios previstos, se contempla un nuevo archivo de configuración creado dentro del stack donde se encuentra el servicio. Dicho archivo permite no solo la customizacion de ciertos parámetros relacionados con loki, sino también la configuración pertinente al guardado de los logs dentro de grafana.

Es importante aclarar que, si usted ya tiene desplegado la versión de loki 1.6.0, al actualizar a la versión 2.3.0 se perderá el registro histórico de los logs dentro de grafana (es decir, no podrá ver los registros anteriores a la version 2.3.0 dentro de grafana, pero podrá seguir accediendo a los archivos donde quedan guardados dichos logs de manera manual, ya que éstos no son eliminados). Si lo desea, puede configurar loki de tal manera que los logs de ambas versiones sigan mostrandose en grafana, simplemente haciendo una modificación concreta en el archivo de configuración de loki mencionado previamente.

En dicho archivo, dirijase al apartado donde se encuentra el schema_config

schema_config:
  configs:
    - from: 2018-04-15
      store: boltdb
      object_store: filesystem
      schema: v11
      index:
        prefix: index_
        period: 168h
    - from: 2020-10-24
      store: boltdb-shipper
      object_store: filesystem
      schema: v11
      index:
        prefix: index_
        period: 24h

Notará dos fechas específicas en la configuración, una perteneciente al store boltdb (cuya fecha por defecto es 2018-04-15) y otra al boltdb-shipper (cuya fecha por defecto es 2020-10-24). boltdb es el index type utilizado en la versión 1.6.0 para procesar los logs de loki dentro de grafana, y boltdb-shipper es el que comenzó a utilizarse desde la versión 2.0 de loki. Para conservar los logs antiguos y los nuevos en grafana, deberá modificar la fecha de boltdb a la fecha más antigua desde que desplegó loki 1.6.0, y deberá modificar la fecha de boltdb-shipper a la fecha desde que desplegó loki 2.3.0

Por ejemplo: Si venía utilizando loki 1.6.0 desde el 29 de Noviembre del 2021, y decide desplegar la versión de loki 2.3.0 el 29 de Marzo del 2022, deberá modificar el archivo y dejarlo de la siguiente manera

schema_config:
  configs:
    - from: 2021-11-29
      store: boltdb
      object_store: filesystem
      schema: v11
      index:
        prefix: index_
        period: 168h
    - from: 2022-03-29
      store: boltdb-shipper
      object_store: filesystem
      schema: v11
      index:
        prefix: index_
        period: 24h

Nota: también puede dejar la fecha de boltdb por defecto, en caso de que no recuerde desde cuándo utiliza loki 1.6.0

Una vez actualizado ésto, para que surta efecto los cambios en el archivo de configuración deberá volver a desplegar el stack del servicio de la siguiente manera:

docker stack rm loki

y luego

docker stack deploy --with-registry-auth -c loki.yml loki