Saltar al contenido principal
Version: Next

Actualizar desde versiones 1.3 a 1.4

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.3.0 (última al generar esta guía, no se probaron versiones previas)
  • se actualiza toda la solución EEI que se despliega con Docker

Huarpe​

Actualizar variables​

En la versión 3.0 de Huarpe se agregaron nuevas configuraciones como variables de entorno y se renombraron otras. Todas se detallan acá.

Todas estas configuraciones, se deben ver reflejados en el archivo huarpe.env.

Asi mismo se eliminó el archivo huarpe_parameters.yml el cual contenía reemplazos de configuración sobre el runtime de SIU-Huarpe (especialmente utilizados por los módulos para la configuración de sus respectivos bundles). Esto ahora se realiza en forma íntegra mediante variables de entorno.

Actualizar la URL​

Huarpe es un caso especial pues existe una expresión regular con la URL que deberemos ajustar (reemplace universidad\\.edu\\.ar con la URL de su institución):

sed -i 's/uunn\\.local/universidad\\.edu\\.ar/g' huarpe.env

Actualizar secrets​

La configuración de las rutas al secret correspondiente (ej para claves de acceso a API) se trasladó al archivo huarpe.env como variable de entorno. Busque la env-var correspondiente al secret que desea indicar y modifique el valor de la ruta según tenga definido en el archivo huarpe.yml.

Actualizar el despliegue​

  1. Bajar stack huarpe

    docker stack rm huarpe

  2. Desplegar las nuevas versiones del servicio

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

Opcional. Conectar con módulos SIU​

Si en el ambiente EEI 1.3 pre-existente, se realizó alguno de los pasos de configuración para conectar un módulo SIU con Huarpe, deberá verificarlo y realizarlo nuevamente.

Los siguientes módulos son factibles de requerir ajustes en las configuraciones de Huarpe:

Sudocu​

Antes de actualizar​

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

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

Storage compartido tipo NFS​

Si se configuró un storage compartido tipo NFS siguiendo esta guia
deberá asegurarse tener incorporado el parametro all_squash a todos los exports.

Ej:

/mnt/nfs_share  IP_Cliente(rw,sync,no_subtree_check)

pasa a ser

/mnt/nfs_share  IP_Cliente(rw,sync,all_squash,no_subtree_check)

Finalmente, el nuevo parámetro all_squash requiere actualizar los permisos asignandolo al usuario "anónimo" y volver a re-exportar:

chown -R nobody:nogroup /mnt/nfs_share/
exportfs -a

Sin ese parametro el server NFS mapea los usuarios usando UID y GID. En algunos escenarios puede traer problemas de permisos.