Saltar al contenido principal
Version: Next

Actualizar desde versiones 1.13 a 2.0

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.13.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-Documentos​

En esta versión de Araí-Documentos se incluyen nuevas funcionalidades en la gestión de los repositorios de documentos. https://documentacion.siu.edu.ar/arai/documentos/

Tambien se distribuyen nuevos servicios opcionales cuya documentación se encuentra en la sección del despliegue de Araí-Documentos Esta versión soporta el uso de multiples repositorios de documentos y archivos en simultáneo, pero se ofrece un mecanismo para continuar usando el repositorio de documentos vigente configurando nuevas variables de entorno.

Actualizar variables​

En la versión 2.0 de Arai-Docs se agregaron nuevas variables de entorno para la gestion de los repositorios de documentos. Los cambios se detallan acá.

Para configurar el repositorio por defecto usado para almacenar documentos y archivos, se debe definir los parámetros de conexión en las siguientes variables de entorno dependiendo de si se utiliza un repositorio como nuxeo o uno compatible con S3. Al momento de actualizar a la versión 2.0, el repositorio vigente usado para el almacenamiento de documentos/archivos es el que debe ser configurado como repositorio por defecto.

Conexión con Nuxeo​

  • STORAGE_TYPE: Debe especificar RDI
  • STORAGE_HOST: Es la url de nuxeo, debe apuntar a la API CMIS < url-host-nuxeo >/nuxeo/atom/cmis/
  • STORAGE_USUARIO: API User de Nuxeo
  • STORAGE_CLAVE: Password asociada al User anterior

Conexión con S3​

En caso de que opte por utilizar la solución de object storage de S3, debe configurar y agregar de ser necesario las siguientes variables:

  • STORAGE_TYPE: Debe especificar S3
  • STORAGE_ENDPOINT: Configuracion del endpoint donde se encuentran los buckets.
  • STORAGE_KEY: Key para autenticar contra el bucket.
  • STORAGE_SECRET: Secret para autenticar contra el bucket.
  • STORAGE_REGION: Region donde se encuentra el bucket. Ej: us-west-2.
  • STORAGE_BUCKET: Nombre del bucket. Ejemplo: bucket_test.
  • STORAGE_VERSION: Version del servicio web utilizado. Ejemplo: 2006-03-01 o latest.

Bajar stack docs-api​

docker stack rm docs

Actualizar Base de Datos​

  1. Realizar el backup de PostgreSQL de manera preventiva

  2. Desplegar el servicio que actualiza la base de datos

docker stack deploy --with-registry-auth --compose-file prod/arai/util/docs_migrar_base.yml docs-migrar-base

Se puede observar el avance del proceso de migración en el log del servicio. Finalizada la migración, se puede eliminar dicho despliegue del servicio

docker service logs docs-migrar-base_migrar-base -f
docker stack rm docs-migrar-base

Desplegar el stack​

Una vez realizada la configuración e inicialización de la base de datos, pasamos a desplegar el módulo de la siguiente forma:

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

Arai-Usuarios​

Se presenta como una versión con grandes cambios internos. Las principales novedades de Arai-Usuarios son:

  • la integración de la subcomponente de Arai-Documentos que maneja archivos para almacenar imágenes del usuario y aplicación
  • la integración de Araí-Notificaciones para el envío de los emails
  • nuevos servicios del stack worker para el procesamiento en segundo plano.

Todos los cambios se detallan acá.

Bajar el stack​

docker stack rm usuarios

Incorporar nuevos secretos​

Una vez realizado dichos backup, hay que agregar un nuevo secreto requerído en esta nueva version de Arai-Usuarios para el correcto despliegue del servicio:

  • usuarios_conexion_archivos: Parámetros de conexión con la Api de Araí-Archivos

  • usuarios_conexion_notificaciones: Parámetros de conexión con la Api de Araí-Notificaciones

  • La distribucion provee el script de bash secrets.sh.dist para ejemplificar como inicializar todos los valores requeridos.

Puede crear el secret usuarios_conexion_archivos y usuarios_conexion_notificaciones (en caso de no haberlo generado con el secret.sh.dist de la ultima versión) de la siguiente manera:

printf '[["documentos", "docs123", "http://docs_api-archivos:8080/docs/rest/archivos/v1/"]]' | docker secret create usuarios_conexion_archivos -
printf '[["usuarios", "usuarios123", "http://notificaciones-api:8080/api/v1/"]]' | docker secret create usuarios_conexion_notificaciones -

Eliminar variables no utilizadas​

Dado que el envío de los mails se delega formalmente en el servicio de Arai-Notificaciones, ya no son necesarias las variables de entorno que especificaban la forma de conectarse con un SMTP.

