Réponse rapide : pour déployer PostgreSQL proprement avec Ansible, il faut 4 briques : un rôle fiable, des variables explicites (version, utilisateurs, bases), une politique d’accès pg_hba.conf maîtrisée et un contrôle d’idempotence. Résultat : un déploiement reproductible, plus rapide à maintenir, et nettement plus sûr qu’une installation manuelle.

Si tu veux un accompagnement direct pour industrialiser ce type de déploiement, tu peux me contacter ici : https://linux-man.fr/index.php/nous-contacter/.

Contexte : pourquoi PostgreSQL devient vite un sujet critique

PostgreSQL est souvent le cœur de l’application métier. Quand la base n’est pas standardisée, chaque incident coûte plus cher : le diagnostic prend plus de temps, les changements sont plus risqués, et les opérations deviennent dépendantes d’une seule personne qui connaît l’historique exact du serveur.

En pratique, je vois trois situations récurrentes : migration d’un serveur historique, ouverture d’un nouvel environnement client, ou reprise après incident. Dans les trois cas, l’automatisation permet de retrouver un socle stable rapidement.

Pour les équipes qui veulent déléguer l’exploitation au quotidien, j’ai détaillé mon approche ici : infogérance serveurs Linux en entreprise.

Base technique utilisée : rôle officiel geerlingguy.postgresql

Le rôle de référence est le repo officiel geerlingguy.postgresql (GitHub), maintenu et documenté avec des variables claires pour piloter installation, configuration, comptes, bases et privilèges.

• Repo officiel : https://github.com/geerlingguy/ansible-role-postgresql
• Compatibilité indiquée : Debian/Ubuntu et RHEL/CentOS
• Variables clés du rôle : postgresql_global_config_options, postgresql_hba_entries, postgresql_databases, postgresql_users, postgresql_privs
• Point d’attention officiel : choisir postgresql_python_library selon Python 2/3 (souvent python3-psycopg2 en distribution récente)

Compatibilité Linux du rôle (analyse du repo officiel)

D’après le README officiel de geerlingguy.postgresql, le rôle est compatible avec deux grandes familles Linux :

• Debian / Ubuntu
• RHEL / CentOS

Concrètement, ça couvre la majorité des contextes PME/SaaS en production. Le rôle adapte ses variables selon l’OS via ses fichiers vars internes (packages, chemins de configuration, nom du service, binaire PostgreSQL), ce qui évite d’écrire des conditions partout dans ton playbook.

Important : sur Linux/Ubuntu récents, pense à aligner postgresql_python_library avec Python 3 (souvent python3-psycopg2) pour que les modules Ansible PostgreSQL fonctionnent correctement.

Architecture recommandée avant de toucher au playbook

Avant l’écriture des variables, je recommande de verrouiller quatre points : version cible PostgreSQL, stratégie d’accès réseau, politique des comptes, et logique de sauvegarde/restauration. Sans ce cadrage, l’automatisation accélère juste les erreurs.

Un plan simple et efficace :

1. Choisir la version PostgreSQL cible pour l’ensemble des environnements.
2. Définir les sous-réseaux qui doivent parler à la base.
3. Séparer les comptes applicatifs, d’administration et d’audit.
4. Documenter un test de restauration complet avant mise en service.

Exemple de playbook minimal

- name: Deploy PostgreSQL with geerlingguy.postgresql
  hosts: db
  become: true
  vars:
    postgresql_version: 16
    postgresql_service_enabled: true
    postgresql_service_state: started
    postgresql_restarted_state: restarted
    postgresql_python_library: python3-psycopg2

    postgresql_global_config_options:
      - option: unix_socket_directories
        value: '/var/run/postgresql'
      - option: log_directory
        value: 'log'

    postgresql_hba_entries:
      - { type: local, database: all, user: postgres, auth_method: peer }
      - { type: local, database: all, user: all, auth_method: peer }
      - { type: host, database: app_prod, user: app_user, address: '10.10.0.0/16', auth_method: md5 }

    postgresql_databases:
      - name: app_prod
        owner: app_user
        encoding: 'UTF-8'
        lc_collate: 'en_US.UTF-8'
        lc_ctype: 'en_US.UTF-8'

    postgresql_users:
      - name: app_user
        password: "CHANGE_ME"
        role_attr_flags: "LOGIN"

    postgresql_privs:
      - db: app_prod
        roles: app_user
        type: database
        privs: ALL
  roles:
    - role: geerlingguy.postgresql

