PostgreSQL géré sur Dockup : guide complet

PostgreSQL géré fournit à une application une base de données provisionnée, dont les opérations de cycle de vie sont indépendantes du conteneur du service. Dockup prend en charge la création, le démarrage et l’arrêt, les logs, l’inspection de la taille, les sauvegardes, la restauration via la plateforme, les utilisateurs en lecture seule, la migration de nœud et le réseau privé.

Le principe opérationnel clé est la séparation : l’image de l’application est éphémère, les données PostgreSQL sont persistantes, les identifiants sont des secrets et la récupération de la base de données doit être testée indépendamment d’un rollback de l’application.

Comment créer une base de données PostgreSQL gérée ?

Sélectionnez l’espace de travail souhaité, puis créez la base de données :

dockup db create \
  --name main-db \
  --type postgresql \
  --json

Répertoriez les bases de données pour confirmer le slug exact et le statut :

dockup db list --json

Les opérations sur les bases de données utilisent des cibles project/db :

dockup db size production/main-db --json

Attendez la fin du provisionnement avant d’attacher une application. Ne devinez pas le hostname, le port, le nom d’utilisateur ou le mot de passe à partir du nom de la base de données.

Le plan Free autorise trois bases de données dans un même espace de travail et inclut un crédit initial de 10 $. Les plans payants — Hobby à 5 $, Pro à 20 $ par mois — autorisent un nombre illimité de bases de données, d’espaces de travail et de déploiements. La consommation de CPU, de RAM et de disque est mesurée à la minute et déduite du solde d’utilisation inclus.

Comment connecter une application de manière sécurisée ?

Récupérez les informations de connexion à la base de données depuis l’interface de base de données de Dockup et traitez la chaîne de connexion comme un secret. Ne la collez pas dans le dépôt ni dans le transcript de l’agent.

Définissez-la sur le service :

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

dockup deploy production/api --wait --json

Le redeploy est nécessaire, car le processus en cours a reçu son environnement au démarrage. La valeur enregistrée est masquée lors de la lecture de la configuration de l’environnement.

Configurez délibérément le connection pooling de l’application. Un trop grand nombre de workers applicatifs dotés de pools importants peut épuiser les connexions à la base de données, même lorsque le CPU et la mémoire semblent fonctionner normalement. Définissez la taille du pool en fonction de la charge et de la capacité de la base de données, et non du nombre maximal accepté par un framework.

Testez une nouvelle connexion après le déploiement. Un endpoint de health check peut confirmer que le processus HTTP est actif sans prouver qu’une nouvelle session de base de données peut être établie.

Le guide variables d’environnement et secrets explique la rotation des identifiants et l’affichage masqué.

Comment le réseau privé protège-t-il le trafic PostgreSQL ?

Activez un réseau privé au niveau du projet :

dockup network enable production --json

Les services et les bases de données gérées de ce projet reçoivent des hostnames stables au format <slug>.internal. Redeployez l’application pour recevoir les variables de connexion internes injectées.

Pour supprimer le listener public de la base de données et la rendre accessible uniquement en privé :

dockup db private production/main-db --json

Rétablissez l’accès public et privé si nécessaire :

dockup db private production/main-db --off --json

Rendre la base de données accessible uniquement en privé recrée son conteneur tout en préservant les données. Planifiez et vérifiez cette modification comme une opération sur la base de données, et non comme une simple modification DNS sans risque.

Le réseau privé contrôle le routage, tandis que les identifiants PostgreSQL contrôlent l’identité et les autorisations. Conservez les deux niveaux de contrôle. Des projets distincts ne peuvent pas communiquer entre eux, car chaque projet possède son propre réseau.

L’article réseau privé et domaines internes présente la topologie complète.

Comment fonctionnent les sauvegardes et la restauration PostgreSQL ?

Répertoriez les sauvegardes existantes :

dockup db backups production/main-db --json

Lancez une sauvegarde côté serveur :

dockup db backup production/main-db --json

La commande de sauvegarde crée une sauvegarde adaptée à la base de données, et non une copie à chaud du volume brut. Notez l’ID de la sauvegarde, sa date de création, la version de la base de données et la raison de sa création.

Dockup prend en charge la restauration des sauvegardes de bases de données gérées via la plateforme. La référence CLI actuelle ne documente pas de commande dockup db restore ; ce guide n’en invente donc pas. Effectuez la restauration depuis l’interface Dockup prise en charge, sélectionnez la sauvegarde exacte, obtenez l’approbation nécessaire pour la production et vérifiez le résultat.

