Actualizaciones de nodos y comportamiento sin conexión

Los servicios aplicados siguen funcionando en un nodo mientras se actualiza o está sin conexión; lo que se detiene es la capacidad de Opfield de cambiarlos u observarlos en tiempo real. Conserva la identidad duradera del nodo, restablece la sesión autenticada y comprueba que se han conciliado todos los recursos dependientes, no solo que el estado ha vuelto a verde.

Una actualización o una recuperación está completa cuando hay una conexión nueva, inventario, métricas y capacidades actualizados, los caminos de las cargas de trabajo representativas funcionan y no queda ninguna operación interrumpida sin explicar.

Detalles para operadores: actualización y reconexión

Comprueba la compatibilidad antes de actualizar Opfield, Relay y los daemons. Aplica las actualizaciones firmadas de los daemons a través del ciclo de vida del nodo y verifica la reconexión, la versión, el inventario, los logs, el estado y las vinculaciones gestionadas.

Cuando un nodo se desconecta, sus cargas de trabajo siguen funcionando localmente y los cambios de Opfield sobre él se desactivan. Diagnostica la disponibilidad del host, el servicio del daemon, la hora del sistema, la identidad del certificado, el DNS y el acceso saliente hacia Relay. Evita eliminar el registro del nodo mientras el daemon antiguo pueda volver a conectarse.

Tras la recuperación, verifica la conciliación del estado deseado de las Routes, las cargas de trabajo, las vinculaciones de bases de datos, el material de los certificados y la monitorización. Una conexión en verde por sí sola no demuestra que se hayan recuperado todos los recursos dependientes.

Lanzador de actualizaciones a prueba de fallos

En la 2.10, Docker, nginx, la monitorización y el supervisor de Relay recibieron un lanzador independiente. Cuando lo gestiona el lanzador, una actualización conserva el binario anterior y un journal en disco. El candidato debe informar de su preparación local y superar una ventana de estabilidad de 30 segundos antes de confirmarse; los candidatos fallidos se pueden revertir. El gestor de servicios supervisa el lanzador, que supervisa el proceso del daemon.

La preparación local no demuestra la conectividad con Relay ni el estado de las aplicaciones. Sigue verificando la versión, la reconexión, las capacidades del nodo y una operación real después de actualizar. Si el arranque del lanzador no está disponible y el daemon se ejecuta directamente, la protección de reversión del lanzador no está disponible.

Un daemon candidato que declara la preparación de la conexión de control también debe llegar a Opfield en los 3 minutos siguientes a su preparación local; si no, el lanzador restaura el daemon anterior. Opfield espera otro tanto (4,5 minutos) antes de dar por fallida la actualización; en ese caso, la reversión se muestra como “The daemon came back on … instead of …”.

El lanzador también se actualiza a sí mismo. Cuando un daemon actualizado está confirmado y conectado, el lanzador se sustituye en su sitio por el lanzador de esa versión y conserva su proceso, el daemon en ejecución y los sockets de escucha que mantiene. Solo lo hace con systemd u OpenRC; en modo manual, el nuevo lanzador arranca con el siguiente reinicio manual. Los detalles del nodo muestran la versión del lanzador.

Conexiones durante la actualización de un daemon

En un nodo Docker o nginx cuyo daemon admite el traspaso en vivo (2.11.4 y posteriores), una actualización conserva las sesiones de flujos de relay y los container links hacia un destino del mismo nodo: el nuevo proceso del daemon las asume tras una pausa de uno o dos segundos. Los flujos en bruto de pares más antiguos, los enlaces de PostgreSQL en los que el daemon abre TLS, las descargas y subidas del registro y las ejecuciones de copias de seguridad se siguen cortando. La primera actualización a un daemon con traspaso en vivo, y una reversión por debajo de él, cortan una vez las conexiones abiertas. Un nodo cuyo lanzador arrancó antes de la 2.11.4 reinicia una vez todo su servicio en su siguiente actualización del daemon, lo que también corta una vez las conexiones abiertas; las actualizaciones posteriores las conservan.

La página del nodo indica lo que haría ahora una actualización: The update keeps connections, N connections will be cut u Open connections are cut once. Last Update, en Runtime, muestra lo que conservó y cortó la última actualización.

Renovación de certificados

Opfield renueva sus certificados internos mientras se ejecuta, sin reiniciarse, y registra cada renovación en el registro de auditoría:

