Connecter une application à une base de données privée

Ce parcours donne à une application un accès privé à une base de données sans publier le port de la base et sans partager l’identifiant du propriétaire de la base. Opfield crée une liaison durable — la relation gérée entre une charge de travail et une base de données — et provisionne une identité dédiée dans le moteur pour cette relation.

S’il s’agit de votre premier processus avec une base de données, lisez la vue d’ensemble des bases de données, préparez une base de données managée et examinez le comportement des liaisons applicatives avant de créer des données de production.

La charge de travail ne reçoit que les valeurs de connexion dont elle a besoin. Retirer l’accès de l’application et supprimer la base de données sont deux opérations distinctes.

Décider si une base de données managée est appropriée

Utilisez une instance PostgreSQL, clé-valeur ou ClickHouse gérée par Opfield lorsque vous voulez qu’Opfield prenne en charge le provisionnement, le cycle de vie d’exécution, les paramètres de capacité, les identifiants, la supervision et les liaisons privées des charges de travail sur un nœud Storage. Utilisez une connexion externe lorsqu’une autre plateforme exécute déjà la base de données et qu’Opfield se contente de stocker la connexion et d’exécuter dessus les vérifications de santé, l’Explorer, la Console et les sauvegardes. Les liaisons, et donc ce parcours, ne s’appliquent qu’aux bases de données managées ; une application qui utilise une base externe reçoit ses valeurs de connexion sous forme de secrets de la charge de travail. Comparez les deux modèles dans Bases de données managées et externes en un coup d’œil.

Avant de créer des données, approuvez :

• le moteur de base de données et sa version prise en charge ;
• le nœud Storage et l’emplacement du stockage durable ;
• les limites de CPU, de mémoire, de swap et de stockage ;
• la responsabilité des sauvegardes, de la conservation, de la restauration et de la suppression ;
• si une publication TCP directe est réellement nécessaire ;
• quelle ressource applicative recevra la liaison ;
• les limites de connexions attendues et le comportement de relance de l’application.

La suppression d’une base de données managée est destructive et retire son disque, son image ou son montage managés en même temps que l’instance. La suppression d’une connexion ou d’une liaison n’est pas la même action. Rendez cette distinction claire dans les permissions des opérateurs et dans les runbooks.

1. Préparer le nœud Storage

Enrôlez un nœud Storage dédié et vérifiez ses contrôles préalables de stockage. Les nœuds Storage utilisent un stockage managé de taille fixe, avec une limite appliquée à la frontière de l’hôte. L’installateur vérifie le Docker Engine local et le cycle de vie des périphériques loop, du montage, de l’écriture, de l’agrandissement, du redimensionnement, du démontage et du détachement utilisé par les instances managées.

Une VM ou un hôte physique expose normalement ces capacités directement. Un invité LXC nécessite des permissions explicites de périphériques loop et de montage accordées par son hôte externe ; Opfield ne se rabat pas sur un volume non borné lorsque la frontière requise est absente.

Le nœud doit être en ligne, disposer de suffisamment de stockage non alloué pour la base demandée et avoir une destination de sauvegarde documentée. Ne placez pas de conteneurs applicatifs sur un nœud Storage simplement parce que tous deux utilisent Docker en interne.

2. Provisionner la base de données en privé

Ouvrez Databases, choisissez le moteur et la version pris en charge, sélectionnez le nœud Storage et configurez les limites de ressources et de stockage. Laissez Publish TCP désactivé, sauf si l’accès client direct est une exigence revue. La publication et son port d’hôte peuvent être modifiés plus tard dans les paramètres de la base ; Opfield recrée alors le conteneur de la base en conservant ses données, prévoyez donc une courte interruption.

Attendez que le provisionnement et les vérifications de santé atteignent Ready. Confirmez le moteur, le nœud, la capacité de stockage, l’état TLS et la supervision affichés. Ne poursuivez pas à partir d’un état simplement créé ou en cours de démarrage.

Opfield garde l’identifiant du propriétaire dans le moteur en interne. Reveal credentials affiche un utilisateur d’accès direct distinct uniquement tant que la publication TCP est activée ; il sert à l’administration externe contrôlée, et non à être copié dans chaque application.

3. Créer la liaison applicative

Ouvrez le Container, le Deployment ou le service Compose cible et créez un lien vers une base de données managée. Sélectionnez la base et les variables ou options de connexion prises en charge. Opfield crée un rôle PostgreSQL, un utilisateur ACL clé-valeur ou un utilisateur ClickHouse distinct pour cette liaison.

Pour un Container autonome, Opfield rattache le réseau privé de la liaison et utilise le processus de recréation normal pour appliquer l’environnement de connexion. Pour un Deployment, la configuration souhaitée est mise à jour et un slot est renouvelé, afin que les futures instances blue et green reçoivent le même point de terminaison privé, servi par le connecteur secure-link partagé du nœud Docker cible. Compose garde la liaison rattachée au service propriétaire plutôt qu’au nom d’un conteneur enfant éphémère. Une charge de travail arrêtée, en échec ou pas encore déployée peut aussi être liée : la liaison est enregistrée comme pending et appliquée au prochain démarrage de la charge de travail ou à la fin de son déploiement ; voir Charges de travail qui ne s’exécutent pas.