Un plan de restauration doit inclure :

1. Le point de récupération et la fenêtre de perte d’écritures attendue.
2. Le gel des écritures de l’application ou le comportement prévu en maintenance.
3. La compatibilité de la base de données et des extensions.
4. Une sauvegarde récente de l’état actuel, lorsque cela est utile.
5. Le responsable de la restauration et l’approbation requise.
6. La reconnexion de l’application et le smoke test.
7. La traçabilité dans l’audit et l’incident.

Les sauvegardes ne sont pas validées tant qu’un exercice de restauration n’a pas abouti. Utilisez une base de données hors production ou un environnement de récupération approuvé pour tester la procédure.

Conservez les sauvegardes conformément à une politique approuvée. Supprimez les points de récupération obsolètes uniquement via l’interface de base de données prise en charge, après avoir vérifié qu’aucune exigence de récupération ou de conformité ne dépend encore d’eux.

Comment fonctionnent les utilisateurs PostgreSQL en lecture seule ?

Les utilisateurs supplémentaires en lecture seule sont utiles pour l’analytics, les investigations du support, les preview deployments et les outils qui doivent effectuer des requêtes sans écrire.

Répertoriez les utilisateurs :

dockup db users production/main-db --json

Créez-en un avec un label :

dockup db user-add production/main-db \
  --label analytics \
  --json

Récupérez le credential généré de manière sécurisée lors de la création et ne le reproduisez pas dans une réponse d’agent. Révoquez l’utilisateur supplémentaire via l’interface de gestion des utilisateurs de base de données prise en charge lorsque son rôle prend fin.

Le contrôle en lecture seule au niveau des permissions de la base de données est plus fiable que de demander à un outil de requête de « ne pas écrire ». Il autorise néanmoins l’accès aux données de production lisibles : les règles de confidentialité et de moindre privilège s’appliquent donc.

Dockup crée automatiquement un utilisateur de base de données en lecture seule pour une PR ou une branch preview dans un projet utilisant le réseau privé. La preview peut accéder à la même base de données de production via <slug>.internal et lire les données sans disposer de droits d’écriture.

Comment surveiller la taille, les logs et le placement ?

Inspectez la taille sur disque :

dockup db size production/main-db --json

Consultez les logs d’exécution de l’application pour repérer les échecs de connexion sans exposer les mots de passe ni les chaînes de connexion complètes :

dockup logs production/api --json

La maintenance de la base de données peut rendre les services dépendants indisponibles. Planifiez les opérations qui modifient l’état, exigez une approbation opérationnelle explicite et communiquez l’impact avant d’agir.

Déplacez une base de données entre des nœuds en indiquant l’ID du nœud cible :

dockup db migrate production/main-db \
  --node <nodeId> \
  --json

Une migration est une opération avec état. Vérifiez le statut des sauvegardes, les attentes en matière de maintenance, les connexions au réseau privé et les contrôles applicatifs à effectuer après le déplacement.

Checklist de production PostgreSQL géré

Un runbook complet consigne :

Domaine	Éléments de preuve requis
Identité	Cible project/db exacte
Connectivité	Chaîne de connexion secrète et nouvelle session testée
Réseau	Politique publique, privée ou privée uniquement
Accès	Rôle de l’application et utilisateurs en lecture seule identifiés par un label
Capacité	Taille actuelle et analyse de la croissance
Sauvegardes	ID des sauvegardes récentes et politique de rétention
Récupération	Exercice de restauration réussi
Opérations	Approbation du démarrage, de l’arrêt, du redémarrage et de la migration
Audit	Modifications de la base de données traçables jusqu’à un acteur

Le rollback d’un déploiement applicatif ne restaure pas PostgreSQL. La restauration de la base de données n’effectue pas automatiquement de rollback du code applicatif. Coordonnez les deux uniquement lorsque la compatibilité du schéma l’exige.

Pour les décisions de scaling plus larges, consultez stratégies de scaling des bases de données. Pour les commandes exactes, utilisez la référence CLI de Dockup.

Concevoir les migrations de schéma pour le déploiement et le rollback

Le déploiement de l’application et la modification du schéma de la base de données évoluent selon des calendriers différents. Une migration sûre est généralement rétrocompatible pendant au moins une fenêtre de release : ajoutez une colonne nullable avant de la rendre obligatoire, déployez du code capable de gérer les deux schémas, effectuez le backfill selon un processus contrôlé, puis supprimez l’ancienne structure ultérieurement.

