Ma in questo caso, il passaggio di bootstrap deve essere eseguito sulla macchina di produzione, il che vanifica in un certo senso lo scopo di spingere un’immagine base su un registry di container, se non sbaglio (poiché ciò verrebbe fatto con l’intenzione di non dover eseguire il bootstrap di un’immagine in produzione, tranne forse per eseguire un passaggio di migrazione del database o qualcosa di simile).
Questo è ciò che faccio nei siti non Discourse che ospito: normalmente uso Flyway per eseguire le migrazioni nel database, insieme ad altre operazioni come svuotare la cache Redis, ma senza eseguire altri processi intensivi, specialmente quelli che dipendono da servizi esterni, come l’aggiornamento dei certificati HTTPS (lo farei in un cronjob, tranne la prima volta, il che va bene) o la modifica del codice sorgente (questo sarebbe statico nell’immagine, come pacchetti, librerie e altro). Sembra che Discourse utilizzi Rake, il che va bene, ma esegue anche altre operazioni come l’installazione di gem, la generazione di asset, l’aggiornamento del database MaxMind e forse altri servizi (il che potrebbe interrompere il passaggio di rebuild se, ad esempio, il servizio è offline o se modificano l’API, cosa rara ma possibile).
Non sto dicendo che Discourse dovrebbe fare in quel modo, ovviamente, ma generare un’immagine in un ambiente CI ed eseguire semplicemente un passaggio di migrazione del database sui server di staging/produzione, definendo anche le variabili d’ambiente, è ciò che mi aspetterei ed è facilmente realizzabile con altri software come WordPress, MediaWiki, Rocket.Chat, ecc. Discourse è il miglior software per forum, a mio avviso, e potrebbero avere buone ragioni per procedere come fanno, ma per ora utilizzerei solo l’installazione standard (o l’installazione multicontainer) per evitare mal di testa e sperare semplicemente che nulla vada storto durante i rebuild.
Sembra che il bootstrap debba comunque essere eseguito in un ambiente di produzione e non in un ambiente CI per generare un’immagine base da utilizzare sia in staging che in produzione. Inoltre, non essere un’installazione standard è un enorme campanello d’allarme, che potrebbe diventare un mal di testa in futuro man mano che il software riceve aggiornamenti.