Jour 4 : Projet Fil Rouge & Infrastructure “Production-Ready”

Aujourd’hui, nous ne jouons plus. Nous allons construire une infrastructure web complète, isolée, persistante et accessible depuis n’importe où dans le monde, le tout sans ouvrir un seul port sur votre routeur.

4.1. L’Architecture Cible

Voici ce que nous allons construire. Une architecture “3-Tiers” moderne sécurisée par un tunnel.

Extrait de code

@startuml
!theme sunlust
skinparam componentStyle rectangle

cloud "Internet" {
  [Utilisateur (Smartphone/PC)] as User
}

node "Cloudflare Network" {
  [Tunnel Endpoint (https://xyz.trycloudflare.com)] as CF
}

node "Votre Ordinateur (Docker Host)" {
  component "Cloudflared (Tunnel)" as Tunnel #Orange
  component "Caddy (Reverse Proxy)" as Proxy #Yellow

  frame "Réseau Privé (Backend)" {
    component "WordPress (Web App)" as App
    component "Adminer (DB Admin)" as Admin
    database "MySQL (Database)" as DB
  }
}

User -> CF : HTTPS
CF <-> Tunnel : Connexion Sécurisée (Outbound)
Tunnel -> Proxy : HTTP (:80)
Proxy -> App : Route "/"
Proxy -> Admin : Route "/adminer"
App <--> DB : Port 3306
Admin <--> DB : Port 3306

note right of Tunnel : Passe à travers\nles Pare-feux/NAT !
@enduml

4.2. Le Concept de Reverse Proxy (Caddy)

En entreprise, on n’expose jamais une application directement sur internet (pas de app:3000). On place un Reverse Proxy devant.

Pourquoi Caddy ?

Contrairement à Nginx ou Apache, Caddy est conçu pour le cloud moderne :

Configuration lisible : Un fichier simple (Caddyfile).
HTTPS Automatique : Il gère les certificats (même en local).
Routage simple : Il dirige le trafic vers le bon conteneur selon l’URL.

Dans notre cas, Caddy écoutera toutes les requêtes venant du tunnel et les distribuera :

Tout ce qui arrive sur /adminer $\rightarrow$ Conteneur adminer.
Tout le reste $\rightarrow$ Conteneur wordpress.

4.3. Le “Tunnel Magique” (Cloudflare)

Le plus gros problème du développement local, c’est de montrer son travail. “Ça marche sur ma machine”, mais comment le client à New York peut-il le voir ?

Nous allons utiliser Cloudflare Tunnel (cloudflared).

Ce conteneur crée un lien sortant vers le réseau Cloudflare.
Il génère une URL temporaire https://random-name.trycloudflare.com.
Nul besoin de configurer votre Box Internet ou d’acheter un nom de domaine.

4.4. Cahier des Charges du Projet

Votre mission : Déployer la stack suivante via docker-compose.

Arborescence de fichiers :

 mon-projet/
 ├── Caddyfile            # Config du proxy
 ├── docker-compose.yml   # Définition de l'infra
 └── wp_data/             # (Optionnel) Dossier pour voir les fichiers WP

Services requis :
- BDD : MySQL ou MariaDB (Persistante ! Si je redémarre, je ne perds pas mes articles).
- App : WordPress (Connecté à la BDD).
- Admin : Adminer (Pour gérer la BDD graphiquement).
- Proxy : Caddy (Point d’entrée unique).
- Internet : Cloudflared (Pour l’accès externe).

4.5. Guide de Mise en Œuvre

Étape 1 : Le Caddyfile

Créez un fichier nommé Caddyfile (sans extension) à la racine.

# Caddyfile

# On écoute sur le port 80 interne (celui que le tunnel va attaquer)
:80 {
    # Règle 1 : Si l'URL commence par /adminer
    # handle_path retire le préfixe "/adminer" avant d'envoyer la requête
    handle_path /adminer* {
        reverse_proxy adminer:8080
    }

    # Règle 2 : Tout le reste (le site WordPress)
    handle {
        reverse_proxy webapp:80
    }
}

Étape 2 : Le docker-compose.yml

Voici le squelette à compléter/utiliser.

services:
  # --- 1. ACCÈS EXTERNE ---
  tunnel:
    image: cloudflare/cloudflared:latest
    # La commande magique : Crée un tunnel vers le service "caddy" sur le port 80
    command: tunnel --url http://caddy:80
    depends_on:
      - caddy
    restart: unless-stopped

  # --- 2. ROUTAGE INTERNE ---
  caddy:
    image: caddy:latest
    ports:
      - "80:80" # On garde l'accès localhost pour débugger
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile # Injection de la config
      - caddy_data:/data
    depends_on:
      - webapp
      - adminer

  # --- 3. APPLICATION ---
  webapp:
    image: wordpress:latest
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: user
      WORDPRESS_DB_PASSWORD: password
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - wp_data:/var/www/html
    restart: unless-stopped

  # --- 4. BASE DE DONNÉES ---
  db:
    image: mysql:5.7 # Ou mariadb:latest
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: user
      MYSQL_PASSWORD: password
      MYSQL_RANDOM_ROOT_PASSWORD: '1'
    volumes:
      - db_data:/var/lib/mysql # PERSISTANCE VITALE
    # Astuce sécurité : Pas de "ports:" ici. La DB est inaccessible de l'extérieur.

  # --- 5. ADMINISTRATION ---
  adminer:
    image: adminer
    environment:
      ADMINER_DEFAULT_SERVER: db
    restart: unless-stopped

volumes:
  wp_data:
  db_data:
  caddy_data:

4.6. Lancement et Vérification

Démarrer la stack :
```
 docker compose up -d
```
Trouver l’URL publique :

Regardez les logs du conteneur tunnel.
```
 docker compose logs -f tunnel
```
Cherchez une ligne contenant trycloudflare.com encadrée par des bannières ASCII.
Tester :
- Ouvrez l’URL `https://
  .trycloudflare.com` $\rightarrow$ Vous devriez voir l’installation de WordPress.
- Ouvrez l’URL `https://
  .trycloudflare.com/adminer` $\rightarrow$ Vous devriez voir l’interface de login DB.

4.7. Challenges Bonus (Pour aller plus loin)

Si votre infrastructure tourne, essayez d’ajouter ces briques :

Redis Cache :

Ajoutez un service Redis et configurez WordPress (via le fichier wp-config.php ou un plugin) pour l’utiliser. Cela accélère le site drastiquement.

Monitoring (Portainer) :

Ajoutez une interface de gestion Docker web.

 portainer:
   image: portainer/portainer-ce
   volumes:
     - /var/run/docker.sock:/var/run/docker.sock
 # Ajoutez une route dans le Caddyfile pour y accéder via /monitor !

Le Test de Survie :
- Écrivez un article sur votre WordPress.
- Faites docker compose down.
- Faites docker compose up -d.
- Si votre article a disparu, vous avez raté la configuration des volumes !