Почему когда используют Docker для поднятия окружения, создают по контейнеру на каждый сервис а не всё в одном контейнере?

Question

[Lexxtor]

Http сервер в одном контейнере, БД в другом, язык программирования запускается в третьем.
Получается 3 виртуалки, так же накладных расходов больше, чем если бы всё в одном контейнере было.
Это наверное для последующего масштабирования так или не только или это тут не причем?

Comments

[hckn]

язык программирования запускается в третьем

Это как?))

[Владислав Лысков]

SmInc, я нуб, не могли бы вы пояснить этот тезис
А как мне быть, если я Http сервер написал на языке программирования? Разорвать его на две части? :)

[Lexxtor]

hckn, ну я имел ввиду программу на языке программирования :) WordPress например.

Answer 1

[Александр Талалаев]

Вы совсем не понимаете Докер. У него основная концепция - один сервис/приложение - независимое окружение.
Для чего это сделано? Прежде всего безопасность и облегчение развертывания приложения.
Любой администратор линукс (ну и других) систем знает, какого это поддерживать сервер одновременно в актуальном состоянии и нужные версии ПО, библиотеки которых часто между собой конфликтуют, нужно проводить танцы в бубном для того чтобы нужные библиотеки были там те, в другом месте другие. Далее возня с правами, кто под кем запускается, что может, дыры в самом ПО, когда из-за этого будет угроза другим частям системы. Ну и простота настройки, одним одни параметры, другим другие.
Докер позволяет решить эти и кучу других проблем, каждый докер образ это грубо говоря максимально минимизированный образ ОС с установкой только необходим библиотек для конкретного сервиса (например mysql), запускается независимо. Таким образом у себя на сервисе вы имеете возможно спокойно, без затрат умственных ресурсов поднять кучу версий например mysql или php. Да и просто разные программы/сервисы которые могут с друг другом конфликтовать, теперь не будут мешать.
У вас есть свои заготовки образов, либо вы берете готовый рецепт и работаете.
Далее тестирование/разработка значительно упрощается, так как организовать условия максимально приближенные к боевым теперь легче.
Далее можно создавать проверенные системы развертывания, снова таки каждый образ под свои задачи и тд и тп.
Короче говоря да, у докера есть свои минусы, но одновременно это значительный прогресс и облегчения прежде всего работы которая касается улосноый Devops части в разработки ПО, значительно автоматизируются и упрощаются многие штуки.
Так же советую потратить время и посмотреть запись введение в Докер от Хекслет Кирилла Мокевнина. Там небольшие проблемы бывают со звуком, сам вебинар 2 часа, но советую потратить время, он именно рассказывает проблематику, которая привела людей к изобретению Докера и этой концепции.

Comments

[sim3x]

Прежде всего безопасность

докер не является панацеей и более того не является тулзой для изоляции подозрительных окружений

Для изоляции зоопарка библиотек есть множество подходов и докер не самый простой

Таким образом у себя на сервисе вы имеете возможно спокойно, без затрат умственных ресурсов поднять кучу версий например mysql или php

Что означает, что у вас будет перерасход по озу и кешам

И что еще хуже - никто, никогда не обновляет те 100 пхп версий в 100 контейнерах

[Philipp]

Большое спасибо, Александр Талалаев!

Answer 2

[Saboteur]

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

Answer 3

[samizdam]

На примере LAMP
1. Задел на горизонтальную масштабируемость. Нужно сделать несколько бэкендов, делаете два P. Оркестраторы это поддерживают. В одном контейнере не тривиальная задача.
2. Распределённость, изолированность. Общаясь только по сети, все сервисы могут быть запущены на разных нодах, в кластере, etc. Опять из коробки же есть разные плюшки для организации сетей. Сюда же отвязка от файловой системы одного хоста.
3. Один контейнер - один процесс. Докер, как супервизор, либо оркестраторы, берёт на себя часть проблем по перезапуску контейнера. в случае некоторых проблем. Если мухи и смузи в одном стакане (контейнере), самостоятельно придётся решать, к какому из процессов его привязать.

Первый два комментатора похоже не очень умеют в докер. Или не понимают. Или не пробовали.

Comments

[samizdam]

Дополню такой аналогией. Если знаете ООП, и первую букву из SOLID.
Образ - это класс.
Контейнер - объект.
Единая ответственность сервиса(контейнера/образа), такая же хорошая практика как и в ООП, и даёт те же преимущества: локализация изменений и проблем, лучшая декомпозиция задач и логики.

