PostgreSQL géré, et ce que ce n'est pas

Bases de données, dans le menu, vous donne du PostgreSQL géré : répliqué, avec bascule automatique, sauvegardé, et facturé comme un environnement.

La première chose à poser clairement, c'est ce que ce n'est pas. En créer une ne déplace pas votre Odoo dessus. Votre environnement continue de tourner sur la base avec laquelle il est né tant que vous ne demandez pas explicitement le contraire, et la plupart des équipes ne le font jamais : elles créent une base gérée pour tout autre chose, et c'est le cas normal, pas l'exception.

À quoi sert une base gérée

Trois usages, à peu près dans l'ordre de fréquence :

• Une base pour votre propre code. Un module qui stocke ses propres données, une intégration, un schéma de reporting — tout ce que vous préférez ne pas mettre dans le schéma d'Odoo.
• Une base pour une application qui n'est pas Odoo du tout. Un service à part, un script, un outil que votre équipe fait tourner. C'est du PostgreSQL ordinaire ; rien n'y est spécifique à Odoo.
• La base sur laquelle Odoo lui-même tourne, si vous voulez les données de l'environnement sur un cluster répliqué plutôt que sur la base partagée de la plateforme. C'est une bascule explicite, décrite plus bas.

La liste est aussi la vue honnête de l'état. Un cluster passe par demandé → en création → en service, et les actions de sa ligne restent inactives tant qu'il n'y est pas. Cela prend des minutes, pas des secondes : ce sont du vrai stockage et de vraies réplicas que l'on met en route.

La forme que vous choisissez, et les deux nombres

Nouvelle base demande quatre choses : un nom, un plan, une version de PostgreSQL et une quantité de stockage.

Deux de ces choix méritent une phrase.

La haute disponibilité, c'est un nœud ou trois. Aucun plan ne propose deux nœuds. Un nœud, c'est une instance seule ; trois, c'est un primaire avec deux réplicas et une bascule automatique — la plus petite forme qui conserve une majorité quand un nœud disparaît, ce qui fait de la bascule une décision et non un pari.

Le stockage ne fait que grandir. Vous pourrez l'augmenter plus tard ; vous ne pourrez pas le réduire. Partez donc de là où vous pensez être dans quelques mois plutôt que de là où vous êtes aujourd'hui : sous-dimensionner se corrige à peu de frais, surdimensionner non.

Puis les deux nombres. L'assistant affiche une estimation, calculée dans votre navigateur comme prix de base × nœuds + prix par Gio × stockage, dans la devise du plan. Le montant réellement facturé est produit par la facturation au moment de la création, dans la devise de votre équipe, et c'est celui-là qu'affiche la liste. Si les deux diffèrent, c'est la liste qui a raison.

L'argent est aussi la première chose vérifiée. Avant que quoi que ce soit ne soit créé, la plateforme demande à la facturation si vous pouvez assumer le nouveau coût mensuel. Un compte suspendu est refusé d'emblée ; un solde insuffisant est refusé avec le montant qui manque. Et si la facturation elle-même est injoignable, la création est refusée plutôt que laissée passer — c'est le bon sens du refus quand l'autre option serait d'offrir une base que personne ne paie.

S'y connecter

Se connecter, sur un cluster en service, ouvre tout ce dont vous avez besoin, et rien de plus.

Le mot de passe est masqué tant que vous ne le demandez pas, et chaque ligne se copie d'un clic. En dessous se trouve l'adresse externe, si vous avez activé l'accès externe, et un bouton qui copie une URI prête à coller avec sslmode=require déjà dedans — c'est celle à donner à psql, à un client graphique ou à une application hébergée ailleurs.

La section repliée Points d'accès internes (avancé) contient les adresses qui ne se résolvent qu'à l'intérieur de la plateforme. Ce sont celles qu'utilisent vos environnements, et elles ne fonctionneront pas depuis votre poste ; il y a rarement une raison d'ouvrir cette section.

Deux choses de plus vivent ici. Faire tourner le mot de passe tient en un bouton — et cela réinjecte aussi les nouveaux identifiants dans chaque environnement auquel ce cluster est attaché, et les redémarre, faute de quoi ces environnements garderaient un mot de passe qui ne marche plus.

Et voir les informations de connexion exige database.connect, une permission distincte de database.view. Quelqu'un peut être autorisé à voir qu'un cluster existe, sa taille et son coût, sans qu'on lui remette jamais ses identifiants.

