Prérequis et planification

Donnez à Opfield son propre hôte et gardez les applications et les bases de données sur des nœuds gérés. Opfield détient les utilisateurs et les permissions, la configuration des ressources, les certificats, les opérations et l’historique d’audit, et surveille l’état de santé de chaque nœud. Les hôtes eux-mêmes restent de votre ressort : leur dimensionnement, leurs disques, les mises à jour de leur système d’exploitation et leur durcissement.

Opfield est un plan de contrôle privilégié

L’hôte Opfield a accès aux identifiants d’infrastructure chiffrés et à un socket Docker accessible en écriture, utilisé pour les mises à jour signées, la reprise, les tâches de maintenance et les services managés locaux. Contrôler cet hôte revient en pratique à contrôler l’installation Opfield avec les droits root, et peut affecter chaque ressource connectée dans les limites de son périmètre autorisé. Utilisez une VM ou un hôte dédié, placez-le dans un réseau de gestion restreint et ne le partagez pas avec des charges de travail sans rapport.

Choisir la forme du déploiement

Une petite évaluation peut placer l’application Opfield et ses services internes sur un seul hôte Linux. En production, cet hôte doit malgré tout être traité comme une dépendance du plan de contrôle, avec un responsable explicite, un stockage durable, une procédure de reprise et une capacité surveillée. Les rôles des charges de travail gérées peuvent être enrôlés plus tard et résider sur des hôtes physiques, des machines virtuelles ou des conteneurs système correctement isolés.

Avant l’installation, consignez :

• l’URL HTTPS canonique à laquelle les utilisateurs et les nœuds gérés feront confiance ;
• qui est responsable du DNS, des certificats, de l’authentification, des sauvegardes et des mises à niveau ;
• quels réseaux peuvent joindre l’application web et Relay ;
• quels rôles de nœuds sont nécessaires immédiatement et lesquels peuvent être ajoutés plus tard ;
• le plan produit et les droits fonctionnels requis ;
• l’objectif de reprise pour les données et le matériel de chiffrement d’Opfield.

Évitez de concevoir l’installation autour d’adresses IP temporaires ou d’un nom d’hôte qui sera renommé après la mise en service. L’URL canonique intervient dans la sécurité du navigateur, les redirections, les commandes générées et les intégrations.

Choix de l’hôte et de la capacité

Fournissez un hôte Linux pris en charge avec un accès root ou un sudo fonctionnel. Docker n’est pas un prérequis pour l’installateur public : lorsque Docker Engine ou le plugin Compose v2 est absent, l’installateur les installe et les configure depuis les dépôts de paquets officiels de Docker. L’installation automatique de Docker prend en charge les familles Debian, Ubuntu, Fedora, CentOS et RHEL. Si Docker est déjà présent, l’installateur vérifie que le moteur est joignable et que Compose v2 est disponible.

Utilisez ces profils de dimensionnement de base pour le plan de contrôle :

Profil	CPU	Mémoire	Espace SSD libre
Minimum	2 vCPU	4 Go de RAM	32 Go
Recommandé	4 vCPU	8 Go de RAM	64 Go

Les valeurs de disque correspondent à l’espace libre après l’installation du système d’exploitation. La journalisation ClickHouse locale gérée par Opfield nécessite 32 Go supplémentaires au minimum, 128 Go recommandés ; l’utilisation réelle dépend du volume ingéré et de la rétention. Un ClickHouse externe n’ajoute pas de stockage de journalisation local sur l’hôte Opfield.

Réservez un stockage persistant pour les données PostgreSQL d’Opfield, la persistance Redis lorsqu’elle est configurée, les artefacts téléversés, les certificats, la configuration, le registre interne et les journaux structurés facultatifs. Les builds à partir de sources Git nécessitent une capacité de registre supplémentaire, car les artefacts réussis, actifs, de retour arrière, en cours et épinglés manuellement sont conservés. Les conteneurs propres à Opfield — l’application, Relay, le registre, PostgreSQL et Redis — conservent chacun au plus trois fichiers journaux de 50 Mo ; une mise à jour ajoute cette limite aux installations existantes, sauf si un service possède déjà sa propre configuration de journalisation.

Assurez-vous au minimum que l’hôte dispose également :

