Architecture

Opfield sépare l’intention et l’identité, centralisées, de l’exécution locale sur les hôtes.

flowchart TB
    users["Utilisateurs et automatisation"] -->|"HTTPS / WebSocket"| opfield["Application Opfield"]
    opfield <-->|"État durable et coordination"| state[("PostgreSQL / Redis")]
    opfield <-->|"Canal de service authentifié"| relay["Opfield Relay<br/>TCP 9443"]

    subgraph hosts["Hôtes gérés"]
        direction LR
        daemons["Démons de rôle<br/>nginx · Docker · Storage · Build Worker · Monitoring"]
        workloads["Points de terminaison privés des applications et des bases de données"]
        daemons -.->|"Cycle de vie local à l'hôte"| workloads
    end

    relay <-->|"Sessions de contrôle sortantes"| daemons
    relay <-->|"Flux privés du plan de données"| workloads

Les données privées circulent directement entre Relay et les points de terminaison locaux des applications ou des bases de données. Opfield autorise et coordonne ces chemins, mais l’application Opfield ne se trouve pas dans le flux de données.

Plan de contrôle

L’application Opfield est le plan de contrôle. Elle détient les utilisateurs, les groupes, les scopes, les définitions de ressources, l’état souhaité, les enregistrements d’audit, les identifiants d’intégration chiffrés, l’état des opérations de longue durée et les décisions de reprise. PostgreSQL est la source de vérité durable de ces enregistrements. Redis fournit la coordination de courte durée nécessaire, comme les sessions, les caches, les files d’attente, les limites de débit et les réservations bornées ; il ne remplace pas l’état durable des ressources.

Les opérateurs et l’automatisation soumettent leur intention au plan de contrôle via l’Operations Console, l’API REST, OAuth, le MCP distant ou AI Workspace. Ces points d’entrée partagent les mêmes contrôles côté serveur d’autorisation, de validation, de droits du plan, de propriété et de cycle de vie. Masquer une action dans l’interface n’est pas la frontière de sécurité, et l’utilisation d’une API ou d’un outil d’IA ne contourne aucune règle du produit.

Le plan de contrôle ne considère pas une requête acceptée comme la preuve que le travail local sur l’hôte est terminé. Les modifications qui nécessitent un démon sont enregistrées et distribuées sous forme d’opérations bornées. Le démon propriétaire signale l’avancement et l’état observé, et Opfield expose des tâches durables, l’état des ressources, des événements et des journaux pour qu’un opérateur puisse vérifier la convergence.

Relay

Relay est un service obligatoire et de longue durée du plan de données, et le seul détenteur public de 9443/tcp. Les démons gérés se connectent en sortie via un transport authentifié ; leurs interfaces de contrôle ne sont normalement pas exposées au réseau. L’application Opfield garde son écouteur gRPC interne et communique avec Relay à travers une frontière de service authentifiée.

Relay transporte le trafic de contrôle des nœuds gérés et les flux privés pris en charge. Il ne détient pas la configuration nginx, les conteneurs, les bases de données, les builds ni le travail de supervision sur l’hôte de destination. Il ne transporte que les flux autorisés par Opfield ; ce n’est pas un réseau à plat entre les hôtes. Chaque hôte géré doit pouvoir joindre le point de terminaison Relay qui lui est attribué : Relay n’ouvre pas de règles de pare-feu et ne traverse pas le NAT pour y parvenir.

La production exécute au moins deux relais sur des hôtes autres que l’hôte Opfield ; voir Combien de relais. Si aucun relais n’est disponible, les nouvelles opérations sur les nœuds gérés et les nouvelles admissions de liens privés échouent de manière fermée, car l’identité et l’autorisation ne peuvent pas être établies. Une panne de la seule application Opfield est différente : un relais admet les connexions selon une politique signée assortie d’un bail, de 72 heures par défaut ; il continue donc d’admettre les connexions autorisées pendant que l’application Opfield est arrêtée ou injoignable ; voir Les relais sans Opfield. Les charges de travail appliquées continuent de s’exécuter localement. Les sessions existantes du plan de données se poursuivent dans la mesure où le protocole et le cycle de vie des autorisations le permettent ; ne déduisez pas d’un processus applicatif au vert que le chemin de contrôle est rétabli.

Démons gérés

Chaque démon géré a un rôle et une identité bornés. Les profils Ingress, Docker, Storage, Build Worker, Monitoring et Relay exposent des capacités et des frontières de confiance différentes. Un démon Docker ne peut pas devenir un démon de base de données parce qu’un client modifie une requête, et les API de cycle de vie des utilisateurs ne doivent pas modifier les conteneurs internes appartenant à Opfield.

