Vue d'ensemble des bases de données

Opfield travaille avec les bases de données de deux façons : une instance managée qu’Opfield provisionne et exécute sur un nœud Storage, et une connexion externe vers une base qui s’exécute ailleurs. Les deux apparaissent dans la même liste, avec les mêmes vérifications de santé, métriques, Explorer, Console et sauvegardes.

Choisissez le modèle avant la mise en service d’une application. Utilisez une connexion externe pour une base dont le moteur est déjà exploité par une autre plateforme ou une autre équipe. Utilisez une instance managée lorsqu’Opfield doit exécuter le moteur : il la provisionne sur un disque local borné, affiche sa santé et ses actions de cycle de vie, et crée des liaisons applicatives privées. Convertir un modèle en l’autre est une migration, et non un paramètre.

Bases de données managées et externes en un coup d’œil

Les deux modèles prennent en charge PostgreSQL, les stockages clé-valeur et ClickHouse et apparaissent dans la même liste Databases. Un stockage clé-valeur fonctionne avec les clients Redis ; les nouveaux stockages managés exécutent Valkey (voir Stockages clé-valeur). Le tableau indique ce qu’Opfield provisionne et exécute, et ce à quoi il se connecte seulement.

Capacité	Base de données managée	Connexion externe
Qui provisionne et exécute le moteur	Opfield, sous forme de conteneur avec un stockage de taille fixe sur un nœud Storage	Le propriétaire actuel de la base, hors d’Opfield
Versions du moteur	Un catalogue sélectionné d’images PostgreSQL, Valkey et ClickHouse épinglées par empreinte ; les stockages créés avant 2.12 conservent Redis jusqu’à Move to Valkey	Ce qu’exécute le propriétaire
Test de connexion, santé et métriques	Oui, y compris CPU, mémoire, swap et processus du conteneur	Oui, santé et métriques du moteur
Explorer pour les schémas et les données	PostgreSQL et ClickHouse	PostgreSQL et ClickHouse
Console SQL ou console de commandes clé-valeur	Oui	Oui
Extensions PostgreSQL	Activer ou désactiver les extensions incluses dans l’image	Non
Journaux du moteur	Oui	Non
Mise en pause, reprise, redémarrage et nouvelle tentative d’un provisionnement en échec	Oui	Non
Redimensionnement du CPU, de la mémoire, du swap et du stockage	Oui ; le stockage ne peut qu’augmenter	Non
Paramètres du moteur	Nombre maximal de connexions PostgreSQL, paramètres de persistance et de mémoire du stockage clé-valeur, configuration XML de ClickHouse	Non
Publication TCP directe avec TLS natif	Sur option, modifiable plus tard	Sans objet
Comment Opfield vérifie TLS	Opfield joint l’instance via le tunnel Relay à authentification mutuelle ; le TLS de PostgreSQL est aussi vérifié par rapport à l’Opfield Database CA	La chaîne de certificats et le nom d’hôte sont vérifiés par défaut ; CA personnalisée facultative ; désactivation explicite. Voir Vérification des certificats TLS
Identifiants	Opfield garde l’identifiant du propriétaire en interne ; l’affichage et la rotation s’appliquent à un utilisateur d’accès direct distinct d’une instance publiée	Détails de connexion enregistrés, chiffrés au repos et affichables avec `databases:credentials:reveal` ; un URI PostgreSQL affiché utilise `sslmode=verify-full` lorsque la vérification est activée et `sslmode=require` lorsqu’elle est désactivée
Liaisons privées vers les Containers, Deployments et services Compose	Oui, avec une identité distincte dans le moteur par liaison	Non ; fournissez les valeurs de connexion sous forme de secrets de la charge de travail
Mise à niveau de la version du moteur	Via l’API et MCP, vers une version plus récente du catalogue pour le même moteur : PostgreSQL au sein de sa version majeure, Valkey et ClickHouse vers la version suivante du catalogue. Une autre version majeure de PostgreSQL implique de restaurer une sauvegarde dans une nouvelle base	Responsabilité du propriétaire
Sauvegarde et restauration	Sauvegardes natives planifiées vers une connexion de stockage ; restauration dans une nouvelle base managée, ou dans une base existante vide via l’API	Identique aux bases managées
Plusieurs serveurs avec basculement	En Business et Enterprise, de 2 à 5 nœuds Storage avec un primaire et des copies ; voir Bases de données et stockage sur plusieurs serveurs	Responsabilité du propriétaire
Suppression	Retire le moteur, son stockage et ses données ; bloquée tant que des liaisons existent	Retire uniquement l’enregistrement conservé par Opfield
Plan	Personal ou supérieur	Personal ou supérieur

