Adapter NetBox sans recopier toute sa configuration

Adapter NetBox sans recopier toute sa configuration examine une difficulté propre à cette architecture. Le profil combine NetBox, un worker RQ, PostgreSQL et deux Valkey. Le premier Valkey porte les tâches et conserve un état durable authentifié ; le second sert de cache reconstructible. Les fusionner parce qu’ils utilisent le même moteur supprimerait une distinction de sécurité et de reprise. L’image fournit déjà sa configuration de base, complétée par un petit override géré. L’objectif était de conserver le contrat du produit tout en confiant à Coolify le déploiement, les domaines et le renouvellement des conteneurs.

NetBox est une solution de modélisation et référentiel des réseaux et infrastructures adaptée à des usages structurés et à un hébergement maîtrisé. Le choix d’un logiciel existant permet de concentrer l’ingénierie sur l’adaptation, la gouvernance et l’exploitation plutôt que de recréer son cœur fonctionnel.

L’architecture du produit distingue interface, logique métier, traitements différés et états persistants. Cette carte des responsabilités a servi de référence avant toute modification liée à Coolify. NetBox est une source de vérité pour les réseaux et les infrastructures, pas un outil de découverte automatique.

Le risque était de traiter comme absents des fichiers déjà intégrés à l’image netbox-docker, puis de multiplier les montages et les divergences.

Coolify ajoute son propre proxy, sa gestion des domaines, ses variables magiques, ses fichiers gérés et son cycle de redéploiement. Chaque adaptation devait donc être analysée à la frontière entre la plateforme et le logiciel. Sites, équipements, baies, câbles, préfixes, adresses et machines virtuelles y sont modélisés avec leurs relations.

Le diagnostic a suivi les couches dans l’ordre : validation de la composition, création des services, santé des magasins d’état, fin des tâches d’initialisation, réponse du service public, authentification et parcours fonctionnel. Cette méthode évite de confondre un problème de réseau avec une migration inachevée ou un secret incohérent. La valeur apparaît lorsque l’équipe définit qui maintient chaque donnée et utilise l’API ou les scripts pour confronter l’intention décrite à la réalité opérationnelle.

Les journaux ont été lus par responsabilité. Un échec de la passerelle ne signifie pas nécessairement que la base est en cause ; un conteneur actif ne garantit pas qu’un worker consomme une vraie tâche. Les contrôles ont donc porté sur les effets observables de chaque service. Le profil combine NetBox, un worker RQ, PostgreSQL et deux Valkey.

L’architecture finale garde la configuration embarquée et n’ajoute qu’un petit remplacement géré. Deux services Valkey séparent clairement la file de tâches du cache.

La correction retenue est la plus petite modification capable de rétablir le contrat du produit. Les services dont l’utilité était démontrée ont été conservés ; les composants ajoutés uniquement par habitude ont été écartés. Le premier Valkey porte les tâches et conserve un état durable authentifié ; le second sert de cache reconstructible.

Installation fraîche, initialisation native, accès web, administration, travail du worker, persistance et redéploiement.

Le parcours part d’une ressource neuve et se termine par un redéploiement avec conservation des données. Lorsqu’une sauvegarde et une restauration sont prévues, la vérification se fait dans des volumes isolés et revient à l’interface pour contrôler un objet métier connu. Les fusionner parce qu’ils utilisent le même moteur supprimerait une distinction de sécurité et de reprise.

PostgreSQL et les fichiers d’extension sont autoritatifs ; le cache peut être reconstruit, contrairement à une file en cours.

Les volumes sont classés selon leur rôle : état autoritatif, fichier métier, file durable, cache reconstructible ou journal opérationnel. Cette classification détermine l’ordre de sauvegarde, l’ordre de restauration et les tests nécessaires avant remise en service. L’image fournit déjà sa configuration de base, complétée par un petit override géré.

Une adaptation fiable commence par comprendre le logiciel, pas par compter les conteneurs. La complexité utile provient des responsabilités réelles : base, recherche, files, tâches, temps réel, passerelle ou stockage. La plateforme doit simplifier leur exploitation sans modifier silencieusement leur contrat. Deux détails ont changé le diagnostic.

