Installation de Discourse dans Docker, impossible de se connecter

J’ai donc utilisé la documentation d’installation standard et tout semblait se passer correctement. J’ai ensuite édité le fichier app.yml pour modifier les ports utilisés, commenté Let’s Encrypt et reconstruit l’application. Tout semblait fonctionner correctement.

Mais lorsque j’essaie de me connecter via la méthode la plus directe :

$lynx https://127.0.0.1:44443

Je reçois l’erreur suivante :

Alerte ! : Impossible d’établir une connexion sécurisée avec l’hôte distant.

Je ne peux même pas faire un ping sur le port.

Cela a-t-il un sens ? Y a-t-il des journaux à l’intérieur du conteneur ?

—Édition pour ajouter----

$ sudo ./launcher logs app
run-parts: exécution de /etc/runit/1.d/00-ensure-links
run-parts: exécution de /etc/runit/1.d/00-fix-var-logs
run-parts: exécution de /etc/runit/1.d/01-cleanup-web-pids
run-parts: exécution de /etc/runit/1.d/anacron
run-parts: exécution de /etc/runit/1.d/cleanup-pids
Nettoyage des fichiers PID obsolètes
run-parts: exécution de /etc/runit/1.d/copy-env
runsvdir démarré, PID est 43
ok: run: redis: (pid 56) 0s
**chgrp : groupe invalide : « syslog »**
ok: run: postgres: (pid 55) 0s
supervisor pid: 57 unicorn pid: 85
(57) Réouverture des journaux

----Édition pour ajouter plus----

root@hestia-app:/shared/log/rails# tail -f *.log
==\u003e production_errors.log \u003c==

==\u003e production.log \u003c==

==\u003e sidekiq.log \u003c==

