Installazione da zero restituisce 502 Bad Gateway

Installazione
1

Ciao a tutti,

Ho configurato Discourse due volte, una volta in un container e l’attuale in una VM. In entrambe le installazioni, Discourse non è raggiungibile. Non sono molto sicuro di cosa possa essere sbagliato.

VM di Discourse:

  • Core 4
  • RAM 6 GB
  • Archiviazione 50 GB
  • OS: Ubuntu 22.04.3

Comandi di installazione Post OS puliti:

apt update -y && apt upgrade -y && apt wget curl zip git docker.io -y && reboot

Quindi ho seguito la seguente guida: discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub

Una volta completato, posso vedere che il container è in esecuzione ma restituisce 502 Bad Gateway.

Come l’ho configurato: Nginx Reverse Proxy (include SSL) → VM. Questo non funziona.
Non si carica nemmeno quando lo aggiungo direttamente al mio file hosts.

Dalle ultime righe dell’installazione, vedo che Docker ha creato una nuova rete:

DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443

Come posso farlo utilizzare l’IP della macchina HOST?
Non ho bisogno di un’altra rete nella rete. Sono felice che Docker utilizzi l’IP HOST poiché questo è l’unico servizio su questa VM.

Qualsiasi assistenza sarebbe molto apprezzata!

Esiste un metodo ufficiale per installare senza Docker?

2 Mi Piace
4

La container si trova su una macchina con un IP pubblico? A quell’IP pubblico è assegnato un nome di dominio?

Hai eseguito discourse-setup? Sei andato oltre la parte in cui verifica se il tuo DNS è valido e l’host è disponibile?

Hai eseguito una serie di rebuild in modo da essere limitato da let’s encrypt e non poterti assegnare un certificato?

5

No, a questa macchina è assegnato un IP locale e il traffico viene instradato all’IP locale tramite il mio firewall. Questo non è il problema.
L’IP pubblico ha un record A per il server e viene instradato correttamente. forum.somedomain.com punta –\u003e al server corretto.

Sì, ho superato l’installazione. L’ho completata al 100% (3 volte) fino al punto in cui il container è in esecuzione.
Supera tutti i controlli di dominio/DNS. Indica che sono validi.

No, questo non può essere limitato poiché il certificato SSL viene emesso tramite il mio reverse proxy. Ho il certificato.

Questa installazione è completata al 100%. Il problema è che Docker sta creando una nuova rete 172.17.0.1 che non è necessaria poiché vorrei utilizzare l’IP locale dell’HOST 192.xx.xx.xx

Il container è in esecuzione ma su una rete diversa. Non riesco a farlo passare all’IP dell’HOST.

Il docker host dovrebbe essere l’IP del server host (192.xxx.xxx.xxx) e non una nuova rete. Probabilmente sta funzionando ma su quella rete.
Come posso dire all’installazione di utilizzare il mio IP locale e non 172.17.0.1?

6

@pfaffman Qualcosa del genere. Da un tuo commento

Come imposto ./discourse-setup per utilizzare l’IP host 192.168.1.X e la rete durante l’installazione?

7

Non è possibile utilizzare discourse-setup con un proxy inverso. Dovrai modificare tu stesso il file yml. Ci sono alcuni argomenti su come eseguire discourse con altri siti sulla stessa macchina.

Dovrai rimuovere i template ssl e let’s encrypt se stai utilizzando un proxy inverso che gestisce le impostazioni ssl.

8

Questa è la cosa, non sto eseguendo altri servizi su questa macchina. È una VM standalone.

Penso ci sia un malinteso.

./docker-setup si installa correttamente. Crea una propria rete per l’app 172.17.0.1.

Come faccio a far utilizzare all’installazione o al container Docker l’IP host 192.168.1.X, ovvero utilizzare una rete bridge invece di crearne una propria.

9

Ma hai detto questo:

Se stai usando un proxy inverso non puoi usare discourse-setup.

10

Sì, il reverse proxy è su un altro server ma ho capito cosa stai dicendo.

Ho un’idea. Instraderò tutto il traffico dalla mia rete alla rete dei container docker.

