Infra de A à Z 063 – Postgresql & Ansible : déploiement primary du cluster

TL;DR

Cette série construit progressivement une infrastructure cloud complète sur Infomaniak Public Cloud. Dans cet épisode, le sujet précis est: Postgresql & Ansible : déploiement primary du cluster. Concentrer l épisode sur PostgreSQL: installation, réplication, failover, sauvegarde ou restauration selon "Postgresql & Ansible : déploiement primary du cluster".

La vidéo de référence

Vidéo: https://www.youtube.com/watch?v=zbEMUxs2RvY

Playlist complète: https://www.youtube.com/playlist?list=PLn6POgpklwWpehxly1wOT6eB2NvZX9A-X

Le dépôt support est disponible ici: https://gitlab.com/xavki/infrastructure-cloud-infomaniak. Le chapitre correspondant est 62-postgresql-replication-manager-ansible.

Objectif précis de l épisode

Concentrer l épisode sur PostgreSQL: installation, réplication, failover, sauvegarde ou restauration selon "Postgresql & Ansible : déploiement primary du cluster".

Concrètement, cet épisode sert à passer d une intention formulée dans le titre à une modification vérifiable dans l infrastructure. Le dépôt donne les fichiers, la vidéo donne l ordre de manipulation, et la vérification doit confirmer que la brique fonctionne vraiment.

Postgresql & Ansible : déploiement primary du cluster: c est quoi exactement ?

Dans une infrastructure cloud réelle, chaque épisode ajoute une brique: réseau, compute, sécurité, automatisation, découverte de services, observabilité, sauvegardes ou orchestration. Ici, les outils détectés sont: openstack, ansible, consul, postgresql.

Dans cet épisode, il faut surtout regarder les éléments qui correspondent au titre: les ressources créées ou modifiées, les fichiers du chapitre, les services touchés et la preuve de fonctionnement. Les outils détectés donnent le contexte, mais le fil rouge reste Postgresql & Ansible : déploiement primary du cluster.

Ce que la vidéo cherche à modifier

• organiser inventaire, variables et playbooks du chapitre
• appliquer la configuration de manière reproductible
• vérifier les rôles réellement exécutés sur les hôtes ciblés
• séparer configuration base, supervision et sauvegarde
• vérifier le rôle primaire/secondaire ou la stratégie de backup
• documenter la preuve de restauration ou de bascule

Indices extraits des slides

• Postgresql: Ansible && Replication Manager – part 1
• create a new role for postgresql replication
• focus on postgresql and replication manager (failover management in a next video)
• The playbook – postgresql simple
• databases/postgresql/postgresql_simple

Notions et définitions des outils

• openstack: OpenStack est la couche cloud IaaS: instances, réseaux, routeurs, IP flottantes, groupes de sécurité, volumes et images. Chez Infomaniak Public Cloud, il sert de socle programmable via GUI, CLI, Terraform et API.
• ansible: Ansible automatise la configuration des machines après leur création. Les playbooks, rôles, inventaires et variables transforment une VM brute en service exploitable.
• consul: Consul apporte service discovery, DNS interne, health checks et catalogue de services. Il relie machines, proxy, monitoring et automatisation.
• postgresql: PostgreSQL est le SGBD relationnel de la plateforme. La série aborde installation, réplication, failover, utilisateurs, sauvegardes, PITR et monitoring.

Ces définitions sont volontairement pratiques: elles expliquent à quoi sert l outil dans la chaîne, pas seulement ce qu il est sur le papier.

Points clés à retenir pour cet épisode

• Comprendre le rôle de Postgresql & Ansible : déploiement primary du cluster dans la progression globale de l infrastructure.
• Identifier la couche concernée: cloud, automatisation, réseau, service, observabilité ou orchestration.
• Relier les fichiers du dépôt au résultat attendu sur les machines ou dans le cloud.
• Vérifier les inventaires, variables et rôles avant de lancer un playbook.

Approfondissement spécifique

Dans Postgresql & Ansible : déploiement primary du cluster, Ansible doit être lu comme la couche de convergence système. Le sujet n est pas uniquement le playbook lancé, mais la combinaison inventaire, variables, rôles et tâches qui transforme une machine provisionnée en service configuré.