Certificado	Validez	Renovación
Listeners de Opfield y certificados de servicio y de cliente del Relay local	365 días	Se comprueba cada hora y se renueva 30 días antes de la caducidad; las conexiones existentes conservan el certificado antiguo hasta que se vuelven a conectar. Mientras existan tokens de registro sin usar, la renovación espera hasta los últimos 7 días, porque los comandos de instalación fijan la huella del certificado de Opfield; los comandos generados antes de una renovación deben generarse de nuevo
Un certificado proporcionado mediante GRPC_TLS_CERT	La que tú fijes	Opfield nunca lo renueva; se registra una advertencia diaria
Certificados de servidor de los Relays remotos	365 días	Se comprueba cada hora mientras el supervisor de Relay está conectado y se renueva 60 días antes de la caducidad, como máximo una vez al día
Certificados de cliente de los daemons en cada nodo	365 días	El daemon lo comprueba cada hora y lo renueva cuando queda un tercio de su vida útil, unos 120 días antes de la caducidad. Un intento fallido se reintenta a los 5, 10, 20 y 40 minutos y después cada hora. El daemon se vuelve a conectar para presentar el nuevo certificado
Certificado del proxy del registro en los nodos Docker	2 años	Se comprueba al arrancar el daemon y cada 12 horas, y se vuelve a emitir desde la misma CA cuando queda un tercio de su vida útil o 30 días; se sirve sin reinicio
Certificados TLS del almacenamiento gestionado y de las bases de datos gestionadas	La que fija Opfield	Se comprueban cada hora y se recargan en su sitio sin reinicio; consulta almacenamiento gestionado y bases de datos gestionadas

Un nodo debe seguir conectado para renovar su certificado. Como la renovación empieza meses antes de la caducidad, un certificado de nodo con menos de 30 días restantes significa que la renovación está fallando: Opfield genera una alerta de advertencia a los 30 días y una crítica a los 7 días. Asegúrate de que el nodo puede llegar a Opfield y ejecuta un daemon actual; cuando su certificado caduca, hay que volver a registrar el nodo.

Las CA del sistema que emiten estos certificados son válidas durante 10 años y todavía no tienen renovación automática. Los certificados que emiten terminan junto con la CA, y Opfield avisa 730, 365, 180, 60, 30 y 7 días antes de que caduque una CA del sistema. Consulta PKI interna.

Tokens de registro

Los tokens de registro son de un solo uso y caducan a los 7 días. Para un nodo que todavía está pendiente, New enrollment token emite un comando de instalación sustituto. Un nodo registrado no se puede volver a registrar en su sitio; solo los miembros de Relay admiten un nuevo registro. Consulta Relay y Relay Pool.

Actualizaciones de los daemons

Actualiza un nodo desde su página de detalle con Update, o varios a la vez con Nodes > Update Nodes. El diálogo enumera cada nodo cuyo daemon es más antiguo que la última versión de su tipo y actualiza juntos los seleccionados. Los nodos Relay no aparecen: se actualizan con el Relay Pool (Settings > General > Update Relay Pool), que los vacía de uno en uno. Opfield rechaza la actualización del daemon de un nodo que no está conectado, de un nodo Relay y de un nodo que ya ejecuta esa versión o una más reciente.

• Estado de la actualización. Un nodo conserva su estado de actualización en la lista y en su página, sin una insignia de actualización ni un parpadeo de desconexión mientras se actualiza. Una actualización fallida, revertida o que ha agotado el tiempo conserva su motivo en el nodo, que se muestra en Update Available, y un nodo que vuelve con su versión anterior se notifica como tal de inmediato.
• Pares de lease. Los nodos que comparten una política de Availability en modo lease se reinician uno tras otro; una actualización en cola muestra Queued con lo que está esperando. Consulta Actualizaciones y versiones mixtas.
• Tareas en ejecución. Una actualización espera primero a las tareas largas que se están ejecutando en el nodo: ejecuciones de copias de seguridad y restauraciones, builds de imágenes, migraciones de Docker, descargas de imágenes y acciones sobre contenedores, trabajos de copia de almacenamiento y exportaciones e importaciones de archivos de contenedores. Al cabo de 30 minutos sigue adelante de todos modos y el nodo conserva una advertencia; Update now la inicia de inmediato tras una confirmación, porque las tareas en ejecución pueden fallar.
• Reinicios de Opfield. Tras un reinicio de Opfield durante las actualizaciones de nodos, las actualizaciones en curso esperan a que sus nodos se vuelvan a conectar y terminan o fallan a tiempo, y las actualizaciones en cola se retoman. Opfield comprueba si hay actualizaciones de los daemons al arrancar y tras una actualización de Opfield.
• Conexiones rotas. Un daemon que ha preparado una autoactualización se reinicia en ella aunque su conexión con Opfield se haya roto durante la descarga.
• Instaladores. Los comandos de configuración de nodos y de Relay proceden de la propia versión de la instalación de Opfield en ejecución y se comprueban con las sumas de comprobación de esa versión, y los instaladores de daemons fijan el daemon más reciente de la línea de versiones de esa instalación, de modo que una instalación de Opfield nunca entrega instaladores de una línea de desarrollo más reciente.

