Come installare Discourse su Google Cloud in prova gratuita

Discourse su Google Cloud in prova gratuita si può fare, ma va impostato con criterio: il punto non è solo far partire il container, è evitare di finire subito contro limiti di CPU, RAM, disco, SMTP o IP reputazionale. Se l’obiettivo è una community piccola per test, il percorso più lineare resta una singola VM Linux con Docker, dominio dedicato, posta esterna affidabile e backup fuori dalla macchina.

La scelta architetturale giusta, in questo caso, è semplice: una istanza piccola ma stabile, un volume persistente separato, DNS pulito, TLS automatico e nessun componente superfluo. Discourse non è un’app “leggera”: il motore principale gira bene solo se risorse e rete sono coerenti. In prova gratuita si lavora sul minimo indispensabile, poi si misura.

Prima di partire: cosa serve davvero

Per una installazione affidabile servono almeno: un dominio o sottodominio, una VM Linux recente, accesso SSH amministrativo, un provider SMTP esterno e la possibilità di pubblicare record DNS. Senza SMTP funzionante, Discourse parte a metà: gli utenti non ricevono inviti, reset password e notifiche in modo affidabile.

Su Google Cloud, la “prova gratuita” non va confusa con risorse illimitate. Le offerte cambiano nel tempo e variano per area geografica, quindi conviene verificare nella console quale macchina sia effettivamente eleggibile e quali crediti siano disponibili sul progetto. Se l’obiettivo è non sforare, conviene partire con una VM piccola, monitorare consumo e tenere disattivate le componenti non essenziali.

Scelta della VM: dimensionamento minimo sensato

Discourse tende a soffrire più sulla RAM che sulla CPU. Per un ambiente di prova, il margine minimo realistico è una macchina con almeno 2 GB di RAM; se la community inizia a muoversi o se vuoi margine per rebuild e aggiornamenti, meglio 4 GB. Con meno, il rischio concreto è che il sistema entri in swap o che il container venga ucciso dall’OOM killer.

La scelta del disco conta altrettanto: usa un disco persistente, non il filesystem temporaneo. Anche per un test, è meglio prevedere almeno 20–30 GB liberi tra sistema, Docker, immagini, log e dati applicativi. Se il disco si riempie, Discourse degrada rapidamente: posta, rebuild e aggiornamenti diventano fragili.

Creazione della VM su Google Cloud

Dal pannello Google Cloud, il percorso tipico è Compute Engine → VM instances → Create instance. Qui imposti nome, regione, zona, tipo di macchina e disco. Se vuoi restare vicino alla prova gratuita, scegli una configurazione compatibile con il budget del progetto e una regione coerente con il tuo pubblico o con i limiti della promo disponibile.

In pratica, evita di complicare la topologia: niente bilanciatori, niente database separati, niente architetture multi-zona. Discourse in fase iniziale va tenuto su una singola VM. Ogni componente aggiuntivo aumenta il blast radius e introduce problemi che non servono in un test.

1. Apri Compute Engine e crea una nuova VM Linux recente, preferibilmente una LTS supportata.
2. Assegna un disco persistente sufficiente e verifica che il tipo di disco sia adeguato al carico previsto.
3. Abilita l’accesso SSH e limita l’esposizione solo alle porte necessarie.
4. Se possibile, assegna un IP esterno statico: per il DNS è molto più pulito rispetto a un IP effimero.

Se non hai ancora l’IP statico, puoi comunque procedere, ma sappi che un cambio di indirizzo rompe il DNS e il certificato fino all’aggiornamento dei record. È uno dei classici errori da prova gratuita: la VM si ricrea, l’IP cambia, il forum smette di rispondere e sembra un problema “misterioso”.

Preparazione del sistema operativo

Una volta collegato via SSH, aggiorna il sistema e prepara il supporto a Docker. Le distribuzioni cambiano nei dettagli, ma il principio resta quello: sistema pulito, pacchetti aggiornati, nessun demone inutile esposto. Se usi Ubuntu o Debian recenti, il flusso è lineare.

sudo apt update && sudo apt -y upgrade

Verifica che il kernel e i servizi di base siano in stato normale, poi installa Docker seguendo il metodo ufficiale della distribuzione o la documentazione di Discourse. Evita repository improvvisati: per un’app esposta su Internet, la manutenzione conta più della velocità iniziale.

Se il sistema ha già swap molto aggressivo o poco spazio libero, sistemalo prima di andare oltre. Un check rapido del disco e della memoria evita falsi problemi dopo il deploy.

df -h
free -h
docker --version