Je recommande aussi de fixer explicitement l’interpréteur Python dans l’inventaire quand tu as un parc mixte, pour éviter les surprises avec les dépendances PostgreSQL côté modules Ansible.

Diagnostic : symptômes d’un déploiement fragile

Voici les signaux faibles qui indiquent qu’il faut standardiser maintenant :

• Configuration différente entre deux serveurs censés être identiques.
• Règles pg_hba.conf modifiées manuellement sans historique fiable.
• Comptes SQL créés ponctuellement, sans convention de nommage.
• Dépendance à une personne pour les opérations sensibles.
• Tests de restauration absents ou incomplets.

Causes racines les plus fréquentes

Absence de source de vérité unique

Quand l’état réel du serveur est différent de ce qui est documenté, chaque intervention devient un pari.

Priorité donnée à la vitesse court terme

Installer vite sans cadrage peut dépanner une fois, mais génère ensuite des heures de correction.

Peu de tests d’idempotence

Le vrai test n’est pas le premier déploiement, mais la relance sans changement inattendu.

Solution pragmatique en 7 étapes

1. Créer un inventaire dédié aux hôtes base de données.
2. Fixer la version PostgreSQL et le mode d’authentification.
3. Déclarer utilisateurs et bases dans les variables du rôle.
4. Poser des règles HBA minimales puis ouvrir progressivement.
5. Lancer le playbook en préproduction.
6. Relancer le playbook pour valider l’idempotence.
7. Documenter procédure de restauration + test fonctionnel applicatif.

Prévention : éviter les incidents après mise en service

Une fois PostgreSQL en place, le sujet n’est pas terminé. La stabilité long terme vient de la discipline d’exploitation : patching régulier, contrôle des accès, supervision, sauvegardes vérifiées et revues périodiques des comptes inutilisés.

Si tu veux un cadre opérationnel complet (maintenance, supervision, gestion des changements), j’ai aussi une offre dédiée : maintenance serveurs Linux.

Checklist opérationnelle

• Version PostgreSQL figée dans l’inventaire (quel que soit l’OS cible)
• Variables critiques relues en pair review
• Comptes applicatifs dédiés par service
• Règles HBA validées avec l’équipe réseau
• Double exécution Ansible sans drift
• Sauvegarde planifiée + test de restauration
• Supervision des métriques clés (latence, connexions, disque)

Erreurs courantes que je corrige en audit

1) Ouvrir trop large dans pg_hba.conf

Le “0.0.0.0/0” dépanne vite mais expose inutilement. Il faut partir du minimum puis élargir uniquement si nécessaire.

2) Réutiliser le compte postgres pour l’application

Ça simplifie au début, puis ça bloque la traçabilité et la sécurité. Un compte par usage reste la bonne pratique.

3) Mélanger config système et config applicative

Quand tout est dans le même fichier de variables, les changements deviennent risqués. Sépare les rôles et les responsabilités.

4) Oublier la restauration

Une sauvegarde non testée n’est pas une sauvegarde fiable. Le test de restauration doit être planifié.

FAQ

Conclusion

Automatiser PostgreSQL avec Ansible te donne un socle fiable, relançable et auditable. Tu réduis les écarts entre environnements, tu limites les erreurs humaines, et tu facilites le passage de relais dans l’équipe.

Si tu veux accélérer proprement sans sacrifier la sécurité, je peux t’aider à cadrer l’architecture, l’automatisation et l’exploitation : contacte-moi ici.

Mise en œuvre détaillée : variables à traiter avec méthode