[mureevms]

Первый два комментатора похоже не очень умеют в докер. Или не понимают. Или не пробовали.

Плюсую

Answer 4

[Валентин]

Получается 3 виртуалки, так же накладных расходов больше, чем если бы всё в одном контейнере было.

Так на что там расходы? Это же не гипервизор какой-то, простое разделение файлов и процессов по логическим сущностям. Chroot упаковали в красивую обертку и сделали подобие квот над ним.

Используют его хипстерские стартапы, у которых нет денег на админов и devops, а с линуксом работают программисты по шпаргалке вида «нажмите кнопку пуск для выключения компьютера», глубоко не погружаясь в детали. В солидных организациях используют нормальные средства виртуализации, средства типа докеров и джейлов в пром среду не запускают

Comments

[⚡ Kotobotov ⚡]

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

[Валентин]

дима кубитский, Артём Петренков,

все маштабирование крупных сервисов и держится

Стартапов чтоли и веб-мордочек? Так это разве промышленное применение. Вот пример мне приведите, что крупный банк или там оператор связи сделал свою внутреннюю инфраструктуру на докерах (именно инфраструктуру, бизнес-логику, а не личный кабинет).

Если на одну кнопку можно все автоматически виртуализировать и масштабировать, разворачивать, внедрять автоматически решать проблемы

Это если только на локалхосте) Влажные мечты программиста - нажать на кнопку, система обновилась, ничего не сломалось, перерыва сервиса никакого не было. Ну тут на тостере периодически спрашивают вопросы, как установить там питон, nginx etc. Да, для таких людей подходит хорошо. А как только оказывается 10+ реальных серверов с раскатаной виртуализацией про докер забывают.

[sim3x]

дима кубитский,

Благодаря докеру - для множества задач не нужны никакие админы

уточните, для каких задач теперь не нужны никакие админы

[⚡ Kotobotov ⚡]

sim3x, ну например средний программист теперь в два клика может развернуть приложение упакованное в контейнер, не являясь специалистом ни по серверам или сопутствующим технологиям используемым в этом контейнере. Ранее же это могло представлять проблемы, отнимая кучу времени у программистов. Сейчас же это не представляет проблем, не занимает никакого времени, и делается автоматически.
Также уже есть готовые пайплайны для разработки, которые можно внедрять вообще не являясь специалистом по девопс -> на примере fabric8 , там гиганский обьем задач автоматизирован.
Вам лучше зайти и самим посмотреть какой функционал сейчас в таких системах (типа fabric8) идет из коробки.
Фактически вообще ни девопс, ни какой-то системный администратор вообще не нужен, покраней мере в рамках стартапа/малого бизнеса.

[sim3x]

дима кубитский,

ну например средний программист теперь в два клика может развернуть приложение упакованное в контейнер, не являясь специалистом ни по серверам или сопутствующим технологиям используемым в этом контейнере.

Перед етим синьиор админы должны пару месяцев настраивать кубернетес и нормально упаковать много контейнеров
Среднему программисту никто не даст пихать код на продакшен самостоятельно

Для автоматизации есть - ансибл

Фактически вообще ни девопс, ни какой-то системный администратор вообще не нужен, покраней мере в рамках стартапа/малого бизнеса.

время преднастройки - боле чем время изучения доков каждой тулзы

Вместо 1 скрипта деплоя - требуется магия и отдельный спец по кубернетес

[⚡ Kotobotov ⚡]

>настраивать кубернетес и нормально упаковать много контейнеров
специально указал чтоб вы зашли на fabric8, и посмотрели что там весь пайплайн из коробки, ничего настраивать не надо, никакие синьеры и уж тем более системные администраторы (именно для настройки инфраструктуры и пайплайнов не нужны), две кнопки нажал все работает, поверхностных знаний и пониманий выше крыши, там любой "сын нашей бухгалтерши" справиться.
И это то никакое не будущее это то что есть уже сейчас и активно используется.

[⚡ Kotobotov ⚡]

Валентин,
>А как только оказывается 10+ реальных серверов с раскатаной виртуализацией про докер забывают.
ой да пожалуйста, пускай забывают, пускай хоть в присядку дрочат, мне пофиг.
Не хотите использовать - не используйте, или там что-то другое используйте, ни кто не запрещает.
Есть просто железобетонный факт что во всем мире докер уже активно используют, он УЖЕ решает задачи тестирования, деплоя, маштабирования, отделения софта от инфраструктуры и тд. Можно не признавать это - но это та реальность которая есть.

