Avevo un sito di grandi dimensioni che falliva ripetutamente durante l’avvio. Si tratta di un’installazione a due container, quindi il container vecchio continuava a funzionare mentre avveniva la migrazione durante il bootstrap. Alla fine ho risolto il problema attivando SKIP_POST_DEPLOYMENT_MIGRATIONS=1 per il bootstrap e poi eseguendo le migrazioni dopo che il nuovo container era stato avviato. Con SKIP_POST_DEPLOYMENT_MIGRATIONS=1 nella sezione ENV, la migrazione è stata molto rapida; il sito ha quindi potuto funzionare normalmente (sebbene forse più lentamente) mentre le migrazioni venivano eseguite, il che ha richiesto, credo, oltre 20 minuti.
Penso, anche se non l’ho ancora testato, che utilizzare lo stesso trucco possa funzionare per minimizzare i tempi di inattività anche durante un’installazione a singolo container. Se ho ragione, quello che dovresti fare è:
- aggiungere
SKIP_POST_DEPLOYMENT_MIGRATIONS=1al tuoapp.yml - ./launcher rebuild app
- ./launcher enter app
- SKIP_POST_DEPLOYMENT_MIGRATIONS=0 rake db:migrate
- annullare la modifica in
app.yml, a meno che tu non intenda ricordare di eseguire le migrazioni dopo ogni aggiornamento - forse eseguire di nuovo il rebuild per assicurarti di non avere problemi mentre ricordi ancora cosa potrebbe aver rotto il tuo sito; tra 4 mesi, quando riproverai, non avrai idea di cosa sia successo e sarà difficile per chiunque indovinare qual era il problema
Se esistesse un modo per far sì che ./launcher passi SKIP_POST_DEPLOYMENT_MIGRATIONS=1 senza richiedere una modifica al file app.yml, renderebbe tutto meno macchinoso per chi ha difficoltà con l’editing.
Se riesco a portare a termine il lavoro su questo argomento, come penso farò, creerò un nuovo topic per riportare ciò che ho scoperto. Anche se il fumo mi ha costretto a rinchiudermi in una stanza dove non ho il mio grande monitor. (Non bastava la pandemia?! Dobbiamo avere anche il fumo? E non sono nemmeno particolarmente vicino al dannato incendio.)