Sì, lo farei a fasi:
- procurati un server leggermente più potente
- fai funzionare l’installazione dei due contenitori
se a questo punto sei soddisfatto, fermati qui, oppure:
- implementa la pagina di manutenzione seguendo l’ottima guida di @Lilly sopra.
haha sono felice che tu l’abbia chiesto perché non ho preso il tempo di spiegare questa parte (avrei dovuto - c’è molto da spiegare e Cloudflare è complesso!)
quando la route degli workers è impostata, ogni singolo caricamento di immagine e visualizzazione di pagina sul forum viene instradato attraverso quell’worker.
Il piano CDN gratuito di Cloudflare include un limite di 100.000 richieste/giorno per una route degli workers.
quindi, se hai un forum relativamente trafficato, per evitare di raggiungere il limite del piano gratuito in un giorno, è una buona idea non tenerlo attivo tutto il tempo. Si tratta solo della route degli workers, non della pagina di manutenzione: puoi lasciare la pagina di manutenzione attiva tutto il tempo; non viene attivata a meno che tu non abbia abilitato la route degli workers. Si tratta semplicemente di questa parte del Passo 2 in cui hai assegnato la route (che è facile da impostare e rimuovere). A meno che tu non utilizzi un piano Cloudflare a pagamento, è quindi una buona pratica tenerla attiva solo quando esegui la tua manutenzione.
- vai alla pagina delle route degli workers di Cloudflare per il tuo dominio e clicca il pulsante sul lato destro della route.
- in basso nella schermata di modifica, clicca il pulsante
removeper scollegare la pagina dell’worker dalla route.
- non preoccuparti, il codice dell’worker stesso non verrà eliminato, solo la regola di instradamento. La prossima volta che eseguirai una ricostruzione/aggiornamento, potrai semplicemente aggiungerlo di nuovo come nel Passo 2 sopra.
Se utilizzi un piano Cloudflare a pagamento, non devi preoccuparti di nulla. Tuttavia, in quel caso puoi utilizzare le pagine di errore di Cloudflare invece di una pagina degli workers… (ho già detto che Cloudflare è piuttosto complesso? LOL)
configurazione avanzata per amministratori di seguito
Se si desidera automatizzare completamente gli aggiornamenti con il piano gratuito, si dovrebbe utilizzare un token API di Cloudflare, il proprio zone-id e un comando curl per ottenere l’route id degli workers. Quindi modificare lo script /root/update-web.sh con qualche altra cosa divertente per attivare e disattivare automaticamente la route degli workers:
#!/bin/bash
cd /var/discourse
CF_TOKEN="your_actual_token_here" #<---token API di Cloudflare
ZONE_ID="xxxx" #<---dalla tua pagina profilo Cloudflare
ROUTE_ID="xxxx"
WORKER_NAME="my-site-maintenance-page"
echo "➡️ Pulling latest Discourse docker scripts..."
git pull
echo "➡️ Bootstrapping new web container in the background..."
./launcher bootstrap web_only
if [ $? -eq 0 ]; then
echo "✅ Bootstrap successful!"
# Turn ON the Cloudflare Maintenance Worker
echo "🚧 Enabling Maintenance Page..."
curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/workers/routes/$ROUTE_ID" \
-H "Authorization: Bearer $CF_TOKEN" \
-H "Content-Type: application/json" \
--data '{"pattern":"*your-site.com/*","script":"'$WORKER_NAME'"}' > /dev/null
# Swap the containers (The 30-second downtime window)
echo "🔄 Swapping containers..."
./launcher destroy web_only && ./launcher start web_only
# Turn OFF the Cloudflare Maintenance Worker
echo "🌍 Disabling Maintenance Page..."
curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/workers/routes/$ROUTE_ID" \
-H "Authorization: Bearer $CF_TOKEN" \
-H "Content-Type: application/json" \
--data '{"pattern":"*your-site.com/*","script":null}' > /dev/null
echo "🚀 Done! Site updated with zero visible downtime."
else
echo "❌ Bootstrap failed! Aborting swap to keep current site online."
fi
Utilizzo la versione precedente dello script perché non mi interessa automatizzare tutto e mi piace essere presente durante gli aggiornamenti/ricostruzioni. Aggiungo semplicemente la route degli workers subito prima di eseguire un aggiornamento e la rimuovo dopo. Ci vogliono solo pochi secondi.
I miei passaggi generali sono:
- aggiungere la route degli workers su Cloudflare
- accedere via SSH a Hetzner
- eseguire eventuali aggiornamenti di sistema (es:
sudo apt update && sudo apt upgrade -y, quindi riavviare il server se necessario - accedere di nuovo via SSH se è stato necessario riavviare
- eseguire
./update-web.sh - rimuovere la route degli workers su Cloudflare
Non ho la minima idea di programmazione o del mondo dello sviluppo, oltre a quel semplice hello world che feci con Visual Basic tanto tempo fa. Però riesco a fare alcune cose, perché conosco meglio come amministrare i miei server WordPress e Mastodon/Pixelfed, e in qualche modo anche il mio Discourse. Poi c’è quella roba chiamata IA (che non è affatto facile per un principiante, come viene pubblicizzato).
Non so se sia anche solo remotamente possibile con Discourse a causa di Docker, ma nel mondo ordinario Nginx-Varnish-WordPress ho costruito un sistema in cui un server Plesk riceve informazioni sugli errori 50x e mostra una pagina di errore. In realtà ho tre configurazioni: il frontend Nginx mostra il contenuto di uno snapshot generato se Varnish è giù, Varnish inizia a usare lo snapshot per i contenuti non in cache quando il backend legato a WordPress è giù, e la terza è una pagina di errore se il frontend Nginx non risponde.
Le cose legate a Varnish non sono possibili per Discourse, ma non vedo alcun motivo per cui non si possa costruire una simile ragnatela anche nel mondo Docker, in cui qualsiasi errore 50x mostrerebbe una pagina di errore.
Potrebbe trattarsi di un sistema molto soggetto a errori. E non ho la più pallida idea di cosa succederebbe se ci fossero più di un pugno di utenti.
C’è anche la risposta più ovvia, ovviamente: usare ad esempio Nginx prima di Discourse. Lo usavo prima di passare alla configurazione a due container.