Actualizaciones, copias de seguridad y restauración

Las actualizaciones y las copias de seguridad protegen dos resultados distintos: las actualizaciones hacen avanzar la plataforma, mientras que las copias de seguridad permiten recuperar la identidad, el estado deseado, las credenciales de los servicios y los datos de las aplicaciones tras un fallo. El responsable de la plataforma es responsable de la secuencia de actualización; el responsable de seguridad, de las claves de recuperación; y los responsables de las bases de datos y de las aplicaciones, de las copias de seguridad nativas de los datos de cada motor y de su validación.

Define el objetivo de punto de recuperación (cuántos datos se pueden perder) y el objetivo de tiempo de recuperación (cuánto puede tardar la restauración) antes de elegir la frecuencia de las copias de seguridad o las ventanas de actualización. El éxito es una restauración probada, no la existencia de archivos de copia.

Antes de una actualización de Opfield, lee las notas de la versión, verifica los mínimos de compatibilidad, haz una copia de seguridad de PostgreSQL y de los archivos persistentes, conserva las claves de cifrado y las claves maestras y registra las referencias de las imágenes en ejecución. Actualiza mediante el instalador compatible o la configuración de Compose generada.

Las actualizaciones de los daemons están firmadas y se gestionan por nodo. Mantén el comportamiento con versiones mixtas dentro de la ventana de compatibilidad documentada y verifica la reconexión, el inventario, las vinculaciones, los logs y las operaciones tras la actualización de cada rol.

Haz copia de seguridad de:

• PostgreSQL;
• los volúmenes persistentes de artefactos y de configuración de Opfield;
• las claves maestras de cifrado y de PKI;
• el volumen de identidad de Relay;
• las copias de seguridad nativas de las bases de datos de cada motor;
• la configuración externa de DNS, del proveedor de identidad, del correo, de los registros y del SIEM que se guarda fuera de Opfield.

Una prueba de restauración debe demostrar el inicio de sesión, el descifrado, la reconexión de los nodos, la autorización de Relay, las Routes, los certificados, las vinculaciones de bases de datos gestionadas y la continuidad de la auditoría. Una copia de seguridad que nunca se ha restaurado no es un plan de recuperación.

Los datos de las bases de datos quedan fuera de este conjunto de recuperación. En Personal y superiores, las copias de seguridad de bases de datos crean copias de seguridad nativas programadas de las bases de datos PostgreSQL, clave-valor y ClickHouse gestionadas y externas en una conexión de almacenamiento; en Community, o para los motores que necesitan recuperación a un punto en el tiempo, usa las herramientas nativas del motor. Consulta Bases de datos gestionadas y externas de un vistazo.

Flujos de trabajo integrados

Las conexiones de almacenamiento y el almacenamiento de objetos gestionado y la copia de seguridad y restauración de bases de datos están disponibles en Personal y superiores. La exportación de la configuración, para trasladar Opfield a otro host, está disponible en todos los planes.

Exportación de la configuración

Settings > General > Configuration export (ámbito admin:system) empaqueta la instalación en un único archivo cifrado con una frase de paso de al menos 12 caracteres: la base de datos de Opfield, PKI_MASTER_KEY, las claves de firma de las CA y de las políticas de relay, los archivos de Opfield, el commercial core de una instalación de pago, el ID de instalación y, opcionalmente, los ajustes de .env. Las imágenes del registro interno y los logs del ClickHouse gestionado por Opfield son opcionales. Opfield sigue funcionando mientras exporta y no guarda la frase de paso.

Una exportación solo se restaura en una instalación nueva de la misma versión de Opfield, ya sea desde el asistente de configuración (Restore from an export) o con la opción --restore <file> del instalador; después actualiza como de costumbre. La restauración pide la URL pública y la dirección gRPC del nuevo host, y la nueva instalación conserva sus propias contraseñas de base de datos y de registro. Las sesiones iniciadas no se trasladan. Los datos de las bases de datos de los nodos Storage no forman parte de la exportación: protégelos con copias de seguridad de bases de datos. Para trasladar los nodos a una dirección nueva, usa Settings > General > Move nodes to a new address en la instalación antigua antes de apagarla.

Una exportación de la configuración es distinta de la exportación de archivos de contenedores. El conjunto de recuperación manual que se describe a continuación sigue siendo una forma de mantener tus propias copias de seguridad del plano de control; las copias de seguridad de bases de datos protegen los datos de las aplicaciones, no el estado propio de Opfield.

Prepara el conjunto de recuperación

Documenta el responsable, la ubicación, la retención, el método de cifrado y el orden de restauración de cada componente de la copia de seguridad. Guarda las claves maestras y las credenciales de recuperación fuera del host de Opfield y fuera del mismo dominio de fallo que la copia de seguridad de la base de datos.

PostgreSQL es el almacén autoritativo de las identidades, el estado deseado, las relaciones, las operaciones y los metadatos de auditoría. Los volúmenes persistentes contienen artefactos y material de identidad de los servicios que no se pueden reconstruir solo a partir de PostgreSQL. Las copias de seguridad nativas de las bases de datos gestionadas protegen los datos de las aplicaciones; una copia de seguridad del plano de control no las sustituye.

Conjunto de recuperación de Compose manual

El instalador manual usa los servicios app, relay, registry, postgres y redis, más estos volúmenes persistentes:

