LectureÉlément 5 sur 22 · 20 min

Exploitation, dépannage et glossaire

La plateforme est en service — cette page couvre le travail du deuxième jour : la maintenance de routine, une table de dépannage transversale aux couches, et un glossaire des termes utilisés tout au long du module.

Partie 4 sur 4 — Aperçu · Atelier 1 : Provisionner et configurer · Atelier 2 : Déployer et livrer

Ce que vous apprendrez

Faire tourner le mot de passe de la base entrepôt via les secrets GitHub, sans SSH ni édition manuelle du .env
Confirmer que le renouvellement TLS Let’s Encrypt est automatisé via le cron de certbot
Prendre des snapshots de VM datés avant les changements risqués
Diagnostiquer les problèmes transversaux (hôte, VM, Ansible, CI/CD, application) à l’aide de la table de dépannage
Rechercher les termes inconnus dans le glossaire

Phase 6 — Exploitation et maintenance

Faire tourner le mot de passe de la base de données

Un mot de passe de base de données en clair a été commité par le passé et reste dans l’historique git. Faites-le tourner sur le serveur de base de données lui-même, puis mettez à jour le secret et redéployez :


ALTER USER <DB_USER> WITH PASSWORD 'new-strong-password-here';


gh secret set DB_PASSWORD --body 'new-strong-password-here'

Un push sur main (ou une relance du workflow) régénère le .env de la VM et redémarre les conteneurs avec la nouvelle valeur. Règle générale : faire tourner n’importe quel identifiant = gh secret set NAME --body '…' + redéploiement. Aucun SSH ni aucune édition manuelle du .env n’est nécessaire.

Renouveler les certificats TLS

Si vous avez utilisé le playbook Ansible 04, certbot a installé un cron de renouvellement quotidien (certbot renew --quiet && systemctl reload nginx). Les certificats Let’s Encrypt durent 90 jours ; le cron les garde à jour automatiquement.

Snapshots autour des changements risqués

Prenez un snapshot frais de la VM avant tout changement significatif (mise à jour de l’OS, gros déploiement, modification de configuration) :


sudo virsh snapshot-create-as --domain <VM_NAME> \
  --name "pre-<change>-$(date +%Y%m%d)" --description "before <change>" --atomic

Nommez les snapshots avec une date + une raison, pour que leur objet soit clair au moment de revenir en arrière.

Phase 7 — Dépannage (transversal aux couches)

Symptôme	Couche	Correctif
Les règles de redirection de ports disparaissent après un redémarrage	Hôte	`sudo netfilter-persistent save` (les règles sont volatiles)
La VM a obtenu une autre IP après un redémarrage	VM	Netplan non enregistré / `netplan apply` non exécuté — refaites l’Étape 1.3
`nc -zv <PUBLIC_IP>` bloque depuis l’intérieur de la VM	VM	Attendu — le hairpin NAT n’est pas pris en charge ; testez depuis une machine externe
Port 443 refusé alors que nginx tourne	VM	Vérifiez `ss -tlnp \| grep 443` ; si vide, le lien symbolique `sites-enabled` manque — recréez-le
Erreur de syntaxe `nginx -t`	VM	Généralement un `;` ou une accolade manquant — `sudo nginx -t 2>&1` indique la ligne
SSH demande d’accepter une nouvelle clé d’hôte	toutes	La VM a été reconstruite — `ssh-keygen -R <IP_ADDRESS>` sur votre client
`ansible all -m ping` échoue	Ansible	Vérifiez `ansible_user`/le chemin de clé dans l’inventaire, et que la redirection de port/SSH est joignable
Pull GHCR 401/403 au premier déploiement	CI/CD	Donnez au dépôt l’accès Write sous Manage Actions access de chaque package (Étape 3.4)
Superset a perdu tous les tableaux de bord / utilise SQLite	App	Le montage de volume `./.superset:/app/pythonpath` manque — restaurez-le
La planification Dagster ne se déclenche jamais	App	Confirmez le `default_status=RUNNING` de la planification ; les planifications Dagster démarrent arrêtées par défaut

Glossaire

Le glossaire complet des termes se trouve désormais sur sa propre page : Glossaire.