@Stephen Hay un fallo en tu argumento: la descripción de contenedores múltiples está llena de advertencias sobre la necesidad de asumir la responsabilidad de las actualizaciones y comprender cómo funciona, y la descripción larga de arriba está tan oscurecida que probablemente cualquiera que la viera se rendiría de todos modos. Lee mi Migrate quickly to separate web and data containers y dime que no asustará a las personas que tendrán dificultades para seguirlo, o que no enfatiza la necesidad de realizar copias de seguridad y la capacidad de volver a una copia de seguridad si algo sale mal.
Estaba muy molesto cuando ejecuté ./launcher rebuild app poco después de migrar a un servidor más potente (para una corrección de seguridad) y tener mi sitio caído durante un tiempo excesivamente largo, gran parte del cual se dedicó a reconstruir las partes de postgres del contenedor. Fue entonces cuando encontré la documentación de 2 contenedores y esta documentación, y realmente no quería pasar por otras 4 horas de inactividad para migrar, así que seguí soportando largas interrupciones para ./launcher rebuild app para evitar las 4 horas de inactividad que tomaría una restauración. Como persona vagamente competente, me molestó mucho durante mucho tiempo que esta configuración estuviera efectivamente oculta.
El tema de postgres 12 es una excelente referencia, porque las personas terminan con más tiempo de inactividad porque tienen que reconstruir toda la aplicación varias veces, cuando podrían estar reconstruyendo solo el contenedor de postgres dos veces. No puedo decir que haya leído todo el hilo debido a la eliminación automática a los 6 días, pero no me parece en absoluto obvio que las implementaciones de múltiples contenedores incompetentes sean el problema principal, o incluso un problema importante allí.
(Lo siento, a veces me canso un poco de la idea de que “todos los usuarios son incompetentes” por aquí.)