Esiste una guida all’installazione per eseguire discourse dietro un reverse proxy nginx?

O un modo per costruire discourse da solo?

11

È piuttosto banale. Consentite la porta http su app.yml dove Ngix sta inviando traffico. E SSL è disabilitato. Queste due cose sono le uniche che dovete correggere. Naturalmente dovete specificare l’IP reale, ma questo dovete farlo ogni volta che il backend è Discourse, Moodle, WordPress o qualsiasi altra cosa. UFW cerca di limitare l’accesso solo tra frontend e backend perché non c’è bisogno di consentire l’accesso diretto al backend.

Se non ricordo male, qui c’è la documentazione su come configurare Apache2. Nginx fa la stessa cosa, ma ovviamente a modo suo.

O cosa mi sfugge adesso?

1 Mi Piace
12

Lasciami iniziare dall’inizio così puoi capire che è qualcosa di semplice che mi manca.

Ho Nginx Reverse Proxy. Gestisce l’IP pubblico e il routing ai servizi.

ES: il client richiede cloud.domain.com → Nginx Reverse Proxy (gestisce ssl) → Punta a cloud.domain.com

Ora ho configurato una VM per discourse e ho usato quanto segue:
Ubuntu 23.04. Comandi post installazione OS:

apt update -y \
apt upgrade -y \
apt install wget curl zip git docker.io -y

Poi ho seguito questa guida da Discourse discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub

L’installazione si completa con successo e poi iniziano i problemi.

Non riesco ad accedere al container docker dall’host a causa della rete docker0. Posso pingare 172.17.0.2 ed è attivo e funzionante, ma dalla macchina host 192.168.1.10:80/443 non passa traffico al container.

Tutto quello che voglio è che il container docker utilizzi la rete host poiché il container ha le porte 80 e 443 esposte.

Il primo reverse proxy nginx gestisce il traffico dall’esterno e lo passa correttamente alla VM. Se non lo facesse, ./discourse-setup non avrebbe rilevato correttamente il nome del dominio e non sarebbe stato in grado di recuperare i certificati ssl per il container.

Alla fine. So che il container funziona al 100% ma non riesco ad accedervi a causa della rete docker.

Se hai bisogno di informazioni, fammelo sapere.

13

Un altro modo per affrontare questo problema è utilizzare l’immagine di base di discourse

https://hub.docker.com/r/discourse/base

E creare la propria orchestrazione con, ad esempio, docker compose (ricordando che sono necessari altri servizi come redis e postgres)

14

Posso farlo con Nginx o Nginx+Varnish per Discourse sullo stesso VPS o su VPS con IP diverso. Non dici cosa fai effettivamente con il tuo Nginx che agisce come reverse proxy. I tuoi esempi sono un po’ difficili perché non c’è modo di sapere se si tratta di esempi o se stai effettivamente cercando di utilizzare una rete privata.

Ma:

Certo che no, perché quello si occupa del traffico in entrata. Devi usare un’altra porta per il backend.

Qualcosa del genere (che viene effettivamente utilizzato con Varnish, ma il principio è esattamente lo stesso, e roba molto di livello 101):

proxy_pass http://127.0.0.1:8080;
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 https;
proxy_set_header X-Forwarded-Port 443;
proxy_set_header Host $host;
proxy_pass_header Server;
15

Comprensibile, grazie per essere specifico :).

Non sono sicuro di quale, perché questa rete Docker è confusionaria.

Assolutamente, ecco perché mi sto frustrando con Docker lol

Di seguito è esattamente come la rete WAN passa e instrada il traffico dal mio proxy inverso nginx all’host corretto.

map $scheme $hsts_header {
    https   "max-age=63072000;includeSubDomains; preload";
}