Le diagnostic part de la cible: quel groupe d hôtes est visé, quelles variables sont chargées, quel rôle applique le changement et quel fichier ou service prouve le résultat sur la machine.

Pour Postgresql & Ansible : déploiement primary du cluster, le sujet PostgreSQL doit être lu autour de l état: données, réplication, sauvegarde, restauration ou failover. La réussite ne se limite pas au service démarré.

La preuve dépend du thème: une requête SQL pour l installation, un retard de réplication pour le cluster, une restauration pour le backup, ou une bascule contrôlée pour le failover.

Exemple de code ou configuration du dépôt

- name: install our postgresql cluster
  become: yes
  hosts: meta-app_postgresql
  roles:
    - volumes
    - databases/postgresql/postgresql_simple
  vars:
    volumes_disks:
      - {disk: '/dev/sdb',path: '/data', owner: "root"}
    postgresql_simple_data_dir: /data/postgresql
    postgresql_simple_pghba_enabled: false

Cet extrait doit être lu comme un support pédagogique. Avant de l utiliser tel quel, vérifiez les variables, noms de réseau, plages CIDR, identifiants, secrets, régions, images et règles d exposition.

Chemin de diagnostic recommandé

• valider l inventaire Ansible
• relancer le playbook sans changement inattendu
• contrôler les services et fichiers modifiés sur la machine
• tester une connexion SQL
• vérifier réplication ou backup
• contrôler les métriques PostgreSQL utiles
• Comparer l état attendu dans le dépôt et l état réel dans le cloud, la machine ou le cluster.
• Documenter la commande, l écran ou la métrique qui prouve que l étape est fonctionnelle.

Répertoires et commandes utiles

• Répertoire support: 62-postgresql-replication-manager-ansible

Pièges fréquents

• lancer un playbook sur le mauvais groupe
• mélanger variables de lab et variables sensibles
• ne pas vérifier l idempotence
• considérer un backup non restauré comme fiable
• ne pas surveiller la réplication
• mélanger droits applicatifs et droits admin

Liens utiles externes

• Dépôt Xavki infrastructure-cloud-infomaniak
• Playlist YouTube Infra de A à Z
• docs.infomaniak.cloud
• docs.infomaniak.cloud/getting_started/first_project
• docs.infomaniak.cloud/compute/instances
• docs.infomaniak.cloud/orchestration/terraform
• docs.infomaniak.cloud/network/networks
• docs.infomaniak.cloud/network/security_groups

Liens internes conseillés

• Parcours Kubernetes pour relier la partie cluster et orchestration.
• Prometheus, Grafana et observabilité pour approfondir métriques et dashboards.
• RabbitMQ et workloads stateful pour comparer stockage, redémarrage et état applicatif.

Pour continuer, lire Infra A à Z 064 – Postgresql & Ansible : installation du secondaire.

FAQ

Pourquoi utiliser Terraform et Ansible ensemble ?

Terraform est adapté à la création et au cycle de vie des ressources cloud. Ansible est adapté à la configuration des machines et services. Les mélanger sans frontière claire rend les changements difficiles à relire.

Pourquoi Infomaniak/OpenStack dans cette série ?

Infomaniak Public Cloud expose des concepts OpenStack standards: compute, réseau, volumes, security groups, object storage, identity et orchestration. Cela permet d apprendre des notions transférables tout en travaillant sur un fournisseur concret.

Que faut-il sécuriser en premier ?

Les accès: credentials cloud, state Terraform, SSH, VPN, dashboards, secrets Ansible, tokens GitLab, consoles d administration et ports exposés publiquement. Une infrastructure automatisée amplifie aussi les erreurs de sécurité.

Comment savoir si une étape est terminée ?

Chaque étape doit produire une preuve: une ressource visible, un service joignable, une métrique collectée, un backup restaurable, une requête qui répond ou un déploiement qui converge.

Conclusion

L épisode 63 s inscrit dans une progression complète: construire, automatiser, sécuriser, observer et exploiter une infrastructure cloud. Le dépôt Xavki donne les exemples concrets, la documentation Infomaniak/OpenStack donne le cadre fournisseur, et le deep dive permet de comprendre le rôle des outils au lieu de seulement rejouer des commandes.