Volumen	Finalidad para la recuperación
postgres_data	usuarios, recursos, estado deseado, Tasks y metadatos de auditoría
app_data	artefactos subidos, configuración generada, TLS y estado de la aplicación
relay_identity	identidad del Relay local compartida por app y relay
relay_state	estado de ejecución del Relay local
registry_data	blobs y manifiestos del registro privado
registry_auth	material de firma de tokens del registro
redis_data	estado persistido de Redis; útil para una recuperación completa coordinada, pero no sustituye a PostgreSQL

Estas son las claves de docker-compose.yml. Una instalación nueva llama a los volúmenes opfield_app_data, etc.; una instalación que se trasladó desde /opt/gateway (consulta Actualización a la 2.12.1) conserva los nombres que tenía, como gateway_gateway_data, indicados en name: en docker-compose.yml. Los comandos siguientes usan las rutas de contenedor de una instalación configurada con la 2.12.3 o posterior (/var/lib/opfield, /var/lib/opfield-relay, /var/lib/opfield-registry-auth); una instalación configurada antes monta los mismos datos en /var/lib/gateway, /var/lib/gateway-relay y /var/lib/gateway-registry-auth, así que usa esas rutas en ella.

Cuando el logging estructurado local está activado, haz también copia de seguridad del volumen del ClickHouse gestionado por Opfield.

Conserva también .env y el docker-compose.yml exacto que usa la instalación; tanto el instalador como la instalación manual lo guardan junto a .env, por defecto en /opt/opfield para el instalador. El archivo .env contiene secretos sensibles para la recuperación; cifra su copia de seguridad por separado y no lo adjuntes nunca a un ticket de soporte.

El siguiente ejemplo crea una breve ventana de coherencia sin conexión. Ejecútalo desde el directorio que contiene el archivo Compose manual:

mkdir -p opfield-recovery/{app_data,relay_identity,relay_state,registry_data,registry_auth,redis_data}
cp .env docker-compose.yml opfield-recovery/
chmod 700 opfield-recovery
chmod 600 opfield-recovery/.env

docker compose -f docker-compose.yml stop app relay registry
docker compose -f docker-compose.yml exec -T postgres \
  pg_dump -U opfield -d opfield -Fc > opfield-recovery/postgres.dump
docker compose -f docker-compose.yml stop redis
docker compose -f docker-compose.yml cp --archive app:/var/lib/opfield/. opfield-recovery/app_data/
docker compose -f docker-compose.yml cp --archive app:/var/lib/opfield-relay/. opfield-recovery/relay_identity/
docker compose -f docker-compose.yml cp --archive relay:/var/lib/opfield-relay/state/. opfield-recovery/relay_state/
docker compose -f docker-compose.yml cp --archive registry:/var/lib/registry/. opfield-recovery/registry_data/
docker compose -f docker-compose.yml cp --archive app:/var/lib/opfield-registry-auth/. opfield-recovery/registry_auth/
docker compose -f docker-compose.yml cp --archive redis:/data/. opfield-recovery/redis_data/
docker compose -f docker-compose.yml start redis registry app relay

La base de datos y su rol se llaman opfield; una instalación que todavía no se ha trasladado desde /opt/gateway usa gateway para ambos.

Copia opfield-recovery a un almacenamiento cifrado fuera del host y verifica allí su suma de comprobación. Este ejemplo no hace copia de seguridad de las bases de datos gestionadas en nodos Storage; protege sus datos con copias de seguridad de bases de datos o con las herramientas nativas del motor.

Para restaurar en un host limpio y compatible, restaura primero .env y el mismo archivo Compose, crea después los contenedores detenidos, copia los datos persistentes, arranca PostgreSQL e importa el volcado antes de arrancar el resto del plano de control:

docker compose -f docker-compose.yml create

docker compose -f docker-compose.yml cp --archive opfield-recovery/app_data/. app:/var/lib/opfield
docker compose -f docker-compose.yml cp --archive opfield-recovery/relay_identity/. app:/var/lib/opfield-relay
docker compose -f docker-compose.yml cp --archive opfield-recovery/relay_state/. relay:/var/lib/opfield-relay/state
docker compose -f docker-compose.yml cp --archive opfield-recovery/registry_data/. registry:/var/lib/registry
docker compose -f docker-compose.yml cp --archive opfield-recovery/registry_auth/. app:/var/lib/opfield-registry-auth
docker compose -f docker-compose.yml cp --archive opfield-recovery/redis_data/. redis:/data

docker compose -f docker-compose.yml up -d postgres
docker compose -f docker-compose.yml cp opfield-recovery/postgres.dump postgres:/tmp/opfield.dump
docker compose -f docker-compose.yml exec -T postgres \
  pg_restore -U opfield -d opfield --clean --if-exists /tmp/opfield.dump

docker compose -f docker-compose.yml up -d redis registry app relay

Usa primero la misma versión. Verifica el inicio de sesión, el descifrado de los secretos, la identidad de Relay y reconexiones nuevas de los nodos antes de intentar una actualización. La propiedad de los archivos puede variar entre hosts; si un servicio informa de errores de permisos, compara la propiedad dentro de los contenedores original y restaurado en lugar de aplicar permisos de escritura amplios.

Procedimiento de actualización de Opfield