Antes de una actualización

1. Lee las notas de la versión del componente y su mínimo de compatibilidad.
2. Confirma que el canal de actualización de la instalación es intencionado: Stable para las versiones de producción o Preview para las versiones preliminares aceptadas explícitamente.
3. Verifica que el nodo está en línea y no está ejecutando una operación de ciclo de vida en conflicto.
4. Registra su versión actual, sus capacidades, las cargas de trabajo activas y los errores recientes.
5. Para un Relay Pool, usa la actualización del Relay Pool, que vacía, actualiza y verifica un miembro cada vez.
6. Asegúrate de que un operador puede llegar al host si la recuperación automática falla.

Opfield y los daemons verifican los manifiestos firmados de las actualizaciones y las sumas de comprobación. No sustituyas una actualización firmada fallida por un binario sin firmar copiado de otro host.

Verificación de la actualización

Cuando se reinicie el daemon, verifica algo más que su versión:

• la reconexión autenticada y una última conexión reciente;
• un informe de capacidades completo;
• la actualización del inventario y de las métricas;
• el estado de los servicios específicos del rol;
• la conciliación de los Tasks pendientes;
• las Routes, los certificados, las cargas de trabajo, los proyectos Compose y las vinculaciones de bases de datos que pertenecen a ese nodo;
• que las alertas se generan o se resuelven como se espera.

Comportamiento sin conexión según la responsabilidad

Una conexión de control caída no detiene automáticamente los servicios del host. nginx, los contenedores, las bases de datos gestionadas y otros servicios aplicados previamente pueden seguir funcionando a partir del estado local. Opfield impide los cambios que requieren un propietario en vivo y muestra el inventario en caché solo para el diagnóstico.

Las vinculaciones de bases de datos pueden seguir funcionando a través de un camino de Relay y de base de datos en buen estado durante un reinicio solo de la aplicación Opfield; los Relays siguen admitiendo conexiones nuevas con su última política firmada durante el lease de la política. Una caída de Relay es distinta: interrumpe las nuevas admisiones de enlaces privados y el tráfico de control de los nodos gestionados aunque las cargas de trabajo locales sigan funcionando. Cuando Opfield vuelve, los daemons se reconectan en 15 segundos.

Reinicios del daemon de Docker

Reiniciar o actualizar el daemon de Docker no detiene los contenedores, y solo interrumpe brevemente el tráfico hacia ellos. Una actualización con traspaso en vivo conserva las conexiones abiertas, como se describe en Conexiones durante la actualización de un daemon; los puntos siguientes se aplican a los reinicios que no traspasan las conexiones:

• El daemon se conecta primero a Opfield y vuelve a registrar sus endpoints de Relay, en aproximadamente un segundo, en cuanto llegan las concesiones nuevas de Opfield. Después, Secure Runtime (gVisor) se vuelve a verificar en segundo plano. Hasta que termina, el nodo informa del último resultado verificado para la misma versión de runsc, o de un estado desconocido con el motivo verification_pending en el primer arranque de una versión nueva, de modo que la creación de cargas de trabajo seguras no oscila.
• Un reinicio o una actualización ordenados se anuncian. Antes de detenerse, el daemon comunica a los Relays que sus endpoints se están reiniciando, termina las peticiones de Secure Link en curso (como máximo 1 segundo) y cierra las conexiones inactivas entre peticiones. Los Relays conservan sus registros hasta 15 segundos hasta que se registra el siguiente proceso, y los nodos Ingress retienen las conexiones nuevas hacia él hasta 8 segundos en lugar de hacerlas fallar, de modo que un reinicio se percibe como un retraso de unos segundos y no como errores. Una réplica de Availability con otra réplica sirviendo no espera: sus peticiones van de inmediato a la otra réplica. Esto requiere Relays y daemons de nginx de esta versión; con Relays más antiguos, el nodo Ingress sigue reteniendo las conexiones nuevas hasta 3 segundos.
• El titular de un lease de Availability sigue sirviendo a lo largo de un reinicio en el mismo arranque: su lease sigue siendo válido, así que su copia vuelve a recibir tráfico en cuanto se registra el nuevo proceso.
• Un daemon que falla, o cuyo host deja de ser accesible, no se retiene: los Relays cortan su conexión en unos 3,5 segundos, y las peticiones pasan a otras ubicaciones donde las haya.
• Tras un reinicio del host, cada Secure Link se restablece por su cuenta: un enlace cuyo destino no ha vuelto se queda sin asociar hasta que su destino se ejecuta, y no bloquea a los demás.
• Un Docker Engine (dockerd) bloqueado no detiene el tráfico hacia los contenedores y los Deployments en ejecución: las conexiones de Secure Link, de bases de datos gestionadas y de almacenamiento esperan como máximo 300 milisegundos a que responda y usan después la última dirección que indicó, los enlaces siguen asociados cuando no responde a una sincronización, y los routers de los Deployments no usan ni el DNS de Docker ni un log de acceso. Una aplicación que escribe cada petición en la salida de su contenedor puede seguir bloqueándose mientras dockerd está congelado.
• Un nodo Storage o de bases de datos arranca aunque falte uno de sus contenedores gestionados; ese almacenamiento o esa base de datos aparecen como no en ejecución en lugar de dejar el nodo sin conexión.
• Las advertencias de todos los componentes del daemon, como las conexiones de enlaces rechazadas, llegan a los logs del nodo en Opfield, no solo al journal del host.