L’accès à l’Explorer et à la console nécessite les scopes distincts databases:query:read, databases:query:write ou databases:query:admin en plus de databases:view. Opfield classe chaque instruction de la console comme une opération de lecture, d’écriture ou d’administration et exige le scope correspondant.

Vérification des certificats TLS pour les connexions externes

Lorsqu’une connexion externe utilise TLS, Opfield vérifie la chaîne de certificats du serveur et que le certificat a été émis pour l’hôte configuré. C’est le comportement par défaut des nouvelles connexions. Dans les paramètres de la connexion :

Verify server certificate active ou désactive la vérification pour cette connexion. La désactiver laisse le trafic chiffré, mais permet à quiconque se trouve sur le chemin réseau d’usurper l’identité de la base et de capturer ses identifiants ; ne l’utilisez que comme exception délibérée.
CA certificate accepte un bundle PEM d’une CA privée, utilisé à la place du bundle de CA publiques. Seuls des certificats sont acceptés ; une clé privée collée est refusée.

Opfield teste la connexion avec les nouveaux paramètres avant d’enregistrer une connexion nouvelle ou modifiée. Si le certificat ne peut pas être vérifié, la modification est refusée avec DATABASE_TLS_VERIFICATION_FAILED (HTTP 422) et la connexion enregistrée reste inchangée. Désactiver la vérification, ou faire passer une connexion vérifiée à une autre CA, exige de ressaisir le mot de passe de la base, car le mot de passe enregistré pourrait sinon atteindre un serveur non vérifié.

Une connexion qui utilise TLS sans vérification affiche TLS certificate is not verified sur sa page de détail. Test and enable verification active la vérification après un test réussi, et Add CA certificate ouvre les paramètres pour ajouter une CA privée. Les connexions PostgreSQL et Redis qui utilisaient TLS avant 2.11 démarrent dans cet état non vérifié afin que la mise à niveau les garde connectées ; les connexions HTTPS ClickHouse étaient déjà vérifiées. Les sauvegardes des bases de données utilisent le même paramètre.

Modèle de ressources

Les instances PostgreSQL, clé-valeur et ClickHouse managées sont privées par défaut. Opfield coordonne la configuration du moteur, le stockage, les identifiants, la santé, les journaux, les opérations et les liaisons applicatives. Le nœud Storage sélectionné exécute le moteur, tandis qu’Opfield conserve l’état souhaité de la ressource et ses relations avec les charges de travail.

Une connexion externe ne transfère pas la propriété de la base de données à Opfield. Opfield stocke sa configuration de connexion et ses identifiants chiffrés au repos derrière des permissions explicites et peut sauvegarder la base ; la disponibilité de la base externe, sa politique d’accès et le cycle de vie de son moteur restent du ressort de son opérateur.

Traitez les identifiants enregistrés comme des secrets d’infrastructure privilégiés. Accordez séparément les permissions de consultation, de modification, d’affichage et de requête lorsque le modèle de rôles le permet, et évitez de partager un compte propriétaire ou superutilisateur lorsqu’un compte de service plus restreint est disponible. Supprimer une connexion externe retire la relation enregistrée par Opfield ; cela ne supprime ni la base distante, ni son stockage, ni ses utilisateurs.

Accès privé par défaut

Utilisez une liaison applicative lorsqu’une charge de travail gérée a besoin d’accéder à une base de données managée. Une liaison accorde une identité distincte dans le moteur avec des privilèges de niveau applicatif — jamais l’identifiant du propriétaire ou du superutilisateur — et un point de terminaison privé qu’Opfield préserve lors des recréations normales de la charge de travail. Il n’existe aucun service supplémentaire par liaison que l’équipe applicative devrait exploiter. Les liaisons ne sont pas disponibles pour les connexions externes.

