Почему так не делают в docker (all-in-one чёрный ящик)?

yokotoka, мне кажется три года назад Вы были достаточно компетентны и рассудительны, чтобы ответить на собственный вопрос.

Многие подходы и многие программные продукты созданы, чтобы решать проблемы крупных корпораций, вроде 100.000 или 1.000.000 запросов в секунду.

Практиковать эти подходы и ПО имеет смысл, если Вы собираетесь трудоустроиться в крупную IT компанию с огромными нагрузками.

Однако, если Вы решите внедрять их в маленькую компанию с маленькими нагрузками (допустим, молодой стартап), то сделаете медвежью услугу всем: повысите сложность инфраструктуры, порог входа новых разработчиков, расходы и риски компании.

Чтобы развернуть проект парой команд (или чуть больше), есть масса более простых в устройстве инструментов: от совсем банальных установочных скриптов до уже упомянутого в ответах Ansible.

Собственно почему я заговорил о простоте? Я полагаю, что слишком большое количество магии вызывает тяжёлую форму зависимости с непредсказуемыми последствиями. Собственно, на магии выехал и нелюбимый вами веб-фреймворк Django: заготовка проекта с новым секретным ключом по команде, миграции по двум командам и куча батареек разной степени магичности. Если на достойном уровне знать Django, то прототипировать с ним быстро, 90% задач решаются быстро, а вот небольшое допиливания и кастомизация... подобны попыткам сломать головой стену, заботливо выстроенную разработчиками Django.

Похожая история и с Docker. Многие используют Docker, чтобы не писать большую документацию по установке, не пакетировать приложения, не писать установочные скрипты, не вникать в нюансы разных платформ и не поддерживать ПО в актуальном состояния. В итоге можно наблюдать в продакшене магические коробочки, в которых крутится какое-то магическое легаси с устаревшими лет пять назад зависимостями. Причём без Docker на актуальных дистрибутивах Linux это уже не собирается и не запускается. А если контейнер откажется подниматься после обновления Docker...

В общем, обычно технологии пилят под свои нужды и потом раскручивают, чтобы переложить разработку на OpenSource сообщество и получить в отделе кадров поток специалистов уже знающих эту технологию. Поэтому пользоваться всем, что на слуху -- не стоит. А если пользоваться -- то порой бывает очень полезно скептически подходить к рекомендациям и подходам из официальной документации. Нужно понимать контекст для кого это писались, какие задачи должно решать, хорошо ли всё это переносится на ваши задачи, и т.д.