Los nodos que votan o pueden tener leases de conmutación por error del plano de datos se actualizan de uno en uno por política de Availability: la actualización del daemon de uno de esos nodos puede esperar a sus pares de lease, y mientras tanto el nodo aparece como en actualización. Consulta Actualizaciones y versiones mixtas. En los nodos Docker que pueden tener leases, el lease watchdog se ejecuta como su propio servicio, opfield-lease-watchdog, y se actualiza a sí mismo.

Un nodo revertido a cualquier versión del daemon desde la 2.10.0 sigue arrancando: los daemons conservan junto a los suyos los archivos de estado que lee una versión anterior. Los daemons sustituyen sus archivos de estado de forma duradera (escritura, volcado, renombrado), de modo que un kill -9 o un corte de corriente nunca dejan un archivo parcial.

Daemon de Docker 2.11.1 y el conector compartido

El daemon de Docker 2.11.1 sirve todas las vinculaciones de bases de datos, los enlaces de almacenamiento y los container links del nodo a través de un único conector de Secure Links compartido, sin contenedores por enlace ni listeners en el host; consulta Conector compartido y redes de enlace.

• Las vinculaciones de bases de datos pasan al conector tras la actualización: Opfield recrea una vez cada carga de trabajo vinculada, de una en una en cada nodo, y la siguiente cuando la anterior funciona en buen estado. Un Deployment se despliega en blue/green sin tiempo de inactividad; un Container independiente o un servicio de Compose se reinician una vez.
• Los enlaces de almacenamiento creados antes de la 2.11.1 pasan al conector tras la actualización, y Opfield recrea una vez cada carga de trabajo enlazada justo después de que cambie su enlace. Los enlaces creados en la 2.11.1 no necesitan recreación.
• Revertir el daemon de Docker a la 2.11.0 devuelve los enlaces automáticamente, de nuevo 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 del conector conservan las conexiones abiertas de los enlaces: desde la 2.11.4, el conector anterior las entrega al nuevo. Un conector anterior a la 2.11.4 las conserva hasta una hora y después las cierra una vez; los clientes se vuelven a conectar al nuevo conector.
• Los container links necesitan el daemon de Docker 2.11.1 en ambos nodos y muestran update required hasta entonces.
• Rango de las redes de enlace: las redes de enlace nuevas toman cada una un /26 de docker.secure_links.subnet_pool en /etc/docker-daemon/config.yaml, 10.213.x.x (un /16) por defecto. El daemon omite las subredes que ya usan las redes Docker o las rutas del host; cambia el rango cuando se solape con una red a la que el nodo llega a través de su ruta predeterminada y reinicia después el daemon.

Reinicios del daemon de nginx

Reiniciar o actualizar el daemon de nginx en un nodo Ingress no cierra sus sockets de Secure Link. El lanzador que supervisa el daemon conserva una copia de cada socket de escucha y la entrega al siguiente proceso del daemon; con systemd, también los guarda en el almacén de descriptores de archivo de la unidad, de modo que sobreviven a systemctl restart. Mientras no se ejecuta ningún proceso del daemon, las conexiones nuevas esperan en la cola del socket y las sirve el siguiente proceso. Al apagarse, el daemon deja de aceptar, termina las peticiones en curso durante hasta 1,5 segundos y cierra las conexiones inactivas entre peticiones para que nginx se vuelva a conectar a la cola.