Answer 5

[Denis Michurin]

Потому что концепция Docker такова, один контейнер - один процесс.

Comments

[Lexxtor]

Поясните, пожалуйста, какой от этого профит?
Так можно и БД с http сервером в одном контейнере назвать одним процессом.

[mureevms]

Идеология докера: один процесс - один контейнер. Что тут не понятного?
Вот для примера:

root@host:~/sites# docker exec -it memcached ps ax
PID   USER     TIME  COMMAND
    1 memcache 19:05 memcached -u memcached -m 512
   15 root      0:00 ps ax

В контейнере memcached существует только один запущенный процесс

root@host:~/sites# docker exec -it nginx ps ax
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:00 nginx: master process nginx -g daemon off;
    6 ?        Sl    14:59 nginx: worker process
    7 ?        Sl     0:47 nginx: worker process
   22 pts/0    Rs+    0:00 ps ax

В контейнере nginx существует один запущенный процесс nginx и несколько его воркеров, если хотите, его дочерних процессов.
Т.е. в каждом контейнере только один сервис.

[mureevms]

Можно запихать в контейнер и несколько демонов, но тогда теряется смысл от использования докера, по крайней мере в продакшн среде. Но для разработки\тестирования\переносимости удобно.

[Denis Michurin]

Lexxtor, профит такой в запущенном контейнере докер следит только за одним процессом - самым главным и единственным, и в случае падения докер сможет перезапустить его. А если у вас будет солянка в контейнере - то при падение одного процесса, контейнер продолжит работать как не в чем не бывало, и у вас все ваше приложение упадет.

Answer 6

[Sanes]

От нечего делать. Особенно, когда банальный LAMP

Comments

[Sanes]

Артём Петренков, И в чем проблема? CGI, FastCGI, PHP-FPM. Выбирай по-вкусу.

[Sanes]

Артём Петренков, делай, если заняться больше нечем.

[Roman K]

Sanes, мне, например, проще написать 5 строчек в Dockerfile, чем каждый раз вручную разворачивать эти твои LAMP'ы

[Anton Mashletov]

Roman Kitaev, если в целях разработки, то зачем каждый раз? Ну один раз поставил себе php 5.6/7.2, composer, git, phpstorm, node, npm, mariadb. Вместо apache - php builtin web server. Лично моих 95% задач это покрывает.

[Roman K]

Anton Mashletov, угу. А потом перенёс на продакшен, а там "чёта не работает". А если у тебя экосистема — 30 таких проектов, 29 из которых разрабатывал не ты и даже не на тех языках, которые ты знаешь и кодовая база некоторых превышает 100к строк — удачи)

[Sanes]

Roman Kitaev, делай так, чтобы везде работало. Кто же тебе в этом виноват?

[Anton Mashletov]

Roman Kitaev, у вас просто особый случай. У 90% других веб-прогеров всё довольно типично.

[Roman K]

Sanes, прости, сверхразум, в моей маленькой голове не умещаются миллионы зависимостей.

[Roman K]

Anton Mashletov, Ну так докер и не нужен для визиток и интернет-магазинов

[Sanes]

Roman Kitaev, если ваш сверхразум готов страдать с докером и не осилил настройку сервера, то надо учиться.

[Anton Mashletov]

Roman Kitaev, а если понадобится сделать интернет-магазин, то вы LAMP'ом будете пользоваться?

[Sanes]

Anton Mashletov, Если понадобиться сделать интернет-магазин, я обращусь к программисту.

[Roman K]

Anton Mashletov, если у меня есть бесплатный docker registry — то скорее всего докером. Уж слишком я к нему пристрастился, потому что он очень простой. Но раньше ansible и даже иногда fabric хватало.

[Sanes]

Roman Kitaev, это для себя вы сделаете. Отдавать будете всем зоопарком?

[Roman K]

Sanes, Если пара докер-образов для тебя — зоопарк, а куча файлов, зависимостей и прочих кишок — не зоопарк, то не о чем с тобой разговаривать)

[Sanes]

Roman Kitaev, ок

Answer 7

[ru-soft]

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

Comments

[hckn]

