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 contenitori duali dietro il CDN di Cloudflare. La configurazione a contenitori duali 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 di default del server web è brutta e non dà alcun indizio su quanto tempo rimarrà offline.
La documentazione per fare questo è ora disponibile qui:
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?