Ce transport est distinct du connecteur Secure Link entre nginx et les charges de travail. Secure Link reste un composant distinct pour sa propre fonction d’ingress et de relais. Ne considérez pas l’échec d’une liaison comme la preuve que le composant Secure Link doit être retiré, recréé ou configuré comme transport de base de données.

La publication TCP directe est une option explicite destinée aux clients externes. Elle n’ouvre pas automatiquement les pare-feu des hôtes et ne doit être activée que pour un chemin client identifié, avec des identifiants et une confiance dans les certificats appropriés. Publier une instance ne modifie pas le modèle de liaison privée utilisé par les charges de travail.

Cycle de vie et frontières d’exploitation

La vue de détail de la base réunit la santé, les métriques, les paramètres du moteur, les identifiants, les certificats, le redimensionnement, la mise en pause et la reprise, le redémarrage, les journaux et l’accès éligible à l’Explorer ou à la Console. Les actions disponibles dépendent du moteur, de la connectivité du nœud, de la santé de l’instance et des permissions qui vous sont accordées.

La mise en pause préserve les données tout en désactivant intentionnellement le calcul du moteur. Une instance en pause ne fournit pas le comportement normal de santé, de métriques, d’Explorer ou de Console jusqu’à sa reprise. Le redémarrage est utile pour une action opérationnelle contrôlée ; ce n’est pas une réparation pour des problèmes non résolus de stockage, d’authentification ou de nœud.

Base de préparation

Avant de confier une base de données à une équipe applicative, vérifiez l’ensemble de la frontière de propriété :

Le nœud Storage sélectionné est en ligne et signale des capacités de stockage prises en charge.
L’instance managée est Ready, ou le point de terminaison externe est joignable avec la vérification des certificats TLS activée.
La responsabilité des sauvegardes, la conservation et les preuves de restauration sont documentées en dehors de l’instance elle-même.
L’application utilise une identité propre à la liaison ou un autre compte à privilèges minimaux plutôt qu’un identifiant de propriétaire.
La supervision collecte les données sans qu’un opérateur ait besoin de garder la page de détail ouverte.
Un redémarrage ou une reconnexion contrôlés prouvent que le client se rétablit comme prévu.

Un badge de moteur au vert ne constitue pas à lui seul une preuve de bout en bout. Confirmez au moins une vraie requête applicative, la frontière de permissions attendue et l’absence d’identifiants dans la gestion de sources, les journaux, la sortie des tâches et la configuration d’exécution publique.

Disponibilité et limites

Une instance managée s’exécute sur un seul nœud Storage, sauf si vous l’exécutez sur plusieurs serveurs, ce que proposent Business et Enterprise : une copie sur un autre hôte prend alors le relais lorsque le primaire est perdu, et la page indique ce qu’un basculement peut faire perdre. Sur un seul serveur, Opfield préserve l’état souhaité et coordonne la reprise, mais un nœud perdu signifie une base perdue jusqu’à son retour ou sa restauration depuis une sauvegarde. Dans les deux cas, planifiez des sauvegardes hors du nœud et un temps de reprise adaptés à la criticité métier de la base.

Les sauvegardes de configuration d’Opfield ne contiennent pas les données des bases. Supprimer une base de données managée retire son stockage managé ; disposez d’une sauvegarde vérifiée ou d’une cible de migration avant de la supprimer.

Détails pour l’opérateur : transport privé

La charge de travail joint la base de données via le connecteur secure-link partagé de son nœud Docker, sur un petit réseau privé propre à la liaison ; il n’existe ni conteneur connecteur par liaison ni écouteur sur l’hôte. Opfield réconcilie le lien et l’identité de la liaison comme un état souhaité durable. Voir Liaisons de bases de données pour le transport et la mise à niveau 2.11.1.

Étapes suivantes

Provisionner et retirer une base de données managée
Stockages clé-valeur et Move to Valkey
Exécuter une base de données ou un stockage sur plusieurs serveurs
Créer des liaisons applicatives privées
Superviser et rétablir les opérations sur les bases de données
Connecter une application à une base de données privée de bout en bout
Lier une base de données à un Container, un Deployment ou un service Compose
Planifier la protection des données avec Mises à jour, sauvegardes et restauration