N’appliquez ou ne recréez la charge de travail que lorsque l’interface indique que la configuration d’exécution modifiée l’exige. L’état souhaité de la liaison est durable ; une recréation normale de la charge de travail ne doit pas créer un nouvel utilisateur dans le moteur à chaque fois.

4. Vérifier depuis l’application

Utilisez l’application ou un diagnostic contrôlé à l’intérieur de la charge de travail pour ouvrir une connexion et effectuer une opération inoffensive propre au moteur. Vérifiez que :

• le nom d’hôte, le port, le nom de la base et les identifiants proviennent de la liaison et non d’identifiants du propriétaire copiés ; la liaison se connecte via le réseau privé de la liaison et n’ajoute pas de paramètres TLS ;
• la connexion réussit sans publier le port d’hôte de la base ;
• le moteur voit l’utilisateur propre à la liaison ;
• le comportement des connexions et des requêtes correspond aux paramètres du pool de l’application, et les pools de tous les conteneurs que la base sert ensemble restent sous la limite de connexions propre à la base, partagée par tous ses liens, de même que par les deux slots d’un Deployment pendant un déploiement : max_connections de PostgreSQL (100 par défaut, de 20 à 10000, défini dans Database Settings → Maximum connections), maxclients du stockage clé-valeur, ou 4096 pour ClickHouse (Capacité des liens) ;
• la télémétrie d’exécution de la liaison devient saine et montre les flux et le trafic attendus ;
• les journaux de la charge de travail n’affichent pas les valeurs secrètes.

Recréez ensuite la charge de travail via son cycle de vie Opfield normal et répétez la requête. Redémarrez le démon Docker ou reconnectez le nœud pendant les tests de recette et confirmez que la réconciliation rétablit le lien et la liaison sans créer de rôle supplémentaire. Un redémarrage d’Opfield n’interrompt pas le trafic établi d’une liaison ; une mise à jour de Relay peut le faire.

Garanties et limites attendues

• La charge de travail ne reçoit pas l’identifiant du propriétaire de la base de données.
• Chaque liaison reçoit une identité distincte dans le moteur, révocable indépendamment.
• La recréation de la charge de travail préserve la propriété souhaitée de la liaison.
• La suppression de la liaison révoque son principal sans supprimer la base de données.
• Les nouvelles admissions échouent de manière fermée lorsque la base, le démon ou le chemin Relay requis sont indisponibles.
• La réconciliation rétablit le lien de la liaison et valide l’identité existante dans le moteur au lieu de créer des utilisateurs orphelins lors de pannes transitoires.

Une liaison privée n’est ni une sauvegarde, ni une réplication, ni un système de haute disponibilité. La disponibilité de la base dépend toujours de l’instance managée, de son nœud, du stockage et de votre conception de la reprise. En Business et Enterprise, la base elle-même peut s’exécuter sur 2 à 5 nœuds Storage, un primaire et ses copies ; les liaisons atteignent toujours le primaire (Bases de données et stockage sur plusieurs serveurs). Les mises à jour de Relay sont une maintenance explicite du plan de données et peuvent interrompre les sessions de tunnel ; les mises à jour de l’application ou du plan de contrôle et la maintenance de Relay sont des événements différents.

Défaillance et reprise en toute sécurité

Si la liaison n’est pas saine, identifiez d’abord quelle couche est indisponible : charge de travail applicative, nœud Docker, connecteur secure-link du nœud, Relay, nœud Storage, instance de base de données, identité dans le moteur ou TLS. Examinez un historique d’opérations et des journaux limités avant de modifier l’état.

Préférez la réconciliation ou une relance ciblée après avoir corrigé la cause racine. Ne supprimez pas manuellement les réseaux, connecteurs ou utilisateurs de moteur appartenant à Opfield ; cela peut transformer une panne d’exécution récupérable en incohérence de propriété ou en problème de nettoyage orphelin. Ne publiez pas le port de la base simplement pour contourner un incident de lien privé.

Si l’accès de l’application doit être retiré, supprimez la liaison et vérifiez que son principal dans le moteur est révoqué. Si la base de données elle-même doit être supprimée, confirmez les exigences de sauvegarde et de conservation et utilisez le processus de suppression des bases managées, en sachant que son stockage managé est supprimé. Gardez ces deux décisions séparées dans l’approbation des changements.

Carte de diagnostic

Symptôme	À vérifier d’abord	Guide détaillé
La base n’atteint jamais Ready	Nœud Storage, contrôles préalables de stockage, version du moteur, tâche de provisionnement	Bases de données managées
La liaison n’est pas saine	Base de données, les deux nœuds, Relay, le lien de la liaison et l’identité dans le moteur	Liaisons applicatives aux bases de données
L’application est refusée	Valeurs de connexion, mode TLS et principal propre à la liaison	Exploitation des bases de données
La liaison échoue après le redémarrage d’un nœud	Fraîcheur du nœud et historique de réconciliation	Mises à jour des nœuds et comportement hors ligne
Un accès direct est nécessaire	Port TLS publié et restrictions réseau	Ports et chemins réseau