Arquitectura

Opfield separa la intención y la identidad centralizadas de la ejecución local en cada host.

flowchart TB
    users["Usuarios y automatización"] -->|"HTTPS / WebSocket"| opfield["Aplicación Opfield"]
    opfield <-->|"Estado duradero y coordinación"| state[("PostgreSQL / Redis")]
    opfield <-->|"Canal de servicio autenticado"| relay["Opfield Relay<br/>TCP 9443"]

    subgraph hosts["Hosts gestionados"]
        direction LR
        daemons["Daemons por rol<br/>nginx · Docker · Storage · Build Worker · Monitoring"]
        workloads["Endpoints privados de aplicaciones y bases de datos"]
        daemons -.->|"Ciclo de vida local en el host"| workloads
    end

    relay <-->|"Sesiones de control salientes"| daemons
    relay <-->|"Flujos privados del plano de datos"| workloads

El tráfico privado se mueve directamente entre Relay y los endpoints locales de aplicaciones o bases de datos en cada host. Opfield autoriza y coordina esas rutas, pero la aplicación Opfield no está en el flujo de datos.

Plano de control

La aplicación Opfield es el plano de control. Es responsable de los usuarios, los grupos, los ámbitos, las definiciones de recursos, el estado deseado, los registros de auditoría, las credenciales cifradas de las integraciones, el estado de las operaciones de larga duración y las decisiones de recuperación. PostgreSQL es la fuente de verdad duradera de esos registros. Redis proporciona la coordinación de corta duración necesaria, como sesiones, cachés, colas, límites de peticiones y reservas acotadas; no sustituye al estado duradero de los recursos.

Los operadores y la automatización envían su intención al plano de control a través de la Operations Console, la REST API, OAuth, MCP remoto o AI Workspace. Esos puntos de entrada comparten las mismas comprobaciones de autorización, validación, derechos del plan, propiedad y ciclo de vida en el backend. Ocultar una acción en la interfaz no es el límite de seguridad, y usar una API o una herramienta de IA no elude ninguna regla del producto.

El plano de control no considera que una petición aceptada demuestre que el trabajo local en el host ha terminado. Los cambios que requieren un daemon se registran y se envían como operaciones acotadas. El daemon propietario informa del progreso y del estado observado, y Opfield expone Tasks duraderos, el estado de los recursos, eventos y logs para que un operador pueda verificar la convergencia.

Relay

Relay es un servicio obligatorio y de larga duración del plano de datos, y el único responsable público de 9443/tcp. Los daemons gestionados se conectan hacia fuera mediante un transporte autenticado; sus interfaces de control normalmente no se exponen a la red. La aplicación Opfield mantiene interno su listener gRPC y se comunica con Relay a través de un límite de servicio autenticado.

Relay transporta el tráfico de control de los nodos gestionados y los flujos privados compatibles. No es responsable de la configuración de nginx, los contenedores, las bases de datos, los builds ni el trabajo de monitorización en el host de destino. Solo transporta los flujos que Opfield autoriza; no es una red plana entre hosts. Cada host gestionado debe llegar a su endpoint de Relay asignado: Relay no abre reglas de cortafuegos ni atraviesa NAT para llegar a él.

En producción se ejecutan al menos dos Relays en hosts distintos del host de Opfield; consulta Cuántos Relays. Si no hay ningún Relay disponible, las nuevas operaciones de nodos gestionados y las nuevas admisiones de enlaces privados fallan de forma segura, porque no se pueden establecer la identidad ni la autorización. Una caída solo de la aplicación Opfield es distinta: un Relay admite conexiones según una política firmada con un lease, de 72 horas por defecto, así que sigue admitiendo conexiones autorizadas mientras la aplicación Opfield está detenida o inaccesible; consulta Relays sin Opfield. Las cargas de trabajo aplicadas siguen funcionando localmente. Las sesiones existentes del plano de datos continúan donde lo permiten el protocolo y el ciclo de vida de la autorización; no deduzcas que un proceso de la aplicación en verde significa que la ruta de control se ha recuperado.

Daemons gestionados

Cada daemon gestionado tiene un rol y una identidad acotados. Los perfiles Ingress, Docker, Storage, Build Worker, Monitoring y Relay exponen capacidades y límites de confianza distintos. Un daemon de Docker no puede convertirse en un daemon de bases de datos porque un cliente cambie una petición, y las API de ciclo de vida de los usuarios no deben modificar los contenedores internos propiedad de Opfield.

