Daniel Allaire 716be304c5 wiki : 10 unités restantes (Communication, Données, Observabilité, Socle & méthode)

Complète les 14 unités d'apprentissage au moule à 4 temps : Reverse-proxy,
Courriel, Bases de données, Cache, Métriques & journaux, Supervision & impact,
Virtualisation, Sécurité & durcissement, Infra as Code & idempotence,
Liaisons (bindings, avec l'analogie NetScaler). Navigation complétée.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-04 15:33:17 -04:00

3 KiB

Raw Blame History

Bases de données

Unité d'apprentissage. Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.

① Le concept (générique)

Une base de données relationnelle stocke des données en tables (lignes/colonnes) reliées. Modèle client-serveur : le serveur (PostgreSQL) détient les données ; les applications s'y connectent par le réseau, avec un compte et un mot de passe, sur une base donnée.

Schéma = la structure (tables, contraintes). ACID = les garanties de fiabilité des transactions (Atomicité, Cohérence, Isolation, Durabilité). Rôles/permissions = qui peut lire/écrire.

Bonne pratique : une base + un compte dédiés par application (isolation) — pas un compte tout-puissant partagé.

② Comment Set-OPS le fait

serveur_postgresql (nœud data-sql) est le serveur partagé. L'élégance : un registre déclaratif des bases (plan/bases-donnees.yml). Chaque entrée dit quelle base, quel compte, quel secret, pour quel consommateur :

Registre ──> PostgreSQL crée la base + le compte propriétaire
        ──> le rôle consommateur (Keycloak, Forgejo, Icinga…) LIT la même
            entrée et bâtit sa connexion — via resoudre_base

Le secret vit dans la voûte (Ansible Vault), déréférencé au déploiement, jamais en clair dans le plan. C'est une liaison app → base, de modalité requise (Keycloak sans sa base ne démarre pas). Consommateurs prouvés : Keycloak, Forgejo, IcingaDB.

③ Pourquoi c'est transférable

Set-OPS	Équivalents ailleurs
PostgreSQL	MySQL/MariaDB · SQLite · Oracle · SQL Server
une base/compte par app	pratique universelle d'isolation
secret en voûte	Vault · SOPS · secrets managers cloud

Tu as appris le modèle client-serveur, le schéma, l'isolation par app, les secrets — pas « PostgreSQL ».

④ À toi de jouer

Liste les bases (sur data-sql-01) :

sudo -u postgres psql -c '\l'          # keycloak, forgejo, icingadb…
sudo -u postgres psql -c '\du'         # les comptes propriétaires

Vois l'isolation. Chaque app a sa base et son compte — pas de compte partagé.
Suis une liaison. Ouvre plan/bases-donnees.yml : l'entrée keycloak (serveur, base, propriétaire, secret) est exactement ce que le rôle serveur_keycloak va lire pour se connecter.
Casse & répare. Change le mot de passe d'un compte dans PostgreSQL (garde l'ancien !) sans mettre à jour la voûte : l'app ne se connecte plus. Restaure : ça repart. Tu sens que la connexion = identité + secret cohérents des deux côtés.

Pour aller plus loin (dépôt)

Rôle : roles/serveur_postgresql ; résolveur partagé : roles/resoudre_base.
Le registre : instance/plan/bases-donnees.yml ; validation : scripts/bases_donnees.py verifier.
Sauvegarde (Tier 1, pg_dumpall) : unité Sauvegardes.

3 KiB Raw Blame History