Plan De Standardisation - Frontends Nginx en conteneur & Déploiement unifié

5 min de lecture

Objectif : adopter la même approche pour toutes les applications (existantes et futures) :

  • Frontend statique servi par Nginx dans un conteneur (full container static server)
  • Apache (hôte) comme terminator TLS + reverse‑proxy vers les conteneurs
  • Même pipeline de déploiement (CI/CD GitHub Actions → serveur) en prod
  • Cohabitation DEV/PROD des apps sans collision de ports

0) Décisions déjà validées

  • Frontend: Nginx dans le conteneur pour chaque app (SPA Vite/React).

  • Hôte: Apache pour TLS, vhosts, reverse‑proxy.

  • Sous‑domaines (production) :

    • MDP → app.mon-site.ca (frontend), api.mon-site.ca (API)
    • Calendrier → cal.mon-site.ca (frontend), cal-api.mon-site.ca (API)

  • Ports (production, loopback) :

    • MDP frontend → 127.0.0.1:8081
    • CAL frontend → 127.0.0.1:8082
    • MDP API → 127.0.0.1:8002
    • CAL API → 127.0.0.1:8004

  • Ports (développement) — rappels & proposition :

    • MDP : frontend 5174→5173, API 8002→8000, DB 5433→5432 (déjà en place)
    • CAL : proposer frontend 5175→5173, API 8004→8000 (éviter toute collision)

  • Env files : .env.dev et .env.prod, avec lien symbolique .env → env actif.

  • Dockerfiles distincts dev/prod (backend & frontend).

1) Stratégie d’implémentation (ordre)

  1. Application #1 : Calendrier (CAL) — prioritaire car jeune et déjà amorcée côté GitHub Actions. On y définit le standard.
  2. Application #2 : Gestionnaire MDP (MDP) — on réplique le standard (même structure, mêmes étapes) et on remplace le déploiement par “git pull” par la même CI/CD que CAL.

On procède itérativement : on ne passe pas à l’étape suivante tant que l’étape en cours n’est pas validée (tests/critères d’acceptation OK).

2) Branche de travail & sécurité (pour chaque repo)

  • Créer une branche de feature dédiée (nommage suggéré) :

    • feat/containers-frontend-nginx (si on ne touche qu’au frontend)
    • feat/cicd-standardisation (si on inclut CI/CD)

  • Commandes de base (ex. CAL) :

    • git checkout -b feat/containers-frontend-nginx
    • Travail + commits atomiques (git add -p, git commit -m "...")
    • git pull --rebase origin main (avant push pour garder l’historique propre)
    • git push -u origin feat/containers-frontend-nginx
    • Ouvrir une PR et ne merger qu’après validation sur la machine de prod de test.

Réversibilité : en cas de souci, on reste sur la branche ; en prod, on garde des images taguées pour rollback.

3) Application #1 (CAL) — Plan d’exécution détaillé

Étape 1 — Frontend CAL : conteneur Nginx (production)

But : le build Vite produit /dist; Nginx (dans le conteneur) sert la SPA ; Apache hôte proxifie.

  • Tâches :

    1. Ajouter/valider frontend/Dockerfile (prod) build → Nginx (sans détailler ici le contenu).
    2. Fournir un nginx.conf minimal (SPA fallback + cache assets hashés).
    3. Standardiser la variable VITE_API_BASE via ARG/ENV au build ; la valeur vient de .env.prod.

  • Vérifications (acceptation) :

    • Build image locale OK.
    • Conteneur local répond sur port loopback choisi (ex. 127.0.0.1:8082) ; assets et SPA fallback OK.

Étape 2 — Compose CAL : ports & services

But : définir/valider les services cal_frontend (Nginx) et cal_backend (Django), réseaux & ports.

  • Tâches :

    1. Mettre à jour docker-compose.prod.yml (services cal_frontend/cal_backend, ports 8082 et 8004).
    2. DEV : proposer 5175→5173 pour le frontend CAL et 8004→8000 pour l’API CAL.
    3. Toujours utiliser --env-file .env.prod / .env.dev.

  • Vérifications :

    • docker compose ... build & up -d OK ; ps montre les services ; logs propres ; curl local OK.

Étape 3 — Apache hôte : vhosts reverse‑proxy CAL

