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).
|
||
|---|---|---|
| .. | ||
| 2026-04-23--cadrage-projet.md | ||
| 2026-04-24--infra-docker.md | ||
| README.md | ||
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.