Aller au contenu principal

Bases de données sur BYOS

Chaque déploiement sur votre serveur s'appuie sur sa propre base de données PostgreSQL. Cette page couvre les deux choix de base de données propres à l'exécution sur votre propre matériel : l'emplacement de PostgreSQL lui-même, et l'ouverture d'un accès direct en lecture seule à la base d'un déploiement pour vos outils BI et vos scripts.

Emplacement de PostgreSQL​

Lors de l'enregistrement d'un serveur, le tableau de bord demande « Où les bases de données Odoo doivent-elles résider ? » Deux options existent, et ce choix détermine la commande d'installation à exécuter sur le serveur.

Sur votre serveur (par défaut)​

L'installateur met en place une instance PostgreSQL dédiée sur le serveur lui-même, aux côtés de Docker et de l'agent. Chaque déploiement y reçoit sa propre base de données, et les sauvegardes, restaurations et copies de staging fonctionnent sans configuration supplémentaire. C'est le bon choix pour la plupart des serveurs : pas d'infrastructure en plus, pas de trajet réseau entre Odoo et sa base.

PostgreSQL externe ou géré​

Si vous préférez un service de base de données géré (Amazon RDS, Google Cloud SQL, Azure Database for PostgreSQL) ou un cluster PostgreSQL existant, sélectionnez PostgreSQL externe / géré lors de l'enregistrement du serveur. La commande d'installation inclut alors SKYSIZE_PG_MODE=external, et l'installateur demande les informations de connexion (hôte, port, utilisateur, mot de passe, paramètres SSL) directement sur votre serveur.

remarque

Les identifiants de la base de données sont saisis sur votre serveur et y restent. Ils ne sont jamais envoyés à Skysize ; le tableau de bord affiche uniquement le mode utilisé par le serveur et l'hôte de la base.

