Daniel Allaire
716be304c5
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>
71 lines
3 KiB
Markdown
71 lines
3 KiB
Markdown
# 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
|
|
|
|
1. **Liste les bases** (sur data-sql-01) :
|
|
```bash
|
|
sudo -u postgres psql -c '\l' # keycloak, forgejo, icingadb…
|
|
sudo -u postgres psql -c '\du' # les comptes propriétaires
|
|
```
|
|
2. **Vois l'isolation.** Chaque app a **sa** base et **son** compte — pas de compte partagé.
|
|
3. **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.
|
|
4. **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**.
|