Вы забили упомянуть "удобство" настройки этого зоопарка)

[Lexxtor]

ru-soft, hckn, ради удобства создавать для каждого сервиса вирт. ОС? Оно того стоит? Alpine Linux 130мб занимает, по современным меркам не много, но всё же...

[Roman K]

Lexxtor, вообще-то 4.2мб занимает Alpine

[Roman K]

Lexxtor, И, кстати,

ради удобства создавать для каждого сервиса вирт. ОС?

Ты вообще читал про докер? Там есть слои, которые имеют особенность шариться между контейнерами. Даже если бы твой Alpine Linux занимал 130мб диска и у тебя было бы 30 контейнеров, то он бы занимал именно 130мб диска, а не 130*30, как тебе может показаться. Но он занимает только 4.2мб и ещё и шарится между всеми контейнерами, которые его используют (при условии, что версии алпайна одинаковые)

[sim3x]

Roman Kitaev,
О!
Мож у тя есть нормальный кейс из жизни с докером, так чтоб не оверинжиниринг ради инжиниринга?

[Roman K]

sim3x, Да, есть один проект.

Всего есть 39 контейнеров:

laptop:~ deliro$ docker ps | wc -l
      39

Из них где-то 5-7 штук — это всякие mysql, redis, elasticsearch. В среде разработки они контейнеризованы (самые стандартные, без тюнинга — percona и redis), на проде они работают без докера.

Остальные 30+ контейнеров — проекты соседних команд, к которым ты вообще можешь не иметь отношения. Написаны они на самых разных языках и технологиях: Python, PHP, Perl, Ruby, Node.js и прочее. Если бы ты захотел поднять эту экосистему без докера — тебе понадобился бы вагрант и очень много своего времени. Либо засорять свою любимую систему, но всё равно очень много времени. С докером это: скачал образ, поставил галочку в .env файле, что проект надо запускать, иногда склонировал репозиторий, запустил docker-compose — работает.

Наружу каждого контейнера торчит какой-то интерфейс (обычно HTTP). Это всё, что тебе нужно знать о каждом. Не надо знать, как настраивать, uwsgi там или gunicorn или uvicorn. pip или composer. Запустил — работает.

Каждый коммит в git запускает сборку образа. Прод использует код из ветки production и (иногда) собирается по-другому, не как master. Например, статика там вебпаком сжимается в production-mode, у джанги отключается DEBUG=True, а у Gunicorn reload=True. На проде rancher.

Из минусов — это занимает очень много места на диске. Но дело поправимое — почти все образы можно собрать с alpine (сейчас почти везде debian).

Answer 8