1. Lee las notas de la versión y las versiones intermedias necesarias.
2. Confirma el canal de actualización activo y la versión de destino y, para una instalación que tiene o tuvo un plan de pago, que Opfield puede llegar al servicio de licencias; consulta Requisitos previos de la actualización en la 2.11. Al actualizar desde la 2.10, sigue antes Actualización desde la 2.10.
3. Verifica las copias de seguridad recientes de PostgreSQL y de los volúmenes persistentes.
4. Registra las versiones actuales de Opfield, Relay y los daemons y los digests de las imágenes.
5. Confirma el estado de PostgreSQL, Redis, Relay y el disco.
6. Pon los servicios de cara a los clientes en mantenimiento solo cuando la actualización lo requiera.
7. Aplica la actualización compatible sin sustituir los volúmenes persistentes ni las claves maestras.
8. Espera a que Opfield esté listo y a que terminen las migraciones del esquema.
9. Verifica Relay, el inicio de sesión, el arranque del Dashboard, las reconexiones de los nodos, las Routes y las vinculaciones de bases de datos.
10. Retira el mantenimiento solo tras la verificación externa.

No trates un contenedor en ejecución como una actualización correcta. La aplicación debe descifrar los secretos existentes, leer el estado anterior, conciliar los servicios en segundo plano y exponer caminos de clientes en buen estado.

Requisitos previos de la actualización en la 2.11

Cada actualización de Opfield autoriza primero la versión de destino con el servicio de licencias. Opfield mantiene una lista firmada de las direcciones del servicio y usa la que responda, normalmente license.opfield.dev. LICENSE_SERVICE_URL en .env, por ejemplo un proxy de salida, se prueba primero. Esto se aplica a las actualizaciones iniciadas desde la consola y a volver a ejecutar el instalador. Opfield verifica la versión firmada antes de cambiar el host:

• Instalaciones de pago: una instalación que tiene o tuvo una activación de pago (incluida una caducada, revocada, transferida o desactivada) recibe el commercial core de la versión de destino, de modo que sus recursos de pago existentes siguen funcionando tras la actualización. Opfield verifica la firma, la versión, los tamaños y los hashes del core, y solo acepta la autorización como un estado de licencia firmado para esa petición. Una instalación así necesita el servicio de licencias durante la actualización: si no se puede llegar al servicio, rechaza la versión o devuelve un estado que no supera la verificación, la actualización se detiene antes de cualquier cambio y sigue funcionando el Opfield actual. Opfield nunca sustituye silenciosamente una instalación de pago por Community, así que permite el acceso saliente al servicio de licencias durante las ventanas de actualización.

• Instalaciones Community: una instalación que nunca tuvo un plan de pago se actualiza como Community. Cuando no tiene clave de licencia, ni plan de pago en su estado de licencia, ni commercial core en el host, también se actualiza mientras no se puede llegar al servicio de licencias, porque no descarga nada privado. Un rechazo o un estado de licencia que no supera la verificación siguen deteniendo la actualización.

• Operaciones en curso: tras descargar las imágenes y antes de cambiar el host, Opfield espera a que terminen los trabajos de orquestación en curso y en cola: los despliegues blue/green y el vaciado de sus slots anteriores, las operaciones de Compose, las acciones de Workload Availability, las migraciones y los despliegues de builds. La espera dura hasta 15 minutos por defecto, o hasta el plazo más largo que anuncien los trabajos en curso, y como máximo 60 minutos. La pantalla de actualización enumera las operaciones a las que espera. Los trabajos de orquestación nuevos iniciados durante la espera se rechazan con OPFIELD_UPDATING. Un administrador puede terminar antes la espera con Update now; Opfield reanuda o concilia entonces las operaciones interrumpidas tras el reinicio.

• Espacio libre en disco: antes de sustituir la aplicación, la actualización hace una instantánea de la base de datos de Opfield y necesita espacio libre para ella en el sistema de archivos que contiene el directorio de Opfield: el tamaño de la base de datos más un 10 % más 256 MiB. Con menos espacio, la actualización se detiene antes de cualquier cambio, y los logs del contenedor de actualización indican cuánto espacio se necesita.

La imagen y el commercial core anteriores se conservan para que una actualización fallida pueda revertirse. Consulta Commercial core para saber cómo se entregan las funciones de pago.

La espera de las operaciones en curso, la comprobación del espacio en disco y la instantánea de la base de datos que se describe a continuación pertenecen al actualizador de la versión en ejecución. Se aplican a las actualizaciones iniciadas desde la 2.11, no a la actualización desde la 2.10; consulta Actualización desde la 2.10.

Reversión automática e instantánea de la base de datos

Justo antes de que arranque la nueva versión, la actualización escribe una instantánea de la base de datos de Opfield en formato personalizado de pg_dump en .opfield-foundation-backups/pre-update-<time>/opfield-db.dump, en el directorio de Opfield, junto al .env y el docker-compose.yml guardados. Si la nueva versión no llega a estar en buen estado en unos cinco minutos, el contenedor de actualización revierte: restaura .env y docker-compose.yml, detiene todos los servicios de Compose excepto postgres, elimina la base de datos de Opfield y la vuelve a crear a partir de la instantánea (las actualizaciones iniciadas desde una versión anterior a la 2.12.1 escriben .gateway-foundation-backups/pre-update-<time>/gateway-db.dump). Así, la versión anterior nunca se ejecuta sobre un esquema modificado por las migraciones de la nueva versión. Los datos escritos después de la instantánea se pierden.

La instantánea se elimina cuando la actualización o la restauración tienen éxito, y una actualización posterior elimina cualquier instantánea sobrante de más de 7 días. Si no se puede eliminar la base de datos migrada, la versión anterior arranca sobre ella como antes y la instantánea se conserva. Si la restauración falla después de la eliminación, Opfield se queda detenido y la instantánea se conserva: corrige la causa que muestran los logs del contenedor de actualización y restaura después desde el directorio de Opfield:

docker compose exec -T postgres psql -U opfield -d postgres -c 'DROP DATABASE IF EXISTS opfield WITH (FORCE)'
docker compose exec -T postgres pg_restore --create --exit-on-error -U opfield -d postgres < .opfield-foundation-backups/pre-update-<time>/opfield-db.dump
docker compose up -d

La instantánea solo protege la propia actualización. Conserva también las copias de seguridad de PostgreSQL del conjunto de recuperación.

Actualización desde la 2.10

La actualización desde la 2.10.x la ejecuta el actualizador de la 2.10.x. No espera a las operaciones en curso ni hace una instantánea de la base de datos de Opfield, así que prepárala tú mismo.

Antes de actualizar

1. En el directorio de Opfield (/opt/gateway por defecto), haz una copia de seguridad de la base de datos y guarda una copia de .env, que contiene PKI_MASTER_KEY:

   docker compose exec -T postgres pg_dump -Fc -U gateway gateway > gateway-2.10.dump
   cp .env env-2.10.backup

2. Evita los despliegues, las copias de seguridad y las migraciones de Docker mientras se ejecuta la actualización.

3. En una instalación de pago, asegúrate de que el host de Opfield puede llegar al servicio de licencias: la actualización descarga el commercial core firmado de la 2.11 y se detiene antes de sustituir la aplicación si no puede. Las instalaciones Community que nunca tuvieron un plan de pago se actualizan sin él.

4. En Community, lee Actualización de una instalación Community desde la 2.10: desde la 2.11, las bases de datos (incluidas las conexiones externas guardadas en la 2.10), el almacenamiento, la integración con GitLab y AI Workspace Plan Mode, Scenarios y Sandboxes requieren Personal o superior. Sus registros se quedan en la base de datos y vuelven a ser utilizables con una clave Personal o superior.

La actualización aplica las migraciones de la base de datos de la 2.11. Los datos existentes que la 2.11 ya no permite, como dos cargas de trabajo en un mismo puerto del host de un nodo, dos Routes activadas con el mismo nombre en un nodo o ejecuciones de copias de seguridad activas duplicadas, se marcan en el registro de auditoría en lugar de hacer fallar la actualización; consulta Conflictos resueltos por la actualización a la 2.11.

Si la actualización se revierte, la 2.10.x vuelve a arrancar sobre la base de datos ya migrada y conserva sus permisos y una licencia válida; volver a actualizar restablece todo lo que tenía la 2.11. Corrige la causa que muestran los logs del contenedor de actualización y vuelve a actualizar. Para volver en su lugar al estado anterior a la actualización, vuelve a poner el .env guardado, detén todos los servicios excepto postgres (docker compose stop app relay registry redis), restaura gateway-2.10.dump con los comandos DROP DATABASE y pg_restore de Reversión automática e instantánea de la base de datos y ejecuta docker compose up -d.

Orden de actualización

1. Actualiza Opfield.
2. Actualiza los daemons de los nodos con Nodes > Update Nodes, que enumera cada nodo Docker, Nginx, Storage y Monitoring que tiene un daemon más reciente y actualiza juntos los seleccionados.
3. Actualiza el Relay Pool con Settings > General > Update Relay Pool.

No actualices los daemons de los nodos ni los Relays antes que Opfield: el Relay de la 2.11 requiere Opfield 2.11, y muchas funciones y correcciones de la 2.11 necesitan las versiones 2.11 de Docker, Nginx y Relay. Los Relays de la 2.10 mantienen el lease de 15 minutos de la política de relay hasta que se actualizan.

Tras las actualizaciones de los daemons y de Relay:

• La primera aplicación de un proyecto Compose, incluso de una revisión sin cambios, recrea sus servicios una vez, porque reciben los nuevos ajustes de logs y una etiqueta con el digest de su propia configuración; las revisiones posteriores solo recrean los servicios que cambian; consulta Configuración de Compose compatible. Los routers de los Deployments dejan de limitar el tamaño de los cuerpos de las peticiones en su siguiente despliegue, cambio de slot o reinicio.
• Las políticas de Docker Availability pasan solas al modo lease cuando todos los nodos Docker, nodos Ingress y Relays de la carga de trabajo han ejecutado la 2.11 durante 2 minutos. Cada nodo Docker necesita el lease watchdog: lo instala el instalador de nodos Docker, y un daemon de Docker 2.11 que se ejecuta como root con systemd u OpenRC lo instala por sí mismo. En caso contrario, la política enumera el nodo en Excluded nodes; vuelve a ejecutar allí el instalador de nodos Docker con sudo y el mismo --user. En modo lease, cada nodo de la política debe llegar a todos los Relays. Consulta Conmutación por error del plano de datos.
• Los nodos Storage necesitan HTTPS saliente hacia ghcr.io para descargar el runner de copias de seguridad. Las demás imágenes de ejecución de terceros proceden primero del mirror de Opfield en ghcr.io y, como alternativa, de Docker Hub.
• Las conexiones externas de PostgreSQL y clave-valor con TLS creadas antes de la 2.11 siguen sin verificar y muestran una advertencia. Ejecuta la comprobación de un clic o añade la CA privada; consulta Verificación del certificado TLS.
• Los modelos Claude Fable 5.1 y Opus 5.5 publicados en Opfield Inference antes de la 2.11 tienen las herramientas desactivadas; ábrelos y vuelve a guardarlos.

