Actualizar de versión#

Cómo se pasa una instalación de Empowerment Center a una versión nueva, qué ocurre con la BD propia, cómo se vuelve atrás si hace falta y cómo se mantienen al día las imágenes de terceros con sus parches de seguridad.

Antes de empezar#

Lea las notas de la versión nueva: pueden pedir algo antes de actualizar (una extensión de la BD, una variable nueva).
Elija un momento sin uso: los trabajos en curso se pierden y las tareas programadas que estén en marcha se dan por interrumpidas.
Tenga a mano las imágenes nuevas, del backend y del frontal, de la misma versión: se actualizan siempre a la vez.

Las migraciones solo van hacia delante#

Al arrancar, el backend nuevo actualiza el esquema de la BD propia (sus migraciones) antes de atender a nadie. Esas migraciones solo van hacia delante:

una versión anterior no arranca sobre una BD ya migrada;
volver atrás es restaurar la copia de antes de actualizar con las imágenes de antes.

Por eso el primer paso es siempre la copia.

Actualizar con Docker Compose#

Haga una copia de la BD propia y compruebe que el fichero no está vacío (véase Copias de seguridad y restauración):

docker compose -f deploy/compose.yaml exec -T db \
  pg_dump -U postgres -Fc ecenter > ecenter-antes-de-actualizar.dump

Traiga las imágenes nuevas. Si vienen de un registro, cambie la etiqueta en deploy/.env (ECENTER_BACKEND_IMAGE y ECENTER_FRONTEND_IMAGE) y tráigalas; si las construye, use las fuentes nuevas:
```
docker compose -f deploy/compose.yaml pull     # desde un registro
docker compose -f deploy/compose.yaml build    # desde las fuentes
```
Sustituya también deploy/compose.yaml por el de la versión nueva, si trae cambios (por ejemplo, otra versión fijada de Chromium o de PostGIS), conservando su .env y su application.yml propio.
Arranque:
```
docker compose -f deploy/compose.yaml up -d
```
Compose para el backend antiguo (con 45 s para terminar ordenadamente), arranca el nuevo, que aplica las migraciones, y después atiende.
Compruebe la versión en https://ecenter.example.org/api/about y en Administración › Operación › Resumen, y que no hay alertas nuevas.

Lo que sigue y lo que no:

Qué	Tras actualizar
Sesiones de los usuarios	Siguen: están en la BD propia. Al recargar, el navegador carga la aplicación web nueva.
Trabajos en curso y sus resultados	Se pierden: los usuarios vuelven a calcular.
Tareas programadas en marcha	Se dan por interrumpidas y quedan así en su historial.
Datos conservados de los cubos	Si la versión nueva calcula de otra forma, cada documento afectado se calcula una vez, al abrirlo o en su siguiente recálculo programado.

Nota

La primera vez que arranca una versión nueva puede volver a indexar lo que usan los libros y las publicaciones del portal. Mientras tanto, las búsquedas de usos son algo más lentas, pero completas.

Con varias instancias#

Pare todas las instancias antes de arrancar la primera nueva. Una instancia antigua no entiende la BD migrada y podría guardar datos que la nueva no sabe leer.

Haga la copia.
Pare todos los backends.
Arranque uno nuevo y espere a que esté sano (ha migrado la BD).
Arranque los demás.

Sin contenedores#

Haga la copia de la BD propia.
Pare el servicio del backend.
Sustituya el jar por el nuevo y los ficheros de la aplicación web por los nuevos.
Arranque el servicio y siga su registro hasta que atienda.

Volver atrás#

Si algo sale mal y hay que volver a la versión anterior:

Pare el backend.
Restaure la copia de antes de actualizar (véase Restaurar la BD propia).
Vuelva a poner en deploy/.env las etiquetas de las imágenes anteriores (y el compose.yaml anterior, si lo cambió).
Arranque: docker compose -f deploy/compose.yaml up -d.

Lo que se hizo entre la actualización y la vuelta atrás se pierde.

Las imágenes fijadas#

Las imágenes de terceros (PostGIS, Chromium, Valhalla y las bases de las imágenes de ECenter) van fijadas por su digest, con la etiqueta delante para leerla:

image: postgis/postgis:18-3.6-alpine@sha256:…

Así, una etiqueta que alguien vuelve a publicar no cambia lo que se instala sin que usted lo decida. Pero fijado no es parcheado: con el digest, volver a arrancar no toma los parches de seguridad que se publiquen después con la misma etiqueta.

Cada mes, y antes de actualizar ECenter, revise las imágenes de terceros de deploy/compose.yaml:

Mire el digest actual de la misma etiqueta:
```
docker buildx imagetools inspect postgis/postgis:18-3.6-alpine
```
La línea Digest: es la de la imagen para todas sus plataformas.
Si ha cambiado, sustituya el digest en deploy/compose.yaml y vuelva a arrancar ese servicio.
Compruebe que todo sigue funcionando.

Imagen	Con qué frecuencia suele tener parches
`postgis/postgis` (y su PostgreSQL)	Con cada versión menor de PostgreSQL.
`chromedp/headless-shell`	Cada pocas semanas: carga el mapa base de fuera.
`ghcr.io/valhalla/valhalla-scripted`	Con cada versión de Valhalla.

Las imágenes de ECenter (backend y frontal) las actualiza Action Ware con cada versión, con su JRE, su nginx y sus dependencias al día. No cambie su digest por su cuenta.

Importante

No cambie la versión mayor de PostgreSQL (de la 18 a otra) cambiando la etiqueta de la imagen: los datos de una versión mayor no se leen con otra. Eso exige una migración de PostgreSQL (pg_upgrade o copia y restauración) y que ECenter admita esa versión.

Si el usuario de la BD es superusuario#

Con el deploy/compose.yaml de las versiones preliminares de ECenter 8, el usuario ecenter de la BD propia era el superusuario de la imagen. El script de inicio no se vuelve a ejecutar sobre un volumen que ya existe, así que sigue así y funciona, pero conviene quitárselo. Con la aplicación parada y una copia hecha:

Entre en la BD como ecenter:

docker compose -f deploy/compose.yaml exec db psql -U ecenter -d ecenter

Cree el superusuario de la imagen, sin contraseña (solo podrá entrar desde dentro del contenedor), y la extensión de las búsquedas, si no está:
```
CREATE ROLE postgres SUPERUSER LOGIN;
CREATE EXTENSION IF NOT EXISTS pg_trgm;
```

Salga (\q) y vuelva a entrar como postgres para quitarle el superusuario a ecenter:

docker compose -f deploy/compose.yaml exec db psql -U postgres -d ecenter -c "ALTER ROLE ecenter NOSUPERUSER;"

Desde entonces, haga las copias con postgres, como en Copias de seguridad y restauración.