Los daemons informan de las capacidades, el inventario, el estado, las métricas, las direcciones de servicio y los resultados de las operaciones. Opfield usa esos informes para decidir si un host puede realizar una acción de forma segura. Los paquetes instalados no demuestran por sí solos una capacidad: el daemon debe informar de que la función está disponible y en buen estado. Cuando un nodo está desconectado o su informe de capacidades está desactualizado, las vistas de solo lectura pueden seguir disponibles a partir de una instantánea depurada, pero se rechazan los cambios que necesitan el estado actual del host.

El daemon es responsable de la ejecución en su host: por ejemplo, nginx aplica la configuración, Docker gestiona los objetos de ejecución y un nodo Storage ejecuta los motores de bases de datos. Opfield es responsable de la identidad duradera y de la configuración deseada de los recursos gestionados. Esta división permite que una carga de trabajo siga funcionando durante una interrupción temporal del plano de control sin que el host pueda inventarse un nuevo estado autorizado.

Plano de datos

El tráfico público de las aplicaciones lo sirven los nodos Ingress que ejecutan nginx. Un dominio selecciona la ubicación, una Route define el comportamiento del tráfico y Opfield distribuye el material de los certificados solo a los nodos con Routes TLS activadas que lo necesitan. El proceso de nginx forma parte, por tanto, del plano de datos, mientras que los registros de dominios, Routes, certificados, acceso y estado deseado siguen en el plano de control.

Las rutas privadas usan mecanismos definidos con precisión en lugar de una red plana compartida. Un Secure Link de nginx a una carga de trabajo usa un conector propiedad de Opfield y el transporte de Relay. Las vinculaciones de bases de datos gestionadas, los enlaces de almacenamiento y los container links funcionan a través de un único conector de Secure Links compartido por nodo Docker, cada enlace en una red privada propia; una vinculación de base de datos tiene además una identidad del motor distinta. Estos mecanismos tienen propiedad y diagnósticos separados, aunque todos proporcionan conectividad privada.

Opfield Inference es otro plano de datos separado. Un inference core supervisado ejecuta el trabajo de cara a los proveedores y se llega a él a través del proxy de Opfield. Los ID de modelos publicados, las conexiones con proveedores, los límites por usuario, la contabilidad y la autorización siguen siendo cuestiones del plano de control de Opfield.

Límites operativos

Usa la página de detalle del recurso y su historial de operaciones duradero para determinar a quién corresponde un fallo. Un estado deseado guardado con un nodo desconectado apunta primero al host, al daemon, a la hora, al DNS, a la identidad del certificado o a la conectividad con Relay. Un nodo conectado con un Task fallido apunta al entorno de ejecución específico del rol o a un requisito previo. Un entorno de ejecución en buen estado con una petición pública que falla apunta al dominio, a TLS, a la Route, al Secure Link o a la ruta de la aplicación.

No repares un problema de propiedad editando directamente los hijos de implementación. Los slots de un Deployment los controla su Deployment, los contenedores y las redes propiedad de Compose los controla su Compose Project, los Secure Links propiedad de una Route siguen a su Route y las identidades de las bases de datos gestionadas siguen el ciclo de vida de su vinculación. Los cambios directos en el host pueden crear una deriva que Opfield no puede conciliar de forma segura.

Modelo de fallos

Las vistas de lectura pueden usar instantáneas depuradas de lo último conocido mientras un nodo está desconectado. Esos datos son pruebas para el diagnóstico, no una autorización actual. Los cambios siguen sin estar disponibles siempre que Opfield no pueda demostrar la propiedad, la capacidad, el derecho del plan o el estado actual.

El estado deseado y los registros de operaciones son duraderos para que Opfield pueda conciliar tras reinicios de la aplicación, de Relay, del daemon o del nodo. La recuperación debe restablecer primero al propietario que falló, esperar a informes nuevos de inventario y capacidades y verificar después cada familia de recursos dependiente. Evita eliminar y volver a crear identidades como primera respuesta: hacerlo puede eliminar concesiones, romper relaciones o dejar al daemon antiguo sin poder volver a conectarse de forma segura.

Para una matriz de caídas ruta por ruta, incluida la diferencia entre un Relay en buen estado, un Relay local perdido junto con el host de Opfield y un Relay externo independiente, consulta Disponibilidad, compatibilidad y límites.