Permisos tras la actualización

• Los grupos, los usuarios, los tokens de API y las concesiones OAuth que tenían un nombre de ámbito retirado recibieron su sustituto, y los nombres retirados se siguen aceptando como entrada durante dos versiones. Los scripts que leen los nombres de los ámbitos deben esperar los nombres nuevos. Consulta Nombres de ámbitos retirados.
• Algunos sustitutos son más amplios que el ámbito antiguo. Revisa los grupos, los permisos de los usuarios, los tokens de API y las concesiones OAuth que tenían alguno de estos:
  • integrations:gitlab:ci:edit, :variables:edit, :variables:delete, :webhooks:manage y :registry:manage pasaron a ser integrations:gitlab:repo:write, que además confirma archivos en el repositorio y cambia la configuración de CI, las variables de CI/CD, los webhooks y los ajustes del registro. Un token de CI que solo limpiaba el registro ahora puede hacer push de commits.
  • integrations:gitlab:ci:view pasó a ser integrations:gitlab:repo:read, que además lee los archivos del repositorio.
  • integrations:gitlab:sync, :github:sync y :git:sync pasaron a ser el permiso manage del conector: ajustes, tokens, lista de permitidos, prueba y eliminación.
  • nodes:config:edit pasó a ser nodes:manage, que además instala Secure Runtime, cambia las direcciones de servicio y enciende, redimensiona y restaura instantáneas de las VM alojadas.
  • proxy:advanced:bypass y proxy:raw:bypass pasaron ambos a ser proxy:unrestricted, así que cualquiera de los dos levanta ahora ambas restricciones.
  • proxy:templates:create, :edit y :delete pasaron a ser proxy:templates:manage, todas las operaciones con plantillas de nginx.
  • notifications:alerts:create, :edit y :delete pasaron a ser notifications:alerts:manage, y notifications:webhooks:create, :edit y :delete pasaron a ser notifications:webhooks:manage, que además revela las URL, las cabeceras y los payloads de entrega de los webhooks.
  • docker:containers:folders:manage pasó a ser docker:folders:manage, que cubre las carpetas de todos los tipos de recursos de Docker.
• integrations:gitlab:variables:view pasó a ser integrations:gitlab:repo:read y ya no lee los valores de las variables de CI/CD; leer los valores requiere integrations:gitlab:repo:write.
• Todos los permisos de acción excepto los de creación implican ahora el permiso de visualización de su familia con el mismo calificador: un grupo o un token que solo tenía un permiso de eliminación, edición, gestión o ejecución ahora también puede listar y ver esos recursos. Revisa las concesiones que solo permiten eliminar.
• Los grupos integrados reciben los nuevos permisos automáticamente. Los grupos personalizados no: concede diagnostics:view y diagnostics:logs para el diagnóstico de Opfield, databases:backups:view, :manage, :run y :restore, nodes:backups:execute, y storage:view, :create, :edit, :delete, :iam, storage:objects:* y storage:credentials:use donde haga falta. storage:credentials:reveal implica storage:credentials:use.
• Los tokens nunca ven más que la cuenta que los emitió, y un permiso de creación ya no cuenta como visualización cuando se delega el acceso: los tokens de los usuarios cuyo acceso se ha reducido pierden ese acceso.
• Los orígenes Git guardados después de la actualización solo se construyen automáticamente mientras la cuenta que los guardó conserve use sobre el repositorio; los webhooks y los despliegues automáticos comprueban la cuenta que los configuró.
• Desplegar o actualizar un Deployment con una imagen, un comando o un entorno nuevos, y actualizar la imagen de un contenedor, requieren los permisos de entorno y de secretos; conectar un contenedor a redes requiere acceso de edición a las redes. El SQL con ámbito de escritura en un PostgreSQL externo ejecuta una sentencia cada vez, y los cambios de esquema o de roles requieren el permiso de administración.
• Los límites del plan Community son 25 nodos gestionados, 3 usuarios y 1 grupo de permisos personalizado (100, 10 y 5 en la 2.10). No se elimina nada existente; crear más se rechaza.

Cambios de comportamiento

