Impossibile superare il bootstrap

Ho installato Discourse su 2 VM diverse.
Sto seguendo le istruzioni di installazione ufficiali.
Uno in esecuzione su Debian 12 in un’istanza VMWare Fusion su un Mac Pro, l’altro è Ubuntu 24 in una VM che gira sotto TrueNAS.
Entrambi sono su server dedicati sulla mia rete locale con reti bridge e hanno indirizzi IP accessibili univoci.
Il server TN ospita più altre app containerizzate con Docker e tutte funzionano e sono accessibili tramite LAN e Internet, il Mac Pro ospita nativamente una wiki.
Su entrambe, la funzione di bootstrap termina, ma non ottengo un sito funzionante. Appare solo ‘server non risponde’ nel browser.
Secondo docker ps il container “app” è attivo e in esecuzione, in ascolto sulle porte 80 e 443, ufw conferma che sta permettendo queste porte.
Per un po’, il sito Debian mostrava una pagina di benvenuto di nginx di default, ma ora anche quella non risponde più.
Non sono uno sviluppatore né un mago del web, quindi non so come risolvere i problemi, ho chiesto aiuto a Grok ma finora niente ha funzionato.

Apprezzo davvero qualsiasi aiuto venga dato.

Se non sono su Internet pubblico con un nome di dominio che punta su di essi, non è possibile eseguire un’installazione standard.

Puoi dare un’occhiata a Install Discourse on a residential internet with Cloudflare Tunnel

1 Mi Piace

Ho un indirizzo IP statico pubblicamente disponibile e un nome di dominio che punta a quell’indirizzo.
In generale, uso un record A wildcard per collegare qualsiasi host a quell’IP, ma nel mio troubleshooting sono incappato in un post che diceva che Discourse potrebbe non funzionare bene con indirizzi proxy nei DNS di Cloudflare, quindi ho creato un record A dedicato e disattivato il proxy per quello.

Hai eseguito discourse-setup? Ha superato il test di connessione?

Sto usando correttamente il termine ‘bootstrap function’?
Voglio solo essere sicuro che stiamo parlando della stessa cosa.
./discourse-setup è il bootstrap, giusto?
Quindi, se dico che si avvia il bootstrap e il container è in esecuzione, allora il test di connessione, che avviene all’inizio della configurazione, è passato.

Ha senso tutto questo?

Beh, più o meno. Crea un file app.yml e poi esegue ./launcher bootstrap app.

Se l’hai eseguito un bel po’ di volte senza che il DNS funzionasse correttamente, allora hai raggiunto i limiti di richieste di Let’s Encrypt. Le soluzioni semplici sono aspettare una settimana o usare un nome di dominio diverso.

E non c’è nient’altro in esecuzione su quella macchina?

E quando hai eseguito discourse-setup non si è lamentato di non essere in grado di connettersi a se stesso?

L’ho eseguito solo una volta su ogni VM e ho usato un nome host diverso per ciascuna.

VM nuove di zecca senza nient’altro in esecuzione. Sull’hardware effettivo ci sono altre cose in esecuzione. Ma hanno indirizzi IP interni separati dai loro host.

Corretto.

Ecco gli errori che ho trovato nell’output dell’installazione, nessuno sembra bloccare il funzionamento:

690:M 30 apr 2025 22:05:22.859 # Avviso: Impossibile creare la socket di ascolto TCP del server *:6379: bind: Indirizzo già in uso
690:M 30 apr 2025 22:05:22.859 # Fallito l'ascolto sulla porta 6379 (TCP), si interrompe.
109:M 30 apr 2025 21:59:42.411 # AVVISO La sovraccarico di memoria deve essere abilitato! Senza di essa, un salvataggio in background o una replica potrebbero fallire in condizioni di bassa memoria...
2025-04-30 21:59:41.125 UTC [60] postgres@postgres ERRORE:  database "discourse" già esistente
2025-04-30 21:59:41.274 UTC [63] postgres@discourse ERRORE:  ruolo "discourse" già esistente
AVVISO: Specifiche non risolte o ambigue durante Gem::Specification.reset:
      stringio (>= 0)
      Versioni disponibili/installate di questa gemma:
      - 3.1.7
      - 3.1.5
      - 3.1.1
AVVISO: Pulizia delle specifiche non risolte. Prova 'gem cleanup <gemma>'
Segnala un bug se questo causa problemi.
L'impostazione 'staticAddonTrees' sarà impostata di default su true nella prossima versione di Embroider e non potrà essere disattivata. Per prepararti, dovresti impostare 'staticAddonTrees: true' nella tua configurazione di Embroider.
L'impostazione 'staticAddonTestSupportTrees' sarà impostata di default su true nella prossima versione di Embroider e non potrà essere disattivata. Per prepararti, dovresti impostare 'staticAddonTestSupportTrees: true' nella tua configurazione di Embroider.
Il limite di heap_size di Node.js è inferiore a 2048MB. Impostare --max-old-space-size=2048 e CHEAP_SOURCE_MAPS=1
e DISCOURSE_SMTP_DOMAIN=discourse.example.com
[ BABEL ] Nota: Il generatore di codice ha deottimizzato lo stile dei file /var/www/discourse/app/assets/javascripts/discourse/ember/ember-template-compiler.js poiché supera i 500KB di massimo.
[ BABEL ] Nota: Il generatore di codice ha deottimizzato lo stile dei file /var/www/discourse/app/assets/javascripts/discourse/ember/ember.js poiché supera i 500KB di massimo.

Quali sono le specifiche delle tue VM? Cioè, quante vCPU/RAM vengono assegnate loro?

Entrambi hanno 2/2

1 Mi Piace

Aumentarlo a 4 GB di RAM aiuta? Penso che i requisiti di memoria siano aumentati.

1 Mi Piace

Non pensavo al fatto che, poiché la porta 80 è già in uso e ho solo un IP esterno, anche se il controllo del dominio passava durante il processo di configurazione, dovevo modificare le porte dal lato host per far funzionare le cose.

Sto usando NPM internamente.

Passaggi per far funzionare le cose:

  1. Cambia la porta dal lato host a 7080 per http
  2. Poiché passerò il traffico attraverso il mio gestore di proxy, ho semplificato la mia vita disattivando gli script LE
  3. Aggiornato l’app
  4. Ho passato ‘ext IP:80’ a ‘int IP:7080’ nel reverse proxy, poi il container ha invertito le porte… poi si sono fatti il Hokey Pokey e si sono girati.

Ora sembra che tutto funzioni fino ad ora.

2 Mi Piace