Les deux façons dont un environnement s'en sert

C'est la distinction autour de laquelle tourne toute cette page, et l'onglet Bases de données de l'environnement montre les deux à la fois.

La base principale est celle sur laquelle Odoo lui-même tourne. Par défaut, c'est le PostgreSQL de la plateforme, et la carte le dit. Changer de base de données la déplace — vers l'un de vos clusters en service, ou de retour vers la plateforme — et c'est une vraie migration : les données sont exportées, restaurées sur la cible, et l'environnement est réaiguillé. On vous demande d'abord de saisir le nom de l'environnement, puis l'opération se déroule en arrière-plan avec son état affiché sur la carte. Une vérification peut vous arrêter : une version d'Odoo qui exige un PostgreSQL plus récent que celui du cluster visé est refusée avant que rien ne bouge.

Les attachements sont l'autre relation, et ils ne changent rien à Odoo. Attacher un cluster injecte sept variables dans les processus de l'environnement — hôte, hôte en lecture seule, port, nom de base, utilisateur, mot de passe et une URI toute faite — sous un préfixe que vous choisissez, et le redémarre pour que votre code puisse les lire. Attachez une deuxième base et vous obtenez un deuxième jeu sous un deuxième préfixe ; la plateforme recalcule l'ensemble à chaque fois, si bien qu'attacher et détacher convergent au lieu de dériver.

Le panneau liste les noms des variables, jamais les valeurs. Les noms sont ce dont votre code a besoin et on peut les montrer à quiconque voit l'environnement. Les valeurs, elles, exigent database.connect, et n'existent que dans les processus en cours d'exécution.

Attacher se fait depuis la page Bases de données, parce qu'un cluster peut servir plusieurs environnements. Changer la base principale se fait ici, parce que c'est une propriété de cet environnement-là.

L'agrandir, la sauvegarder, revenir en arrière

Ouvrez un cluster et vous obtenez son propre espace : aperçu, configuration, sauvegardes, exports, réseau, métriques et journaux.

Redimensionner change le plan, le nombre de nœuds ou le stockage d'un cluster en service. La facturation est mise à jour d'abord, et si le changement ne peut ensuite pas être appliqué, la modification de facturation est annulée — vous ne restez pas à payer une taille que vous n'avez pas obtenue. Le stockage, encore une fois, ne fait que grandir.

Les sauvegardes tournent toutes seules — une sauvegarde complète chaque jour à 02:00, conservée sept jours — et vous pouvez en déclencher une à tout moment. La restauration fonctionne ici autrement que partout ailleurs sur la plateforme : elle crée un nouveau cluster à partir des sauvegardes, éventuellement à un instant choisi, et ne touche jamais à la source. C'est la forme la plus sûre pour une restauration, puisque ce que vous cherchez à sauver est toujours là si la restauration se révèle mauvaise. Cela signifie aussi que le cluster restauré est un second cluster, avec son propre prix mensuel, tant que vous n'en supprimez pas un des deux.

Configuration expose une liste blanche de réglages PostgreSQL. Les valeurs sont vérifiées contre la plage que votre plan autorise réellement avant d'atteindre le serveur : un mauvais réglage est donc refusé dans le formulaire au lieu de casser un redémarrage. Vider un champ rend ce réglage à sa valeur par défaut.

Réseau est l'endroit où l'on active l'accès externe, et cela vient avec une règle : une liste d'adresses IP autorisées est obligatoire. La plateforme n'expose pas une base à l'internet entier, il n'y a donc aucun moyen d'activer l'accès externe sans dire qui a le droit de se connecter. Les adresses s'écrivent en notation CIDR, comme 203.0.113.10/32, et les connexions passent par TLS.

Quand ça refuse, et qui a le droit

Quatre permissions découpent cette surface : database.view pour voir les clusters, database.create pour en ajouter un, database.manage pour redimensionner, configurer et ouvrir l'accès externe, et database.connect pour les identifiants et les attachements. La suppression reste aux administrateurs et propriétaires de l'équipe — comme supprimer un environnement, elle détruit des données.

Une dernière chose à lire avant de cliquer dessus. Supprimer un cluster détruit son stockage et toutes ses sauvegardes : aucune restauration n'est ensuite possible, depuis nulle part. Les environnements qui lui sont attachés perdent leurs variables et redémarrent. La confirmation énumère tout cela et demande de saisir le nom du cluster — et cette énumération est exacte, ce qui est la seule raison de la lire.