En mode externe :

  • Aucun PostgreSQL local n'est installé. Toutes les bases des déploiements sont créées sur le serveur externe.
  • La connexion peut utiliser TLS. Si votre fournisseur exige ou propose TLS (c'est le cas de la plupart des services gérés), les paramètres SSL que vous saisissez sont transmis à chaque déploiement, y compris le certificat CA si vous en fournissez un.
  • L'utilisateur de la base doit pouvoir créer des rôles et des bases. L'installateur vérifie à l'installation que l'utilisateur fourni dispose des privilèges CREATEROLE et CREATEDB ; chaque déploiement reçoit toujours sa propre base et son propre rôle.
  • Les extensions doivent être disponibles sur le serveur. Les extensions dont vos modules dépendent (par exemple vector) sont activées base par base lorsque le serveur les propose. Sur un service géré, vérifiez la liste des extensions prises en charge par le fournisseur.

Le serveur PostgreSQL doit être joignable depuis votre serveur Skysize (appairage VPC, réseau privé, ou point d'accès public avec liste d'autorisation, selon votre fournisseur), et sa version doit être prise en charge par votre version d'Odoo.

attention

Choisissez l'emplacement de la base de données lors de la première installation du serveur. Passer un serveur existant du PostgreSQL local à un PostgreSQL externe (ou inversement) est possible, mais les bases des déploiements doivent être migrées manuellement ; contactez le support avant de vous lancer.

Accès direct à la base de données (lecture seule)​

Vous pouvez ouvrir un accès PostgreSQL direct et en lecture seule à la base d'un déploiement, pour des outils BI (Metabase, Power BI, Grafana), des scripts de reporting ou du SQL ponctuel. L'accès est défini par branche, protégé par TLS, et bloqué tant que vous n'avez pas explicitement autorisé les adresses IP qui peuvent se connecter.

Cette fonctionnalité est disponible uniquement sur vos propres serveurs, et réservée aux administrateurs du projet. Elle s'applique aux serveurs utilisant le PostgreSQL local par défaut ; si le serveur utilise une base externe ou gérée, gérez l'accès via votre fournisseur de base de données.

Activer l'accès​

  1. Ouvrez la branche dans le tableau de bord et repérez la carte Accès base de données.
  2. Cliquez sur Créer l'accès en lecture seule. Cela crée un rôle dédié en lecture seule sur votre serveur et affiche son mot de passe une seule fois ; copiez-le avant de fermer le bandeau.
  3. Téléchargez le certificat CA depuis la même carte. Les connexions exigent TLS, et le CA permet à votre client de vérifier qu'il parle bien à votre serveur.
  4. Ajoutez les adresses IP autorisées à se connecter (voir ci-dessous). Tant que la liste d'autorisation est vide, toutes les connexions externes sont bloquées.

La carte affiche les informations de connexion complètes : hôte, port (5432 par défaut), nom de la base et rôle. Une chaîne de connexion typique ressemble à :

postgresql://[email protected]:5432/mabase?sslmode=verify-full&sslrootcert=skysize-db-ca.crt

Utilisez sslmode=verify-full avec le certificat CA téléchargé pour que la connexion soit à la fois chiffrée et authentifiée.

remarque

Si le tableau de bord indique que le port de la base de données n'est pas encore publié sur votre serveur (serveurs installés avant cette fonctionnalité), il affiche une commande d'une ligne à exécuter sur le serveur pour le publier. Le port 5432 doit aussi être ouvert dans le pare-feu de votre fournisseur cloud (security group AWS, règle de pare-feu GCP, etc.). Un pare-feu bloquant fait pendre les connexions sans erreur ; une IP absente de la liste d'autorisation est rejetée instantanément.

La liste d'autorisation d'adresses IP​

Chaque modification de la liste est d'abord appliquée sur votre serveur, puis seulement enregistrée : ce que montre le tableau de bord correspond donc toujours à ce que le serveur applique réellement. Si le serveur est hors ligne, la modification est refusée.

  • Ajoutez une adresse seule (203.0.113.5) ou une plage réseau (203.0.113.0/24), avec une étiquette facultative comme « VPN du bureau » ou « Metabase Cloud ».
  • Supprimer une entrée bloque ce réseau immédiatement.
  • Les plages très larges sont signalées par un badge d'avertissement, et 0.0.0.0/0 (tout Internet) par un avertissement plus fort. Préférez la plage la plus étroite qui couvre vos outils ; les fournisseurs BI SaaS publient les adresses de sortie depuis lesquelles ils se connectent.

Ce que le rôle en lecture seule peut faire​

  • Tout lire, ne rien modifier. Le rôle peut faire des SELECT sur toutes les tables de la base de cette branche, y compris les tables créées par de futures installations de modules. Il ne peut ni écrire, ni créer d'objets, ni atteindre d'autres bases du serveur.
  • Consommation de ressources bornée. Le rôle est limité à 10 connexions simultanées, et les requêtes trop longues ou les transactions laissées ouvertes sont interrompues automatiquement.
attention

Les requêtes en lecture seule s'exécutent sur le même serveur que votre instance Odoo. Des requêtes lourdes ou permanentes peuvent la ralentir ; pour du reporting intensif, lancez vos requêtes hors des heures de pointe ou répliquez les données vers votre propre système.

Rotation et suppression​

  • Renouveler le mot de passe invalide immédiatement le mot de passe courant et en affiche un nouveau, une seule fois. Chaque outil connecté doit recevoir le nouveau mot de passe.
  • Supprimer l'accès supprime le rôle en lecture seule et bloque à nouveau toutes les connexions externes à la base de la branche.

Les mots de passe sont générés par la plateforme (aléatoire de 128 bits) et stockés chiffrés ; ils ne peuvent pas être choisis manuellement.

Modèle de sécurité​

  • Seule la base de la branche est exposée, uniquement aux réseaux de la liste d'autorisation, uniquement via TLS, et uniquement au rôle dédié en lecture seule. Tout le reste, y compris les tentatives de connexion depuis des adresses non autorisées, est rejeté avant même l'authentification par mot de passe.
  • Ce que vous autorisez vous appartient : les plages que vous ajoutez, ainsi que le pare-feu de la machine et du compte cloud qui hébergent le serveur, restent sous votre responsabilité, comme pour le reste du modèle de sécurité BYOS.