Ho aggiornato i miei siti da 3.1.0.beta1 a 3.1.0.beta2, e dopo il bootstrap della nuova versione, ma prima di distruggere i vecchi container dell’app e avviarne di nuovi, almeno uno di quei siti ha iniziato a mostrare la pagina di errore generica agli utenti.
Non l’ho notato sul mio sito di test o sugli altri siti che gestisco, ma è possibile che sia successo e io non l’abbia visto.
In ogni caso, per me, almeno in un caso, il processo di aggiornamento “zero downtime” non è riuscito.
9 messaggi sono stati divisi in un nuovo argomento: Problemi con l’aggiornamento self-hosted a 3.x: impossibile eseguire il rollback
Un post è stato unito a un argomento esistente: Problemi con l’aggiornamento self-hosted a 3.x: impossibile eseguire il rollback
Vorrei ripetere che non stavo usando l’aggiornamento GUI. Ho un’installazione multi-container. Ho fatto:
git pull
./launcher bootstrap app
./launcher destroy app && ./launcher start app
./launcher cleanup
(Uso app per l’app web anche per installazioni multi-container. So che non è la pratica normale. Odio digitare web_only)
Qualche tempo dopo aver avviato bootstrap e prima di distruggere l’app, la vecchia versione in esecuzione contro il nuovo database ha mostrato solo una schermata di errore. Non ricordo il contenuto e non ho creato un’interruzione più lunga fermandomi a fare uno screenshot prima di distruggere/avviare, ma era solo testo su bianco e non la pagina di manutenzione del sistema. Ho visto questo solo poche volte prima, che quando bootstrap esegue db:migrate come parte della ricostruzione asincrona “zero-downtime”, il vecchio software ancora in esecuzione fallisce a causa di un’incoerenza dello schema.
Quello che ho visto è stato qualunque cosa accada in caso di incoerenza del database. È molto meglio che procedere beatamente, rompendo il database! Quando ho postato, era per avvertire che questo era uno di quei rari casi in cui l’applicazione di un aggiornamento puntuale (qui da 3.1.0.beta1 a 3.1.0.beta2) ha creato un’incompatibilità di schema tra il codice 3.1.0.beta1 e il database dopo aver eseguito il db:migrate di 3.1.0.beta2, come accade raramente ma occasionalmente con i normali aggiornamenti a bassa interruzione nel deployment multi-container.
La mia esperienza è diversa dall’errore segnalato con ruby nell’aggiornamento GUI. È un problema completamente non correlato. Riconosco che il mio post è stato spostato dall’annuncio a una discussione generale “problemi con”, ma voglio essere chiaro che il motivo per cui l’ho postato nell’annuncio era per avvertire altri self-hoster come me quando hanno visto l’annuncio che questo particolare aggiornamento era uno che poteva avere questo impatto.
Il mio messaggio non si lamentava di un bug, o anche di un problema. Era inteso solo come avviso di un caso normale ma infrequente associato a questa particolare release e non evidenziato nelle note di rilascio.
Le lamentele sul fatto che il gestore docker non riconosca di non poter aggiornare dall’interno dell’immagine sono completamente estranee al mio tentativo di fornire una notifica utile ad altri amministratori self-hosting.
Sarebbe molto sensato separare questi problemi non correlati in thread indipendenti per problemi indipendenti. EDIT di @supermathie: Fatto
Stai eseguendo una migrazione in due fasi con Introducing Post Deployment Migration?
Questo pattern è fondamentale se stai eseguendo, ad esempio, un blue/green deployment e hai bisogno che la versione precedente continui a funzionare.
Penso che questo risponda alla domanda. Lo script launcher non ha supporto per SKIP_POST_DEPLOYMENT_MIGRATIONS
Di nuovo, NON sto segnalando un bug. Sto solo cercando di avvisare altri con l’installazione standard multi-container utilizzando il normale processo documentato per l’uso di launcher con un’installazione multi-container che questa è diversa dalla loro esperienza tipica.
Davvero, veramente, onestamente, lo intendo, questo non è un bug report!
Se voglio il blue/green deployment con launcher dovrei fornire una PR per launcher per implementarlo. 
Non ho ideato il “problema” nel titolo dell’argomento; è stato creato quando il mio commento è stato spostato fuori dal thread dell’annuncio. Ho ora modificato il titolo per chiarire, spero, che non mi sto lamentando di un problema.
Tutto bene!
Sospetto che ci sia un numero molto esiguo di utenti che utilizzano il blue/green multi-container, ma saremmo lieti di ricevere suggerimenti su come farlo.
E anche su come trovare l’argomento che ho linkato; sospetto che non sia facile da trovare se non si sa già che esiste.
Avevo visto la documentazione SKIP_POST_DEPLOYMENT_MIGRATIONS. Quello che mi era davvero sfuggito era questo post che mostra come eseguire deploy senza downtime con launcher:
Quindi ora devo pensarci, ora che so che è fattibile. Se lo farò, aggiornerò MKJ's Opinionated Discourse Deployment Configuration con quello che farò.
Ho avuto molti problemi a preoccuparmene quando fornisco quattro, alcuni mesi quattro e mezzo nove di disponibilità su un servizio che gestisco gratuitamente nel mio tempo libero. È una testimonianza della qualità dello sviluppo di Discourse che posso farlo con una politica di superamento dei test, incluse cose come il minuto in più circa di downtime che ho visto questa volta, e talvolta il riavvio dell’host per gli aggiornamenti di sicurezza.
Lo script ansible che dashboard.literatecomputing.com utilizza esegue un’attività rake dopo che il nuovo container è stato avviato per eseguire le migrazioni post-deployment. Conta sull’attivazione di SKIP_POST_DEPLOYMENT_MIGRATIONS in web_only.yml. Lo faccio solo sui siti che so saranno gestiti dai miei script, poiché se non capisci come funziona, è una bomba a orologeria.
Nota che per molti aggiornamenti, l’avvio del nuovo container non interromperà le cose per il container in esecuzione, ma per alcuni sì. Non è raro che un aggiornamento esegua una migrazione tale che il vecchio container non possa utilizzare il database (senza utilizzare SKIP_POST_DEPLOYMENT_MIGRATIONS).