But : publier https://cal.mon-site.ca (→ 127.0.0.1:8082) & https://cal-api.mon-site.ca (→ 127.0.0.1:8004).

  • Tâches :

    1. Créer/activer les vhosts correspondants (redir HTTP→HTTPS, ProxyPass/ProxyPassReverse, en‑têtes sécurité).
    2. Certificats Let’s Encrypt déjà en place ou à provisionner.

  • Vérifications :

    • sudo a2ensite ... && sudo systemctl reload apache2 OK.
    • curl -I https://cal.mon-site.ca renvoie 200/SPA ; curl -I https://cal-api.mon-site.ca renvoie 200/DRF.

Étape 4 — CORS/ALLOWED_HOSTS CAL (backend)

But : autoriser uniquement les origines nécessaires.

  • Tâches :

    1. ALLOWED_HOSTS inclut cal-api.mon-site.ca.
    2. CORS_ALLOWED_ORIGINS = ["https://cal.mon-site.ca"] (via env si possible).

  • Vérifications :

    • Appels fetch depuis le frontend CAL → API CAL OK (200, pas d’erreur CORS).

Étape 5 — CI/CD CAL : standard GitHub Actions (prod)

But : même pipeline que l’on réutilisera pour MDP.

  • Tâches :

    1. Workflow build & push images (frontend & backend) vers un registre (ex. GHCR) avec tags (main, sha, release).
    2. Workflow deploy (sur push/tag) : SSH vers le serveur, docker compose pull, up -d, ps, court healthcheck.
    3. Secrets GitHub : clé SSH, GHCR_TOKEN/GHCR_USERNAME, variables d’environnement.

  • Vérifications :

    • Sur commit/tag, images poussées ; déploiement tiré sur le serveur ; site accessible.

Étape 6 — Basculer & rollback CAL

But : sécuriser la mise en prod.

  • Tâches :

    1. Taggage images (ex. cal-frontend:2025-09-01T…), conservation de N versions.
    2. Procédure rollback : docker compose ... down && docker compose ... up -d avec image précédente ou docker compose pull d’un tag stable.

  • Vérifications :

    • Rollback testé sur un tag antérieur (non‑destructif pour les données).

Étape 7 — Runbook & documentation CAL

But : consigner le standard.

  • Tâches :

    1. Mettre à jour la doc (ports, vhosts, commandes usuelles dev/prod, CI/CD, rollback).
    2. Ajouter une check‑list de validation et un “quick fix” (FAQ) pour incidents courants.

4) Déploiement production — check‑list de passage (CAL)

  • Images construites et taguées (frontend & backend)
  • Compose prod à jour (services, ports, réseaux) ; --env-file correct
  • Vhosts Apache activés (TLS OK, proxy OK)
  • CORS/ALLOWED_HOSTS OK
  • CI/CD : build → push → deploy validé
  • Rollback testé (au moins une fois)
  • Runbook/documentation mis à jour

5) Préparer l’Application #2 (MDP) — Aperçu rapide

Une fois CAL validée, on réplique à l’identique sur MDP pour standardiser totalement.

  • Frontend MDP : Nginx conteneur, port loopback 8081 en prod, 5174→5173 en dev (inchangé).
  • API MDP : inchangée côté port (prod 8002), ajuster CORS si besoin.
  • Vhosts Apache : app.mon-site.ca (→ 8081) et api.mon-site.ca (→ 8002).
  • CI/CD : aligner sur le pipeline CAL ; abandon du git pull manuel.
  • Doc : mettre à jour les runbooks MDP.

6) Conventions (noms & tags)

  • Services Compose : cal_frontend, cal_backend, mdp_frontend, mdp_backend.
  • Images : cal-frontend, cal-backend, mdp-frontend, mdp-backend.
  • Tags : main, sha-<short>, rel-<YYYYMMDD-HHMM>.
  • Branches feature : feat/containers-frontend-nginx, feat/cicd-standardisation.

7) Points ouverts (à trancher)

  • Healthchecks applicatifs (endpoint simple pour le frontend ; /healthz DRF pour le backend)
  • Activation gzip/Brotli côté Apache hôte (HTTP/2 déjà géré par TLS hôte)
  • Politique de rétention d’images et nettoyage
  • Logs : centralisation (journald vs fichiers), rotation
  • Monitoring simple (UptimeRobot sur les 4 sous‑domaines)

Prochaine action proposée

Démarrer l’Étape 1 (CAL) sur une branche : feat/containers-frontend-nginx.

  • Objectif : image frontend Nginx qui sert la SPA localement (loopback), sans toucher encore au vhost Apache.
  • Quand c’est validé localement, on passe à l’Étape 2 (Compose) puis Étape 3 (vhosts).