• d’une marge suffisante pour l’application, PostgreSQL, Redis et Relay sans pression prolongée sur le swap ;
• d’un stockage durable avec surveillance de l’espace libre et d’une destination de sauvegarde testée ;
• d’une heure système correcte et d’une résolution DNS fiable ;
• d’un processus de mise à jour du système d’exploitation qui ne remplace pas silencieusement les volumes persistants ;
• d’un accès à la version signée actuelle d’Opfield et au service de licences.

Ne stockez pas l’unique copie de la sauvegarde ou de la clé de chiffrement sur l’hôte Opfield. Une sauvegarde de base de données sans le matériel de chiffrement des secrets correspondant ne constitue pas un jeu de reprise complet.

Détail pour l’opérateur : accès réseau

L’installation publique a normalement besoin de HTTP/HTTPS entrant pour l’interface utilisateur et l’API. Les nœuds gérés se connectent via Relay, ce qui exige que le port 9443/tcp soit joignable lorsque les nœuds sont hors du réseau local. Restreignez l’accès administratif en bordure de réseau lorsque c’est possible, mais ne placez pas de proxy ou de pare-feu sur le chemin de Relay s’il ne prend pas en charge les connexions de longue durée nécessaires.

L’accès sortant dépend des fonctionnalités activées. Les destinations habituelles comprennent les fournisseurs d’identité, les fournisseurs ACME et DNS, les systèmes de gestion de sources, les registres de conteneurs, les services de versions et de licences, les points de terminaison e-mail et webhook, les récepteurs SIEM et les fournisseurs d’IA configurés. Les Build Workers peuvent nécessiter une politique de sortie différente et plus restrictive que le plan de contrôle.

Certains rôles de nœuds ont des besoins supplémentaires :

• Les nœuds Storage récupèrent l’exécuteur de sauvegardes depuis GitHub Container Registry ; ils ont donc besoin d’un accès HTTPS sortant vers ghcr.io. Les moteurs managés (SeaweedFS, PostgreSQL, Valkey, ClickHouse) et le sidecar Compose des nœuds Docker sont récupérés par empreinte depuis le miroir Opfield sur ghcr.io en priorité, avec Docker Hub en secours.
• Workload Availability en mode bail : chaque nœud Docker d’une politique et chaque nœud Ingress de ses Routes doivent joindre chaque relais du pool sur son port annoncé ; voir Basculement du plan de données.

Consultez Ports et réseau avant de modifier les pare-feu. Validez les chemins depuis l’hôte et l’espace de noms réseau qui initieront réellement la connexion ; une requête réussie depuis l’ordinateur portable d’un administrateur ne prouve pas qu’Opfield ou un nœud peut joindre le même point de terminaison.

Rôles des nœuds et frontières de confiance

Ne choisissez que les rôles dont vous avez besoin :

• nœud nginx : ingress, matérialisation TLS, Pages, journaux d’accès et d’erreurs, et métriques de trafic ;
• nœud Docker : Containers, Deployments, projets Compose, fichiers, journaux et état d’exécution ;
• nœud Storage : instances managées PostgreSQL, clé-valeur ou ClickHouse, stockage objet managé, leur stockage durable et les tâches de sauvegarde des bases de données ;
• Build Worker : exécution isolée BuildKit/containerd sans exposer de socket Docker Engine ;
• nœud de supervision : collecte propre à la supervision pour les cibles prises en charge ;
• membre du Relay Pool : transporte les Secure Links ainsi que les liens vers les bases de données et le stockage. La production et toute configuration Availability en nécessitent au moins deux, sur des hôtes autres que l’hôte Opfield, dans des domaines de panne différents (hôte, alimentation, chemin réseau) ; voir Combien de relais.

Prérequis des nœuds Storage et Docker