Ne faites pas exécuter une migration longue par un health check. Si l’application démarre plusieurs replicas, assurez-vous qu’un seul migration runner peut prendre en charge la modification. La commande exec du conteneur PRO peut exécuter une commande ponctuelle et propager son véritable code de sortie :

dockup exec "npm run migrate" \
  -s production/api \
  --json

Utilisez-la uniquement lorsque la commande de migration a été revue et que le service s’exécute sur le main server pris en charge. Capturez stdout, stderr et le code de sortie. Un déploiement applicatif réussi ne signifie pas qu’une migration en échec peut être ignorée.

Faire tourner les identifiants de base de données sans interruption

Créez le nouvel identifiant ou utilisateur en lecture seule, mettez à jour le secret du service consommateur, redeployez, puis vérifiez une nouvelle connexion avant de révoquer l’ancien identifiant. Les connection pools existants peuvent masquer un nouveau mot de passe incorrect jusqu’à leur reconnexion.

Pour l’identifiant principal de l’application, utilisez l’interface Dockup prise en charge et la politique de la base de données. Pour un utilisateur analytique supplémentaire, créez un compte en lecture seule identifié par un label et distribuez-le uniquement au consommateur approuvé.

L’enregistrement de la rotation doit mentionner le label de l’utilisateur, les services consommateurs, les ID de déploiement, la requête de vérification, l’heure de révocation et l’événement d’audit — jamais le mot de passe.

Observer la croissance avant de faire du scaling

La taille de la base de données est un indicateur :

dockup db size production/main-db --json

Mettez-la en regard de la latence des requêtes applicatives, du nombre de connexions, du comportement du cache, de la durée des sauvegardes et de la croissance du stockage. Une allocation plus importante de CPU ou de mémoire ne corrigera pas nécessairement l’absence d’index ou les requêtes sans limite.

Consultez stratégies de scaling des bases de données avant de déplacer des nœuds ou d’augmenter les ressources. PostgreSQL géré réduit le travail de provisionnement, mais la conception du schéma et des requêtes reste sous la responsabilité de l’application.

Distinguer disponibilité et exactitude

Un conteneur de base de données en cours d’exécution prouve que PostgreSQL est disponible, mais pas que les requêtes de l’application sont correctes. Incluez une nouvelle connexion à faible risque et une lecture représentative dans la vérification post-déploiement. Pour tester une écriture, utilisez une transaction dédiée ou un enregistrement de test qui peut être supprimé sans risque.

Le runbook PostgreSQL géré doit également préciser si les replicas, les utilisateurs analytiques, les previews ou les background workers génèrent une pression supplémentaire sur les connexions.

Vérifier régulièrement les accès PostgreSQL

Répertoriez les utilisateurs supplémentaires, confirmez que chaque label possède un responsable actif et supprimez les comptes obsolètes. Cette simple vérification évite que les accès en lecture de PostgreSQL géré ne s’accumulent après la fin des previews, des projets d’analytics ou des investigations du support.

Commencer par un déploiement vérifiable

Créez une base de données PostgreSQL hors production, connectez un service de test au moyen d’un secret masqué, effectuez une sauvegarde et terminez un exercice de restauration avant le basculement en production.

Commencez gratuitement sur app.dockup.ai. Le plan Free coûte 0 $ par mois, inclut un crédit initial de 10 $ et prend en charge un espace de travail, trois bases de données et trois déploiements.

FAQ

Quels types de bases de données gérées Dockup prend-il en charge ?

Dockup prend en charge les bases de données gérées PostgreSQL, MySQL, MongoDB et Redis.

Comment une application doit-elle recevoir sa chaîne de connexion PostgreSQL ?

Traitez la chaîne de connexion comme une variable d’environnement secrète, définissez-la sur le service exact, puis redeployez afin que le nouveau conteneur la reçoive.

Dockup peut-il créer un utilisateur PostgreSQL en lecture seule ?

Oui. La commande user-add de la base de données crée un utilisateur supplémentaire en lecture seule et renvoie son mot de passe une seule fois, lors de la création.

Existe-t-il une commande CLI documentée dockup db restore ?

La référence CLI actuelle n’en documente aucune. Dockup prend en charge la restauration des sauvegardes via l’interface de la plateforme : utilisez donc ce parcours pris en charge plutôt que d’inventer un flag ou une commande.

Le rollback de l’application restaure-t-il la base de données PostgreSQL ?

Non. L’historique des déploiements de l’application et celui des sauvegardes de la base de données sont deux systèmes de récupération distincts ; ils doivent être coordonnés lorsque les modifications de schéma l’exigent.