Les domaines publics, les URL canoniques et les cibles internes doivent rester distincts. Les secrets partagés utilisent une identité stable. Les migrations ont un seul propriétaire. Les contrôles de santé observent la fonction du service et la reprise porte sur tous les états qui rendent l’application utilisable. Le healthcheck devait envoyer un Host accepté par Django : localhost et 127.0.0.1 atteignaient la même socket mais pas la même politique d’hôte.

Le modèle Docker Compose et le guide de déploiement associés permettent de reproduire l’architecture. Pour une nouvelle version, le travail reprend par la lecture des changements amont, une sauvegarde restaurable et un environnement isolé. Le même parcours fonctionnel sert ensuite de test de non-régression. Ensuite, un secret valide pour NetBox pouvait être altéré par le transport Coolify lorsqu’il contenait un signe dollar.

Le passage en exploitation réunit le responsable fonctionnel, l’administrateur de l’application et l’équipe infrastructure. Ensemble, ils confirment les comptes, les droits, le courrier sortant, les domaines, les sauvegardes, la supervision et la procédure d’assistance. Les utilisateurs disposent d’un point d’entrée unique et d’instructions adaptées à leur rôle. Le correctif a séparé exigence applicative et compatibilité de sérialisation.

Une fenêtre de maintenance est définie pour les mises à jour. Les changements de version sont d’abord reproduits sur une copie isolée, puis le parcours critique est rejoué. Les observations sont consignées dans une procédure courte afin que le service ne dépende pas d’une mémoire individuelle. Relire les deux URL Valkey, leurs mots de passe et leurs politiques de persistance avant déploiement.

Cette étude renforce une règle simple : l’architecture doit être expliquée par les responsabilités qu’elle remplit. Chaque service, volume, variable et contrôle de santé répond à une fonction identifiable. Lorsqu’une modification ne peut pas être reliée à cette carte, elle mérite d’être remise en question. Les volumes couvrent PostgreSQL, médias, rapports, scripts et la file de tâches ; le cache peut être reconstruit.

La validation doit ensuite suivre la même logique. Elle commence par l’infrastructure, traverse le produit et revient jusqu’à la décision de l’utilisateur. La restauration referme la boucle en montrant que l’organisation peut récupérer son service et ses données après un incident. La création du premier administrateur et les migrations restent confiées au cycle natif NetBox, sans sidecar qui dupliquerait ces responsabilités.

Chaque itération a été traitée comme une hypothèse à vérifier. Une composition valide était d’abord déployée sur une ressource neuve. L’équipe observait ensuite le premier service qui ne remplissait pas sa responsabilité, corrigeait la cause la plus proche et rejouait le parcours depuis le début. Cette chronologie a empêché l’accumulation de modifications sans relation avec le problème. NetBox est une source de vérité pour les réseaux et les infrastructures, pas un outil de découverte automatique.

Les corrections ont été comparées avec l’architecture attendue et avec les effets visibles dans l’application. Lorsqu’un changement améliorait le démarrage mais cassait une fonction, il était rejeté. L’architecture finale conserve ainsi les choix qui satisfont ensemble installation, usage, persistance et reprise. Sites, équipements, baies, câbles, préfixes, adresses et machines virtuelles y sont modélisés avec leurs relations.

Trois décisions reviennent dans le cas : choisir le bon service public, attribuer clairement l’initialisation et protéger tout l’état autoritatif. Elles conditionnent le domaine, les contrôles de santé, les dépendances et la stratégie de sauvegarde. Leur formulation explicite facilite le passage de relais vers l’équipe d’exploitation. La valeur apparaît lorsque l’équipe définit qui maintient chaque donnée et utilise l’API ou les scripts pour confronter l’intention décrite à la réalité opérationnelle.

Après la mise en service, les contrôles sont rejoués à intervalles réguliers : connexion, création ou modification d’un objet, traitement différé, redéploiement et lecture des données. Un exercice de restauration planifié vérifie que les sauvegardes restent compatibles avec la version courante et que l’équipe sait reconstruire le service. Le profil combine NetBox, un worker RQ, PostgreSQL et deux Valkey.

Deux détails ont changé le diagnostic. Le healthcheck devait envoyer un Host accepté par Django : localhost et 127.0.0.1 atteignaient la même socket mais pas la même politique d’hôte. Ensuite, un secret valide pour NetBox pouvait être altéré par le transport Coolify lorsqu’il contenait un signe dollar. Le correctif a séparé exigence applicative et compatibilité de sérialisation.