De acuerdo, las instrucciones podrían necesitar un ajuste. Parece extraño que la parte de los datos ya no funcione.
Un tiempo de inactividad más largo cada año más o menos no está tan mal…
No, ningún problema excepto los que creé al editar erróneamente web_only.yml con la configuración existente de app.yml. 
¡Me complace informar que esto ahora parece estar funcionando para esta configuración de dos contenedores!
El único problema que queda es el texto del sitio utilizado para indicarte cómo reconstruir desde la cli (“app”), pero eso es algo muy pequeño.
cc: @pfaffman
sí. eso está codificado. Si no puedes recordarlo, tendrás que personalizar el texto. 
5 publicaciones se dividieron en un nuevo tema: Build fails due to ruby version mismatch
Eso nunca funcionará. Siento haberme perdido eso antes. Actualicé el OP. Si necesitas reconstruir los datos, entonces necesitas
./launcher stop web_only; ./launcher rebuild data && ./launcher rebuild web_only
No. Eso es exactamente lo que se espera. No puedes reconstruir postgres mientras otro postgres está accediendo a los archivos. Si se crea un nuevo contenedor de datos, debes destruir e iniciar un nuevo contenedor web_only porque docker de alguna manera se vincula al contenedor exacto en lugar de alguna referencia al llamado data.
Gracias por las ediciones del OP 
y la ayuda en Build fails due to ruby version mismatch
¿Me estoy volviendo loco o el script discourse-install ya no contiene el argumento --two-container? Lo ejecuté directamente desde la ubicación recomendada (https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse) en un VPS Ubuntu 24.04 recién instalado en Hetzner y simplemente instaló una configuración normal de un contenedor con un app.yml. Pensé que tal vez necesitaba ejecutar el discourse-setup que sale de él, pero eso solo hizo lo mismo de nuevo.
Utiliza el método de instalación manual y ./discourse-setup --two-container Me funcionó bien la última vez que lo usé.
O instala usando el elegante script de instalación y luego convierte a dos contenedores como se hace referencia en el OP.
@Falco y @pmusaraj ¿Creen que sería útil mantener partes del antiguo INSTALL-cloud.md a mano en algún lugar y hacer referencia a ellas en el actual INSTALL-cloud.md?
Efectivamente fue eliminado, eliminé la referencia de la wiki de arriba.
Gracias por la información. ¿Por qué se eliminó? Era un método muy útil.
Dos instalaciones de contenedores realizadas por personas que no están muy familiarizadas con Docker generaron demasiada carga de soporte. Es una configuración de instalación avanzada, que debe reservarse para personas que saben lo que hacen.
Así que lo está haciendo difícil para aquellos de nosotros que usamos esa función. ¿Preguntaron a alguien sobre el cambio con antelación? Parece que podrían haberlo dejado en su lugar dado que uno puede usar el método OP incorrectamente e incluso crear algunos problemas para sí mismo.
¿Carga para quién? ¿En este hilo? El soporte ha sido proporcionado por voluntarios/usuarios, no tanto por el Equipo.
Entonces, ¿dejarás web_only y data en las muestras y las personas que quieran usar dos contenedores tendrán que copiarlos y configurarlos manualmente? El único soporte adicional que requería antes era ayudar a las personas que nunca se molestaron en actualizar el contenedor de datos.
Ahora tendremos que decirle a mucha gente cómo usar cp y nano. Podría argumentarse que si no sabes usar cp y nano, no deberías ejecutar una configuración de dos contenedores. Jeff argumentó que si no sabes usar cp y nano, entonces no deberías instalar Discourse, pero logré cambiar su opinión cuando escribí discourse-setup.
En el próximo tiempo, reescribiré mi dashboard.literatecomputing.com para que deje de hacer instalaciones estándar (ya que no puede canalizar respuestas a discourse-setup más) y seguiré ofreciendo una instalación de 2 contenedores como opción allí.
No soy un fan. Esto se siente como un paso más hacia la eliminación del soporte para contenedores dobles en general y eso sería una gran lástima.
¡Y eso es lo grandioso del código abierto; la gente tiene la opción de elegir su propia aventura!
Decenas de personas ejecutando contenedores obsoletos completamente olvidados no es genial y causó mucha confusión cada vez que PostgreSQL necesitaba una actualización importante, lo que a su vez hizo que nuestro PostgreSQL ocurriera con menos frecuencia, empeorando el producto en general.
Estoy de acuerdo 
No es posible eliminar realmente el soporte para instalaciones de dos (o N) contenedores; Discourse se conecta de forma nativa a bases de datos externas, como se documenta en Configurar Discourse para usar un servidor PostgreSQL separado.
No se eliminó flexibilidad, pero análogo a The Power of Defaults, cada opción en las herramientas que creamos se convierte en algo que debe ser considerado.
Eliminar miles de líneas de script y simplificar el instalador para cubrir el caso de uso mucho más común fue una elección consciente, pero Discourse todavía admite todos los mismos casos de uso, y las personas son libres de aventurarse por su propio camino si así lo eligen.
Gracias por la tranquilidad de que este modo de producción seguirá funcionando sin niveles significativos de personalización 
Se sacrificó la conveniencia para aquellos que usamos el método eliminado en favor de forzar un camino para todos. ¿Fue una decisión de uno o participaron otros?
De codinghorror
"Los valores predeterminados son posiblemente las decisiones de diseño más importantes que jamás tomarás como desarrollador de software. Elige buenos valores predeterminados y los usuarios elogiarán tu software y lo fácil que es de usar. Elige valores predeterminados deficientes y te enfrentarás a la angustia del usuario por la configuración, y probablemente también a una gran cantidad de llamadas de soporte técnico."
En mi humilde opinión, se han elegido valores predeterminados deficientes y la elección/cambio se realizó sin la participación, discusión o consideración de la clase de usuarios que lamentan el cambio.
Preguntando de nuevo, ¿una elección consciente por parte de quién?
Este usuario experimenta ese comentario como arrogancia y falta de respeto. Se siente como lo que uno podría sentir si es menospreciado e ignorado. Dudo que la intención fuera causar tal reacción, pero aquí estamos.
En general, este episodio es consistente con lo que me quejaba en un mensaje privado con @nat hace unas semanas. CDCK/Meta tiene dos clases desiguales de clientes, los que pagan por el alojamiento y los que se autoalojan. El enfoque en este episodio es el último y quizás el ejemplo más flagrante de este sistema de dos clases.
Dicho todo esto…
Felicito al nuevo instalador. Hace un buen trabajo al manejar los problemas de instalación y las demandas de soporte resultantes desde el primer día.
En cuanto al cambio, CDCK tiene el derecho de construir/cambiar como mejor le parezca. No hay discusión sobre eso. Mi esperanza es que puedan hacerlo de una manera que no aliene a la gente.
Por último, la relectura de la publicación de codinghorror me hizo pensar en cómo solían ser las cosas cuando Jeff se involucraba en una publicación. Sus publicaciones a menudo olían a desprecio, falta de respeto y leve arrogancia. Afortunadamente, nunca fui el foco directo de eso, pero algunas de esas publicaciones eran dolorosas de leer. Mi interacción reciente con el personal sobre cómo se manejó una publicación y este episodio se sienten muy similares. Quizás solo sea yo.
Eso parece un poco duro. El equipo ayuda a los autoalojados todos los días en este foro, incluso a aquellos que caen en unsupported-install 