Modelo de ciclo de vida y seguridad

Opfield distingue una operación solicitada de su resultado verificado.

Esta distinción importa siempre que el trabajo atraviesa el plano de control, Relay, un daemon gestionado y el entorno de ejecución de un host. Una respuesta de la API puede confirmar que Opfield validó y registró una instrucción mientras el daemon propietario todavía la está aplicando. Usa el estado duradero del recurso, el Task, los eventos, el estado de salud y los logs para determinar el resultado real.

Estado deseado y estado observado

El plano de control guarda la configuración deseada y el estado de la operación antes del envío. Los daemons informan del inventario observado, las capacidades, el estado de salud y el estado de ejecución. Opfield compara esas vistas y registra el trabajo necesario para que converjan.

El estado deseado sobrevive a un reinicio de la aplicación, a una interrupción temporal de Relay, a la reconexión de un daemon o al reinicio de un host. El estado observado puede quedar desactualizado mientras el propietario no está disponible. Una instantánea depurada de lo último conocido puede seguir visible para el diagnóstico, pero no demuestra que el entorno de ejecución siga existiendo ni que un cambio sea seguro.

Un resultado completado requiere pruebas del componente propietario. Para una carga de trabajo, verifica el estado de ejecución, el estado de salud, los logs y su Route o dependencia privada. Para un cambio de Ingress, verifica que nginx aceptó la configuración y prueba el nombre de host externo. Para una vinculación de base de datos, verifica el enlace de la vinculación en el conector de Secure Links del nodo, la identidad en el motor y una consulta real de la aplicación.

Ciclo de vida de una operación

El trabajo de larga duración se representa con un Task o una operación duraderos. Las etapas habituales incluyen el trabajo en cola, el envío a un propietario, la preparación local en el host, la validación, la aplicación o el cambio, la verificación y la limpieza. Las etapas exactas y el comportamiento de cancelación dependen del recurso.

Registra el ID del Task o de la operación antes de dejar un cambio. Al recargar la página, debería volver a conectarse al mismo registro duradero. Un tiempo de espera agotado en el navegador, una respuesta perdida o un flujo interrumpido no demuestran que el propietario no haya recibido el comando. Inspecciona tanto el Task como el estado actual del recurso antes de enviar una creación, recreación, migración o eliminación duplicadas.

El progreso es una prueba informada por el worker o el daemon propietario, no una animación del navegador. Un éxito final debe corresponder a la poscondición definida por la operación. Un fallo final debe conservar suficiente contexto de fase, error y petición para identificar el requisito previo no cumplido sin repetir la acción a ciegas.

Conciliación

Opfield reintenta el trabajo idempotente seguro tras desconexiones transitorias y concilia los recursos tras un reinicio de la aplicación o del daemon. La conciliación usa el propietario duradero, el estado deseado, el informe de capacidades actual y el estado de ejecución observado. Evita inventarse un éxito a partir de un inventario desactualizado o adoptar un objeto no relacionado con el mismo nombre.

Cuando no se puede demostrar la propiedad, la capacidad, el derecho del plan o el estado actual, los cambios fallan de forma segura. Restablece primero el requisito previo que falta: vuelve a conectar el nodo, recupera Relay, corrige el registro o el certificado, restaura el almacenamiento o resuelve la operación activa. Después deja que Opfield actualice el inventario y concilie el recurso original.

No uses la eliminación directa en el host como herramienta genérica de conciliación. Eliminar un Container, una red, un listener, un rol del motor, un conector o un marcador de revisión propiedad de Opfield puede destruir las pruebas necesarias para completar o revertir la operación. Usa las acciones compatibles de reintento, reparación, cancelación o recuperación de la limpieza cuando estén disponibles.

Acciones destructivas

La eliminación, la rotación de credenciales, el cambio final de una migración, la importación de archivos, el desmantelamiento de una base de datos y la sustitución de certificados tienen efectos más amplios que las ediciones normales. Antes de empezar, identifica el recurso propietario, las Routes y vinculaciones dependientes, los datos persistentes, los clientes externos, el candidato de reversión y la limpieza esperada.