Atteso: spazio libero sufficiente su `/`, memoria disponibile compatibile con l’istanza scelta e Docker installato. Se `free -h` mostra RAM quasi satura già a sistema fermo, non ha senso continuare: serve una VM più capiente o una configurazione più leggera.

Installazione di Discourse con Docker

Discourse distribuisce un’installazione containerizzata con script di bootstrap. Il vantaggio è che riduce la variabilità dell’ambiente; lo svantaggio è che devi rispettare bene i prerequisiti. La directory tipica è `/var/discourse`, dove vivono configurazione, container e dati applicativi.

sudo mkdir -p /var/discourse
sudo git clone https://github.com/discourse/discourse_docker.git /var/discourse
cd /var/discourse

Prima del bootstrap, modifica il file di configurazione del container, di solito `containers/app.yml`. Qui imposti hostname, email del sito, SMTP e parametri essenziali. È il file da trattare con più attenzione: fai sempre un backup prima di toccarlo.

sudo cp containers/app.yml containers/app.yml.bak

Nel file `app.yml` vanno inseriti almeno hostname e configurazione mail. Il formato esatto può cambiare nel tempo, ma la logica non cambia: Discourse deve sapere su quale nome risponde e come inviare posta. Se il dominio non è ancora pronto, fermati qui e sistema prima il DNS.

templates: - "templates/redis.template.yml" - "templates/web.template.yml" - "templates/web.ratelimit.template.yml" expose: - "80:80" - "443:443" params: db_default_text_search_config: "pg_catalog.english" env: LANG: en_US.UTF-8 DISCOURSE_HOSTNAME: forum.example.com DISCOURSE_DEVELOPER_EMAILS: admin@example.com DISCOURSE_SMTP_ADDRESS: smtp.example.com DISCOURSE_SMTP_PORT: 587 DISCOURSE_SMTP_USER_NAME: smtp-user DISCOURSE_SMTP_PASSWORD: "redacted" DISCOURSE_SMTP_ENABLE_START_TLS: true

Il dettaglio importante è che la password SMTP non va mai lasciata in chiaro in documentazione condivisa o in repository pubblici. Se devi fare assistenza, redigi il valore e ruotalo se c’è dubbio di esposizione.

Quando la configurazione è pronta, esegui il bootstrap. Questo passaggio costruisce il container, scarica le immagini e prepara il servizio.

./launcher bootstrap app

Il tempo di esecuzione dipende dalla VM e dalla rete. Se fallisce, la prima cosa da guardare sono i log di bootstrap, non la configurazione “a occhio”. Cerca errori di download, DNS interno, mancanza di RAM o problemi di Docker.

DNS e certificato TLS

Discourse va pubblicato solo quando il DNS punta correttamente alla VM. Crea un record A per `forum.example.com` verso l’IP esterno della macchina. Se usi un IP dinamico, il rischio operativo è evidente: ogni cambio rompe l’accesso.

Se il dominio è sotto il tuo controllo, verifica anche che non esistano record confliggenti di tipo AAAA o vecchi CNAME che puntano altrove. Il sintomo classico è che il sito funziona per alcuni e non per altri, oppure che il certificato non riesce a validarsi perché il nome risolve in modo incoerente.

Per il TLS, Discourse può gestire il certificato automatico se la configurazione è corretta e la porta 80 è raggiungibile per la validazione. Non chiudere la porta 80 prima che il certificato sia stato emesso e rinnovato con successo. Se metti davanti un proxy o una CDN, devi sapere esattamente chi termina TLS e chi risponde alla challenge.

Controllo minimo da fare dopo la propagazione DNS:

dig +short forum.example.com
curl -I https://forum.example.com

Atteso: l’IP coincide con la VM e la risposta HTTPS restituisce almeno un codice 200, 301 o 302 coerente con il setup. Se compare un certificato non valido o un errore di connessione, il problema è prima del livello applicativo.

SMTP esterno: il punto che spesso blocca tutto

La posta è il collo di bottiglia più frequente. Google Cloud, come molti ambienti cloud, non è il posto giusto per improvvisare un mail server da zero in prova gratuita. Per un forum piccolo, conviene usare un provider SMTP esterno affidabile, con credenziali dedicate e limiti chiari.

La configurazione va testata subito dopo il bootstrap. Non aspettare che arrivino utenti veri: un forum senza email funzionante sembra vivo, ma in realtà è monco. Inviti, conferme account e notifiche sono parte del servizio, non un optional.

1. Verifica che host, porta, utente e password SMTP siano corretti.
2. Controlla che il provider consenta TLS sulla porta indicata.
3. Fai un test di invio da Discourse, poi controlla gli header del messaggio ricevuto.