Se recommienda por lo tanto, eliminar las variables de entorno siguientes para evitar confusiones sobre la responsabilidad del envío de mails.

MAILER_HELO=mail.unx.edu.ar
MAILER_HOST=smtp.googlemail.com
MAILER_PORT=587
MAILER_FROM=yo@midominio.com
MAILER_SEGURIDAD=ssl
MAILER_AUTH=1
MAILER_USUARIO=usuario
MAILER_CLAVE=clave

Actualizar base PostgreSQL​

Sin importar como se ejecuta la base PostgreSQL, es necesario realizar la exportación de datos de instancia local de la siguiente manera:

docker stack deploy --with-registry-auth --compose-file prod/arai/util/usuarios_exportar_instalacion.yml usuarios_export
docker service logs usuarios_export_idm -f

Esperar a que exporte y se detenga la ejecución. Si tuvo éxito la operación, eliminar el stack temporal usuarios_export:

docker stack rm usuarios_export

Usando los datos de instancia local exportados previamente, realizar la migración de la base de datos PostgreSQL:

docker stack deploy --with-registry-auth --compose-file prod/arai/util/usuarios_actualizar_base.yml usuarios_actualizar_base
docker service logs usuarios_actualizar_base_idm -f

Nota: tenga en cuenta que tanto la exportación como actualización, utilizan un directorio "files" donde se descargan datos. Este directorio tiene que estar para ambas tareas, por lo que se ejecutan en el mismo nodo (por ej, mediante la constraint node.role=manager).

Finalmente, si la migración tuvo éxito, eliminar el stack temporal usuarios_actualizar_base:

docker stack rm usuarios_actualizar_base

Migrar los assets existentes​

Como parte del proceso de mejora y siendo que la gestión de los assets de Arai-Usuarios (avatars, iconos de aplicaciones) necesitaba una alternativa a un volumen de red, se decidió hacer uso de la API que expone un subcomponente de Arai-Documentos que se encarga de realizar la gestión de archivos.

Esta subcomponente que por comodidad denominaremos Arai-Archivos aunque no tiene entidad propia, puede desprenderse del uso de Arai-Documentos y desplegarse como un único servicio.

Como parte de dicha integración entonces, se trasladan los assets de Arai-Usuarios hacia ese servicio, quedando únicamente una copia cacheada del archivo original.

Este proceso de migración lo llevamos adelante desplegando la siguiente job:

docker stack deploy --with-registry-auth --compose-file prod/arai/util/usuarios_migrar_assets.yml usuarios_migrar_assets
docker service logs usuarios_migrar_assets_idm -f

Finalmente, si la migración tuvo éxito, eliminar el stack temporal usuarios_migrar_assets:

docker stack rm usuarios_migrar_assets

Desplegar servicios complementarios​

Para agilizar el procesamiento de ciertos flujos de trabajo se decidió descargar el envío de los mails en el servicio de envío de Notificaciones.

Puede realizar el despliegue del mismo siguiendo las instrucciones presentes aquí.

Desplegar el stack​

Finalmente, solo debemos desplegar el módulo de la siguiente forma:

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

Como los assets ahora quedan en una cache descartable podemos utilizar un service incluido en el mismo stack para hacer el warm-up.

docker service scale usuarios_cache-warmer=1 && docker service logs -f usuarios_cache-warmer

Si se completa exitosamente el proceso de llenado de la cache de assets se puede volver a escalar a 0 dicho service

Luego de ello, podemos eliminar nuestro volumen antiguo para no dejar pendientes

docker volume rm usuarios_usuarios_assets

SUDOCU​

Dentro de esta actualización del ecosistema de expedientes a la versión 2.0, el componente SUDOCU se actualiza a la versión 2.1.0, que trae grandes cambios en el deploy. El procedimiento a seguir depende de la versión de SUDOCU desde la que se parte, por lo que a continuación se describen por separado los dos caminos posibles, cada uno con todos sus pasos. En ambos casos la actualización se realiza en un único despliegue, sin necesidad de pasar por versiones intermedias.

El camino a seguir se determina por la versión de SUDOCU que se tiene instalada, con independencia de la versión del ecosistema de expedientes desde la que se venga. Las versiones del ecosistema y las de SUDOCU no se corresponden de forma estricta.

Este apartado cubre solo lo relativo al deploy. Para las novedades funcionales, consultar el Changelog oficial de SUDOCU y la página oficial de SUDOCU.

Identifique su caso según la versión de SUDOCU que tiene desplegada y siga únicamente el bloque que corresponda:

Desde SUDOCU 1.6.xDesde SUDOCU 1.4.x
¿Cuenta con sudocu-web / api-server2?SíNo
¿Requiere reconfigurar SAML en Araí-Usuarios?NoSí
Servicio sudocu-loginYa estaba eliminadoSe elimina en este salto
Servicio gestionSe elimina en este saltoSe elimina en este salto