Un nœud Storage exécute le démon Docker en root et conserve chaque base de données managée, chaque cluster de stockage objet et chaque espace de travail de sauvegarde dans une image ext4 de taille fixe sur un périphérique loop ; son utilisation du disque est donc bornée. L’installateur le vérifie avant l’enrôlement : il formate, monte, agrandit et détache une image de test, et s’arrête si l’hôte n’y parvient pas. Chaque base de données managée, chaque membre de stockage objet et chaque sauvegarde en cours occupent un périphérique loop tant qu’ils existent. Les machines virtuelles et les hôtes physiques créent des périphériques loop à la demande. Un invité LXC ne fonctionne que si son hôte transmet /dev/loop-control et un ensemble de périphériques loop, et autorise les périphériques bloc loop et les montages ; dimensionnez cet ensemble pour chaque instance managée et chaque sauvegarde simultanée que le nœud hébergera. Lorsque l’ensemble est épuisé, la création d’une instance échoue avec node has no free loop device ; le démon libère de lui-même les périphériques des instances supprimées.

Sur un nœud Docker, un volume managé sur image disque occupe également un périphérique loop. Pour le basculement du plan de données, chaque nœud Docker susceptible de détenir un bail Availability exécute le lease watchdog en tant que service root sous systemd ou OpenRC ; l’installateur du nœud Docker l’installe.

Un nœud Docker a également besoin que Docker fournisse à ses conteneurs les contrôleurs cgroup memory, pids et cpu ; à défaut, l’installateur refuse d’enrôler le nœud. Un invité LXC Alpine avec OpenRC nécessite généralement d’abord une configuration des cgroups ; voir Invités Alpine, OpenRC et LXC. Un Build Worker nécessite systemd. Les démons de supervision, Docker, nginx et Relay peuvent s’exécuter sans root ; voir Exécuter un démon sans root.

La séparation des rôles est une décision d’exploitation et de sécurité. Un nœud Storage doit disposer de politiques de stockage et de sauvegarde adaptées aux services avec état. Un Build Worker traite des entrées de build contrôlées par le dépôt et ne doit pas partager un hôte avec des charges de travail sans rapport ni avec des identifiants d’infrastructure réutilisables. Considérez la VM externe du worker ou son conteneur système non privilégié comme la frontière de sécurité ; le bac à sable de build interne est une défense en profondeur, pas la seule frontière.

Un nœud Docker a normalement besoin de contrôler le Docker Engine local. Quiconque contrôle ce chemin vers le démon peut créer des conteneurs privilégiés, monter des chemins de l’hôte et affecter les autres charges de travail du même moteur. Considérez un nœud Docker comme équivalent à root dans la frontière de confiance Docker de cet hôte ; utilisez un hôte dédié ou une frontière de charges de travail délibérément acceptée, plutôt que de supposer que les scopes de ressources isolent un administrateur d’hôte compromis.

DNS et certificats

Décidez si Opfield gérera le DNS via Cloudflare ou si les enregistrements resteront gérés en externe. L’émission de certificats HTTP-01 exige que le port 80 public soit ouvert sur le nœud ingress attribué. DNS-01 exige une intégration de fournisseur configurée avec les permissions minimales nécessaires pour créer les enregistrements de défi. Les certificats téléversés nécessitent un responsable du renouvellement et de la surveillance de l’expiration.

Pour l’URL initiale d’Opfield, utilisez un nom d’hôte déjà couvert par un certificat de confiance. Les avertissements du navigateur pendant l’amorçage incitent à des contournements dangereux et peuvent masquer de vrais problèmes de proxy ou de nom d’hôte.

Liste de contrôle de préparation

Avant d’exécuter l’installateur, confirmez tous les points suivants :

1. Le nom d’hôte canonique se résout vers le point de terminaison prévu.
2. La terminaison TLS et la responsabilité des en-têtes de transfert (forwarded headers) sont documentées.
3. Un stockage persistant et une destination de sauvegarde hors de l’hôte existent.
4. Les règles de pare-feu couvrent l’application web, Relay et les services sortants nécessaires.
5. Le premier administrateur et un second responsable de la reprise sont identifiés.
6. Les rôles des nœuds et l’isolation des hôtes sont délibérés.
7. Les attentes en matière de rétention, d’audit, de notification et de SIEM sont documentées.
8. Les droits du plan requis sont disponibles.

Si l’une de ces décisions est inconnue, arrêtez-vous avant de mettre en service des charges de travail de production. Il est bien plus sûr de modifier la topologie, le DNS ou l’authentification avant que des nœuds et des intégrations n’en dépendent.

Consultez Ports et réseau avant de modifier les pare-feu.