server {
  set $forward_scheme https;
  set $server         "10.10.1.38";
  set $port           443;

  listen 80;
listen [::]:80;

  listen 443 ssl http2;
listen [::]:443 ssl http2;


  server_name forum.domainname.com;

  # Let's Encrypt SSL
  include conf.d/include/letsencrypt-acme-challenge.conf;
  include conf.d/include/ssl-ciphers.conf;
  ssl_certificate /srv/ssl/domainname.pem;
  ssl_certificate_key /srv/ssl/domainname-ke.pem;


# Asset Caching
include conf.d/include/assets.conf;

# Block Exploits
include conf.d/include/block-exploits.conf;

# HSTS (richiesto ngx_http_headers_module) (63072000 secondi = 2 anni)
add_header Strict-Transport-Security $hsts_header always;

# Force SSL
include conf.d/include/force-ssl.conf;

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;


access_log /var/logs/domainname-access.log proxy;
error_log /var/logs/domainame_error.log warn;

proxy_set_header  X-Real-IP $remote_addr;
proxy_set_header  X-Forwarded-For $http_x_forwarded_for;
proxy_set_header  X-Forwarded-Proto $scheme;

location / {

  # HSTS (richiesto ngx_http_headers_module) (63072000 secondi = 2 anni)
  add_header Strict-Transport-Security $hsts_header always;

    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
    proxy_http_version 1.1;
    
    # Proxy!
    include conf.d/include/proxy.conf;
  }
}

La cosa strana è che una volta ho configurato un container Docker per un cliente che voleva nginx reverse proxy manager ed è stato estremamente semplice.

docker-compose up -d
Questo è tutto. L’IP privato 192.168.1.3 poteva raggiungere le porte 80/443 esposte dai container e il traffico in uscita veniva instradato correttamente a 192.168.1.3.

16

È confusionaria perché è un sistema di pacchettizzazione che opera nella sua sandbox. Fondamentalmente è così.

Ma capire Docker è una cosa diversa dall’usarlo (e ora un sacco di sviluppatori hanno iniziato a piangere :rofl:) Il tuo reverse proxy sta inviando traffico all’IP attraverso il firewall e devi indicare quell’IP e la porta in ascolto. E hai Discourse, alias Docker, su quell’IP, e la porta che indichi in app.yml. L’Nginx interno che lavora con Discourse stesso si occupa del resto.

Discourse non dovrebbe ascoltare sulla porta 443 perché hai già terminato SSL.

E fondamentalmente non puoi usare la cache sul reverse proxy. Il backend, Discourse, non è una pagina web. È un’applicazione web che invia javascript e json.

17

L’ho capito più o meno.

Su questo posso essere d’accordo. Non direi piangere, è solo inutile per gli amministratori di sistema e per gli sviluppatori che conoscono bene linux. Creare un LxC o una VM che è isolata per poi far creare a docker un altro ambiente isolato è ridondante e inutile.

Questa è la parte che crea confusione. app.yml sta esponendo 80:80 e 443:443 su 172.17.0.2 che è sulla rete docker 172.17.0.1/16 con l’IP della VM su 10.10.1.38.

Come faccio a far sì che discourse/docker permetta a tutto il traffico in arrivo su 10.10.1.38 di essere passato a 172.17.0.2 e a tutto il traffico in uscita di essere passato a 10.10.1.38. Questo è tutto ciò che serve per risolvere questo problema. Letteralmente.

Il mio proxy inverso gestirà il routing dalla WAN a forum.dominio.com

La cache è stata rimossa.

1 Mi Piace
18

Solo se non li cambi. Come dovresti fare e usare una sola porta.

80:80 e 443:443 sono predefiniti e usati di per sé solo quando non c’è un reverse proxy, o qualcos’altro, che agisce come frontend.

1 Mi Piace
19

Mi hai dato un’idea.

Stavo controllando tutti i file di base e penso di aver capito.

Così semplice lol. Sono impegnato nella ricostruzione, questo potrebbe funzionare al 100% utilizzando i metodi di installazione standard ufficialmente supportati.

20

Successo Il forum è ora installato e funzionante.

Utilizzando il metodo di installazione standard e supportato :smiley:

congrats
congrats1305×513 64.2 KB

working
working1613×735 51.7 KB

2 Mi Piace
21

@pfaffman Puoi spostare questo in installazione poiché ora è un’installazione supportata.

22

È lì. È solo etichettato come non supportato :smirking_face:

Qual è stato il tuo problema in primo luogo, perché non hai iniziato l’installazione senza proxy inverso? Sono solo curioso.