[d'Ivan]

Потому что Docker отвечает за виртуализацию на уровне процессов ОС, то есть отдельных приложений.
Для оркестрации контейнеров используют Kubernetes / Docker Swarm.

Comments

[Lexxtor]

Разве? Там каждый контейнер - это виртуальная ОС, а не приложение.

[d'Ivan]

Lexxtor, в docker есть аналог виртуализации файловой системы при помощи наложения слоев. Но это не означает виртуализацию всей ОС, а лишь отдельных экземпляров процессов.

[Lexxtor]

Роман Мирр, Артём Петренков, тогда что такое Alpine Linux в контейнере?

[d'Ivan]

Lexxtor, это, прежде всего, образ компактного дистрибутива без всего лишнего, мало весящий. И для запуска контейнера процессу приложения в Docker тогда не нужно иметь, скажем, полновесную Убунту. Допустим, нужно запустить процесс генерации PDF. Этот процесс требует файлы конфигурации, сырьевые данные для подготовки PDF и имеет настройку окружающей среды. При запуске контейнера будут считаны с диска лишь минимально необходимые файлы с файловой системы контейнера для обеспечения виртуальной окружающей среды Alpine Linux, в которой будет бежать один-единственный процесс, генерирующий PDF.
Не будет накладных расходов на эмуляцию работы процессора, модели памяти, загрузчика ОС, драйверов ОС и прочей ненужной фигни.

[Lexxtor]

Роман Мирр, я немного не понимаю. Тут https://alpinelinux.org/downloads образ дистрибутива весит 109 мб. Получается что в ПЗУ потратится 109 мб на базовый образ + каждый контейнер займёт столько МБ на сколько он отличается от базового?
Например, 2 контейнера на базе alpinelinux займут в ПЗУ:
109 мб + 254 мб (mongoDb) + 6 мб (nginx) ???

[Ezhyg]

Lexxtor,

ПЗУ

Мелькор тебя забери! Не используй термины, значения которых не знаешь.

Answer 9

[sim3x]

Почему когда используют Docker для поднятия окружения, создают по контейнеру на каждый сервис а не всё в одном контейнере?

Зависит от подхода к деплою

В случае "хостера" - клиента попросят засунуть все в один контейнер или платить за каждый контейнер отдельно

В случае "балансировки нагрузки" через копирование бекендов, помещение кода в контейнер - разумное решение.
В случае нагруженного проекта - СУБД лучше помещать отдельно прямо на железо без контейнеров и виртуализации

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

Comments

[ru-soft]

Для тяжелых приложений использующих много различных служб и сервисов которые требуют настройки окружения Docker спасает от утомительного занятия заставить все работать вместе.

[sim3x]

ru-soft,
как докер спасает от настройки?
В каком именно кейсе у вас возникли проблемы типа

заставить все работать вместе

?

[ru-soft]

Например одному сервису требуется пакеты версия которых не подходит для другого сервиса

[sim3x]

ru-soft,
конкретнее

Что за сервис?

и
как докер спасает от настройки?

[ru-soft]

например несколько вариантов selenium WebDriver

[sim3x]

ru-soft,

Можно указать на бинарник в настройках или полодить его рядом с точкой входа в код

Кейс слишком притянут за уши

и
как докер спасает от настройки?

[ru-soft]

https://robotninja.com/blog/introduction-using-sel...

[sim3x]

ru-soft,
Why Use Selenium with Docker?

It’s much quicker to get up and running using the pre-made containers than to try and set Selenium up from scratch. You don’t need to install Java #winning.

делать тесты на джаве и не устанавливать ее. Пахнет маразмом. Кроме того обновление джавы руками - занятие не для слабонервных

You don’t need to install all the necessary browsers. Perhaps you don’t want to install Firefox or want to test with a specific older build of Chrome or one with specific plugin or capabilities?

Ясно, делаем функциональные тесты - браузер ставить не хотим

Selenium can (and likely will) crash on you. So in my experience, it’s not really something you can simply set and forget. Using containers means you can spin up a new Selenium instance when you need it, discard and then start fresh. Alternatively, if you do plan on leaving it running for extended periods of time, if/when it crashes you can just set to reboot.

Селениум не гадит в окружение. Каждый раз стартуется новый инстанс.
Что за бред
Даже если требуется сделать профиль пользователя, то ето одна строка в коде

Team members can use the same container regardless of what operating system they use so there are fewer discrepancies between environments.

Одна вменяемая причина - и она никак не относится к докеру. Она про виртуалки с продакшен окружением

Кейс слишком притянут за уши

и
как докер спасает от настройки?

[ru-soft]

речь идет о ASP.NET.... кроме тестирования, с использованием селена грабят сайты причем с весьма изощренной защитой где нужны разные прокси, разные user-agent, характеристики браузера. Награбленное добро нужно передавать другим сервисам и т.д.

[sim3x]

ru-soft,

И докер тут опять не при чем

[batyrmastyr]

sim3x, в нашей внутренней вики раньше был весьма объёмный раздел «развёртывание сайта x» и каждый раз в нём что-то ломалось (в новых версиях ОС пакеты переименовывались, начинали глючить или конфликтовать, репозитарии дохли, некоторые костыли теряли актуальность).

С введением докера всё свелось к git clone и запуску 3 - 10 команд из текстовика в корне проекта (накатить копию базы, установить зависимости кода, где-то - сформировать xml для сфинкса без которых он не сможет стартовать). Плюс ушла проблема параллельного существования разных версий бд / языков.

Да, это можно решить и через классические виртуалки, но по докерфайлу сразу видно что понаставил внутрь создатель контейнера и не курил ли он майский чай.

[sim3x]

batyrmastyr, почему не использовали ансибл?

[batyrmastyr]

sim3x, потому что сейчас мне это представляется, как длинные простыни из «создай виртуалку / виртуалки» (на KVM?), залезь внутрь, установи что надо, пробрось куски файловой системы в свою машину, открой порты, накидай скрипты запуска для systemd и аналогов (внутри же разные среды, не факт что везде одна система будет). И тут моя очередь повторить ваш вопрос про «чтоб не оверинжиниринг ради инжиниринга». Чем ансибл и необходимость настраивать совсем вручную виртуалки лучше докера, где вся мешанина ограничивается установкой через apt get, apk или wget + make install?

[sim3x]

batyrmastyr, тем что ансибл прозрачен и документируем

Для создания докер контейнера все равно потребуется создание ансибл
Иначе контейнер и его создатель превратятся в магию и мага
Думаю не нужно обьяснять к каким проблемам ето приведет

[batyrmastyr]

sim3x, эм... он требует изучения нескольких дополнительных инструментов и обёрток над ними, что уже снижает прозрачность и документируемость, а без полного отказа от использования шелла он сам превратится в магию (первый раз отработал, а на второй упал).
У нас не тысяча человек и пока за глаза хватает докера + docker-compose (даже без swarm) и я не вижу тут места для ансибла. Кроме как ради добавления сложности.

[sim3x]

batyrmastyr,
Сравнивать обчение ансиблу и обучение кубернетесу не будем, ок?

Если у вас докер собирается магическим образом, то впринципе да. Ансибл и любая документация по сборке докера не нужна

[batyrmastyr]

sim3x, не будем, кубернетес не используем.
Вы собственно, с чего взяли, что сборка образа по докерфайлу - магия? Что такого магического в цепочке команд которые либо все завершатся успехом, либо образа не будет?

[sim3x]

batyrmastyr,
Недокументированная цепочка команд === хорошо и просто
Документированный ансибл === магия
???

[batyrmastyr]

sim3x, а что, в ансибл есть документация по установке из исходников для всего на свете? Или в ансибл есть вменяемая документация по настройке iptables, чтобы зарезать доступ к базе для всех, кроме приложения?
Сравните установку постгреса (из пакетов или исходников, на выбор) на альпайне и установку расширения postGIS из исходников на ансибле и на баше. Компиляция postGIS, насколько я себе это вижу, выльется в чёрную магию запуска башевых команд из ансибла. //Вроде заявлен модуль make для этого, но он в статусу "preview" и большой вопрос, сможет ли он откатить изменения если завернуть его в блок.

[sim3x]

batyrmastyr,
Хм
https://gist.github.com/kharandziuk/d11aab8b1560d4...

Но я вообще говорил о другом
Если сравнивать
Ансибл (если хотите баш скрипт с коментами) vs человек, который руками собирает контейнер
Человек ни при каких раскладах не выигрывает

[batyrmastyr]

sim3x, чтобы было понятнее: https://pastebin.com/5bRT4CRB (postgres_ext всего лишь запускает sql "CREATE EXTENSION <имя>", а нужна именно сборка, т.к. бинарники из репозитория в 4 раза медленнее).
Я не вижу ни единой причины, почему ансибл сделает эту портянку лучше и, тем более, он не спасёт от её ручного написания. Всё, что он даст - более аккуратное форматирование.

Но в недостатках ансибла:
(1) нужно будет писать и запускать ещё один сценарий ансибл, чтобы создать нужные виртуалки, прописать им права доступа друг к другу, настроить проброс портов и папок в основную систему... Очевидно, что документированный docker-compose.yml выигрывает у магического ансибл-велосипеда.
(2) Проблемы при обновлении: в докере вы просто скачиваете новый образ и заменяете им старый. С ансиблом пиши отдельный сценарий + обновляйся либо в имеющейся виртуалке (вероятен длительный простой, пока всё не обновится), либо создавай новую (ждать пока всё поставится, поменять порты старой и новой виртуалок, погасить старую виртуалку, простой минимальный).

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

[sim3x]

batyrmastyr,

Не вижу оптимизаций, которые б дали 4х
Но не суть

Мой поинт был в том, что требуется автоматизация + документирование
Ансибл только инструмент

Если у вас автоматизация в баш скрипте или в композе - значит все ок

Теперь как все делается без докера
Делаем деб-пакет с постгресом и всеми требуемыми екстеншенами, которые линкуются статически
Ставим пакет

В итоге на проде не будет лишнего софта типа компиляторов и сборщиков

Скрипт с пастебина потребуется слегка подправить

[batyrmastyr]

sim3x,

Не вижу оптимизаций, которые б дали 4х

из версий только "собирали под кофеварку" т.к. от сборки самого постгреса существенного выигрыша не было.

Скрипт с пастебина потребуется слегка подправить

Вариант, конечно.