Si è verificato un errore nel mio aggiornamento
api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })
Per favore aiutami a risolverlo.
Ciao!
Non sto rispondendo alla tua domanda, sono solo curioso. Perché pensi di aver bisogno di una pagina di manutenzione? Sembra piuttosto fastidiosa da configurare per un beneficio limitato.
Le mie istanze sono inattive per 5 minuti al mese per gli aggiornamenti e questo è praticamente tutto.
Ogni volta che apportavo modifiche significative, come l’installazione di plugin, ad esempio, ci volevano a volte 20 minuti.
Niente di grave, se si considera che queste operazioni non vengono eseguite ogni settimana o persino ogni mese, ma per un nuovo visitatore quella brutta pagina che indica che qualcosa non funziona non fa una buona prima impressione. Anche per i visitatori abituali che non sono a conoscenza del fatto che il sito sarà inaccessibile, questo può farli entrare in “modalità panico”, pensando che l’intera comunità sia stata chiusa o qualcosa del genere, forse alcuni di loro mi inviano immediatamente un’e-mail chiedendo cosa sta succedendo.
Penso che sia solo un bel tocco per il visitatore, nuovo o vecchio, per fargli sapere cosa sta succedendo.
Se l’approccio suggerito da Claude è qualcosa che richiede solo pochi minuti, ma non viene più toccato, credo che sia tempo ben speso.
Ci vogliono pochi secondi se passi all’installazione con due contenitori.
Puoi persino programmare il passaggio di notte, se proprio vuoi, mentre tu e/o il tuo pubblico principale dormite.
Non hai bisogno di una pagina di manutenzione.
Utilizzo la costruzione a doppio contenitore dietro un CDN Cloudflare. Il doppio contenitore minimizza i tempi di inattività e i miei due forum di produzione principali hanno al massimo 30 secondi di offline durante le ricostruzioni. Apprezzo avere una pagina di manutenzione perché la pagina predefinita di “server down” è brutta e non dà alcun indizio su quanto tempo rimarrà offline.
Ad esempio, per un sito su your-domain.com utilizzo semplicemente una route Cloudflare Workers impostata su *yourdomain.com/* (includi gli asterischi).
Passo 1: Creare la pagina Worker
Puoi configurare la pagina di manutenzione nella pagina delle impostazioni Workers & Pages su Cloudflare - clicca il pulsante Crea applicazione:
poi usa il template hello world:
poi dagli un nome e clicca Deploy:
poi vai alla pagina di panoramica per quella pagina di manutenzione e clicca Modifica codice:
e incolla questo codice nella finestra del codice worker.js (sostituisci il tuo dominio e qualsiasi messaggio desideri, modifica il testo, il colore del testo, lo sfondo, ecc.):
export default {
async fetch(request, env, ctx) {
try {
// Recupera la richiesta originale dal tuo server
const response = await fetch(request);
// Se IL TUO SITO sta cambiando contenitori, genera un errore 502, 521 o 530
if (response.status === 502 || response.status === 521 || response.status === 530) {
return returnCustomErrorPage();
}
// Se tutto va bene, restituisci il traffico normale del forum
return response;
} catch (e) {
// Se il server è completamente irraggiungibile
return returnCustomErrorPage();
}
}
};
function returnCustomErrorPage() {
const html = `
<!DOCTYPE html>
<html lang="it">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Aggiornamento Sistema - YOUR-SITE.com</title>
<style>
body { font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif; text-align: center; padding: 50px; color: #333; background-color: #f9f9f9; }
h1 { font-size: 2.5em; margin-bottom: 0.5em; color: #9400D3; }
p { font-size: 1.2em; line-height: 1.5; }
.container { max-width: 600px; margin: 0 auto; background: white; padding: 40px; border-radius: 8px; box-shadow: 0 4px 6px rgba(0,0,0,0.1); }
</style>
</head>
<body>
<div class="container">
<h1>Breve finestra di aggiornamento</h1>
<p><strong>YOUR-SITE</strong> sta subendo un breve aggiornamento di sistema di 30 secondi.</p>
<p>Fai un veloce sorso della tua bevanda—questa pagina si aggiornerà automaticamente non appena saremo di nuovo online.</p>
</div>
<script>
// Controlla automaticamente se il sito è tornato online ogni 10 secondi
setInterval(function() {
window.location.reload();
}, 10000);
</script>
</body>
</html>
`;
return new Response(html, {
status: 503, // 503 è il migliore per SEO così Google non ti penalizza per il downtime
headers: {
"Content-Type": "text/html;charset=UTF-8",
"Retry-After": "30"
}
});
}
dovrebbe apparire più o meno così. Clicca deploy per salvarlo:
Passo 2: Aggiungere la route
ora vai alla pagina delle route Cloudflare Workers e clicca il pulsante Aggiungi route per far apparire la nuova finestra modale della route, compila la route del dominio e seleziona la pagina Worker che hai appena creato, poi clicca salva:
Passo 3: Eseguire aggiornamenti o ricostruzioni
ora, quando ti connetti via SSH al tuo server ed esegui gli aggiornamenti di sistema o fai una ricostruzione, invece di una pagina di sito down o errore, questa pagina apparirà quando il downtime avviene effettivamente (io uso 30 secondi nel mio perché è il massimo per i miei siti)
Tendo ad aggiungere ed eliminare la mia route della pagina Worker ogni volta che faccio manutenzione, ma alcuni preferiscono lasciarla lì tutto il tempo (io lascio il codice effettivo per la pagina, aggiungo e rimuovo solo la route).
Credo che sia tutto.
Opzionale: Eseguire aggiornamenti con uno script e programmarli
Utilizzo anche uno script shell unix sul mio server per eseguire l’aggiornamento specifico per il doppio contenitore, che ho creato in questo modo:
cat << 'EOF' > /root/update-web.sh
#!/bin/bash
cd /var/discourse
echo "➡️ Recupero gli ultimi script docker di Discourse..."
git pull
echo "➡️ Bootstrap del nuovo contenitore web in background (richiede ~8 min)..."
./launcher bootstrap web_only
if [ $? -eq 0 ]; then
echo "✅ Bootstrap riuscito! Cambio dei contenitori..."
./launcher destroy web_only && ./launcher start web_only
echo "🚀 Fatto! Sito aggiornato con quasi zero downtime."
else
echo "❌ Bootstrap fallito! Annullamento del cambio per mantenere il sito attuale online."
fi
EOF
chmod +x /root/update-web.sh
poi lo eseguo al prompt root sul mio server con il comando ./update-web.sh.
modifica: non seguire i passaggi seguenti a meno che tu non abbia un account Cloudflare a pagamento.
Puoi automatizzarlo per un orario specifico, come le 1:00 di domenica mattina nel tuo fuso orario locale con un cron job. Per me 1:00am locale è 8:00 AM UTC, (puoi calcolare la data UTC del tuo server digitando date al prompt dei comandi quando sei connesso via SSH).
Quindi:
esegui questo comando per aprire il pianificatore di attività del tuo server:
crontab -e
(se ti chiede di scegliere un editor, seleziona il tuo editor preferito, 1 per nano è probabilmente il più semplice)
Scorro fino alla fine dei commenti e incollo questo:
0 8 * * 0 /root/update-web.sh >> /var/log/discourse-update.log 2>&1
(cioè esegui il file /root/update-web.sh al minuto 0, ora 8 (UTC), ogni domenica mattina)
poi salva ed esci (se stai usando nano):
Ctrl + Oper salvare.Enterper confermare.Ctrl + Xper uscire.
poi posso eseguire cat /var/log/discourse-update.log quando mi sveglio la domenica mattina per controllare se è stato eseguito correttamente. Se utilizzi un pianificatore di attività cron, vorrai lasciare la route della pagina Worker.
Credo che sia tutto. Fammi sapere se hai domande lol. È molto più semplice di quanto sembri lol. 
Wow! Apprezzo davvero molto questa guida dettagliata! 
Ho appena salvato la tua risposta nei miei appunti, così quando installerò di nuovo Discourse a breve, potrò tornarci. Ti farò sicuramente sapere come è andata, anche se ci vorrà un po’ prima che lo installi. Al momento sto finendo alcune cose di programmazione e solo allora mi concentrerò di nuovo su Discourse.
E sono d’accordo sul fatto che la pagina “web serve is down” sia brutta, e per gli utenti inesperti quel messaggio non significa molto. Avere una semplice pagina di manutenzione con un messaggio personalizzato è sempre preferibile, anche se richiede un po’ di lavoro per la configurazione.
Ancora una volta, grazie tantissimo per aver dedicato tempo a condividere questo. Spero che altre persone lo troveranno utile 
ed è proprio qui il problema.
Non si tratta di una modifica semplice, né di infrastruttura aggiuntiva di cui preoccuparsi e mantenere, e a mio parere non ne vale assolutamente la pena per pochi secondi di downtime.
Capisco cosa intendi, ma quello è solo un caso. E se qualcosa si rompe davvero e devo sistemarlo, impiegando più di qualche secondo?
Inoltre, come fai a ottenere qualche secondo di downtime, mentre io ne vedevo circa 20, dopo aver installato i plugin?
Perché nella configurazione a due container (linkata in entrambi i nostri post e dipendenza non negoziabile) avvii il nuovo build usando ./launcher bootstrap web_only (durante il quale il tuo sito rimane al 100% funzionante), poi semplicemente distruggi e avvi immediatamente il nuovo container già costruito (il che richiede pochi secondi).
Ah, ok, questo vale ancora per la configurazione con 2 container. Pensavo che tu dicessi che non ne valesse la pena costruire completamente la configurazione con 2 container. Quello che stai dicendo non ne vale la pena è solo il lavoro extra della pagina di manutenzione, giusto?
Personalmente sì.
Se desideri una soluzione a doppio livello per gli utenti web che accedono con una navigazione nuova durante i primi 30-60 secondi, allora una pagina di manutenzione è ragionevole.
Dovrai valutare i vantaggi di questa scelta rispetto al tempo necessario per mantenere l’infrastruttura ad essa correlata.
Ora ho capito. Grazie.
Quindi ora chiedo: con 2 contenitori, quei 20 minuti circa sono ancora una realtà, l’unica differenza è che posso farli eseguire su uno dei contenitori, quello non in produzione, e quando è pronto, fare il cambio. È così che funziona?
Sì, ci vuole ancora un po’ di tempo per costruire il container e, per tua informazione, devi assicurarti che il tuo server sia abbastanza potente da permettere che questo processo avvenga in parallelo mentre serve la tua comunità come al solito (fondamentalmente, la cosa più importante è garantire abbastanza memoria per iniziare, quindi è molto importante assicurarsi di avere abbastanza SWAP). La costruzione utilizzerà anche almeno un core, quindi pensa di avere un server con 1 o 2 core in più.
e sembra essere un server meno performante…?Consiglierei almeno 4 GB e 3 core (“vcpu”) per questo tipo di configurazione …
Per riferimento, poiché è stato chiesto in un altro argomento, la (modifica: errata) risposta: Any cheaper alternatives to Hetzner? - #2 by Canapin
Questo è l’unico che corrisponde… che differenza di prezzo…
Immagino che dovrò costruirlo con un singolo container per ora e, quando le condizioni (
) lo permetteranno, fare l’upgrade.
Grazie per le informazioni, Robert!
Non sono d’accordo e penso che valga la pena della pagina di manutenzione. Per la mia esperienza, quando le persone vedono la pagina di errore di Discourse, la prima cosa che fanno è premere aggiorna e poi vedranno la breve pagina di manutenzione che ricaricherà automaticamente il sito quando lo scambio di contenitori sarà completo. Non è molto lavoro da configurare e devi farlo solo una volta. Durante una ricostruzione con la configurazione a doppio contenitore, la parte di bootstrap avviene in background e gli utenti possono ancora usare il sito; è lo scambio di contenitori che causa il breve downtime (a differenza di una configurazione standard a singolo contenitore).
Il costo del server e la selezione sono una cosa completamente diversa e dovrebbero essere in un altro argomento separato.
Immagino di essere in una posizione intermedia al momento. Capisco cosa intendi, così come @merefield. È un bel tocco averlo, e se si configura solo una volta, non credo sia un grosso problema, giusto?
Allo stesso tempo, se effettivamente impiega fino a 60 secondi nel peggiore dei casi, non tutti visiteranno il sito esattamente al secondo zero e dovranno aspettare 60 secondi. Alcune persone vedranno la brutta pagina per 5 secondi, altre per 20, altre per 60. Alcune persone non la vedranno nemmeno (credo?), ad esempio se stanno solo leggendo una risposta o scrivendone una, il passaggio potrebbe avvenire prima che premiano INVIA o prima che smettano di leggere l’argomento e premanno RISPONDI (o visitano un’altra pagina).
Il mio problema con la configurazione nginx era più legato alla questione dei 20 minuti in un setup con un singolo contenitore. Con l’opzione di avere 2 contenitori e passare da 20 minuti a forse 60 secondi al massimo, mi chiedo se sia davvero rilevante? Soprattutto, se sono in grado di aggiungere un annuncio in alto che dice quando il sito sarà offline per pochi secondi, in un momento di basso traffico, non sarà un grosso problema?
Devo sedermi e pensarci su. La configurazione con 2 contenitori sarà sicuramente qualcosa da implementare, se trovo un buon affare per il server.
Puoi chiarire questo punto in modo che una persona alle prime armi come me possa capirlo? Non sono ancora molto familiare con i worker…
Perché aggiungi e rimuovi la pagina del route dei worker, se lasciarla attiva non è un problema? Quindi, se aggiungo la pagina di manutenzione, posso davvero configurarla una volta sola e, da quel momento in poi, posso semplicemente connettermi al mio server via SSH usando il Terminale e fare tutto lì come faccio con un singolo container, senza mai dover accedere a Cloudflare?
@merefield ha menzionato che anche questo (pagina di manutenzione, worker, ecc.) richiede manutenzione, quindi mi chiedo se sia davvero qualcosa che configuri e dimentichi, o se ci sia qualcosa da fare ogni tanto?