@Stephen C’è un difetto nel tuo ragionamento: la descrizione dei container multipli è piena di avvertimenti secondo cui devi assumerti la responsabilità degli aggiornamenti e capire come funziona, e la lunga descrizione sopra è così oscurata che probabilmente chiunque la guardasse si arrenderebbe comunque. Vai a leggere il mio Migrate quickly to separate web and data containers e dimmi che non spaventerà le persone che avranno difficoltà a seguirlo, o che non mette in risalto la necessità di eseguire il backup e la possibilità di tornare a un backup se qualcosa va storto!
Ero profondamente infelice quando ho eseguito ./launcher rebuild app poco dopo aver migrato su un server più performante (per una correzione di sicurezza) e aver avuto il mio sito fuori servizio per un tempo eccessivamente lungo, gran parte del quale dedicato alla ricostruzione delle parti di postgres del container. È stato allora che ho trovato la documentazione a 2 container e questa documentazione e non volevo assolutamente subire un altro periodo di inattività di 4 ore per la migrazione, quindi ho continuato ad accettare lunghi tempi di inattività per ./launcher rebuild app per evitare le 4 ore di downtime che richiederebbe un ripristino. Come persona vagamente competente, sono stato molto infastidito per lungo tempo dal fatto che questa configurazione fosse di fatto nascosta.
L’argomento su postgres 12 è un ottimo riferimento, perché le persone finiscono per avere più tempo di inattività perché devono ricostruire l’intera applicazione più volte, quando potrebbero ricostruire solo il container postgres due volte. Non posso dire di aver letto l’intero thread a causa della cancellazione automatica dopo 6 giorni, ma non mi risulta affatto evidente che i deploy multi-container incompetenti siano il, o anche solo un, grosso problema lì.
(Scusa, a volte mi stanco un po’ dell’idea che “tutti gli utenti siano incompetenti” qui.)