Dans mes déploiements, je structure les variables PostgreSQL en trois couches : globales (version, service), sécurité (HBA, méthodes d’authentification), et applicatives (bases, utilisateurs, droits). Cette séparation évite de casser toute la stack quand tu modifies un seul périmètre.

Exemple de structuration dans group_vars/db.yml :

postgresql_version: 16
postgresql_service_enabled: true

postgresql_hba_entries:
  - { type: local, database: all, user: postgres, auth_method: peer }
  - { type: host, database: app_prod, user: app_user, address: '10.10.0.0/16', auth_method: md5 }

postgresql_users:
  - name: app_user
    role_attr_flags: "LOGIN"

postgresql_databases:
  - name: app_prod
    owner: app_user
    encoding: UTF-8

Cette approche permet aussi de relire rapidement une PR : on voit immédiatement si un changement touche la sécurité réseau, la couche applicative, ou les deux.

Contrôle qualité avant livraison

Je recommande un contrôle en quatre temps :

1. Validation syntaxique Ansible.
2. Exécution en environnement de test.
3. Seconde exécution pour prouver l’idempotence.
4. Test applicatif réel (connexion + requête simple).

ansible-playbook -i inventory/prod site.yml --syntax-check
ansible-playbook -i inventory/preprod db.yml
ansible-playbook -i inventory/preprod db.yml
psql -h db.example.internal -U app_user -d app_prod -c 'SELECT 1;'

Tu évites ainsi le piège classique du “ça marche chez moi” qui explose au premier redéploiement.

Sécurité : ce qu’il ne faut jamais négliger

Un serveur PostgreSQL correctement déployé mais mal exposé reste une cible facile. Le minimum viable côté sécurité :

• Limiter strictement les IP autorisées dans pg_hba.conf.
• Interdire les accès superflus depuis internet.
• Tracer les modifications de droits via Git.
• Isoler les secrets applicatifs hors dépôt.
• Surveiller les connexions et les erreurs d’authentification.

Pour un cadrage complet (durcissement OS, maintenance, exploitation), je peux aussi intervenir en mode régulier : prestataire infogérance Linux.

Plan de migration simple depuis une installation manuelle

Si ton serveur PostgreSQL existe déjà, ne migre pas en une seule fois. Je conseille un plan progressif :

1. Inventorier la configuration actuelle (version, users, bases, HBA).
2. Reproduire l’existant dans Ansible sans changer le comportement.
3. Déployer en préproduction.
4. Valider l’idempotence et les tests applicatifs.
5. Passer en production sur fenêtre planifiée.

Cette stratégie réduit fortement le risque de coupure et facilite le retour arrière.

Indicateurs à suivre après déploiement

Après mise en service, je suis ces indicateurs pour confirmer la stabilité :

• nombre de connexions actives,
• temps moyen des requêtes critiques,
• taux d’erreurs d’authentification,
• croissance disque,
• durée des sauvegardes/restaurations.

Sans suivi, même un bon déploiement finit par dériver.

Ce que tu gagnes concrètement après standardisation

Une fois PostgreSQL géré proprement avec Ansible, les bénéfices sont immédiats : onboarding plus rapide d’un nouveau client, baisse du stress en production, et meilleure continuité de service pendant les changements. Tu peux aussi industrialiser les revues de configuration parce que tout passe par Git et des PR relisibles.

Autre point important : la transmission interne devient plus simple. Même si la personne qui a monté l’infra n’est pas disponible, l’équipe peut relancer, auditer et corriger sans repartir de zéro. C’est ce qui fait la différence entre une infra dépendante d’un expert unique et une infra réellement exploitable par une équipe.

Si ton objectif est de fiabiliser toute la chaîne Linux (base de données, supervision, sauvegarde, sécurité), le plus efficace est de traiter ces sujets ensemble plutôt qu’en silos.

Vous devriez également aimer

Ubuntu Autoinstall : créer une ISO personnalisée et automatisée avec Docker

25 mars 2026

Packer Proxmox : créer des templates Debian automatiques et reproductibles

16 mars 2026

Ansible variables

22 août 2021