Deliver the full Docker stack for Bloc 5 DevOps (Cr 7.c.3 and 7.c.4):
- docker/apache/ Custom httpd:2.4-alpine with hardened main config,
MPM event tuning and 3 vhosts (healthz, kiosk static,
admin reverse FCGI to wakdo-app:9000). Kiosk vhost
explicitly denies .php to enforce Bloc 1 isolation.
- docker/php-fpm/ Custom php:8.3-fpm-alpine3.20 with pdo_mysql, opcache,
intl, exif, zip and tini for signal handling.
Dynamic pool 3-10 workers listening on TCP 9000.
- docker/cron/ Custom alpine:3.20 with dcron, mariadb-client, gzip.
Nightly mysqldump at 03h00 with 14-day rotation and
512-byte sanity check. Purge and stats jobs templated.
- docker-compose.yml 4 services orchestrated on 2 networks (internal
bridge + external reverse-proxy). 2 named volumes
for DB and uploads, bind-mount for backups.
Traefik labels for 2 routers with HTTPS redirect.
Makefile adds `make backup` (manual dump) and `make backup-ls`.
.gitignore adds /var/ for backup bind-mount path.
docs/journal/2026-04-24--infra-docker.md documents 5 decisions with
alternatives, maps 16 RNCP criteria to artefacts and prepares 6 jury Q&A.
Validated: `docker compose config --quiet` passes. Smoke test deferred
to next session (requires server .env).
3.4 KiB
3.4 KiB
Journal du projet Wakdo
Ce dossier contient les retrospectives de chaque session de travail et de chaque feature livree. Il est destine :
- A moi pour la revision de l'oral de certification RNCP
- Au jury qui souhaite tracer la demarche projet et la reflexion technique
Chaque fichier suit le meme template (voir ci-dessous) pour faciliter la relecture.
Organisation
docs/journal/
README.md # ce fichier (index + template)
YYYY-MM-DD--nom-de-la-session.md # un fichier par session significative ou feature mergee
Nommage : YYYY-MM-DD--slug-court.md (ex : 2026-04-23--cadrage-projet.md).
Les fichiers sont ordonnes chronologiquement par leur nom.
Index des sessions
| Date | Fichier | Sujet | Branche / PR |
|---|---|---|---|
| 2026-04-23 | cadrage-projet | Analyse brief RNCP, decisions d'architecture, bootstrap Git | main (commit initial) |
| 2026-04-24 | infra-docker | Stack Docker complete (compose + 4 services), referentiel RNCP integre, cross-check mappings Cr 4.f | feat/infra-docker |
Mis a jour a chaque nouvelle entree.
Template d'une entree
Copier ce bloc pour chaque nouvelle session ou feature :
# [Titre clair de la session ou feature]
**Date** : YYYY-MM-DD
**Branche** : `feat/xxx` ou `main`
**PR** : #n (ou "commit direct" si applicable)
**Duree estimee** : Xh
---
## Ce qui a ete fait
Description factuelle : quels fichiers, quelle feature, quel resultat concret.
Rester descriptif, pas interpretatif. Le "pourquoi" vient apres.
---
## Pourquoi — decisions et alternatives
Pour chaque choix technique significatif :
- **Decision** : [ce qui a ete retenu]
- **Alternatives considerees** : [les autres pistes]
- **Raison du choix** : [contraintes, tradeoffs, criteres]
C'est la section la plus importante pour l'oral. Le jury testera souvent : *"Pourquoi X plutot que Y ?"*
---
## Comment — points techniques cles
2 a 4 decisions d'implementation qui meritent une explication detaillee.
Extraits de code courts si pertinent, liens vers les fichiers concernes.
---
## Criteres RNCP couverts
Mapping explicite avec le referentiel (RNCP 37805) :
- **Bloc X - Critere Y.z** : [comment ce livrable y repond, avec reference au fichier]
- ...
---
## Questions anticipees du jury
Les questions que le jury pourrait poser sur cette session, avec les reponses preparees :
- **Q** : "..."
**R** : [reponse concise, tenue]
- **Q** : "..."
**R** : ...
---
## Points d'amelioration conscients
Ce qui a ete laisse volontairement imparfait, avec la raison. Montrer la maturite technique : savoir ce qui n'est pas optimal et pourquoi on a choisi de ne pas l'optimiser maintenant.
- [Point] : [pourquoi c'est laisse en l'etat + quand ca sera traite]
---
## Liens vers artefacts
- Commit(s) : `abc1234`, `def5678`
- Fichiers principaux : `path/to/file.php`, ...
- Documentation associee : `docs/xxx.md`
Regles de redaction
- Factuel d'abord : decrire ce qui a ete fait avant d'expliquer pourquoi.
- Pas d'emoji (mantra IA-23).
- Sources citees pour toute affirmation technique absolue (voir
.claude/rules/fact-check.md). - Liens vers les fichiers avec chemins relatifs depuis la racine (ex :
src/Core/Router.php:42). - Honnetete technique : si une decision a ete prise sans comprendre parfaitement, le dire. Le jury valorise la lucidite plus que la perfection.