@Stephen Há uma falha no seu argumento: a descrição de múltiplos containers está cheia de avisos de que você precisa assumir a responsabilidade pelas atualizações e entender como funciona, e a descrição longa acima é tão obscura que provavelmente qualquer pessoa que a lesse desistiria de qualquer maneira. Leia meu Migrate quickly to separate web and data containers e me diga que isso não vai assustar as pessoas que terão dificuldade em segui-lo, ou que falha em enfatizar a necessidade de backup e a capacidade de retornar a um backup se algo der errado!
Fiquei profundamente infeliz quando executei ./launcher rebuild app pouco depois de migrar para um servidor mais capaz (para uma correção de segurança) e ter meu site fora do ar por um tempo excessivamente longo, grande parte do qual foi gasto recriando as partes do postgres do container. Foi quando encontrei a documentação de 2 containers e esta documentação, e realmente não quis passar por outra queda de 4 horas para migrar, então continuei aceitando longos períodos de inatividade para ./launcher rebuild app para evitar as 4 horas de queda que uma restauração levaria. Como uma pessoa vagamente competente, fiquei muito irritado por um longo tempo por essa configuração estar efetivamente oculta.
O tópico sobre o postgres 12 é uma ótima referência, porque as pessoas acabam com mais tempo de inatividade porque precisam recriar o inteiro aplicativo várias vezes, quando poderiam estar recriando apenas o container do postgres duas vezes. Não posso dizer que li todo o tópico devido à exclusão automática de 6 dias, mas não me parece óbvio que implantações de múltiplos containers incompetentes sejam o, ou mesmo um, grande problema lá.
(Desculpe, às vezes fico um pouco cansado do “todos os usuários são incompetentes” por aqui.)