==\u003e unicorn.stderr.log \u003c==
I, [2021-08-06T00:56:35.859967 #85]  INFO -- : master terminé la réouverture des journaux
I, [2021-08-06T00:56:50.911700 #142]  INFO -- : worker=0 terminé la réouverture des journaux
I, [2021-08-06T00:56:50.911698 #152]  INFO -- : worker=1 terminé la réouverture des journaux
I, [2021-08-06T00:56:50.935834 #162]  INFO -- : worker=2 terminé la réouverture des journaux
I, [2021-08-06T00:56:50.941733 #233]  INFO -- : worker=7 terminé la réouverture des journaux
I, [2021-08-06T00:56:50.945447 #203]  INFO -- : worker=5 terminé la réouverture des journaux
I, [2021-08-06T00:56:50.947354 #172]  INFO -- : worker=3 terminé la réouverture des journaux
I, [2021-08-06T00:56:50.949949 #187]  INFO -- : worker=4 terminé la réouverture des journaux
I, [2021-08-06T00:56:50.953453 #213]  INFO -- : worker=6 terminé la réouverture des journaux

==\u003e unicorn.stdout.log \u003c==
Sidekiq PID 131 terminé la réouverture des journaux...
root@hestia-app:/var/log/nginx# tail *.log
==\u003e access.letsencrypt.log \u003c==

==\u003e access.log \u003c==

==\u003e error.letsencrypt.log \u003c==

==\u003e error.log \u003c==

Doit être une erreur Docker, car… tout le reste semble correct.

Je viens d’installer un conteneur Apache brut mappé sur le port 8088, et cela fonctionne parfaitement depuis lynx.

J’ai rouvert l’application et exécuté ps ax, et il semble que tout fonctionne. Il semble simplement que le conteneur n’accepte pas les connexions.

root@hestia-app:/var/www/discourse# ps ax
    PID TTY      STAT   TIME COMMAND
      1 pts/0    Ss+    0:00 /bin/bash /sbin/boot
     43 pts/0    S+     0:00 /usr/bin/runsvdir -P /etc/service
     44 ?        Ss     0:00 runsv cron
     45 ?        Ss     0:00 runsv rsyslog
     46 ?        Ss     0:00 runsv redis
     47 ?        Ss     0:00 runsv postgres
     48 ?        Ss     0:00 runsv unicorn
     49 ?        Ss     0:00 runsv nginx
     50 ?        S      0:00 cron -f
     51 ?        Sl     0:00 rsyslogd -n
     52 ?        S      0:00 nginx: master process /usr/sbin/nginx
     53 ?        S      0:00 svlogd /var/log/redis
     54 ?        S      0:00 svlogd /var/log/postgres
     55 ?        S      0:00 /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main
     56 ?        Sl     0:33 /usr/bin/redis-server *:6379
     57 ?        S      0:04 /bin/bash config/unicorn_launcher -E production -c config/unicorn.conf.rb
     64 ?        S      0:00 nginx: worker process
     65 ?        S      0:00 nginx: worker process
     66 ?        S      0:00 nginx: worker process
     67 ?        S      0:00 nginx: worker process
     68 ?        S      0:00 nginx: cache manager process
     79 ?        Ss     0:00 postgres: 13/main: checkpointer 
     80 ?        Ss     0:00 postgres: 13/main: background writer 
     81 ?        Ss     0:03 postgres: 13/main: walwriter 
     82 ?        Ss     0:00 postgres: 13/main: autovacuum launcher 
     83 ?        Ss     0:00 postgres: 13/main: stats collector 
     84 ?        Ss     0:00 postgres: 13/main: logical replication launcher 
     85 ?        Sl     0:13 unicorn master -E production -c config/unicorn.conf.rb
    113 ?        Ss     0:01 postgres: 13/main: discourse discourse [local] idle
    131 ?        SNl    0:48 sidekiq 6.2.1 discourse [0 of 5 busy]
    142 ?        Sl     0:06 unicorn worker[0] -E production -c config/unicorn.conf.rb
    152 ?        Sl     0:06 unicorn worker[1] -E production -c config/unicorn.conf.rb
    162 ?        Sl     0:07 unicorn worker[2] -E production -c config/unicorn.conf.rb
    172 ?        Sl     0:06 unicorn worker[3] -E production -c config/unicorn.conf.rb
    180 ?        Ss     0:00 postgres: 13/main: discourse discourse [local] idle
    187 ?        Sl     0:07 unicorn worker[4] -E production -c config/unicorn.conf.rb
    203 ?        Sl     0:07 unicorn worker[5] -E production -c config/unicorn.conf.rb
    213 ?        Sl     0:07 unicorn worker[6] -E production -c config/unicorn.conf.rb
    233 ?        Sl     0:07 unicorn worker[7] -E production -c config/unicorn.conf.rb
  11733 pts/1    Ss     0:00 /bin/bash --login
  11748 ?        S      0:00 sleep 1
  11749 pts/1    R+     0:00 ps ax

D’accord, donc j’ai lancé l’application et installé lynx à l’intérieur du conteneur Docker de Discourse, et je peux accéder à la page d’accueil ! L’installation fonctionne donc, le problème vient de la mappage réseau depuis le conteneur vers le serveur.

Voici la sortie de docker ps :

CONTAINER ID   IMAGE                 COMMAND        CREATED          STATUS          PORTS                                             NAMES
c6d0209e4e72   local_discourse/app   "/sbin/boot"   51 minutes ago   Up 51 minutes   127.0.0.1:8880->80/tcp, 127.0.0.1:4443->443/tcp   app

…et voici les informations du fichier app.yml :

templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"

expose:
  - "127.0.0.1:8880:80"   # http
  - "127.0.0.1:4443:443" # https

params:
  db_default_text_search_config: "pg_catalog.english"
  db_shared_buffers: "2048MB"

env:
  LC_ALL: en_US.UTF-8
  LANG: en_US.UTF-8
  LANGUAGE: en_US.UTF-8

  UNICORN_WORKERS: 8

  DISCOURSE_HOSTNAME: [redacted]


  DISCOURSE_SMTP_ADDRESS: [redacted]
  DISCOURSE_SMTP_PORT: 587
  DISCOURSE_SMTP_USER_NAME: [redacted]
  DISCOURSE_SMTP_PASSWORD: "[redacted]"
  #DISCOURSE_SMTP_ENABLE_START_TLS: true           # (optionnel, par défaut true)
  DISCOURSE_SMTP_DOMAIN: [redacted]
  DISCOURSE_NOTIFICATION_EMAIL: [redacted]


## Le conteneur Docker est sans état ; toutes les données sont stockées dans /shared
volumes:
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log

## Les plugins vont ici
## voir https://meta.discourse.org/t/19157 pour plus de détails
hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git

## Toutes les commandes personnalisées à exécuter après la construction
run:
  - exec: echo "Début des commandes personnalisées"
  - exec: echo "Fin des commandes personnalisées"

Ah, je vois ce que j’ai fait. Le 8880:80 fonctionne bien, je testais uniquement le côté 4443:443. Cela n’a pas fonctionné car il y a une erreur de certificat. Je compte installer et gérer le certificat au niveau du serveur web dans l’hôte virtuel. Je posterai une solution finale pour ceux que cela intéresse une fois que tout fonctionnera.

Installation de l’environnement
Hestia Control Panel (pour la gestion du serveur)
Apache2 (serveur web)
Discourse dans Docker, inversé via un proxy vers Apache2
Let’sEncrypt non inversé via un proxy, mais géré par Hestia dans www_root

  1. Configurer les sockets Unix dans app.yml (et reconstruire) :
  - "templates/web.socketed.template.yml"
  1. Supprimer la mappage de ports et Let’sEncrypt de app.yml (et reconstruire)
#  - "templates/web.ssl.template.yml"
#  - "templates/web.letsencrypt.ssl.template.yml"
#  - "80:80"   # http
#  - "443:443" # https
#  LETSENCRYPT_ACCOUNT_EMAIL : {votre adresse e-mail, probablement}
  1. Créer des modèles alternatifs de apache2.conf pour HestiaCP comme suit (pour ceux qui n’utilisent pas HestiaCP, sachez simplement que les balises %{replace tags}% sont assez standard et évidentes si vous examinez n’importe quel autre fichier apache2.conf. Les parties les plus importantes n’utilisent pas beaucoup de balises %{replace tags}%. Notez également que le texte standalone pourrait être socket-only selon votre configuration. Vérifiez ce qui se trouve dans le répertoire /var/discourse/shared/ si vous ne vous en souvenez pas.

{Custom Template}.stpl

<VirtualHost %ip%:%web_ssl_port%>

    ServerName %domain_idn%

    ProxyPreserveHost On
    ProxyRequests Off
    ProxyPass / unix:/var/discourse/shared/standalone/nginx.http.sock|http://localhost/
    ProxyPassReverse  / unix:/var/discourse/shared/standalone/nginx.http.sock|http://localhost/

    ServerAdmin %email%

    Alias /vstats/ %home%/%user%/web/%domain%/stats/
    Alias /error/ %home%/%user%/web/%domain%/document_errors/

    CustomLog /var/log/%web_system%/domains/%domain%.bytes bytes
    CustomLog /var/log/%web_system%/domains/%domain%.log combined
    ErrorLog /var/log/%web_system%/domains/%domain%.error.log
    <Directory %home%/%user%/web/%domain%/stats>
        AllowOverride All
    </Directory>
    <Directory %sdocroot%>
        AllowOverride All
        SSLRequireSSL
        Options +Includes -Indexes +ExecCGI
    </Directory>
    SSLEngine on
    SSLVerifyClient none
    SSLCertificateFile %ssl_crt%
    SSLCertificateKeyFile %ssl_key%
    %ssl_ca_str%SSLCertificateChainFile %ssl_ca%

    IncludeOptional %home%/%user%/conf/web/%domain%/%web_system%.ssl.conf_*

</VirtualHost>

{Custom Template}.tpl

<VirtualHost %ip%:%web_port%>

    ServerName %domain_idn%
    %alias_string%

    ProxyPreserveHost On
    ProxyRequests Off
    ProxyPass / unix:/var/discourse/shared/standalone/nginx.http.sock|http://localhost/
    ProxyPassReverse  / unix:/var/discourse/shared/standalone/nginx.http.sock|http://localhost/

    RewriteEngine On
    RewriteCond %{REQUEST_URI} !^.well-known/acme-challenge
    RewriteRule ^(.*) https://%domain_idn%/$1 [R=301,L]

    Alias /vstats/ %home%/%user%/web/%domain%/stats/
    Alias /error/ %home%/%user%/web/%domain%/document_errors/

    CustomLog /var/log/%web_system%/domains/%domain%.bytes bytes
    CustomLog /var/log/%web_system%/domains/%domain%.log combined
    ErrorLog /var/log/%web_system%/domains/%domain%.error.log

    <Directory %home%/%user%/web/%domain%/stats>
        AllowOverride All
    </Directory>
    <Directory %sdocroot%>
        AllowOverride All
        Options +Includes -Indexes +ExecCGI
    </Directory>

    IncludeOptional %home%/%user%/conf/web/%domain%/%web_system%.conf_*

</VirtualHost>

Ah, j’ai oublié quelque chose plus haut : vous aurez également besoin de ceci dans chaque fichier :

RequestHeader set X-Forwarded-Proto https