Concordo, as instruções poderiam usar um ajuste. Parece estranho que a parte de dados não funcione mais.
Um tempo de inatividade mais longo a cada ano ou mais não é tão ruim…
Não, nenhum problema, exceto aqueles que criei com minha edição errônea do web_only.yml com a configuração existente do app.yml. 
Feliz em relatar que isso agora parece estar funcionando para esta configuração de dois contêineres!
O único problema que resta é o texto do site usado para dizer como reconstruir a partir da CLI (“app”), mas isso é uma coisa muito pequena.
cc: @pfaffman
sim. isso é codificado. Se você não conseguir se lembrar, precisará personalizar o texto. 
5 publicações foram movidas para um novo tópico: Falha na compilação devido a incompatibilidade de versão do ruby
Isso nunca funcionará. Desculpe por não ter notado isso antes. Eu atualizei o OP. Se você precisar reconstruir os dados, então você precisa
./launcher stop web_only; ./launcher rebuild data && ./launcher rebuild web_only
Não. É exatamente isso que é esperado. Você não pode reconstruir o postgres enquanto outro postgres está acessando os arquivos. Se um novo contêiner de dados for criado, você precisa destruir e iniciar um novo contêiner web_only porque o docker de alguma forma se vincula ao contêiner exato em vez de alguma referência ao contêiner nomeado data.
Obrigado pelas edições do OP 
e pela ajuda em Build fails due to ruby version mismatch
Estou ficando louco ou o script discourse-install não contém mais o argumento --two-container? Eu o executei diretamente do local recomendado (https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse) em um VPS Ubuntu 24.04 novo na Hetzner e ele apenas instalou uma configuração regular de um contêiner com um app.yml. Pensei que talvez precisasse executar o discourse-setup que sai dele, mas isso apenas fez a mesma coisa novamente.
Use o método de instalação manual e ./discourse-setup --two-container Funcionou bem para mim da última vez que usei.
Ou instale usando o script de instalação bacana e depois converta para dois contêineres como referenciado no OP
@Falco e @pmusaraj Vocês acham que seria útil se partes do antigo INSTALL-cloud.md fossem mantidas em algum lugar e referenciadas no atual INSTALL-cloud.md
De fato foi removido, eu removi a referência da wiki acima.
Obrigado pela informação. Por que foi removido? Era um método muito útil.
Duas instalações de contêiner feitas por pessoas que não estão profundamente familiarizadas com o Docker geraram uma sobrecarga de suporte excessiva. É uma configuração de instalação avançada, que deve ser reservada para pessoas que sabem o que estão fazendo.
Então você está dificultando a vida daqueles de nós que usam esse recurso. Vocês perguntaram a alguém sobre a mudança com antecedência? Parece que vocês poderiam tê-lo mantido, dado que é possível usar o método OP incorretamente e ainda criar alguns problemas para si mesmo.
Fardo para quem? Neste tópico? O suporte tem sido fornecido por voluntários/usuários, e não tanto pela Equipe.
Então você deixará o web_only e o data em samples e as pessoas que quiserem usar dois contêineres terão que copiá-los e configurá-los manualmente? O único suporte extra que era necessário antes era ajudar as pessoas que nunca se deram ao trabalho de atualizar o contêiner de dados.
Agora precisaremos dizer a um monte de pessoas como usar cp e nano. Argumentavelmente, se você não sabe usar cp e nano, você não deveria rodar uma configuração de dois contêineres. Jeff argumentou que se você não sabe usar cp e nano, você não deveria instalar o Discourse, mas consegui mudar a opinião dele quando escrevi o discourse-setup.
No próximo período, reescreverei meu dashboard.literatecomputing.com para parar de fazer instalações padrão (já que não pode mais canalizar respostas para o discourse-setup) e continuarei a tornar a instalação de 2 contêineres uma opção lá.
Não sou um fã. Isso parece um passo mais perto de abandonar o suporte para dois contêineres no geral e isso seria uma grande pena.
E isso é o que é ótimo no código aberto; as pessoas têm a escolha de escolher sua própria aventura!
Dezenas de pessoas executando contêineres desatualizados completamente esquecidos não é ótimo e causou muita confusão toda vez que o PostgreSQL precisava de uma grande atualização, o que, por sua vez, fez com que nosso PostgreSQL acontecesse com menos frequência, piorando o produto geral.
Eu concordo 
Não é possível realmente abandonar o suporte para instalações de dois (ou N) contêineres; o Discourse se conecta nativamente a bancos de dados externos, como documentado em Configure Discourse to use a separate PostgreSQL server.
Nenhuma flexibilidade foi removida, mas análogo a The Power of Defaults, cada opção nas ferramentas que criamos se torna algo que precisa ser contabilizado.
Remover milhares de linhas de script e simplificar o instalador para cobrir o caso de uso muito mais comum foi uma escolha consciente, mas o Discourse ainda suporta todos os mesmos casos de uso, e as pessoas são livres para trilhar seu próprio caminho, se assim o desejarem.
Obrigado pela tranquilidade de que este modo de produção continuará a funcionar sem níveis significativos de personalização 
A conveniência para aqueles que usam o método removido foi sacrificada em favor de forçar um caminho para todos. Esta foi uma decisão de um só ou outros estiveram envolvidos?
De codinghorror
"Defaults are arguably the most important design decisions you’ll ever make as a software developer. Choose good defaults, and users will sing the praises of your software and how easy it is to use. Choose poor defaults, and you’ll face down user angst over configuration, and probably a host of tech support calls as well."
Na minha humilde opinião, foram escolhidos padrões ruins e a escolha/mudança foi feita sem o envolvimento, discussão ou consideração com a classe de usuários que lamenta a mudança.
Perguntando novamente, uma escolha consciente de quem?
Este usuário vivencia esse comentário como arrogância e desrespeito. Parece o que alguém sentiria se fosse olhado de cima e ignorado. Duvido que a intenção fosse causar tal reação, mas aqui estamos.
No geral, este episódio é consistente com o que eu estava reclamando em uma mensagem privada com @nat algumas semanas atrás. CDCK/Meta tem duas classes desiguais de clientes, aqueles que pagam pela hospedagem e o pessoal que auto-hospeda. A abordagem neste episódio é o exemplo mais recente e talvez mais flagrante deste sistema de duas classes.
Com tudo isso dito…
Eu aplaudo o novo instalador. Ele faz um bom trabalho ao lidar com problemas de instalação e as demandas de suporte resultantes desde o primeiro dia.
Quanto à mudança, a CDCK tem o direito de construir/mudar como achar melhor. Não há argumento contra isso. Minha esperança é que eles possam fazer isso de uma maneira que não afaste as pessoas.
Por último, a releitura da postagem de codinghorror me fez pensar em como as coisas costumavam ser quando Jeff se envolvia em uma postagem. Suas postagens muitas vezes cheiravam a desprezo, desrespeito e leve arrogância. Felizmente, eu nunca fui o foco direto disso, mas algumas dessas postagens eram dolorosas de ler. Minha interação recente com a equipe sobre como uma postagem foi tratada e este episódio parecem muito semelhantes. Talvez seja só eu.
Isso parece um pouco duro. A equipe ajuda os auto-hospedados todos os dias neste fórum, mesmo aqueles que se enquadram em unsupported-install 