D’accordo, le istruzioni potrebbero necessitare di una modifica. Sembra strano che la parte dei dati non funzioni più.
Un fermo più lungo ogni anno o giù di lì non è poi così male…
No, nessun problema tranne quelli che ho creato con la mia errata modifica di web_only.yml con la configurazione esistente di app.yml. 
Sono lieto di riferire che ora sembra funzionare per questa configurazione a due container!
L’unico problema che rimane è il testo del sito utilizzato per dirti come ricostruire dalla cli (“app”), ma è una cosa molto piccola.
cc: @pfaffman
sì. è codificato in modo fisso. Se non riesci a ricordarlo, dovrai personalizzare il testo. 
5 messaggi sono stati spostati in un nuovo argomento: Build fails due to ruby version mismatch
Questo non potrà mai funzionare. Scusa se me ne sono accorto solo ora. Ho aggiornato l’OP. Se hai bisogno di ricostruire i dati, devi
./launcher stop web_only; ./launcher rebuild data && ./launcher rebuild web_only
No. È esattamente ciò che è previsto. Non puoi ricostruire postgres mentre un altro postgres sta accedendo ai file. Se viene creato un nuovo container di dati, devi distruggere e avviare un nuovo container web_only perché docker in qualche modo si collega al container esatto anziché a un qualche riferimento a quello chiamato data.
Grazie per le modifiche OP 
e per l’aiuto in Build fails due to ruby version mismatch
Sto impazzendo o lo script discourse-install non contiene più l’argomento --two-container? L’ho eseguito direttamente dalla posizione consigliata (https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse) su una nuova VPS Ubuntu 24.04 su Hetzner e ha semplicemente installato una configurazione standard a contenitore singolo con un file app.yml. Pensavo che forse dovessi eseguire lo script discourse-setup che ne deriva, ma anche quello ha fatto la stessa cosa.
Usa il metodo di installazione manuale e ./discourse-setup --two-container Ha funzionato bene l’ultima volta che l’ho usato.
Oppure installa usando lo script di installazione intelligente e poi converti in due container come fatto riferimento nell’OP (Original Poster - Post originale)
@Falco e @pmusaraj Pensate che sarebbe utile se alcune parti del vecchio INSTALL-cloud.md fossero conservate da qualche parte e referenziate nell’attuale INSTALL-cloud.md
È stato effettivamente rimosso, ho rimosso il riferimento dalla wiki sopra.
Grazie per l’informazione. Perché è stato rimosso? Era un metodo molto utile.
Due installazioni tramite container realizzate da persone non profondamente familiari con Docker hanno generato un carico di supporto eccessivo. È una configurazione di installazione avanzata, che dovrebbe essere riservata a persone che sanno come procedere.
Quindi stai rendendo le cose difficili per coloro di noi che utilizzano quella funzione. Avete chiesto a qualcuno del cambiamento in anticipo? Sembra che avreste potuto lasciarla in vigore dato che si può usare il metodo OP erroneamente e creare comunque alcuni problemi a sé stessi.
Onere per chi? In questa discussione? Il supporto è stato fornito da volontari/utenti, non tanto dal Team.
Quindi lascerai web_only e data in samples e le persone che vogliono usare due container dovranno copiarli e configurarli manualmente? L’unico supporto extra richiesto prima era aiutare le persone che non si sono mai preoccupate di aggiornare il container dei dati.
Ora dovremo dire a un sacco di persone come usare cp e nano. Si potrebbe sostenere che se non conosci cp e nano, non dovresti eseguire una configurazione a due container. Jeff sosteneva che se non conosci cp e nano, non dovresti installare Discourse, ma sono riuscito a fargli cambiare idea quando ho scritto discourse-setup.
Nel prossimo periodo riscriverò il mio dashboard.literatecomputing.com per smettere di fare installazioni standard (poiché non può più inviare risposte a discourse-setup) e continuerò a rendere l’installazione a 2 container un’opzione lì.
Non mi piace. Questo sembra un passo avanti verso l’abbandono del supporto per i due contenitori in generale e sarebbe un vero peccato.
E questo è ciò che è fantastico nell’open source; le persone hanno la scelta di scegliere la propria avventura!
Decine di persone che eseguono container obsoleti completamente dimenticati non è un bene e ha causato molta confusione ogni volta che PostgreSQL necessitava di un aggiornamento importante, il che a sua volta ha reso il nostro PostgreSQL meno frequente, peggiorando il prodotto complessivo.
Sono d’accordo 
Non è possibile eliminare completamente il supporto per le installazioni a due (o N) container; Discourse si connette nativamente a database esterni, come documentato in Configure Discourse to use a separate PostgreSQL server.
Nessuna flessibilità è stata rimossa, ma analogamente a The Power of Defaults, ogni opzione negli strumenti che creiamo diventa qualcosa di cui tenere conto.
Rimuovere migliaia di righe di script e semplificare l’installer per coprire il caso d’uso molto più comune è stata una scelta consapevole, ma Discourse supporta ancora tutti gli stessi casi d’uso, e le persone sono libere di percorrere la propria strada se scelgono di farlo.
Grazie per la rassicurazione che questa modalità di produzione continuerà a funzionare senza livelli significativi di personalizzazione 
La comodità per coloro che utilizzano il metodo rimosso è stata sacrificata a favore di forzare un percorso per tutti. Questa è stata una decisione di uno o sono stati coinvolti altri?
Da codinghorror
"Le impostazioni predefinite sono probabilmente le decisioni di progettazione più importanti che prenderai mai come sviluppatore di software. Scegli buone impostazioni predefinite e gli utenti loderanno il tuo software e quanto sia facile da usare. Scegli impostazioni predefinite scadenti e dovrai affrontare l'angoscia degli utenti riguardo alla configurazione, e probabilmente anche una serie di chiamate al supporto tecnico."
Secondo me sono state scelte impostazioni predefinite scadenti e la scelta/modifica è stata fatta senza il coinvolgimento, la discussione o la considerazione della classe di utenti che lamentano il cambiamento.
Chiedo di nuovo, una scelta consapevole da parte di chi?
Questo utente percepisce quel commento come arroganza e mancanza di rispetto. Sembra come ci si potrebbe sentire se si viene guardati dall’alto in basso e ignorati. Dubito che l’intento fosse quello di causare una reazione del genere, ma eccoci qui.
Nel complesso, questo episodio è coerente con ciò di cui mi lamentavo in un messaggio privato con @nat alcune settimane fa. CDCK/Meta ha due classi di clienti diseguali, quelli che pagano per l’hosting e quelli che si auto-ospitano. L’approccio in questo episodio è l’esempio più recente e forse più eclatante di questo sistema a due classi.
Detto tutto questo…
Applaudo il nuovo installer. Fa un buon lavoro nel gestire i problemi di installazione e le conseguenti richieste di supporto fin dal primo giorno.
Per quanto riguarda il cambiamento, CDCK ha il diritto di costruire/modificare come meglio crede. Nessuna obiezione su questo. La mia speranza è che possano farlo in un modo che non alieni le persone.
Infine, rileggere il post di codinghorror mi ha fatto pensare a come spesso andavano le cose quando Jeff era coinvolto in un post. I suoi post spesso sapevano di noncuranza, mancanza di rispetto e lieve arroganza. Fortunatamente non sono mai stato l’obiettivo diretto di ciò, ma alcuni di quei post erano dolorosi da leggere. La mia recente interazione con lo staff riguardo a come è stato gestito un post e questo episodio mi sembrano molto simili. Forse sono solo io.
Mi sembra un po’ duro. Il team aiuta gli auto-ospitanti ogni giorno su questo forum, anche quelli che rientrano in unsupported-install 