• La actualización desde la 2.10 se nota una vez. El daemon antiguo no entrega nada al detenerse, así que esa única actualización interrumpe durante aproximadamente un segundo las Routes con Secure Links que pasan por el nodo. A partir de entonces, los reinicios y las actualizaciones conservan los sockets, incluido el reinicio en el que el lanzador prueba su nueva versión: mientras todavía se ejecuta un lanzador anterior que no conserva sockets, el propio daemon guarda sus listeners en el almacén de descriptores de archivo de systemd.
• Las peticiones que duran más que el vaciado de 1,5 segundos, y los flujos de larga duración como WebSocket o los server-sent events, se cortan en un reinicio que no traspasa las conexiones; una actualización del daemon con traspaso en vivo los conserva.
• En los nodos sin systemd (OpenRC), el lanzador cubre los reinicios por actualización y tras un fallo, pero no un reinicio del servicio. Las Routes cuya configuración todavía usa un listener TCP de loopback en lugar de un socket de Secure Link rechazan las conexiones durante un reinicio, como antes.

Los sockets de Secure Link se crean con un nombre temporal, con su propietario y su modo definitivos, y después se renombran, de modo que nginx nunca encuentra un socket que falte o que no pueda usar; antes de cargar una configuración, todos los sockets a los que hace referencia ya están escuchando.

Cuando Opfield arranca antes de que un nodo Ingress se haya vuelto a conectar, los cambios para ese nodo, como las Routes reescritas tras una actualización de plantillas, se dejan a la sincronización de reconexión del nodo en lugar de fallar.

Secuencia de recuperación

1. Restablece la alimentación y la accesibilidad de red del host.
2. Verifica la hora del sistema, el DNS y la conectividad con el endpoint de Relay.
3. Inspecciona la unidad de systemd del daemon y unos logs acotados.
4. Confirma que no se han sustituido el certificado del daemon ni la identidad del nodo.
5. Espera a la reconexión y a un inventario nuevo.
6. Revisa las operaciones fallidas o interrumpidas antes de reintentarlas.
7. Verifica cada familia de recursos dependientes que pertenezca al nodo.

No elimines un nodo sin conexión solo para quitar una advertencia. La eliminación cambia la propiedad duradera y puede dejar al daemon antiguo, todavía en ejecución, sin poder conciliar de forma segura.

Operaciones interrumpidas

Una desconexión puede dejar una operación cuya intención se aceptó, pero cuyo resultado final en el host no se confirmó. Tras la reconexión, Opfield concilia el estado interrumpido compatible a partir del daemon y del inventario de recursos. Revisa la operación antes de iniciar otra acción: repetir a ciegas una creación, una actualización, una migración o una eliminación puede entrar en conflicto con trabajo que ya se completó en el host.

Compara el registro de la operación con el recurso propietario real. Un Container puede estar en ejecución aunque el último progreso en la interfaz se haya interrumpido; un Compose Project puede haber aplicado una revisión sin devolver su confirmación final; una actualización puede haber reiniciado el daemon antes de que volviera la sesión de control. Usa la instantánea actualizada y el estado específico del rol como prueba, y reintenta solo la acción de continuación o de recuperación compatible.

Forzar la cancelación de un Task detiene o abandona el trabajo del plano de control cuando se admite; no garantiza que se haya revertido cada subproceso del host ni cada cambio de ejecución ya aplicado. Verifica el recurso tras la cancelación y haz la limpieza explícita cuando la operación indique que es necesaria.

Sustitución frente a recuperación

Recupera la identidad existente cuando el host y el material persistente de su daemon todavía existen. Sustituye el nodo solo cuando el host se reconstruye intencionadamente o su identidad no se puede recuperar. Antes de la sustitución, inventaría las Routes, las cargas de trabajo, las instancias de bases de datos, las asignaciones de builds, los certificados, los volúmenes y las asignaciones de Relay que pertenecen al nodo antiguo, y muévelos o retíralos mediante su ciclo de vida compatible.

No ejecutes nunca la misma identidad de daemon en el host antiguo y en el sustituto a la vez. Si el host original pudiera volver, desactívalo o desinstálalo antes de registrar el sustituto. Una identidad duplicada puede producir inventarios y confirmaciones de operaciones en conflicto aunque los dos hosts tengan direcciones distintas.

Prueba planificada sin conexión

Antes de depender de un nodo en producción, haz un ejercicio de recuperación acotado: reinicia el daemon, confirma que los servicios locales se comportan como está documentado, espera a la reconexión y verifica un inventario nuevo y un recurso dependiente representativo. Para los caminos de Relay y de bases de datos, prueba tanto las conexiones nuevas como las existentes. Registra el tiempo de recuperación observado y la vía de acceso manual necesaria si la reconexión automática falla.