Propriété de l'infrastructure et IaC

Opfield détient la couche de services : nœuds, Routes, certificats, charges de travail, bases de données, sauvegardes, supervision et permissions. Les couches inférieures — comptes chez les fournisseurs, réseaux et système d’exploitation des hôtes — sont créées à la main, par Terraform, OpenTofu ou Ansible, ou par Opfield lui-même via une intégration d’hébergeur.

La règle simple est : une ressource, un propriétaire. Deux systèmes peuvent observer la même ressource, mais ils ne doivent pas la réécrire tous les deux en permanence.

Qui détient quelle couche

Couche	Propriétaire habituel	Exemples
Socle du fournisseur	Terraform, OpenTofu, console cloud ou intégrations d’hébergeurs d’Opfield	réseaux, machines virtuelles, pare-feu, zones DNS, destinations de sauvegarde
Configuration de base des hôtes	Ansible, chaîne de fabrication d’images ou équipe en charge des hôtes	système d’exploitation, utilisateurs, politique du noyau, installation de Docker, disques, sécurité des postes
Couche de services	Opfield	nœuds, routes, certificats, charges de travail, projets Compose, bases de données et stockage managés, liaisons, sauvegardes, métriques, journaux, alertes, permissions, historique d’exploitation
Intention de publication applicative	gestion de sources et Opfield	révision du dépôt, build, artefact, déploiement, retour arrière
Copies hors site	stockage extérieur à l’installation	copies de sauvegarde hors site ; un SIEM lorsque vos règles de conformité exigent une conservation de l’audit en dehors d’Opfield

Une petite équipe crée ses hôtes à la main ou via une intégration d’hébergeur et laisse Opfield détenir tout ce qui se trouve au-dessus du système d’exploitation. Une organisation plus grande crée ses hôtes avec Terraform et enrôle chacun d’eux une fois ses contrôles de sécurité réussis.

Choisir le propriétaire avant l’import

Avant d’intégrer une ressource existante dans Opfield, consignez :

1. quel système est autorisé à la modifier ;
2. quel système est seulement autorisé à l’observer ;
3. où se trouve sa source de vérité ;
4. qui approuve les changements d’urgence ;
5. comment un changement d’urgence est réconcilié ensuite.

Par exemple, si Terraform détient un enregistrement DNS, ne configurez pas aussi Opfield pour réécrire continuellement ce même enregistrement. Soit vous gardez le DNS dans Terraform et le faites pointer vers une route gérée par Opfield, soit vous transférez délibérément le cycle de vie de cet enregistrement à Opfield et le retirez de l’état Terraform.

Éviter la propriété partagée

La propriété partagée crée de la dérive : un outil applique un changement valide, un autre constate une valeur inattendue et la rétablit. Le résultat peut sembler aléatoire alors que les deux systèmes se comportent comme ils ont été configurés.

Les conflits courants comprennent :

• Terraform et Opfield qui gèrent tous deux un même enregistrement DNS ;
• Ansible et Opfield qui remplacent tous deux la même configuration nginx ;
• un script d’hôte qui redémarre ou supprime des conteneurs appartenant à un Deployment ou à un projet Compose d’Opfield ;
• un outil de base de données externe qui modifie des utilisateurs créés pour une liaison gérée par Opfield ;
• une chaîne CI qui déploie la même charge de travail qu’Opfield construit et déploie aussi.

Si deux systèmes doivent intervenir sur un même domaine, divisez-le par une frontière explicite. Terraform peut détenir la VM et le pare-feu tandis qu’Opfield détient les applications à l’intérieur de cette VM. Ansible peut détenir l’installation de Docker tandis qu’Opfield détient les ressources Docker. Un système de sauvegarde externe peut lire une base de données tandis qu’Opfield détient le cycle de vie de son service.

Changements manuels d’urgence

Pendant un incident, une modification directe sur l’hôte peut être l’action la plus sûre. Traitez-la comme une exception temporaire :

1. consignez la ressource, la commande ou le paramètre, l’opérateur, l’heure et la raison ;
2. suspendez l’automatisation qui pourrait écraser le changement ;
3. rétablissez le service pour les clients et préservez les éléments de preuve ;
4. décidez si Opfield ou la source de vérité externe doit adopter le nouvel état ;
5. réconciliez délibérément et supprimez l’exception temporaire.

Ne laissez pas un correctif d’urgence réussi devenir une dérive permanente non documentée. Sinon, le prochain déploiement de routine risque de l’annuler.

Passer à Opfield

Migrez une famille de ressources à la fois : ingress, charges de travail, bases de données, sauvegardes, supervision. Pour chacune, transférez explicitement la propriété, retirez-la de l’ancien outil et prouvez son chemin de restauration avant de passer à la suivante. Migrer votre pile vers Opfield indique l’ordre et la vérification de chaque étape.