Lee el texto de confirmación en lugar de suponer que los objetos relacionados comparten una misma política de eliminación. Eliminar un Container borra las concesiones de ese recurso, pero no elimina automáticamente un volumen separado. Eliminar una Route retira su Secure Link propio, pero no elimina los certificados ni las Access Lists reutilizables. Eliminar una conexión de origen detiene los builds futuros, pero no elimina automáticamente los artefactos desplegados. Eliminar una base de datos requiere gestionar antes las vinculaciones y la retención de las copias de seguridad.

Tras una operación destructiva, verifica tanto la ausencia prevista como los elementos que debían sobrevivir. Comprueba la limpieza de relaciones, la revocación de accesos, la retención del almacenamiento, la accesibilidad pública, la atribución en la auditoría y el Task final. Si la limpieza se interrumpe, conserva el registro duradero y recupera a través de la operación registrada en lugar de borrar a mano los objetos intermedios.

Comportamiento seguro sin conexión

Cuando un nodo está desconectado, Opfield puede mostrar una instantánea depurada de lo último conocido. No permite un cambio que dependa de un estado actual sin verificar. Los servicios ya aplicados, como nginx, los Containers y las bases de datos gestionadas, pueden seguir funcionando de forma independiente.

Empieza la recuperación por la alimentación y la red del host, la hora del sistema, el DNS, el servicio del daemon, la identidad del certificado y la accesibilidad saliente hacia Relay. Evita eliminar el registro del nodo mientras el daemon antiguo pueda volver a conectarse: la eliminación crea una identidad duradera diferente y puede impedir una conciliación segura.

Tras la reconexión, espera a un informe nuevo de capacidades e inventario. Revisa las operaciones fallidas o interrumpidas antes de reintentarlas y verifica después cada familia de recursos que pertenezca al nodo. Un indicador de conexión en verde no demuestra por sí solo que las Routes, los certificados, las cargas de trabajo, los Compose Projects, las vinculaciones de bases de datos o la monitorización hayan convergido.

El estado de la licencia sigue el mismo principio. Una clave caducada o un servicio de licencias inaccesible bloquean, tras el periodo de gracia documentado, las nuevas acciones de gestión exclusivas de los planes de pago, pero Opfield no detiene, elimina ni concilia hasta hacer desaparecer las cargas de trabajo, las Routes, las bases de datos gestionadas ni los despliegues de Pages publicados por ese motivo. Consulta Bajada de plan y caducidad.

Operaciones de larga duración

Los builds, las migraciones, los Deployments, el trabajo con certificados, las actualizaciones y el aprovisionamiento de bases de datos son Tasks duraderos. Usa el historial de operaciones y unos logs acotados en lugar de repetir una acción porque una página parezca lenta. Iniciar un segundo cambio en conflicto puede rechazarse, aplazarse o crear un camino de recuperación más difícil.

Reintenta solo cuando el contrato de la operación marque el trabajo como reintentable o se sepa que el intento anterior ha terminado. La cancelación es cooperativa cuando el propietario la admite. Force Cancel puede hacer que Opfield deje de esperar una operación abandonada, pero no demuestra que la acción subyacente en el entorno de ejecución no se haya producido. Actualiza el estado del propietario y resuelve cualquier marcador de operación interrumpida antes del siguiente cambio.

Disciplina de verificación y recuperación

Para cada cambio significativo, define la poscondición esperada antes de ejecutarlo. Verifica desde el camino real del consumidor: DNS/TLS/HTTP externos para el tráfico público, una consulta de la aplicación para una vinculación de base de datos, un digest inmutable descargado y una comprobación de estado para una versión, o la reconexión y las capacidades actuales para la actualización de un nodo.

Cuando un cambio falla, conserva el ID del Task, el ID de petición, la fase, unos logs acotados, el estado deseado y el estado actual del propietario. Corrige el requisito previo concreto y reanuda a través de Opfield. Revierte a través del propietario de nivel superior cuando exista una revisión, un slot de Deployment, un Tag o un artefacto de origen que se sepa que funciona. No declares la recuperación hasta que el estado de Opfield y el comportamiento observado desde fuera coincidan.