Actualización desde SUDOCU 1.6.x​

Estas instalaciones ya cuentan con sudocu-web, api-server2 y la autenticación SAML migrada, por lo que la actualización se limita a los cambios propios de esta versión.

Cambios de deploy que introduce esta versión:

  • Se elimina el servicio gestion del stack (y su config config-sudocu-gestion.json). El servicio web pasa a llamarse sudocu-web.
  • Se agrega la sección arai en config-api-server.json (conexión con Araí-Personas y Araí-Usuarios), que requiere dos secretos nuevos: arai_personas_api_password y arai_usuarios_api_password.
  • Cambia el ruteo de Traefik para Socket.IO en api-server (routers separados para polling y websocket).
  • MPD y MPC no cambian de arquitectura, solo reciben ajustes menores de ruteo en Traefik.

Pasos:

  1. Realizar un backup de la base de datos de manera preventiva.

  2. Borrar el stack actual:

docker stack rm sudocu
  1. Actualizar el secreto sudocu-api-server para incorporar los nuevos campos arai_personas_api_password y arai_usuarios_api_password. Como los secretos de Docker son inmutables, hay que recrearlo:
docker secret rm sudocu-api-server
docker secret create sudocu-api-server ./prod/sudocu/sudocu-api-server-secret.json

  1. Revisar config-api-server.json e incorporar los parámetros nuevos de esta versión. Los principales:

    • arai (obligatorio): nueva sección con las URLs y usuarios de conexión a las APIs de Araí-Personas y Araí-Usuarios. Las contraseñas correspondientes son las que se agregaron al secreto en el paso anterior.
    • firma.sistemas_origen: identifica a SUDOCU como sistema de origen ante Araí-Documentos.
    • throttler: límites de tasa de peticiones (viene deshabilitado por defecto).
    • queue: nuevos parámetros de gestión de colas (remove_on_complete, remove_on_fail, job_timeout).
    • Nuevos flags funcionales (vista_area, puedo_cancelar_comunicacion, copiar_archivos_adjuntos —ahora es un objeto en lugar de un booleano—, etc.), detallados en el Changelog.

    Como regla general, compare su config-api-server.json con el archivo de configuración por defecto del módulo e incorpore todo parámetro que no tenga.

  2. Ejecutar la 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:2.1.0

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

  1. Desplegar la nueva versión:
docker stack deploy --with-registry-auth -c prod/sudocu/sudocu.yml sudocu

Actualización desde SUDOCU 1.4.x​

Estas instalaciones todavía tienen el login tradicional (sudocu-login) y no cuentan con sudocu-web ni api-server2. Por eso, además de los cambios propios de esta versión, este salto incorpora la migración de arquitectura que SUDOCU introdujo en la versión 1.5.0. Todo se aplica en un mismo despliegue.

Cambios de deploy que introduce este salto:

  • Se incorpora api-server2, nuevo backend en NestJS (/api2) que convive con api-server (legado).
  • Se incorpora sudocu-web, nuevo frontend unificado que reemplaza a sudocu-login como punto de entrada.
  • Se elimina el servicio sudocu-login.
  • Se elimina el servicio gestion del stack (y su config config-sudocu-gestion.json).
  • Se agrega la sección arai en config-api-server.json (conexión con Araí-Personas y Araí-Usuarios), que requiere dos secretos nuevos: arai_personas_api_password y arai_usuarios_api_password.
  • Cambia el ruteo de Traefik para Socket.IO en api-server (routers separados para polling y websocket).
  • MPD y MPC no cambian de arquitectura, solo reciben ajustes menores de ruteo en Traefik.

Pasos:

  1. Ajustar el dominio en el sudocu.yml de esta versión (que ya incluye los nuevos servicios sudocu-web y api-server2), reemplazando uunn.local por el dominio real del despliegue:
sed -i 's/uunn.local/universidad.edu.ar/g' \
    prod/sudocu/sudocu.yml
  1. En la aplicación SUDOCU dentro de Araí-Usuarios, solapa SAML, reconfigurar:
  • Entity ID: https://uunn.local/sudocu/
  • Assertion Consumer Service (ACS): https://uunn.local/sudocu/api2/auth/saml/callback
  • Single Logout Service (SLS): https://uunn.local/sudocu/api2/auth/idp/logout

  1. Realizar un backup de la base de datos de manera preventiva.

  2. Borrar el stack actual:

docker stack rm sudocu
  1. Actualizar el secreto sudocu-api-server para incorporar los nuevos campos arai_personas_api_password y arai_usuarios_api_password. Como los secretos de Docker son inmutables, hay que recrearlo:
docker secret rm sudocu-api-server
docker secret create sudocu-api-server ./prod/sudocu/sudocu-api-server-secret.json

  1. Revisar config-api-server.json. Al acumular la migración de 1.5.0, esta revisión es más extensa que en el otro caso. Además de los parámetros propios de esta versión, hay que contemplar los que se incorporaron entre 1.5.0 y 1.6.x.

    Parámetros propios de esta versión:

    • arai (obligatorio): nueva sección con las URLs y usuarios de conexión a las APIs de Araí-Personas y Araí-Usuarios. Las contraseñas correspondientes son las que se agregaron al secreto en el paso anterior.
    • documentos.sistemas_origen: identifica a SUDOCU como sistema de origen ante Araí-Documentos.
    • throttler: límites de tasa de peticiones (viene deshabilitado por defecto).
    • queue: nuevos parámetros de gestión de colas (remove_on_complete, remove_on_fail, job_timeout).
    • Nuevos flags funcionales (vista_area, puedo_cancelar_comunicacion, copiar_archivos_adjuntos —ahora es un objeto en lugar de un booleano—, etc.), detallados en el Changelog.

    Parámetros arrastrados de la migración 1.5.0 → 1.6.x:

    • URLs de Araí-Documentos versionadas (documentos.url, documentos.url_info, documentos.api, documentos.api_front): ahora incluyen la versión /v1/ en la ruta. Actualícelas.
    • custom_menu: menú de ayuda y links útiles configurable.
    • Flags como email_obligatorio (en gestion y en mpc), vista_rapida_enviados, monitoreo, entre otros.

    Como regla general, compare su config-api-server.json con el archivo de configuración por defecto del módulo e incorpore todo parámetro que no tenga. Puede consultar el listado completo de parámetros aquí

  2. Ejecutar la 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:2.1.0

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

  1. Desplegar la nueva versión:
docker stack deploy --with-registry-auth -c prod/sudocu/sudocu.yml sudocu

Portal del Proveedor (Opcional)​

Si posee desplegado el Portal del Proveedor, en esta versión se actualizó la version del Portal basado en SIU-Huarpe y la API de Proveedores.

Bajar stack proveedores​

docker stack rm proveedores

Actualizar Base de Datos de Proveedores​

  1. Realizar el backup de PostgreSQL de manera preventiva

  2. Desplegar el servicio que actualiza la base de datos

docker stack deploy --with-registry-auth -c prod/modulos/proveedores/util/proveedores_migrar_base.yml proveedores_migrar_base

Puede verificar el estado del mismo con el comando:

docker service logs proveedores_migrar_base_migrar-base -f

Una vez finalizada la migración, puede eliminar el stack ejecutando el comando:

docker stack rm proveedores_migrar_base

Actualizar API y Portal​

Ajustes en variables de entorno​

En el archivo [prod/modulos/proveedores/portal.env] se agrega una nueva variable de entorno para indicar la versión de la API de SIU-Diaguita disponible.

  • API_DIAGUITA_VERSION: En esta nueva variable de entorno se debe indicar la versión de la API de SIU-Diaguita disponible. En la documentación se encuentran los números de versión de API correspondientes a cada versión del módulo SIU-Diaguita. Ej: Si se cuenta con la versión de SIU-Diaguita 4.2.0, la versión de la API correspondiente a esa versión del modulo es la 1.3

También en [prod/modulos/proveedores/portal.env] se ajusta la url de conexión a la API de Proveedores.

En [prod/modulos/proveedores/proveedores.env] se ajusta la url de conexión a la API de Araí-Documentos ya que ahora se requiere la ruta completa a la API Backend.

Desplegar las nuevas versiones de la API y del Portal de Proveedores​

docker stack deploy --with-registry-auth -c prod/modulos/proveedores/proveedores.yml proveedores


Huarpe​

Se realizan varias mejoras en la bandeja, todas funcionales.

Bundle de SIU-Diaguita - Patrimonio​

En esta versión de Huarpe se incluye una nueva variable de entorno en el archivo [prod/huarpe.env] para indicar la versión de la API de SIU-Diaguita disponible.

  • API_DIAGUITA_VERSION: En esta nueva variable de entorno se debe indicar la versión de la API de SIU-Diaguita disponible. En la documentación se encuentran los números de versión de API correspondientes a cada versión del módulo SIU-Diaguita. Ej: Si se cuenta con la versión de SIU-Diaguita 4.2.0, la versión de la API correspondiente a esa versión del modulo es la 1.3 Si se cuenta con el bundle de Patrimonio habilitado se debe configurar la version de la API para que se habiliten las nuevas funcionalidades del Bundle dependiendo la version de SIU-Diaguita utilizada.

Actualizar el despliegue​

Bajar stack huarpe

docker stack rm huarpe

Desplegar las nuevas versiones del servicio

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