@Stephen В вашем аргументе есть изъян: описание мультиконтейнерной архитектуры изобилует предупреждениями о том, что вы несёте ответственность за обновления и должны понимать, как всё работает, а длинное описание выше настолько запутано, что, вероятно, любой, кто на него посмотрит, просто сдастся. Прочитайте мою статью Migrate quickly to separate web and data containers и скажите, что она не отпугнёт тех, кому будет трудно её понять, или что в ней недостаточно подчёркивается необходимость резервного копирования и возможности отката к резервной копии в случае сбоя!
Я был крайне недоволен, когда сразу после миграции на более мощный сервер (для установки исправления безопасности) выполнил команду ./launcher rebuild app, и мой сайт оставался недоступным неоправданно долгое время, значительная часть которого ушла на пересборку частей контейнера, связанных с PostgreSQL. Именно тогда я нашёл документацию о двух контейнерах и эту документацию, и мне совсем не хотелось снова терять 4 часа на миграцию, поэтому я продолжал мириться с длительными простоями из-за ./launcher rebuild app, чтобы избежать 4 часов простоя, необходимых для восстановления из резервной копии. Как человек с определённой компетентностью, я долгое время был очень раздражён тем, что такая конфигурация фактически скрыта.
Тема о PostgreSQL 12 — отличный справочник, потому что люди в итоге сталкиваются с ещё большим временем простоя, так как им приходится пересобирать всё приложение несколько раз, хотя можно было бы пересобрать только контейнер PostgreSQL дважды. Не могу сказать, что я прочитал всю ветку из-за автоматического удаления через 6 дней, но мне совершенно не очевидно, что некомпетентные развёртывания мультиконтейнерных систем являются там главной или даже одной из главных проблем.
(Извините, иногда я немного устаю от того, что здесь всех пользователей считают некомпетентными.)