67 lines
3.1 KiB
Markdown
67 lines
3.1 KiB
Markdown
# Partie 3 — DevOps (infrastructure, déploiement, exploitation)
|
|
|
|
## Infrastructure as Code
|
|
|
|
`docker-compose.yml` décrit l'état désiré de l'infrastructure complète :
|
|
7 services (caddy, flask, mariadb, keycloak, keycloak-db, mattermost,
|
|
mattermost-db), 1 réseau interne (`gesthub-net`), 7 volumes persistants.
|
|
Seul `caddy` publie des ports (80/443) — tous les autres services
|
|
communiquent uniquement via le réseau Docker interne (vérifié par le test
|
|
automatisé TS-06, qui parse le fichier et échoue si un autre service
|
|
déclare une clé `ports`).
|
|
|
|
## Procédure de déploiement
|
|
|
|
```bash
|
|
git clone <repo>
|
|
cd gesthub
|
|
cp web/.env.example web/.env # renseigner les secrets réels
|
|
docker compose up -d --build
|
|
docker compose logs -f flask # vérifier le démarrage
|
|
```
|
|
|
|
**Avant / après** (réingénierie de processus, Bloc 2 — C2) :
|
|
|
|
| | Avant (mai 2025) | Après |
|
|
|---|---|---|
|
|
| Déploiement | Copie manuelle SSH, redémarrage serveur | `docker compose up -d` |
|
|
| Durée | 30 à 60 min | < 5 min |
|
|
| Reproductibilité | Dépend de la mémoire de l'opérateur | Totale (fichier versionné) |
|
|
|
|
## Procédure de mise en exploitation (checklist TD)
|
|
|
|
| ID | Vérification | Méthode |
|
|
|---|---|---|
|
|
| TD-01 | Tous les conteneurs sont `Up` | `docker compose ps` |
|
|
| TD-02 | Healthcheck MariaDB au vert | `docker compose ps` (colonne STATUS) |
|
|
| TD-03 | HTTPS répond (redirection HTTP→HTTPS) | `curl -I https://dashboard.ninolbt.com` |
|
|
| TD-04 | SSO Keycloak fonctionnel | Connexion manuelle de bout en bout |
|
|
| TD-05 | Persistance des données après redémarrage | `docker compose restart mariadb` puis vérification des annonces existantes |
|
|
| TD-06 | Sauvegarde exécutable | `scripts/backup.sh` en mode manuel, vérification de l'archive produite |
|
|
|
|
**[⇒] Projection méthodologique — procédure ITIL complète.** Cette
|
|
checklist couvre les principes ITIL de base (prérequis vérifiés,
|
|
environnement de test avant production, liste de contrôle, rollback
|
|
possible via `docker compose down` + restauration du dernier backup) mais
|
|
n'a pas fait l'objet d'une signature formelle d'un « bon à intégrer » ni
|
|
d'un PV de recette signé par un tiers, faute de contexte client réel sur ce
|
|
projet personnel. En entreprise, ces deux documents formaliseraient
|
|
l'accord du responsable d'exploitation et du Product Owner avant bascule en
|
|
production.
|
|
|
|
## Scripts d'exploitation
|
|
|
|
- `scripts/backup.sh` : dump MariaDB (`mysqldump` + gzip) et archive des
|
|
fichiers uploadés, purge des sauvegardes de plus de 30 jours, prévu pour
|
|
être planifié via cron.
|
|
- `web/init.sql` : création automatique du schéma au premier démarrage du
|
|
conteneur MariaDB (monté sur `/docker-entrypoint-initdb.d/`).
|
|
|
|
## Réutilisation plutôt que réimplémentation (Bloc 2 — C6)
|
|
|
|
Bibliothèques et outils intégrés tels quels plutôt que réécrits :
|
|
**Authlib** (protocole OIDC), **PyMySQL** (connecteur MariaDB),
|
|
**python-magic** (détection MIME), **Mattermost** (chat + Kanban complet,
|
|
avec SSO partagé) — décision explicite de ne pas réinventer un outil de
|
|
chat/Kanban alors qu'une solution mature et intégrable existe.
|