• TLS para nombres desconocidos. Los nodos Ingress rechazan los handshakes TLS para los nombres de host que no sirve ninguna Route. Se rechazan los clientes o los balanceadores de carga que se conectan por IP mediante HTTPS sin SNI o que dependen de un sitio predeterminado. Los nodos cuyo nginx ya tiene su propio servidor predeterminado en el puerto 443 omiten esto con una advertencia. Consulta Routes.
• Restricciones de Compose. Los proyectos Compose no pueden usar la red del host ni las redes internas de Opfield (gateway-secure-links, gateway-db-*, gateway-storage-*), fijar las etiquetas reservadas de Opfield ni fijar variables del cliente Docker como DOCKER_HOST, DOCKER_CONFIG, BUILDKIT_* y COMPOSE_*. Los proyectos existentes que incumplen estas reglas siguen funcionando y se pueden detener y eliminar, pero una revisión nueva, una aplicación, un inicio o un reinicio se rechazan hasta que se editan, incluida la primera aplicación tras la actualización del daemon de Docker. Consulta Configuración de Compose compatible.
• Comprobación de directivas de nginx. El contenido de las plantillas de nginx y la configuración avanzada de las Additional Routes se comprueban como la configuración de las Routes: sin proxy:unrestricted, las directivas denegadas se rechazan y los logs de nginx solo se pueden escribir en /var/log/nginx. Las plantillas guardadas antes de la actualización siguen generándose tal como se guardaron.
• Lease de la política de relay. Los Relays siguen funcionando sin Opfield durante 72 horas por defecto (Settings > Relay, de 1 hora a 7 días); consulta Relays sin Opfield.
• Mantenimiento (housekeeping). El historial de operaciones (builds terminados con sus logs, operaciones de Compose, Availability y hosting y entregas de webhooks) se conserva durante 90 días, y se purgan las concesiones OAuth caducadas y los clientes OAuth que nunca completaron la autorización. Cambia Settings > Features > Housekeeping antes de la primera ejecución si necesitas un historial más largo; consulta Mantenimiento y retención.
• Renovación de la PKI interna. Los certificados de la PKI interna vinculados a Routes se vuelven a emitir automáticamente antes de su caducidad cuando Opfield tiene la clave privada; la renovación automática se activa para los vínculos existentes.
• Rotación de los tokens de GitLab. Opfield rota los tokens de GitLab con el ámbito api o self_rotate que caducan en los 14 días siguientes, y revoca el token antiguo. Da a Opfield un token propio si el mismo token se usa en otros sitios; consulta Caducidad y rotación de los tokens.
• Ajustes. Guardar los ajustes solo reinicia Opfield cuando se cambia el HTTPS interno, o cuando cambia la Public URL con el HTTPS interno activado. Los métodos de inicio de sesión, MFA, el proveedor OIDC y el aprovisionamiento de identidades pasaron a Settings > Authentication, el logging estructurado está en Settings > Features, y Authentication email (SMTP) ahora se llama SMTP configuration.
• API. Las lecturas de nodos ya no incluyen material de los tokens de registro, una actualización vacía de un nodo devuelve 400 y un ID mal formado devuelve 404. Los cambios de entorno, de recreación y de revisión de Compose devuelven 409 mientras el despliegue de un build ocupa el destino. Una ruta /api desconocida devuelve un 404 en JSON.
• Docker Availability ya no está marcado como Tech Preview, y los builds ya no se pueden fijar en el Dashboard ni en la barra lateral.

Conflictos resueltos por la actualización a la 2.11

Opfield 2.11 aplica varias reglas de unicidad en su base de datos y no solo en el código de la aplicación, de modo que también se cumplen cuando varios procesos de Opfield atienden peticiones a la vez. La actualización nunca falla por datos existentes que incumplan alguna de ellas: la migración 0207 conserva el registro más antiguo, marca o renombra los demás y escribe cada caso en el registro de auditoría. Tras la actualización, busca estas acciones en el registro de auditoría y resuelve lo que indiquen.

Regla tras la actualización	Qué hizo la actualización con los conflictos existentes	Acción de auditoría
Dos Routes activadas en un nodo Ingress no pueden servir el mismo nombre (409 PROXY_HOST_DOMAIN_CONFLICT)	La Route más antigua conserva el nombre. Las posteriores conservan su configuración y siguen marcadas hasta que cambian sus nombres o su nodo. Una vez desactivada, una Route así no se puede volver a activar mientras otra Route activada sirva el nombre. nginx solo sirve una de ellas, así que quita el nombre de una Route o desactívala	proxy_host.domain_conflict
Una política de copia de seguridad tiene una sola copia en cola o en ejecución (409 BACKUP_ALREADY_RUNNING), y se ejecuta a la vez una sola restauración hacia un nombre de base de datos nueva concreto (409 BACKUP_RESTORE_ALREADY_RUNNING)	Continúa una ejecución activa: una en ejecución antes que una en cola y, si no, la más reciente. Las demás se marcan como fallidas con la fase superseded, liberan su ejecutor y se cancelan sus runners	database.backup.superseded
Los nombres de los almacenamientos gestionados son únicos por nodo Storage (409 MANAGED_STORAGE_NAME_IN_USE)	El clúster más antiguo conserva el nombre. Los posteriores, y sus conexiones de almacenamiento, se renombran con el primer sufijo libre -2, -3, …	storage.managed.renamed_duplicate
Un puerto del host de un nodo pertenece a un único Deployment, almacenamiento gestionado o base de datos gestionada (409 DEPLOYMENT_HOST_PORT_IN_USE, MANAGED_STORAGE_PORT_CONFLICT o MANAGED_DATABASE_PORT_CONFLICT)	La carga de trabajo más antigua conserva el puerto. Las posteriores siguen funcionando y quedan marcadas; mueve una de ellas a otro puerto	node.host_port_conflict
Un certificado que usa una Route no se puede eliminar (409 CERT_IN_USE)	Nada que resolver: la base de datos aplica ahora la comprobación existente	—

Los puertos del host que elige el daemon de Docker para una base de datos gestionada evitan los puertos que reservan otras cargas de trabajo en ese nodo. Una base de datos gestionada cuyo puerto publicado todavía entra en conflicto con la reserva de otra carga de trabajo lo indica en managed.hostPortConflicts de su conexión de base de datos, con el puerto y la carga de trabajo que lo ocupa.

La actualización no elimina Routes, cargas de trabajo, almacenamiento ni copias de seguridad, y no detiene las cargas de trabajo en ejecución. Revisa los clientes que renombran almacenamientos gestionados o los buscan por nombre por si afectan a los clústeres renombrados.

Actualización a la 2.11.1

La 2.11.1 traslada las vinculaciones de bases de datos y los enlaces de almacenamiento a un único conector de Secure Links compartido por nodo Docker y añade los container links. Actualiza primero Opfield y después los daemons de Docker. Lo que ocurre en cada nodo tras la actualización de su daemon de Docker:

• Cada carga de trabajo con una vinculación de base de datos se recrea una vez, de una en una en cada nodo, y la siguiente cuando la anterior funciona en buen estado. Los Deployments se despliegan en blue/green sin tiempo de inactividad; los Containers independientes y los servicios de Compose se reinician una vez, así que programa en consecuencia la actualización de los nodos que ejecutan esas cargas de trabajo.
• Cada carga de trabajo con un enlace de almacenamiento creado antes de la 2.11.1 se recrea una vez justo después de que cambie su enlace. Los enlaces creados en la 2.11.1 no necesitan recreación.
• Los nombres de las variables y las credenciales no cambian, y no hay que hacer nada a mano. No elimines tú mismo las redes de enlace ni los contenedores antiguos.
• Revertir un daemon de Docker a la 2.11.0 devuelve sus enlaces automáticamente, con una recreación por carga de trabajo. Se recrean como máximo cuatro cargas de trabajo a la vez por nodo, el límite del daemon para comandos simultáneos, así que en un nodo con muchos Deployments enlazados los últimos se vuelven a conectar un poco más tarde.
• Las actualizaciones posteriores del conector conservan las conexiones abiertas de los enlaces: desde la 2.11.4, el conector anterior las entrega al nuevo sin reconexión. Un conector anterior a la 2.11.4 las conserva hasta una hora y después las cierra una vez; una tercera actualización dentro de esa hora cierra de inmediato las conexiones del conector más antiguo.

Las redes de enlace nuevas usan su propio rango de direcciones, 10.213.x.x (un /16) por defecto. Si se solapa con una red a la que tus nodos llegan a través de su ruta predeterminada, fija docker.secure_links.subnet_pool antes de actualizar el daemon de Docker, para que los enlaces trasladados ya usen tu rango (los daemons anteriores ignoran la clave); consulta Conector compartido y redes de enlace.

Actualización a la 2.12

La 2.12 añade las Apps, las bases de datos y el almacenamiento en varios servidores, los almacenes clave-valor Valkey, los relays protegidos y Opfield Cloud. A una instalación 2.11 se le ofrece primero la 2.11.5 y después la 2.12. Actualiza primero Opfield, después los daemons de los nodos y luego el Relay Pool. Qué esperar:

• Direcciones de los servicios. Opfield 2.12 lee las versiones y los instaladores de nodos de get.opfield.dev y usa las direcciones del servicio de licencias indicadas en Requisitos previos de la actualización. Permite get.opfield.dev y license.opfield.dev en una lista de salida permitida antes de la actualización.
• Repositorio de imágenes. Las imágenes se publican en ghcr.io/opfield/opfield. Para una actualización manual, fija GATEWAY_IMAGE_REF en .env a una imagen de allí (OPFIELD_IMAGE_REF desde la 2.12.1).
• Barra lateral más corta. Domains, Ingress Groups, Access Lists y las Templates de nginx son pestañas de Routes; los certificados SSL, Authorities, PKI Certificates y las Templates de certificados son pestañas de Certificates; Profile está en el menú de la cuenta. Las direcciones antiguas de las páginas abren la pestaña correspondiente.
• Los almacenes clave-valor conservan Redis. Los almacenes clave-valor gestionados existentes siguen ejecutando Redis y siguen funcionando. Los almacenes nuevos ejecutan Valkey. Migra un almacén existente con Move to Valkey cuando te convenga y haz después una copia de seguridad nueva: una copia de seguridad solo se restaura en el motor del que se tomó.
• Daemons de Docker. Move to Valkey, ejecutar una base de datos o un almacenamiento en varios servidores y el aislamiento de contenedores mediante el kill switch de una app necesitan el daemon de Docker 2.12 en los nodos Storage y Docker implicados; Opfield te pide que actualices un daemon demasiado antiguo.
• Relays. El modo protegido y alojar testigos de bases de datos necesitan el relay de la 2.12. Ejecuta la actualización del Relay Pool después de los daemons.
• Nada se mueve solo. Los recursos existentes no se unen a ninguna app, y ninguna base de datos ni ningún almacenamiento empiezan a ejecutarse en varios servidores hasta que lo activas.

Actualización a la 2.12.1

La 2.12.1 completa el paso a los nombres de Opfield. Cuando la actualización a la 2.12.1 se ha asentado (unos diez minutos después de que la nueva versión esté en buen estado, para que haya terminado la reversión automática de la versión anterior), una instalación hecha antes de la 2.12.1 se traslada a sí misma una vez:

• el directorio /opt/gateway pasa a ser /opt/opfield; /opt/gateway se mantiene como un enlace a él;
• el proyecto Compose, los contenedores (opfield-app-1, …) y la red (opfield_default) reciben el nuevo nombre;
• la base de datos y su rol se renombran a opfield, y los ajustes de .env pasan a llamarse OPFIELD_*;
• el ClickHouse local gestionado pasa a ser opfield-clickhouse con la base de datos opfield_logs;
• los volúmenes de Docker conservan sus nombres (gateway_gateway_data, gateway_postgres_data, …): docker-compose.yml los asocia por nombre, así que no se copia nada y no se necesita espacio en disco adicional.

Durante el traslado, Opfield no está disponible durante aproximadamente un minuto, y los Secure Links a través del relay del host de Opfield se detienen una vez durante unas decenas de segundos mientras se recrea el stack. Las operaciones de orquestación en curso terminan primero, como antes de una actualización. Cuando actualizas con el instalador, este traslada la instalación justo después de la actualización e imprime el nuevo directorio.