Se il test fallisce, cerca nei log del container errori come autenticazione negata, handshake TLS fallito o timeout di rete. Non cambiare tre parametri insieme: modifica un solo elemento per volta, così capisci cosa ha davvero risolto.

Avvio del container e prime verifiche

Dopo il bootstrap, avvia il container con il launcher previsto dalla distribuzione Discourse. Il comportamento atteso è semplice: il servizio web risponde, il pannello di configurazione iniziale è accessibile e i log non mostrano errori ripetuti.

./launcher start app

Verifica che il container sia effettivamente in esecuzione e che le porte siano ascoltate.

docker ps
ss -ltnp | grep -E ':80|:443'

Atteso: un container attivo e listener su 80/443. Se non c’è listener, il problema è nella configurazione del container o nel servizio non partito. Se il listener c’è ma il sito non risponde, il problema è a livello DNS, firewall o certificato.

Un test utile, subito dopo, è il controllo dell’HTML iniziale e del comportamento HTTP.

curl -I http://forum.example.com
curl -I https://forum.example.com

Se HTTP risponde ma HTTPS no, il problema è quasi sempre nel TLS o nella validazione del certificato. Se entrambi falliscono, guarda firewall, routing e stato del container.

Hardening minimo per un ambiente di prova

Anche in prova gratuita vale la pena fare un hardening minimo. Non serve blindare tutto, ma serve evitare errori banali: SSH aperto al mondo senza restrizioni, backup assenti, credenziali deboli, porte lasciate aperte senza motivo. Il fatto che sia un test non giustifica una configurazione fragile.

• Consenti SSH solo dagli IP amministrativi se possibile.
• Usa chiavi SSH, non password esposte.
• Separa backup e runtime: il backup non deve stare solo sullo stesso disco della VM.
• Ruota le credenziali SMTP se sono state condivise o copiate in ambienti non controllati.

Per i backup, il minimo sindacale è esportare la configurazione e salvare i dati persistenti fuori dalla VM. Se il progetto ha un budget zero, almeno automatizza una copia periodica del volume o dei dump critici su uno storage esterno. Se la VM si corrompe, devi poter ricostruire il forum senza ripartire da zero.

Controlli operativi dopo il go-live

Dopo l’accesso pubblico, osserva tre cose: stabilità del servizio, consumo risorse e capacità di invio mail. Sono i segnali che ti dicono se la prova gratuita è davvero sostenibile o se stai solo ritardando il problema.

1. Stabilità HTTP: nessun aumento anomalo di 5xx o timeout.
2. RAM e swap: se la memoria si satura, Discourse rallenta e può diventare instabile.
3. Disco: log, rebuild e media possono crescere più in fretta del previsto.
4. Mail: verificare che inviti e notifiche arrivino con regolarità.

Se noti lentezza, la metrica da guardare per prima è il tempo di risposta percepito dagli utenti, non solo l’uptime. Un forum “su” ma ingestibile è comunque un servizio degradato. In pratica, controlla TTFB, error rate e saturazione della memoria prima di pensare a tuning più raffinati.

Problemi tipici e come chiuderli senza rifare tutto

Il primo problema tipico è il dominio che non risolve ancora. In quel caso non toccare Discourse: aspetta la propagazione o correggi il record DNS. Il secondo è il certificato che non si emette perché la porta 80 non è raggiungibile. Il terzo è la posta, che spesso fallisce per credenziali errate o TLS incompatibile.

Se il container non parte dopo una modifica a `app.yml`, ripristina subito il backup e rilancia il bootstrap. Il rollback più pulito, in questo scenario, è tornare al file precedente e verificare che il servizio si avvii con la configurazione nota funzionante.

sudo cp containers/app.yml.bak containers/app.yml
./launcher rebuild app

Blast radius del rollback: solo il container Discourse e la sua configurazione; i dati persistenti restano intatti se non hai toccato il volume. Assunzione: stai usando una singola istanza con DNS sotto il tuo controllo e SMTP esterno già disponibile.

Quando la prova gratuita non basta più

Ci sono due segnali chiari che indicano il passaggio a un piano non gratuito o a una macchina più robusta: la RAM è costantemente al limite e il disco cresce senza margine. In quel momento il problema non è più “far partire Discourse”, ma garantire continuità operativa. L’upgrade va pianificato con una finestra di manutenzione e un backup testato prima del cambio.

Se vuoi restare su Google Cloud, la strada corretta è mantenere la stessa architettura e cambiare solo la dimensione della VM o il tipo di disco, senza riscrivere tutto. È il modo più sicuro per evitare regressioni: stesso dominio, stesso container, stessi dati, infrastruttura più adatta al carico reale.