@pfaffman Se dai un’occhiata alle modifiche che ho apportato, non ho modificato le istruzioni del template web in discourse_docker, le ho semplicemente separate in 3 file. In realtà, questo è l’unico cambiamento che ho richiesto: uno di questi esegue istruzioni indipendenti dall’ambiente, come l’installazione dei gem di Ruby, dei repository di Discourse e dei plugin, e così via; un altro esegue alcune validazioni; il terzo si occupa di operazioni specifiche per l’ambiente, come l’esecuzione delle migrazioni del database e la precompilazione delle risorse.
La complessità che, secondo me, questo introduce è che quando viene aggiunto qualcosa a questi file, il team di Discourse deve valutare se tali operazioni siano o meno specifiche per l’ambiente (ad esempio, se dipendono da dati nel database) e, in base a ciò, definire in quale file includerli.
L’installazione ufficiale funzionerebbe esattamente come ora, tranne per il fatto che includerebbe i 3 template nel file app.yml (o farebbe sì che il file templates/web.template.yml includa questi 3, se possibile, e in questo caso, dal punto di vista dell’utente, nulla cambierebbe), invece di procedere in più di un passaggio (non avrebbe i vantaggi dell’installazione in due passaggi, ma funzionerebbe esattamente come viene fatto attualmente, quindi nessun cambiamento dirompente).
So che le attività di sysadmin possono essere davvero complesse, ma ho cercato di implementarle nel modo più diretto possibile, tenendo conto di come vengono svolte attualmente, per evitare troppa complessità (ecco perché non ho menzionato k8s, la separazione dei servizi in un file docker-compose o cose simili, poiché richiederebbero cambiamenti significativi; mi sono invece basato su come viene fatto nell’installazione ufficiale).