El traslado se ejecuta en el contenedor opfield-host-move y registra cada paso en .opfield-host-move/state.json del directorio de instalación. Tras un fallo o un reinicio, Docker lo vuelve a arrancar y continúa donde se detuvo. Si un paso sigue fallando, el traslado deshace lo que hizo y Opfield funciona desde /opt/gateway como antes; lo vuelve a intentar al cabo de seis horas, como máximo tres veces. docker logs opfield-host-move muestra cada paso. Para volver a intentarlo de inmediato:

docker rm opfield-host-move
cd /opt/gateway && curl -fsSL https://get.opfield.dev | bash

Volver a la 2.12.0 después del traslado no es compatible. Las System CA muestran sus nuevos nombres (Opfield Node CA, Opfield Database CA, Opfield Storage CA); sus certificados se mantienen, así que los nodos, los relays y tus aplicaciones que confían en ellas siguen funcionando. Los scripts del instalador que fijan variables GATEWAY_* siguen funcionando; los nombres OPFIELD_* prevalecen cuando se fijan ambos.

Actualizaciones de los daemons y de Relay

Actualiza un dominio de fallo cada vez. Para los miembros del Relay Pool, vacía, actualiza, verifica y devuelve cada miembro antes de pasar al siguiente. Para los nodos normales, verifica los recursos específicos del rol tras la reconexión. No actualices a la vez todos los miembros de Ingress, Storage o Relay salvo que el entorno tenga un camino de recuperación probado de forma independiente.

Nodes > Update Nodes actualiza juntos los daemons de varios nodos, y Opfield rechaza las actualizaciones de daemons para los nodos desconectados, los nodos Relay y los nodos que ya ejecutan la versión; consulta Actualizaciones de los daemons. Tras una actualización de Opfield, actualiza los daemons de los nodos antes que el Relay Pool, sobre todo cuando vienes de la 2.10: la actualización del Relay Pool también actualiza el Relay local, que se recrea de inmediato mientras ejecuta una versión anterior a la 2.11.1, y los daemons actuales se vuelven a conectar a él en una fracción de segundo; consulta Relay y Relay Pool. Opfield ordena las actualizaciones de los daemons y de Relay de los nodos que participan en la conmutación por error del plano de datos, un miembro de cada política de Availability a la vez, de modo que una actualización puede esperar a sus pares de lease.

Procedimiento de restauración

1. Aprovisiona un entorno de Opfield limpio y compatible.
2. Restaura PostgreSQL y los volúmenes persistentes desde el mismo punto de recuperación.
3. Restaura el material de cifrado, de PKI y de identidad de Relay con sus permisos originales.
4. Arranca las dependencias internas, Opfield y Relay en el orden documentado.
5. Verifica el inicio de sesión y el descifrado antes de permitir cambios.
6. Deja que los nodos gestionados se vuelvan a conectar con sus identidades existentes.
7. Concilia las Routes, los certificados, las cargas de trabajo, las vinculaciones de bases de datos, las notificaciones y las integraciones.
8. Restaura las bases de datos de las aplicaciones mediante los procedimientos nativos de cada motor cuando sea necesario.
9. Confirma la continuidad de la auditoría y registra el evento de recuperación.

Si solo está disponible una parte del conjunto de recuperación, detente y evalúa la consecuencia. Generar claves maestras o identidades sustitutas puede dejar huérfanos para siempre el estado cifrado o los nodos gestionados.

Decisión de reversión

Decide el desencadenante de la reversión antes de empezar una actualización: una migración fallida, la imposibilidad de descifrar los secretos existentes, un fallo de autorización de Relay, un estado incompatible de los daemons, Routes de clientes rotas u otra condición medible. Conserva las referencias de las imágenes aprobadas anteriores y la copia de seguridad correspondiente hasta que la nueva versión complete su ventana de observación.

La reversión de la aplicación y la de los datos son cosas distintas. Aparte de la reversión automática de una actualización que nunca llegó a estar en buen estado, volver a una imagen anterior de Opfield no deshace una migración del esquema de PostgreSQL ya completada, y devolver una carga de trabajo a un artefacto anterior no revierte los datos mutables de los volúmenes ni de las bases de datos. Sigue las indicaciones de compatibilidad específicas de cada versión y restaura los datos solo desde un punto de recuperación coordinado cuando la integridad lo exija.

Validación del operador tras la actualización

Capa	Prueba necesaria
Identidad	Los usuarios existentes inician sesión; MFA, OAuth y el descifrado funcionan
Plano de control	Las migraciones han terminado; los planificadores en segundo plano y la auditoría continúan
Relay y nodos	Las versiones son compatibles; los nodos se vuelven a conectar con un inventario nuevo
Tráfico de clientes	El DNS externo, TLS, el estado de las Routes y la respuesta de la aplicación funcionan
Datos	Las bases de datos gestionadas están en buen estado y las vinculaciones de las aplicaciones pueden hacer consultas
Automatización	Funcionan los builds, los webhooks, las notificaciones y los conectores de código que usa la instalación

Conserva el registro de la actualización con la hora de inicio y de fin, las versiones, los digests de las imágenes, los identificadores de las copias de seguridad, el operador, las excepciones y la verificación final. Así, la siguiente actualización será un procedimiento controlado en lugar de una reconstrucción a partir del historial de la shell.