Grazie-- quindi ./launcher rebuild web_only (o rebuild data) invece di ./launcher rebuild app, e dovrei leggere attentamente gli aggiornamenti per vedere quando postgres o redis vengono aggiornati per aggiornarli manualmente. E il vantaggio principale rispetto a standalone è che i rebuild non devono aspettare che il database si spenga e poi si riavvii, annullando le transazioni se venisse interrotto.
Ma con le ultime modifiche di Falco, il DB non dovrebbe mai essere interrotto a meno che non impieghi più di 10 minuti per spegnersi, cosa che certamente non farà a meno che non otteniamo un numero di utenti enormemente maggiore. Quindi gli aggiornamenti non falliranno a causa di quel problema, e l’impatto principale è solo quello di rendere gli aggiornamenti un paio di minuti più lunghi.
La mia interpretazione è che alla fine la modifica aggiunge un sacco di complessità e overhead mentale per guadagni davvero molto piccoli. Per favore, correggimi se sbaglio, non intendo essere sarcastico/ecc.
Solo per dare un po’ di contesto, la modifica dovrebbe offrire benefici sostanziali per valere quell’overhead perché tutto questo è un favore non retribuito da parte mia (uno che ora si estende da oltre 15 anni, ma comunque), non è il mio lavoro. Lì la situazione è decisamente soggettiva.
Molte persone condividono quell’opinione, cosa che continuo a trovare sorprendente. Gli aggiornamenti di Postgres avvengono meno di una volta all’anno e di solito non c’è penalità per ritardarli di mesi dopo la modifica iniziale. Avere una configurazione a 2 container significa che puoi ritardare l’aggiornamento di postgres più facilmente rispetto a un singolo container, il che mi sembra un altro vantaggio.
Ritardare gli aggiornamenti di postgres ha storicamente significato una semplice modifica del file yaml di configurazione, a meno che non abbiate in programma di smettere di supportarlo. Possiamo gestire qualche minuto in più di inattività per gli aggiornamenti e, ai miei occhi, ciò comporta meno rischi rispetto a fare affidamento su una persona (cioè io!) per mantenere correttamente una configurazione meno standard e più complessa.
Dal mio punto di vista, il principale vantaggio di due container è la riduzione dei tempi di inattività: come te, penso che vada bene avere 20-30 minuti di inattività ogni paio di mesi. Ma è facile capire che per alcuni forum sia troppo.
Assolutamente. Anche se stessimo parlando di 90 minuti di inattività standalone rispetto a 5 minuti separati, probabilmente non riterrei il cambiamento degno di nota, anche se probabilmente farei gli aggiornamenti a tarda notte piuttosto che comodamente nel bel mezzo della giornata se ci volesse così tanto tempo. Non siamo una piattaforma di trading azionario in tempo reale, siamo un forum gratuito sui videogiochi.
Con la configurazione a 2 container, significa che non è nemmeno necessario sapere di apportare tale semplice modifica. E ci sarebbe zero possibilità che tu iniziassi un aggiornamento e poi scoprissi di aver già iniziato ad aggiornare postgres.
Ma ho passato quasi 35 anni a vivere in una shell.
E ora ho una dashboard che automatizza quegli aggiornamenti da riga di comando (e gestisce gli aggiornamenti di postgres e un sacco di altre cose).
Ma non riparare ciò che non è rotto, e capisco che spostare le cose e potenzialmente rompere le cose sia spaventoso.
Ho iniziato con Slackware anch’io, semplicemente non vedo la manutenzione del forum come un progetto divertente e voglio che scompaia così posso continuare a sbattere la testa contro il muro cercando di integrare Google Home con Home Assistant (o qualsiasi altra cosa mi passi per la testa quella settimana).