Penso proprio di sì 
Attendi che questa PR venga unita, quindi segui i passaggi elencati:
Circa 100 GB 
lo farò
Quindi, mentre penso a come automatizzare questo aggiornamento, mi rendo conto che sapere quando eseguire questo passaggio di post-deploy è piuttosto complicato.
Per le installazioni con un solo container, a meno che non ci sia una migrazione bizzarra (questa è la prima di cui sono a conoscenza nei miei 4 anni), non c’è alcun vantaggio a procedere in questo modo. La maggior parte degli aggiornamenti prevede poche migrazioni, e probabilmente nessuna che sia intensiva dal punto di vista computazionale.
Per le installazioni con due container, è sempre una buona idea impostare SKIP_POST_DEPLOYMENT_MIGRATIONS, poiché è possibile disabilitare il sito se le migrazioni rompono il container in esecuzione, il che riduce parte del vantaggio della possibilità di avviare il nuovo container mentre quello vecchio continua a funzionare. MA anche in questo caso, non ogni aggiornamento include migrazioni che causano problemi, quindi la soluzione con due riavvii fornita da questo commit (molto gradito) probabilmente comporterà più tempi di inattività (due cicli di riavvio) rispetto al semplice operare “sull’orlo del baratro”.
Il mio pensiero attuale è che una soluzione migliore sarebbe quella di far sì che il bootstrap esegua sempre le migrazioni con SKIP_POST_DEPLOYMENT_MIGRATIONS=1 e poi esegua una migrazione al primo avvio. Tuttavia, non ho ancora una soluzione elegante per far funzionare esattamente questo. Esiste un modo rapido per capire se ci sono migrazioni in sospeso? Immagino che lo script di avvio potrebbe includere qualcosa come “se ci sono migrazioni in sospeso, eseguine una” subito dopo aver avviato unicorn? Questo è però piuttosto macchinoso e probabilmente non vale la pena per la maggior parte delle installazioni nella maggior parte dei casi.
Di sicuro non vale la pena farlo nella maggior parte dei casi, ma se gli aggiornamenti del tuo software raramente (ma a volte) richiedono 10 volte più tempo del normale, questo rappresenta un vero problema per molti utenti.
Da ora in poi non eseguirò gli aggiornamenti di Discourse fino a almeno una settimana dopo il rilascio. Certo, potresti obiettare che sono uno sprovveduto per non aver aspettato fin dall’inizio, me lo sono cercato, avrei dovuto saperlo meglio, e tutto ciò è assolutamente corretto! Tuttavia, rendere i tempi di aggiornamento più coerenti e prevedibili sarebbe un grande servizio per tutti gli altri sprovveduti là fuori.
In alternativa, l’aggiornamento tramite l’interfaccia utente di docker_manager gestisce tutto automaticamente.
Che fantastico! Virtualmente non aggiorno mai in quel modo, quindi non ci avrei mai pensato. Grazie.
Scusa, per essere chiari: se aggiungiamo questa variabile d’ambiente al nostro contenitore dell’applicazione:
O:
SKIP_POST_DEPLOYMENT_MIGRATIONS: true
o
SKIP_POST_DEPLOYMENT_MIGRATIONS: 1
quando eseguiamo il launcher, verranno saltate tutte le migrazioni del database quando ricostruiamo?
È questa la corretta interpretazione?
Non esattamente. Vedi Introducing Post Deployment Migration
Ciao, sono riuscito ad aggiornare tutto con questo metodo (cioè tramite l’interfaccia utente), ma dopo inizia a eseguire questa procedura di deployment con le istruzioni di migrazione (quella che era stata saltata dall’inizio) e così via, e dopo un po’ si blocca, segnalando che l’aggiornamento non è riuscito. Tuttavia, il forum funziona correttamente e la dashboard dell’amministratore mostra tutto come aggiornato.
La mia domanda è: devo fare altro? In particolare, per quanto riguarda questa procedura di deployment, devo eseguirla da riga di comando (per evitare il crash)? Ci sono comandi specifici per questo e il forum si blocca mentre viene eseguita?
Hai ancora i log pertinenti? Devi eseguire le migrazioni, altrimenti la ricerca sul sito non funzionerà.
./launcher enter app
bundle exec rails db:migrate
Nessun log, ma erano le stesse query menzionate prima in questo argomento.
Prima di avviare questo processo e lasciarlo in esecuzione, questo interromperà temporaneamente il sito web (come una ricostruzione) o è “sicuro”? Scusa per insistere su questo punto specifico, ma si tratta di un sito web in produzione e un’interruzione di 10-15 minuti è accettabile, mentre un giorno o due non lo è e deve essere attentamente valutato se non ci sono altre opzioni disponibili.
Se hai già aggiornato all’ultima versione, l’esecuzione delle migrazioni non comporterà alcun downtime per il tuo sito. Per ‘aggiornato’ intendo che la nuova versione è stata distribuita, ma la migrazione post-distribuzione descritta in questo argomento non è riuscita.
Grazie. Alla fine sono tornato agli aggiornamenti tramite l’interfaccia, ho provato ancora una volta e le migrazioni del database post-distribuzione sono effettivamente andate a buon fine. Ci sono volute diverse ore (e un sacco di CPU 
), ma sono state completate e ora tutto è completamente aggiornato! 