Comment auto-héberger CloudBeaver en 2026 : drivers de base de données, workspace et accès
Auto-hébergez CloudBeaver avec les bons ports, un stockage persistant, HTTPS, des secrets, des sauvegardes et des contrôles de mise à niveau. Découvrez comment corriger les échecs de permissions du workspace.
La démonstration CloudBeaver la plus courte prouve qu’un processus écoute sur le port 8978. En production, il faut des preuves plus solides. Le scénario suivant doit fonctionner même après le remplacement du container : terminer la configuration de l’administrateur, installer le driver requis, se connecter via un hostname privé et exécuter une requête en lecture seule.
CloudBeaver est déployé dans un but précis : fournir un client de base de données dans le navigateur pour Postgres, MySQL et d’autres systèmes. Le piège de déploiement le plus courant est l’échec des permissions du workspace ou l’impossibilité pour le DNS du container de résoudre les hosts des bases de données. La gestion de l’URL publique et la persistance de l’état doivent donc recevoir autant d’attention que le démarrage de l’image.
Restaurer CloudBeaver sur un host vide
Répertoriez l’état avant la création du premier enregistrement réel : workspace, utilisateurs, définitions de connexions et stockage des credentials. Montez /opt/cloudbeaver/workspace avant le bootstrap, écrivez des données d’exemple inoffensives et remplacez le container pour prouver que ce chemin est bien persistant. Confirmez le montage en écrivant des données inoffensives, en remplaçant CloudBeaver, puis en les relisant.
Les snapshots sont utiles pour effectuer rapidement un rollback, mais une sauvegarde indépendante est nécessaire si le host ou le volume disparaît. Restaurez dans un environnement vide avec l’image épinglée et vérifiez que le workspace, les utilisateurs, les drivers et les connexions sont restaurés, tandis que chaque base de données sous-jacente suit son propre plan de sauvegarde. Utilisez les volumes persistants et les snapshots pour maintenir ces deux mécanismes de récupération distincts.
Lancer CloudBeaver avec des defaults observables
La commande suivante rend la frontière du container visible sans prétendre provisionner tous les services externes.
docker run -d \
--name cloudbeaver \
--restart unless-stopped \
-p 127.0.0.1:8978:8978 \
-v cloudbeaver-data:/opt/cloudbeaver/workspace \
-e CB_SERVER_NAME=CloudBeaver \
dbeaver/cloudbeaver:latest
Avant d’ouvrir l’ingress, inspectez l’environnement résolu, les montages et le listener. Ajoutez les paramètres de connexion validés pour les routes privées ainsi que les drivers de base de données nécessaires à chaque base ciblée ; utilisez des noms privés pour les services privés. Un lancement réussi se termine lorsque vous pouvez terminer la configuration de l’administrateur, installer le driver requis, vous connecter via un hostname privé et exécuter une requête en lecture seule, pas lorsque docker ps affiche Up.
Ce dont dépend CloudBeaver
Le processus HTTP de CloudBeaver écoute sur le port 8978 ; conservez ce port sur le réseau applicatif et ne publiez que la route de la plateforme. Le contrat réseau de CloudBeaver repose sur des routes privées et des drivers de base de données pour chaque base ciblée. Conservez les endpoints privés sur le DNS interne, n’autorisez que les appels sortants nécessaires et attribuez à CloudBeaver un credential de service aux permissions limitées.
Formalisez cette frontière dans un contrat court : qui est responsable de l’exigence, quel credential est utilisé, quel timeout est acceptable et comment l’échec se manifeste. Exécutez ensuite cette transaction : terminer la configuration de l’administrateur, installer le driver requis, se connecter via un hostname privé et exécuter une requête en lecture seule. Observez l’état du workspace, les téléchargements de drivers, les sessions concurrentes et la latence réseau vers chaque base de données pendant l’exécution, car cette charge fournit une taille de départ plus pertinente qu’un container inactif.
Garder les URLs internes et externes distinctes
La frontière publique de CloudBeaver doit utiliser un hostname canonique unique, un TLS automatique et une seule cible interne sur le port 8978. Définissez l’URL du serveur et les headers du proxy pour l’origine HTTPS publique afin que les clients reviennent vers une adresse reconnue par le service.
Si la transaction d’acceptation échoue, catégorisez la première erreur. Les problèmes de DNS, de certificat et de 502 relèvent de la checklist de validation TLS. La condition « les permissions du workspace échouent ou le DNS du container ne parvient pas à résoudre les hosts des bases de données » relève de la couche applicative après qu’une requête a bien atteint CloudBeaver.
Une procédure d’acceptation de production pour CloudBeaver
N’utilisez pas le trafic du premier utilisateur comme test d’acceptation de CloudBeaver. Préparez un état d’exemple inoffensif et exécutez l’action complète « terminer la configuration de l’administrateur, installer le driver requis, se connecter via un hostname privé et exécuter une requête en lecture seule ». Notez l’URL publique exacte, le résultat, la référence de l’image et l’intervalle de logs associés à l’exécution.
Remplacez le container et recommencez sans reconstruire les données. Récupérez ensuite l’environnement sur un host vide ; la condition de récupération est que le workspace, les utilisateurs, les drivers et les connexions soient restaurés, tandis que chaque base de données sous-jacente suit son propre plan de sauvegarde. Observez l’état du workspace, les téléchargements de drivers, les sessions concurrentes et la latence réseau vers chaque base de données à chaque passage, puis définissez une alerte sur la dégradation de la transaction plutôt que sur les métriques d’un container inactif.
Un dernier contrôle doit échouer volontairement : refusez temporairement à l’identité de test l’accès aux routes privées et aux drivers de base de données pour chaque base ciblée. Vérifiez que le message CloudBeaver obtenu identifie la frontière concernée au lieu de déclencher une suppression de données ou un redémarrage sans fin. Rétablissez la condition valide et confirmez que la même transaction d’exemple réussit. Conservez ce court exercice dans la checklist de release.
Diagnostiquer un CloudBeaver qui semble sain
La première métrique opérationnelle utile pour CloudBeaver est sa capacité à terminer la configuration de l’administrateur, installer le driver requis, se connecter via un hostname privé et exécuter une requête en lecture seule. Associez-la aux signaux de saturation de l’état du workspace, des téléchargements de drivers, des sessions concurrentes et de la latence réseau vers chaque base de données. Une probe limitée au processus ne doit pas appeler de dépendances coûteuses ni redémarrer le container parce qu’un upstream est brièvement indisponible.
Considérez les upgrades comme des changements de données, car les migrations du workspace CloudBeaver et la compatibilité des drivers doivent être testées avant de modifier les versions d’image. Épinglez les versions, répétez la procédure sur un état restauré et conservez l’image précédente tant qu’un rollback reste possible. Lorsque les permissions du workspace échouent ou que le DNS du container ne parvient pas à résoudre les hosts des bases de données, conservez les logs antérieurs au redémarrage ; ils contiennent généralement le message à l’origine du problème.
Décisions de sécurité propres à CloudBeaver
Ne reprenez pas les hypothèses de sécurité d’un tutoriel local. Le point spécifique à CloudBeaver est d’autoriser ou non l’accès anonyme aux connexions de bases de données de production. En production, désactivez donc l’administration anonyme, utilisez des utilisateurs individuels et n’accordez aux comptes de base de données que les permissions nécessaires à chaque connexion.
CB_SERVER_NAME contrôle le comportement, pas la confidentialité ; validez son type et sa valeur, et stockez séparément les véritables credentials CloudBeaver. Limitez les accès au filesystem et au réseau, protégez les endpoints de setup et définissez des limites d’upload, de requête ou d’exécution autour de l’état du workspace, des téléchargements de drivers, des sessions concurrentes et de la latence réseau vers chaque base de données.
Un déploiement Dockup nécessite également un test d’acceptation CloudBeaver
Le déploiement CloudBeaver en un clic de Dockup doit rendre le remplacement sûr : la route doit continuer à cibler le port 8978, les secrets ne doivent pas être intégrés à l’image et les chemins persistants doivent être restaurés sur le nouveau container. Le même déploiement peut s’exécuter sur le compute Dockup ou sur une machine attachée.
Terminez le travail spécifique à l’application en vous connectant et en testant les routes privées ainsi que les drivers de base de données pour chaque base ciblée, en appliquant l’adresse publique canonique et en exécutant ce contrôle d’acceptation : terminer la configuration de l’administrateur, installer le driver requis, se connecter via un hostname privé et exécuter une requête en lecture seule. Ajoutez le résultat de la restauration au runbook avant l’arrivée des vrais utilisateurs.
Questions fréquentes
De quoi CloudBeaver a-t-il besoin pour un déploiement de production ?
Acheminez le container CloudBeaver sur le port 8978 via une origine HTTPS unique. L’exigence réseau associée repose sur des routes privées et des drivers de base de données pour chaque base ciblée. Ne considérez pas CloudBeaver comme prêt tant que vous ne pouvez pas terminer la configuration de l’administrateur, installer le driver requis, vous connecter via un hostname privé et exécuter une requête en lecture seule.
Quelles données CloudBeaver doivent être sauvegardées ?
Rendez /opt/cloudbeaver/workspace persistant et incluez le workspace, les utilisateurs, les définitions de connexions et le stockage des credentials dans le même recovery manifest. Une restauration CloudBeaver propre n’est réussie que lorsque le workspace, les utilisateurs, les drivers et les connexions sont restaurés, tandis que chaque base de données sous-jacente suit son propre plan de sauvegarde.
CloudBeaver nécessite-t-il HTTPS derrière un reverse proxy ?
Utilisez HTTPS pour l’origine publique de CloudBeaver et conservez le port 8978 sur la route interne. Appliquez correctement le réglage CloudBeaver : définissez l’URL du serveur et les headers du proxy pour l’origine HTTPS publique. Pour CloudBeaver, HTTPS protège les credentials ou le contenu utilisateur en transit et garantit la cohérence du comportement client dépendant de l’origine.
Comment tester une mise à niveau de CloudBeaver ?
Restaurez l’état actuel de CloudBeaver dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car les migrations du workspace CloudBeaver et la compatibilité des drivers doivent être testées avant de modifier les versions d’image. Conservez l’image CloudBeaver précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.