Les démons signalent leurs capacités, leur inventaire, leur état de santé, leurs métriques, leurs adresses de service et les résultats des opérations. Opfield s’appuie sur ces rapports pour décider si un hôte peut effectuer une action en toute sécurité. Les paquets installés ne prouvent pas à eux seuls une capacité : le démon doit signaler la fonctionnalité comme disponible et saine. Lorsqu’un nœud est hors ligne ou que son rapport de capacités est périmé, les vues en lecture seule peuvent rester disponibles à partir d’un instantané assaini, mais les modifications qui nécessitent l’état actuel de l’hôte sont refusées.

Le démon détient l’exécution sur son hôte : par exemple, nginx applique la configuration, Docker gère les objets d’exécution et un nœud Storage exécute les moteurs de bases de données. Opfield détient l’identité durable et la configuration souhaitée des ressources gérées. Cette répartition permet à une charge de travail de continuer à s’exécuter pendant une interruption temporaire du plan de contrôle, sans permettre à l’hôte d’inventer un nouvel état autorisé.

Plan de données

Le trafic applicatif public est servi par des nœuds Ingress qui exécutent nginx. Un domaine détermine le placement, une Route définit le comportement du trafic, et Opfield distribue le matériel des certificats uniquement aux nœuds dont les Routes TLS activées en ont besoin. Le processus nginx fait donc partie du plan de données, tandis que les enregistrements de domaine, de Route, de certificat, d’accès et d’état souhaité restent dans le plan de contrôle.

Les chemins privés utilisent des mécanismes étroitement définis plutôt qu’un réseau à plat partagé. Un Secure Link de nginx vers une charge de travail utilise un connecteur appartenant à Opfield et le transport Relay. Les liaisons de bases de données managées, les liens de stockage et les liens entre conteneurs passent par un connecteur secure-link partagé par nœud Docker, chaque lien sur son propre réseau privé ; une liaison de base de données dispose en outre d’une identité distincte dans le moteur. Ces mécanismes ont des responsabilités et des diagnostics séparés, même s’ils fournissent tous une connectivité privée.

Opfield Inference est un autre plan de données distinct. Un cœur d’inférence supervisé exécute le travail tourné vers les fournisseurs et est joint via le proxy Opfield. Les identifiants de modèles publiés, les connexions aux fournisseurs, les limites des utilisateurs, la comptabilité et l’autorisation restent du ressort du plan de contrôle d’Opfield.

Frontières d’exploitation

Utilisez la page de détail de la ressource et son historique d’opérations durable pour déterminer à qui revient une panne. Un état souhaité enregistré avec un nœud hors ligne oriente d’abord vers l’hôte, le démon, l’heure, le DNS, l’identité du certificat ou la connectivité Relay. Un nœud connecté avec une tâche en échec oriente vers l’environnement d’exécution ou les prérequis propres au rôle. Un environnement d’exécution sain avec une requête publique en échec oriente vers le domaine, TLS, la Route, le Secure Link ou le chemin applicatif.

Ne réparez pas un problème de propriété en modifiant directement les éléments enfants d’implémentation. Les slots de Deployment sont contrôlés par leur Deployment, les conteneurs et réseaux appartenant à Compose par leur projet Compose, les Secure Links appartenant à une Route suivent leur Route, et les identités des bases de données managées suivent le cycle de vie de leur liaison. Les modifications directes sur l’hôte peuvent créer une dérive qu’Opfield ne peut pas réconcilier en toute sécurité.

Modèle de défaillance

Les vues en lecture peuvent utiliser des instantanés assainis du dernier état connu pendant qu’un nœud est hors ligne. Ces données sont des éléments de diagnostic, et non une autorisation actuelle. Les modifications restent indisponibles tant qu’Opfield ne peut pas prouver la propriété, la capacité, le droit ou l’état actuel.

L’état souhaité et les enregistrements d’opérations sont durables afin qu’Opfield puisse réconcilier après un redémarrage de l’application, de Relay, d’un démon ou d’un nœud. La reprise doit d’abord rétablir le propriétaire défaillant, attendre de nouveaux rapports d’inventaire et de capacités, puis vérifier chaque famille de ressources dépendantes. Évitez de supprimer et de recréer des identités en première réponse : cela peut supprimer des droits, casser des relations ou empêcher l’ancien démon de se reconnecter en toute sécurité.

Pour une matrice des pannes chemin par chemin — y compris la différence entre un relais sain, un relais local perdu avec l’hôte Opfield et un relais externe indépendant —, voir Disponibilité, compatibilité et limites.