Exécuter Discourse avec WordPress (Docker) sur un seul VPS utilisant un proxy inverse Nginx

Wiki de la communauté Adminsys
1

Introduction

Par défaut, une installation Discourse « autonome » (standalone) se lie aux ports 80 et 443. Pour héberger une autre application comme WordPress sur le même serveur, vous devez reconfigurer Discourse pour qu’il écoute sur un port interne et utiliser un Nginx au niveau de l’hôte comme mandataire inverse (Reverse Proxy) pour gérer le trafic et les certificats SSL.

1. Aperçu de l’architecture

  • Nginx Hôte : La passerelle principale écoutant sur les ports 80 et 443. Il gère la terminaison SSL et achemine les requêtes vers le conteneur approprié en fonction du server_name.

  • Conteneur Discourse : Reconfiguré pour écouter sur localhost:8080.

  • Conteneur WordPress : Géré via Docker Compose, écoutant sur localhost:8081.

2. Phase A : Reconfiguration de Discourse

Modifiez votre fichier /var/discourse/containers/app.yml pour libérer les ports publics :

  1. Modifier le mappage de port :

    YAML

    expose:
  - "8080:80"   # Mappe le port hôte 8080 au port conteneur 80

  2. Désactiver le SSL interne : Commentez les modèles SSL et Let’s Encrypt :

    YAML

    templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  # - "templates/web.ssl.template.yml"
  # - "templates/web.letsencrypt.ssl.template.yml"

  3. Reconstruire : Exécutez ./launcher rebuild app.

3. Phase B : Déploiement de WordPress via Docker Compose

Organisez votre site WordPress dans un répertoire dédié. Assurez-vous que le volume de la base de données est persistant pour éviter toute perte de données.

YAML

services:
  db:
    image: mariadb:10.11
    environment:
      MYSQL_ROOT_PASSWORD: 'your_secure_password'
    volumes:
      - ./mysql_data:/var/lib/mysql
  wordpress:
    image: wordpress:latest
    ports:
      - "8081:80"
    volumes:
      - .:/var/www/html

4. Phase C : Configuration Nginx finale (SSL et Port 443)

Une configuration professionnelle en 2025 nécessite une prise en charge complète de HTTPS et HTTP/2. Après avoir installé Nginx sur votre hôte (sudo apt install nginx), créez une configuration pour vos domaines.

Astuce de pro : Exécutez sudo certbot --nginx pour générer automatiquement les blocs SSL, mais assurez-vous qu’ils incluent les en-têtes de proxy suivants pour que Discourse fonctionne correctement.

Nginx

server {
    listen 443 ssl http2;
    server_name discourse.com;

    # Certificats SSL par Certbot
    ssl_certificate /etc/letsencrypt/live/discourse.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/discourse.com/privkey.pem;

    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme; # Crucial pour la détection HTTPS de Discourse
    }
}

5. Leçons apprises à grands frais et meilleures pratiques

  • Identifiants de base de données : Si vos mots de passe contiennent des caractères spéciaux comme & ou ?, entourez-les toujours d’apostrophes ' ' dans vos fichiers de configuration et commandes de terminal pour éviter les erreurs d’interprétation du shell.

  • Permissions de fichiers : Les conteneurs WordPress s’exécutent en tant que www-data (UID 33). Si vous téléchargez ou décompressez des fichiers en tant que root, vous devez exécuter chown -R 33:33 . pour éviter les erreurs de serveur interne 500.

  • Paramètres Cloudflare : Lorsque vous utilisez un certificat SSL sur serveur (Let’s Encrypt), définissez le SSL/TLS de Cloudflare sur Full (Strict). Cela empêche la boucle « Trop de redirections » couramment causée par le mode « Flexible ».

  • Volumes persistants : Ne lancez jamais docker compose down ou rebuild sans vérifier que vos fichiers de base de données sont stockés dans un volume persistant (par exemple, ./mysql_data).

Conclusion : Dissocier vos applications des ports 80/443 à l’aide d’un mandataire inverse est la méthode la plus évolutive pour gérer un VPS multi-sites. Elle permet une gestion centralisée des SSL et un débogage facile via les journaux Nginx au niveau de l’hôte.

2 « J'aime »