Discourse in Docker installiert, keine Verbindung möglich

Ich habe also die Standard-Installationsanleitung verwendet und alles schien gut zu laufen. Anschließend habe ich die app.yml bearbeitet, um die verwendeten Ports zu ändern, LetsEncrypt auskommentiert und neu aufgebaut. Es sah so aus, als ob alles reibungslos funktioniert hätte.

Aber wenn ich versuche, mich über die direkteste Methode zu verbinden:

$lynx https://127.0.0.1:44443

erhalte ich folgende Fehlermeldung:

Alert!: Unable to make secure connection to remote host.

Ich kann den Port nicht einmal anpingen.

Ergibt das irgendwelchen Sinn? Gibt es Logs innerhalb des Containers?

—Edit hinzugefügt----

$ sudo ./launcher logs app
run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
run-parts: executing /etc/runit/1.d/anacron
run-parts: executing /etc/runit/1.d/cleanup-pids
Cleaning stale PID files
run-parts: executing /etc/runit/1.d/copy-env
Started runsvdir, PID is 43
ok: run: redis: (pid 56) 0s
**chgrp: invalid group: 'syslog'**
ok: run: postgres: (pid 55) 0s
supervisor pid: 57 unicorn pid: 85
(57) Reopening logs

----Edit mit mehr Informationen----

root@hestia-app:/shared/log/rails# tail -f *.log
==> production_errors.log <==

==> production.log <==

==> sidekiq.log <==

==> unicorn.stderr.log <==
I, [2021-08-06T00:56:35.859967 #85]  INFO -- : master done reopening logs
I, [2021-08-06T00:56:50.911700 #142]  INFO -- : worker=0 done reopening logs
I, [2021-08-06T00:56:50.911698 #152]  INFO -- : worker=1 done reopening logs
I, [2021-08-06T00:56:50.935834 #162]  INFO -- : worker=2 done reopening logs
I, [2021-08-06T00:56:50.941733 #233]  INFO -- : worker=7 done reopening logs
I, [2021-08-06T00:56:50.945447 #203]  INFO -- : worker=5 done reopening logs
I, [2021-08-06T00:56:50.947354 #172]  INFO -- : worker=3 done reopening logs
I, [2021-08-06T00:56:50.949949 #187]  INFO -- : worker=4 done reopening logs
I, [2021-08-06T00:56:50.953453 #213]  INFO -- : worker=6 done reopening logs

==> unicorn.stdout.log <==
Sidekiq PID 131 done reopening logs...
root@hestia-app:/var/log/nginx# tail *.log
==> access.letsencrypt.log <==

==> access.log <==

==> error.letsencrypt.log <==

==> error.log <==

Muss ein Docker-Fehler sein, denn… alles andere sieht in Ordnung aus.

Ich habe gerade einen leeren Apache-Container auf Port 8088 gemappt installiert, und er funktioniert einwandfrei über Lynx.

Ich habe die App erneut gestartet und ps ax ausgeführt. Es scheint, als ob alles funktioniert. Es sieht nur so aus, als würde der Container keine Verbindungen akzeptieren.

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

Okay, also ich habe die App gestartet und Lynx innerhalb des Discord-Dockers installiert, und ich kann dort die Willkommensseite aufrufen! Die Installation funktioniert also, das Problem liegt bei der Netzwerkmapping-Konfiguration vom Docker-Container heraus zum Server.

Hier ist die Ausgabe von 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

…und hier sind die Informationen aus der 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           # (optional, default true)
  DISCOURSE_SMTP_DOMAIN: [redacted]
  DISCOURSE_NOTIFICATION_EMAIL: [redacted]


## Der Docker-Container ist zustandslos; alle Daten werden in /shared gespeichert
volumes:
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log

## Plugins kommen hierher
## siehe https://meta.discourse.org/t/19157 für Details
hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git

## Alle benutzerdefinierten Befehle, die nach dem Build ausgeführt werden sollen
run:
  - exec: echo "Beginning of custom commands"
  - exec: echo "End of custom commands"

Ah, ich verstehe, was ich falsch gemacht habe. Die 8880:80-Verbindung funktioniert einwandfrei, ich habe nur die 4443:443-Seite getestet. Diese hat nicht funktioniert, da ein Zertifikatsfehler vorliegt. Ich plane, das Zertifikat auf der Ebene des Webservers im virtuellen Host zu installieren und zu verwalten. Sobald alles funktioniert, werde ich eine finale Lösung für alle Interessierten veröffentlichen.

Umgebung installieren
Hestia Control Panel (zur Serververwaltung)
Apache2 (Webserver)
Discourse in Docker, rückwärts über Apache2 proxyiert
Let’sEncrypt wird nicht rückwärts proxyiert, sondern von Hestia im www_root verwaltet

  1. Unix-Sockets in app.yml einrichten (und neu erstellen):
  - "templates/web.socketed.template.yml"
  1. Port-Mapping und Let’sEncrypt aus app.yml entfernen (und neu erstellen)
#  - "templates/web.ssl.template.yml"
#  - "templates/web.letsencrypt.ssl.template.yml"
#  - "80:80"   # http
#  - "443:443" # https
#  LETSENCRYPT_ACCOUNT_EMAIL: {deine E-Mail, wahrscheinlich}
  1. Alternative apache2.conf-Vorlagen für HestiaCP wie folgt erstellen (für diejenigen unter euch, die kein HestiaCP verwenden: beachtet einfach, dass die %{replace tags}% ziemlich standardisiert und offensichtlich sind, wenn ihr euch eine andere apache2.conf-Datei anschaut. Die wichtigsten Teile verwenden nur wenige %{replace tags}%. Beachtet auch, dass der Text standalone je nach eurer Einrichtung auch socket-only sein könnte. Schaut in das Verzeichnis /var/discourse/shared/, wenn ihr euch nicht mehr erinnert.

{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, ich habe oben etwas übersehen: In jeder Datei benötigen Sie auch Folgendes:

RequestHeader set X-Forwarded-Proto https