Ну, например, требования доступа к СУБД через файловый сокет, а не сетевой.
Вот эти требования, как правило, аморальны и непрактичны. С какой такой целью вам потребовалось прибить гвоздями коннект к постгре к файловому сокету в условиях докерной изоляции?
Откуда больше? Постгри в контейнере почти анлогичен постгри на отдельном хосте с точки зрения основного приложения.
Ну вот мы и пришли к тому, что постгре на локалхосте для самого приложения абсолютно идентичен постгре в сети. Теперь все же вопрос: с какой целью вы отказываете пользователю в возможности использовать remote постгре, при этом еще и в контексте «контейнера приложения». Философия у докера достаточно простая: запускаем процесс в изолированном окружении, как только процесс загнулся — киляем окружение до кучи. Это просто и это работает. Как только вы прикручиваете контроль запуска соседних сервисов при запуске приложения и впиливаете gracefull shutdown в код самого приложения — вы обкладываетесь граблями. Как только вы прикручиваете supervisord и прочие иниты в качестве основного процесса в докер — вы обкладываетесь граблями. Если вам нужен полноценный инит с контролем зависимостей, с графом запуска и прочей фигней, не родной для контейнера приложения, возможно, вам просто нужен контейнер ОС?
Нет, можно, конечно, «пробивать» изоляцию докера, «прибивать» гвоздями один контейнер к другом, шарить между ними те же файловые сокеты через docker-compose и прочее, но зачем если все проблемы взаимодействия между контейнерами можно решить помещением всего что нужно нашей системе в один контейнер?
Потом юзер ставит ваш «чудесный сервис» с постгре унутре к себе на машинку, и все чудесно… Ага… Рядом он поднимает еще парочку, и вуаля, у него 3(три!!!) постгреса, работающие на локальной машинке. А потом он в этот зоопарк запускает еще пользователей, штук 10. И долго думает на тему: почему все встало раком. А потом до него доходит, что 3 постгри на одной машине не есть хорошо, и он поднимает себе отдельную машинку с целью унести «БД вашего гитлаба» туда… А потом он читает 150-страничный мануал по докеру на тему «как распилить один всратый докерфайл на два, чтобы ничего не поломалось». И даже распилил, а ваш божественный образ только по файловому сокету в базу ходить умеет…
Если докер инкапсулирован и наружу не светит, то в его кишках априори копаться не надо.
Несколько постов назад меня пытались убедить, что такие контейнеры хороши в целях отладки и разработки. Т.е. когда в кишках копаться таки надо.
Дело в том, что есть техника, при которой образы для разных сред по-разному тегируются. Тестовая — скажем, image_name:test, для uat — image_name:dev, а продовый образ уже называется по-человечески.
Отличная техника, сам пользуюсь и остальным рекомендую. С одним маленьким нюансом — в контейнере должно быть то, что вы непосредственно пишете. Сделали правки, пересобрали контейнер, погоняли тесты, засунули куда надо. При этом бывает такая надобность — погонять свежесобранную версию на нескольких датасетах. Все их будем локально складировать? Или таки отпилим базу данных от непосредственно собираемого сервиса, и будем цеплять нужный датасет по урлу, передаваемому в переменной окружения?
К тому же в НОРМАЛЬНОЙ практике стремятся к тому, чтобы dev|test|prod образы собирались из одного и того же докерфайла, чтобы не отлаживать еще и их. Если один образ помечен dev, это не значит, что его dockerfile отличается от prod-образа. В нем просто, как правило, лежат разные версии софтины и собирается, возможно, он с разными переменными среды.
Далее пример с образами с тестовыми данными — например, образ с Postgres и запеченной внутрь тестовой базой.
Вот это, в теории, может быть кейсом. При условии, что база либо констрактится на лету из дампа каждый раз при запуске тестов (что сказывается на скорости прохождения этих тестов), либо подмонтирована в read-only, чтобы реран тестов не мог сломать все к чертям. Но это совсем специфический случай, и к «отдать клиенту постгре, упакованный вместе с сервисом» относится мало. Просто клиент за такой подход и проклясть может.
Короче, еще раз кратко. Зачастую нет цели делать prod и dev АБСОЛЮТНО идентичными. Эти окружения решают разные задачи и для большинства достаточно определенной степени схожести, которая определяется в каждом случае отдельно.
Прод и дев, конечно, не должны быть ни в коем случае идентичными, иначе нахрена их вообще разделять. Другое дело, что собираться они должны из одного и того же докерфайла, например. Или, по крайней мере, стремиться к этому нужно. Вся эта каша и заваривалась заради того, чтобы анекдот «у меня все работает» стали историей.
В разработческом окружении должна быть ровно та же версия glibc, тот же набор установленных пакетов, что и в проде. Элементарно «в лоб» ловите багу:
— на прод окружении мы подключаемся к удаленному серверу postgre (это нормальный подход);
— соответственно сам постгре-сервер на проде не стоит (и это абсолютно правильно);
— в dev-окружение вы для «простоты отладки» постгре-сервер запихали;
— разработчик воткнул в код вызов pgdump перед какой-то «особо опасной» операцией.
Теперь, внимание, вопрос, почему на сервере сервис крашится, а «у разработчика все работает»?
определенной степени схожести, которая определяется в каждом случае отдельно
Вот эта «определенная степень схожести» обычно определяется как «собрано из одного и того же докерфайла». Возможно, с разными ключами сборки, со своими нюансами, но из одного и того же, иначе вся эта мутотень, которую вы затевали с контейнеризацией — зря.
Датасайентист (или тестировщик, или кто там еще) не хочет вникать в детали реализации gitlab. Он хочет запустить его и все. Желательно с максимальной инкапсуляцией всех зависимостей и одной командой.
Датасайентист, тестировщик и прочие человеки, которые хотят «просто запустить, чтобы работало» не отличат, смею вас заверить, «docker start» от «docker-compose up», например, и для них такой подход монопенисуален подходу с «все в один контейнер».
Я тоже как администратор хотел бы GitLab потреблять как законченный сервис, а не конструктор из 100500 элементов.
А вот вы, как администратор, должны понимать, где зарыта грабля, и почему так не стоит делать. Впрочем, если вы «администратор локалхоста», вопрос можно снять. Но не выдавайте «best practices» локалхоста за «best practices» системного администрирования.
требуется, например, какая-то специфичная взаимная настройка компонент и делить их на образы нецелесообразно.
О какой «взаимной настройке компонент» мы говорим в случае Postgre? Постгре «калибруется» под железку, на которой он крутится, под размеры базы и прочие специфические вещи. Т.е. он калибруется конкретно под задачи и окружение. Приложение, которое с ним работает, для работы с постгре во «взаимной настройке компонент» не нуждается. От слова «никак». Оно просто должно получать на вход одну строчку с описанием «куда к базе коннектиться». При этом, при росте базы, миграциях и изменениях структуры базы постгре можно беспроблемно перенести на другую машинку, дать ему больше памяти или io… Хотя, нет, в случае, если он у вас в том же контейнере лежит — нельзя.
При этом представим ситуацию: вы мне дали образ с упакованным внутри приложением + постгре. Мне понравилось, я нашел еще 10 приложений с таким же «профессиональным подходом». Вуаля, у меня на локалхосте крутится 11 (одиннадцать, Карл!!!) инстансов постгре. При этом каждый из них стремится отожрать всю память, которая ему доступна, в целях кеширования (мы же не думаем, что человек, не способный настроить ручками коннект к постгре, способен грамотно лимитами разделить 11 инстансов этого самого постгре в пределах одного инстанса).
Нету такого кейса за пределами вашего личного локалхоста, где упаковка постгре в один контейнер с приложением — хорошая идея. И если «у меня на локалхосте все норм», это не значит, что стоит пытаться выдавать это за сколько-нибудь хорошую практику.
Вот именно, что для докеризированного постгреса, который должен конфигурироваться и управляться извне контейнера.
Если постгрес должен иметь возможность конфигурироваться и управляться извне контейнера (а так бывает чуть менее, чем всегда, в случае постгреса), его однозначно проще иметь в отдельном контейнере. В конце концов, вы же для разработческих целей его, вроде, хотели иметь. Вполне реален кейс, когда разработчик что-то накосячил, и нужно отключить от постгреса всех клиентов и пошарить у него в кишках ручками. Вот этот кейс вы как собираетесь реализовывать в своем монолитном контейнере? Докерфайл править, или код приложения?
Новый уровень абстракции порождает новые сложности по низкоуровневому управлению.
Сейчас открою вам тайну. docker-compose — это не сервис, не подсистема и не что-то уберсложное. Это просто парсер конфигов, который на выходе отдает все вот эти конструкции docker start --дальше-миллион-параметров. Вы можете ровно то же самое сделать руками. Я вам честно говорю, с постгре внутри контейнера вы огребете гораздо больше геморроя, чем от — link: postgre в докер-компоуз файле.
Не везде разворачивается всё из одних образов, более того не везде всё вообще из образов разворачивается.
Не все — это конкретно постгре. Он, обычно, из образов не разворачивается, и нефиг ему внутри них делать, соответственно.
И даже если из одного образа разворачивать, то будет именно схожесть в общем случае, а не идентичность гарантируется.
В общих чертах идентичность окружения как раз гарантируется. Поэтому и принято на разработческих окружениях крутить ровно те же версии контейнеров, что и в проде, чтобы хоть какие-то гарантии иметь. Собственно, исключительно заради этой фишки все и затевалось. Если у вас приложение для разработчика обернуто в один докерфайл, а в проде — в другой, в вашем монастыре что-то не так с уставом.
Как минимум из-за аппаратных различий и версий ядра.
Версии ядра-то тут при чем? Контейнер как таковой строится поверх libc, и контейнер как раз изолирует libc нужной версии, с точностью до ABI. Короче, ядро не при делах, если чо.
Чаще всего именно для целей разработки и тестирования, грубо говоря, замена вагрантфайла докерфайлом.
Замените docker-compose файлом, или оберните соответствующими sh-скриптами, или, например, завертите все в кубере — и будет вам счастье.
Кхм, а какие такие задачи датасайентист будет решать глубоко-локальным гитлабом? Что он там будет тестить?
Заметьте, я, по сути, не возражаю против наличия нескольких взаимосвязанных процессов внутри контейнера. Есть, действительно, кейсы, когда «чистота подхода» не стоит свеч. Но это кейсы, когда «сервис снаружи» действительно накладывает дополнительные затраты на разработку и обкладывание костылями. Тут уже упоминали VPN-ки, сборку метрик и все вот это. Просто postgre — это заведомо не тот случай, который сколько-нибудь проще решить внутри монолитного контейнера, его, как раз, а) проще, б) разумнее иметь снаружи.
Еще желательно сразу учесть, чтобы сервисы потом поехали в куб с минимальными изменениями и имели возможность масштабироваться.
Вы же сами все и объяснили. Не только желательно, но и нужно, чтобы все это поехало в куб с минимальными изменениями. Поэтому варианта «один контейнер всё-всё-всё внутри» просто не существует. Да, в некоторых местах будет непросто, но никто и не обещал, что жизнь будет малиной.
Перед вами стоит вполне реальная проблематика: миграции БД, которые однозначно затем понадобятся в прод-окружении. Т.е. задачу взаимосвязности сервисов на уровне оркестрации решать все равно придется, почему этим не заняться на этапе проектирования/пруф-оф-концепта? Зачем обязательно выносить этот геморрой на этап «у нас все готово, осталось на прод вытащить». Когда на этом этапе вылазят такие вот «О, хоспади, слона-то я и не приметил», это верный признак в корне неверного подхода.
А, забыл еще вот что.
Вы же КОПИЮ volume'а создадите. Это будут НОВЫЕ файлы, НОВЫЕ файловые дескрипторы и все вот это. Тот же постгре после отката на совершенно законных основаниях может начать ребилдить индексы, реструктурировать хранилище и все вот эти вещи, которые он так прикольно умеет делать, что может отсрочить возвращение базы в строй «на некоторое слабопредсказуемое время». Думаю, этот кейс мы тоже в плюсы «докеризации» записывать не будем?
Прямо в этом сценарии:
1. Представим, что у вас контейнер mysql:5.6, вот прям с тэгом 5.6. При этом у вас НЕТ гарантии, что там лежит ровно тот же 5.6, что и был в предыдущем образе. В предыдущем, предположим, был 5.6.28, а в регистри уже обновился до 5.6.45 (цифры с потолка). Т.е. вы НЕ вернулись в предыдущее состояние.
2. В случае снапшота системы целиком вы просто запускаетесь из снапшота. В вашем сценарии вы убиваете контейнер, который у вас не завелся — это раз, затем создаете новый вольюм с бэкапом (кстати, он у вас КОПИЯ, т.е. где-то могли права доступа к файлам «поехать» или еще что-то по мелочам, что вы выясните уже гораздо позже) — это два, пересоздали и запустили новый контейнер без гарантии полной идентичности версии (в докер-образе mysql:5.6 5.6 — это ТЕГ контейнера, который, по джентльменскому соглашению с сопровождающими образ совпадает, вроде как, с версией мускуля, при этом не гарантированно совпадает).
Т.е. вы сделали 3 шага вместо одного, вы имеете МЕНЬШУЮ вероятность отката в предыдущее состояние.
Т.е. мы имеем:
1. Более длительный откат состояния (за помощь от докера не засчитывается).
2. Вы получили меньше гарантий возврата в исходное состояние (тоже помощью считать трудно).
3. Вы не получили внятной информации о происходящем и затруднили себе отладку всей этой ситуации (тоже, вроде, не помощь).
Понимаете, докер — это про rolling release. Вот там он цветет и пахнет. Крутить СУБД на rolling-release версиях — так себе удовольствие.
На самом деле, это так и работает. Берешь volume от 9-го, подключаешь к 10-му. Он делает какую-то магию и обновляет БД.
Ну вот этот подход «там произошла какая-то магия, и оно теперь работает» — это малоприемлемо на боевых окружениях со сколько-нибудь ценными данными. Отмазка уровня «какая-то магия как-то там не сработала, и теперь у нас почему-то ничего никак не работает» — это плохая отмазка.
Миграция на новую версию БД — это само по себе отдельная песня, и докером она решается примерно никак. В проде — мигрируем руками, в дев-окружении… Ну, в локальных девелоперских окружениях, почему бы и нет. Но там вам, если быть откровенным, ни консистентность данных, ни надежность хранения, ни миграции какие-то не нужны. В дев-окружении необходимо иметь возможность «в случае чего в разумное время заполучить что-то работающее с какими-то правдоподобными данными». Вы же не собираетесь всерьез бэкапить девелоперскую базу?
Да, правда при вышеописанном процессе запуск volume с обновленными данными со старым 9-м постгрессом зафейлится, т.к. в БД уже будет пометка, что она переконвертирована в 10-ю версию.
Это проверено на моем личном опыте.
Вот и я о том же, происходит миграция/конвертация данных. Поэтому уровень хранения данных для СУБД, собственно, от рантайма неотделим. Так что и снапшотить проще и лучше целиком состояние системы, причем, как показывает практика, иногда с точностью до версии ядра или номера версии «третьей сверху системной библиотеки, которая, вроде, и отношения к БД не имеет»
бекапить постгре в контейнере тоже просто. Версия ПО и все ее зависимости — в образе, который лежит в локальном реджистри. Данные — снаружи. И их можно либо бекапить с простоем БД пофайлово, либо утилитами для работы с БД, которые умеют нагорячую. На рабочей же типовой системе — нужно бекапить И конфиги, И базу, и вероятно исполняемые модули (если какая-то хитрая схема экстеншенов). Окей, можно и только базу, но все равно все остальное нужно учитывать. Т.е. докеризация позволяет переложить сложность работы информационной системы с одного уровня на другой (в общем об этом все новомодные технологии вроде k8s)
Бэкапить БД на уровне логической целостности — просто сделать sqldump. Контейнер на этом уровне не дает вам ничего. Бэкапить БД на уровне физической целостности — отдельный бэкап файлов на диске, с которыми работает СУБД вам опять же ничего не даст. Оно просто не в вакууме живет, и окружение, на котором это все работает, достаточно много значит. Есть же контейнеры ОС, забэкапьте целиком. Собственно, из сценариев быстрого отката в случае БД смысл имеет только бэкап системы. В конце концов, есть же LXD и некоторые другие «контейнеры ОС», дались вам эти «контейнеры приложений».
А докеризация никаких проблем в этом контексте не решает. С точки зрения БД вам один фиг под конкретные кейсы «твикать» окружение придется. А пересобирать окружение под конкретные настройки конкретной базы — тоже та еще дичь, если честно.
К слову, тот же k8s — он вообще не эти проблемы решает. Он про оркестрацию, ничего там про организацию бэкапов/миграций БД нету, я проверял.
Ну и про «рентабельность» всего этого мероприятия (я про контейнеризацию БД). Обычно «докеризованные» сборки СУБД предполагают сценарий «запустить 1 базу на сервере». А СУБД кэшировать любят, индексы строить всяческие и т.д. и т.п. Вот с рациональностью использования ресурсов будут большие вопросы в этом подходе. Запустишь 50 инстансов, в каждом по постгресу. И ограничения выставишь, чтобы «разумно использовать ресурсы». И будет у тебя 40 баз в оперативке лежать закешированные целиком, и еще 10 дейтсвительно «тяжелых» раком встанут под нагрузкой, причем «в среднем по палате» нагрузка на сервер будет околонулевой.
А потом появится база, которая не будет «вытягивать» в рамках отдельной машины — и вот тут встанет вопрос «кластера», репликаций и всего вот этого, что в контейнере приложения делается строго «никак».
И весь этот геморрой для решения проблемы… чего, собственно? Какую проблему мы решаем? Проблему обновления версии СУБД, которая нам встречается раз в год-два? Не та это задача, которую «автоматизируют» и «ставят на поток». Или проблему сохранности данных? Ну, собственно, и для нее контейнеры приложений решения не предоставляют. Проблему масштабирования? Не масштабируются РСУБД «в лоб» горизонтально…
Как вариант — использование докера в качестве промежуточного сборочного этапа (т.е. на входе вольюм с сурцами, на выходе — вольюм с бинарниками, посередине — докер-контейнер со всеми зависимостями для сборки).
Собственно, для этого специальный stage в докер добавили не так давно. Специальный билд-контейнер, по факту.
В общем, все равно мы приходим к идее, что использование контейнеров весьма многогранно и не ограничивается концепцией развертывания приложений в продуктовой среде по принципу «один контейнер — один процесс».
Практика показывает, что использование «контейнера приложений» типа докера офигенно себя показывает именно в схеме «один контейнер-один процесс». Подход 12-факторных приложений, воспроизводимые сборки и т.д. и т.п. — все это офигенно работает в контексте докера.
При этом она же показывает, что часть задач «контейнеры приложений» решать не способны, ну просто не маппятся эти задачи на логику контейнера. Собственно, те же РСУБД и не маппятся, собственно. В каких-то задачах докеро-подобные решения дают профит, в каких-то профита нет, а в каких-то лучше докер-со-товарищи и не трогать. И это факт.
А вот то, что «не докером единым» — это факт. Есть, собственно, тот же LXD, который «контейнер ОС». Но он решает уже другие задачи, правда из профитов «в лоб» дает разве что экономию ресурсов, т.е. «не взлетит».
Ну и, по поводу «контейнер все-в-себе-и-даже-БД»… говно подход. При этом задача уже тысячу лет как решена, есть вполне себе вменяемая оркестрация — docker-compose для мелочей на локалхосте, k8s — для продакшена и тысяча решений где-то между этими двумя крайними точками. При этом поверх того же k8s уже пилятся свои обертки… Короче, оно все растет.
Хотите «чистую» инсталляцию с «только необходимыми данными» — я вас расстрою. Докер тут помогает «никак». Единственный путь: сдампить БД => поднять «голый» инстанс новой версии => развернуть данные из дампа. Автомиграции контейнера к «чистоте» вообще никак не ведут.
Откат на предыдущую версию, выкашивание изменений… Кхм, вы о чем? Сделайте снапшот системы ДО начала миграции. Не получилось — восстановились из снапшота. И быстро, и качественно.
Контейнер приложения НЕ гарантирует вам неизменность состояния, к которому вы планируете вернуться. Он гарантирует воспроизводимость сборки, более ничего.
Спорно, конечно, но так тоже можно. Это уже от применения зависит.
Если вы пилите какой-то веб-проект и конкретно под него собираете контейнер — вполне норм подход.
Если вы хостите сторонние приложения, вам логичнее собрать преднастроенный контейнер-окружение и маппить в него пользовательские «папки», чем ребилдить образ на каждый чих от пользователя.
Конкретно докер вообще никак не маппится на нужды поддержания консистентности БД. Вся концепция контейнеров приложений строится вокруг «мухи отдельно, котлеты отдельно».
В подходе контейнера приложения само приложение — это такая штука, которую совершенно не жалко потерять. Можно пересобрать, перезапустить и вообще делать миллион различных вещей в расчете на то, что все ровно то же самое можно пересобрать и воспроизвести из исходников за достаточно ограниченное время.
Вот с вещами вроде постгреса подход не работает.
Нельзя вот просто так взять persistent volume, на котором работал 9-й постгре и примонтировать его к контейнеру 10-го. А если вы попрыгали с бубном и примонтировали таки, вы уже не сможете по-быстрому откатиться на 9-ю версию.
Собственно структура хранения данных в РСУБД, как правило, очень сильно привязана к версии движка, поэтому вот эти вещи типа «быстрых переключений между версиями безо всяких проблем» — это из разряда сказок на ночь.
Бэкап уровня данных — хорошо. При этом забэкапить контейнер ОС (предположим LXD) с развернутым постгресом и данными до кучи — гораздо более простая в реализации и более быстрая с точки зрения «восстановления» или «отката» идея. Тем более, что базы данных вроде постгре имеет смысл использовать на датасетах такого размера, когда «накладные расходы 50МБ на бэкап самого постгреса» — это совершенно малозначимая вещь.
Просто если развивать концепцию до абсурда, то каждый настоящий мужчина должен ставить постгрес (например) не из бинарного пакета (deb/rpm), а из исходников (make && make install — да, давайте замочим систему «мусором»).
Как бы ни смешно это звучало, именно необходимость сборки из исходников — самый вероятный сценарий обоснованного использования постгреса в докере. Т.е. контейнер, который сам собирает постгрес из его исходников на гитхабе одной командой — норм идея. С одним нюансом — в проде такой подход так себе идея.
Собственно, я несколько далек от php и принятых в нем практик, конечно, и представления о том, что такое webroot и для чего его можно использовать, конечно, у нас могут различаться. Если под webroot'ом понимать папку с конфигами сервера, конфигурациями эндпоинтов, шаблонами для рендера, скриптами и все вот это — совершенно не вижу проблемы в совместном использовании… В readonly режиме.
Т.е. вы наконфигуряли то, что вам надо, разложили скрипты в желаемом порядке настроили, а потом все это «окружение» скормили N контейнерам (нет, N мало, пусть лучше будет K), чтобы они оттуда заинитились и начали работать — нормальный подход.
Если же вы на N контейнеров (в этом случае N уже много, лучше ограничиться M) отдали volume на запись… Кхм, даже при M=2 это УЖЕ плохая идея. Предложить нескольким процессам одновременно писать в один файл — это идея хреновая, вне зависимости от контейнеризации. В рамках одного процесса писать в файл параллельно из двух потоков — уже говнокод, простите уж за откровенность. Не надо так делать, пожалуйста. Шарить persistent volume между несколькими контейнерами безопасно только в read-only режиме.
Как минимум затем, чтобы не заморачиваться межконтейнерными связями, которые в общем случае «почему-то» настроить сложнее, чем межпроцессными связями в рамках одного контейнера/хоста/неймспейса.
Вы точно уверены, что имеете понятие о том, что вы говорите?
Вот ЭТО — базовый докерфайл для нормального контейнеризованного постгреса. Вы вот прямо утверждаете, что принести ЭТО в свой контейнер, а потом поддерживать ЭТО в случае надобности изменений — это проще, чем написать docker-compose.yml? На фоне ЭТОГО link: -postgres — сложно?
Целью контейнеризации приложения может выступать не только и не столько возможность относительного простого горизонтального масштабирования, но и, например, фиксация окружения приложения. Проще говоря, обеспечение очень схожих окружений в средах разработки, тестирования и эксплуатации.
И опять вы, вероятно, хотите видеть слезы ни в чем не повинных авторов подхода. «Схожесть» окружений в средах разработки, тестирования и эксплуатации достигается тем, что во всех этих средах запускаются ОДНИ И ТЕ ЖЕ образы контейнеров, заради этого, собственно, все и затевалось. Зачем писать отдельный образ, который будет «вести себя почти как боевой», если можно просто развернуть копию боевого. Заодно не понадобится аккуратно ручками носить изменения из одного докерфайла в другой, лежащий по соседству.
Не выдавайте, пожалуйста, свои личные фантазии за «полезные практики». Сколько-нибудь полезной практики ношения СУБД в одном контейнере с сервисом не существует в природе.
Ну, собственно, php, пишущий в webroot — это «с душком» называется, если мы в контексте «горизонтального масштабирования без боли».
Собственно, если php «какает» в webroot, то «поднять N контейнеров с этим php и смонтировать в них вольюмом один webroot на всех» — заведомо хреновая идея, например.
Кхм, БД разные бывают. Предлагаю не считать таки Postgre, MsSql, OracleDB и прочие махровые энтерпрайзные РСУБД устаревшим мусором, ок?
Просто вот с ними все эти штуки вроде «простое увеличение количества реплик в statefulset приведет к автоматическому масштабированию» не работают. Тем более, что выше была идея именно потгре/мускуль в контейнер засунуть. Ну так вот — это плохая идея, и вот эти вещи так не масштабируются.
Нюанс в том, что «единица развертывания — под», как раз, отрицает подход «докер-контейнер как единица развертывания».
Связность сервисов/уровня данных обеспечивается на уровне пода, нет смысла городить все это внутри докера, не для того он. На уровне инициализации контейнера та же БД должна быть ссылкой, откуда ее взять. Не надо внутрь него движок базы данных тащить, плохая это идея.
Вы же понимаете, что простенькая веб-морда над постгре-БД, упакованная в контейнер с базой данных не может считаться «all-in-one в разумной мере»?
Вот эти требования, как правило, аморальны и непрактичны. С какой такой целью вам потребовалось прибить гвоздями коннект к постгре к файловому сокету в условиях докерной изоляции?
Ну вот мы и пришли к тому, что постгре на локалхосте для самого приложения абсолютно идентичен постгре в сети. Теперь все же вопрос: с какой целью вы отказываете пользователю в возможности использовать remote постгре, при этом еще и в контексте «контейнера приложения». Философия у докера достаточно простая: запускаем процесс в изолированном окружении, как только процесс загнулся — киляем окружение до кучи. Это просто и это работает. Как только вы прикручиваете контроль запуска соседних сервисов при запуске приложения и впиливаете gracefull shutdown в код самого приложения — вы обкладываетесь граблями. Как только вы прикручиваете supervisord и прочие иниты в качестве основного процесса в докер — вы обкладываетесь граблями. Если вам нужен полноценный инит с контролем зависимостей, с графом запуска и прочей фигней, не родной для контейнера приложения, возможно, вам просто нужен контейнер ОС?
Потом юзер ставит ваш «чудесный сервис» с постгре унутре к себе на машинку, и все чудесно… Ага… Рядом он поднимает еще парочку, и вуаля, у него 3(три!!!) постгреса, работающие на локальной машинке. А потом он в этот зоопарк запускает еще пользователей, штук 10. И долго думает на тему: почему все встало раком. А потом до него доходит, что 3 постгри на одной машине не есть хорошо, и он поднимает себе отдельную машинку с целью унести «БД вашего гитлаба» туда… А потом он читает 150-страничный мануал по докеру на тему «как распилить один всратый докерфайл на два, чтобы ничего не поломалось». И даже распилил, а ваш божественный образ только по файловому сокету в базу ходить умеет…
Вот и пытаюсь я понять, ЗАЧЕМ вы это делаете?
Несколько постов назад меня пытались убедить, что такие контейнеры хороши в целях отладки и разработки. Т.е. когда в кишках копаться таки надо.
Отличная техника, сам пользуюсь и остальным рекомендую. С одним маленьким нюансом — в контейнере должно быть то, что вы непосредственно пишете. Сделали правки, пересобрали контейнер, погоняли тесты, засунули куда надо. При этом бывает такая надобность — погонять свежесобранную версию на нескольких датасетах. Все их будем локально складировать? Или таки отпилим базу данных от непосредственно собираемого сервиса, и будем цеплять нужный датасет по урлу, передаваемому в переменной окружения?
К тому же в НОРМАЛЬНОЙ практике стремятся к тому, чтобы dev|test|prod образы собирались из одного и того же докерфайла, чтобы не отлаживать еще и их. Если один образ помечен dev, это не значит, что его dockerfile отличается от prod-образа. В нем просто, как правило, лежат разные версии софтины и собирается, возможно, он с разными переменными среды.
Вот это, в теории, может быть кейсом. При условии, что база либо констрактится на лету из дампа каждый раз при запуске тестов (что сказывается на скорости прохождения этих тестов), либо подмонтирована в read-only, чтобы реран тестов не мог сломать все к чертям. Но это совсем специфический случай, и к «отдать клиенту постгре, упакованный вместе с сервисом» относится мало. Просто клиент за такой подход и проклясть может.
Прод и дев, конечно, не должны быть ни в коем случае идентичными, иначе нахрена их вообще разделять. Другое дело, что собираться они должны из одного и того же докерфайла, например. Или, по крайней мере, стремиться к этому нужно. Вся эта каша и заваривалась заради того, чтобы анекдот «у меня все работает» стали историей.
В разработческом окружении должна быть ровно та же версия glibc, тот же набор установленных пакетов, что и в проде. Элементарно «в лоб» ловите багу:
— на прод окружении мы подключаемся к удаленному серверу postgre (это нормальный подход);
— соответственно сам постгре-сервер на проде не стоит (и это абсолютно правильно);
— в dev-окружение вы для «простоты отладки» постгре-сервер запихали;
— разработчик воткнул в код вызов pgdump перед какой-то «особо опасной» операцией.
Теперь, внимание, вопрос, почему на сервере сервис крашится, а «у разработчика все работает»?
Вот эта «определенная степень схожести» обычно определяется как «собрано из одного и того же докерфайла». Возможно, с разными ключами сборки, со своими нюансами, но из одного и того же, иначе вся эта мутотень, которую вы затевали с контейнеризацией — зря.
Датасайентист, тестировщик и прочие человеки, которые хотят «просто запустить, чтобы работало» не отличат, смею вас заверить, «docker start» от «docker-compose up», например, и для них такой подход монопенисуален подходу с «все в один контейнер».
А вот вы, как администратор, должны понимать, где зарыта грабля, и почему так не стоит делать. Впрочем, если вы «администратор локалхоста», вопрос можно снять. Но не выдавайте «best practices» локалхоста за «best practices» системного администрирования.
О какой «взаимной настройке компонент» мы говорим в случае Postgre? Постгре «калибруется» под железку, на которой он крутится, под размеры базы и прочие специфические вещи. Т.е. он калибруется конкретно под задачи и окружение. Приложение, которое с ним работает, для работы с постгре во «взаимной настройке компонент» не нуждается. От слова «никак». Оно просто должно получать на вход одну строчку с описанием «куда к базе коннектиться». При этом, при росте базы, миграциях и изменениях структуры базы постгре можно беспроблемно перенести на другую машинку, дать ему больше памяти или io… Хотя, нет, в случае, если он у вас в том же контейнере лежит — нельзя.
При этом представим ситуацию: вы мне дали образ с упакованным внутри приложением + постгре. Мне понравилось, я нашел еще 10 приложений с таким же «профессиональным подходом». Вуаля, у меня на локалхосте крутится 11 (одиннадцать, Карл!!!) инстансов постгре. При этом каждый из них стремится отожрать всю память, которая ему доступна, в целях кеширования (мы же не думаем, что человек, не способный настроить ручками коннект к постгре, способен грамотно лимитами разделить 11 инстансов этого самого постгре в пределах одного инстанса).
Нету такого кейса за пределами вашего личного локалхоста, где упаковка постгре в один контейнер с приложением — хорошая идея. И если «у меня на локалхосте все норм», это не значит, что стоит пытаться выдавать это за сколько-нибудь хорошую практику.
Если постгрес должен иметь возможность конфигурироваться и управляться извне контейнера (а так бывает чуть менее, чем всегда, в случае постгреса), его однозначно проще иметь в отдельном контейнере. В конце концов, вы же для разработческих целей его, вроде, хотели иметь. Вполне реален кейс, когда разработчик что-то накосячил, и нужно отключить от постгреса всех клиентов и пошарить у него в кишках ручками. Вот этот кейс вы как собираетесь реализовывать в своем монолитном контейнере? Докерфайл править, или код приложения?
Сейчас открою вам тайну. docker-compose — это не сервис, не подсистема и не что-то уберсложное. Это просто парсер конфигов, который на выходе отдает все вот эти конструкции docker start --дальше-миллион-параметров. Вы можете ровно то же самое сделать руками. Я вам честно говорю, с постгре внутри контейнера вы огребете гораздо больше геморроя, чем от — link: postgre в докер-компоуз файле.
Не все — это конкретно постгре. Он, обычно, из образов не разворачивается, и нефиг ему внутри них делать, соответственно.
В общих чертах идентичность окружения как раз гарантируется. Поэтому и принято на разработческих окружениях крутить ровно те же версии контейнеров, что и в проде, чтобы хоть какие-то гарантии иметь. Собственно, исключительно заради этой фишки все и затевалось. Если у вас приложение для разработчика обернуто в один докерфайл, а в проде — в другой, в вашем монастыре что-то не так с уставом.
Версии ядра-то тут при чем? Контейнер как таковой строится поверх libc, и контейнер как раз изолирует libc нужной версии, с точностью до ABI. Короче, ядро не при делах, если чо.
Замените docker-compose файлом, или оберните соответствующими sh-скриптами, или, например, завертите все в кубере — и будет вам счастье.
Заметьте, я, по сути, не возражаю против наличия нескольких взаимосвязанных процессов внутри контейнера. Есть, действительно, кейсы, когда «чистота подхода» не стоит свеч. Но это кейсы, когда «сервис снаружи» действительно накладывает дополнительные затраты на разработку и обкладывание костылями. Тут уже упоминали VPN-ки, сборку метрик и все вот это. Просто postgre — это заведомо не тот случай, который сколько-нибудь проще решить внутри монолитного контейнера, его, как раз, а) проще, б) разумнее иметь снаружи.
Вы же сами все и объяснили. Не только желательно, но и нужно, чтобы все это поехало в куб с минимальными изменениями. Поэтому варианта «один контейнер всё-всё-всё внутри» просто не существует. Да, в некоторых местах будет непросто, но никто и не обещал, что жизнь будет малиной.
Перед вами стоит вполне реальная проблематика: миграции БД, которые однозначно затем понадобятся в прод-окружении. Т.е. задачу взаимосвязности сервисов на уровне оркестрации решать все равно придется, почему этим не заняться на этапе проектирования/пруф-оф-концепта? Зачем обязательно выносить этот геморрой на этап «у нас все готово, осталось на прод вытащить». Когда на этом этапе вылазят такие вот «О, хоспади, слона-то я и не приметил», это верный признак в корне неверного подхода.
Вы же КОПИЮ volume'а создадите. Это будут НОВЫЕ файлы, НОВЫЕ файловые дескрипторы и все вот это. Тот же постгре после отката на совершенно законных основаниях может начать ребилдить индексы, реструктурировать хранилище и все вот эти вещи, которые он так прикольно умеет делать, что может отсрочить возвращение базы в строй «на некоторое слабопредсказуемое время». Думаю, этот кейс мы тоже в плюсы «докеризации» записывать не будем?
1. Представим, что у вас контейнер mysql:5.6, вот прям с тэгом 5.6. При этом у вас НЕТ гарантии, что там лежит ровно тот же 5.6, что и был в предыдущем образе. В предыдущем, предположим, был 5.6.28, а в регистри уже обновился до 5.6.45 (цифры с потолка). Т.е. вы НЕ вернулись в предыдущее состояние.
2. В случае снапшота системы целиком вы просто запускаетесь из снапшота. В вашем сценарии вы убиваете контейнер, который у вас не завелся — это раз, затем создаете новый вольюм с бэкапом (кстати, он у вас КОПИЯ, т.е. где-то могли права доступа к файлам «поехать» или еще что-то по мелочам, что вы выясните уже гораздо позже) — это два, пересоздали и запустили новый контейнер без гарантии полной идентичности версии (в докер-образе mysql:5.6 5.6 — это ТЕГ контейнера, который, по джентльменскому соглашению с сопровождающими образ совпадает, вроде как, с версией мускуля, при этом не гарантированно совпадает).
Т.е. вы сделали 3 шага вместо одного, вы имеете МЕНЬШУЮ вероятность отката в предыдущее состояние.
Т.е. мы имеем:
1. Более длительный откат состояния (за помощь от докера не засчитывается).
2. Вы получили меньше гарантий возврата в исходное состояние (тоже помощью считать трудно).
3. Вы не получили внятной информации о происходящем и затруднили себе отладку всей этой ситуации (тоже, вроде, не помощь).
Понимаете, докер — это про rolling release. Вот там он цветет и пахнет. Крутить СУБД на rolling-release версиях — так себе удовольствие.
Ну вот этот подход «там произошла какая-то магия, и оно теперь работает» — это малоприемлемо на боевых окружениях со сколько-нибудь ценными данными. Отмазка уровня «какая-то магия как-то там не сработала, и теперь у нас почему-то ничего никак не работает» — это плохая отмазка.
Миграция на новую версию БД — это само по себе отдельная песня, и докером она решается примерно никак. В проде — мигрируем руками, в дев-окружении… Ну, в локальных девелоперских окружениях, почему бы и нет. Но там вам, если быть откровенным, ни консистентность данных, ни надежность хранения, ни миграции какие-то не нужны. В дев-окружении необходимо иметь возможность «в случае чего в разумное время заполучить что-то работающее с какими-то правдоподобными данными». Вы же не собираетесь всерьез бэкапить девелоперскую базу?
Вот и я о том же, происходит миграция/конвертация данных. Поэтому уровень хранения данных для СУБД, собственно, от рантайма неотделим. Так что и снапшотить проще и лучше целиком состояние системы, причем, как показывает практика, иногда с точностью до версии ядра или номера версии «третьей сверху системной библиотеки, которая, вроде, и отношения к БД не имеет»
Бэкапить БД на уровне логической целостности — просто сделать sqldump. Контейнер на этом уровне не дает вам ничего. Бэкапить БД на уровне физической целостности — отдельный бэкап файлов на диске, с которыми работает СУБД вам опять же ничего не даст. Оно просто не в вакууме живет, и окружение, на котором это все работает, достаточно много значит. Есть же контейнеры ОС, забэкапьте целиком. Собственно, из сценариев быстрого отката в случае БД смысл имеет только бэкап системы. В конце концов, есть же LXD и некоторые другие «контейнеры ОС», дались вам эти «контейнеры приложений».
А докеризация никаких проблем в этом контексте не решает. С точки зрения БД вам один фиг под конкретные кейсы «твикать» окружение придется. А пересобирать окружение под конкретные настройки конкретной базы — тоже та еще дичь, если честно.
К слову, тот же k8s — он вообще не эти проблемы решает. Он про оркестрацию, ничего там про организацию бэкапов/миграций БД нету, я проверял.
Ну и про «рентабельность» всего этого мероприятия (я про контейнеризацию БД). Обычно «докеризованные» сборки СУБД предполагают сценарий «запустить 1 базу на сервере». А СУБД кэшировать любят, индексы строить всяческие и т.д. и т.п. Вот с рациональностью использования ресурсов будут большие вопросы в этом подходе. Запустишь 50 инстансов, в каждом по постгресу. И ограничения выставишь, чтобы «разумно использовать ресурсы». И будет у тебя 40 баз в оперативке лежать закешированные целиком, и еще 10 дейтсвительно «тяжелых» раком встанут под нагрузкой, причем «в среднем по палате» нагрузка на сервер будет околонулевой.
А потом появится база, которая не будет «вытягивать» в рамках отдельной машины — и вот тут встанет вопрос «кластера», репликаций и всего вот этого, что в контейнере приложения делается строго «никак».
И весь этот геморрой для решения проблемы… чего, собственно? Какую проблему мы решаем? Проблему обновления версии СУБД, которая нам встречается раз в год-два? Не та это задача, которую «автоматизируют» и «ставят на поток». Или проблему сохранности данных? Ну, собственно, и для нее контейнеры приложений решения не предоставляют. Проблему масштабирования? Не масштабируются РСУБД «в лоб» горизонтально…
Собственно, для этого специальный stage в докер добавили не так давно. Специальный билд-контейнер, по факту.
Практика показывает, что использование «контейнера приложений» типа докера офигенно себя показывает именно в схеме «один контейнер-один процесс». Подход 12-факторных приложений, воспроизводимые сборки и т.д. и т.п. — все это офигенно работает в контексте докера.
При этом она же показывает, что часть задач «контейнеры приложений» решать не способны, ну просто не маппятся эти задачи на логику контейнера. Собственно, те же РСУБД и не маппятся, собственно. В каких-то задачах докеро-подобные решения дают профит, в каких-то профита нет, а в каких-то лучше докер-со-товарищи и не трогать. И это факт.
А вот то, что «не докером единым» — это факт. Есть, собственно, тот же LXD, который «контейнер ОС». Но он решает уже другие задачи, правда из профитов «в лоб» дает разве что экономию ресурсов, т.е. «не взлетит».
Ну и, по поводу «контейнер все-в-себе-и-даже-БД»… говно подход. При этом задача уже тысячу лет как решена, есть вполне себе вменяемая оркестрация — docker-compose для мелочей на локалхосте, k8s — для продакшена и тысяча решений где-то между этими двумя крайними точками. При этом поверх того же k8s уже пилятся свои обертки… Короче, оно все растет.
Откат на предыдущую версию, выкашивание изменений… Кхм, вы о чем? Сделайте снапшот системы ДО начала миграции. Не получилось — восстановились из снапшота. И быстро, и качественно.
Контейнер приложения НЕ гарантирует вам неизменность состояния, к которому вы планируете вернуться. Он гарантирует воспроизводимость сборки, более ничего.
Если вы пилите какой-то веб-проект и конкретно под него собираете контейнер — вполне норм подход.
Если вы хостите сторонние приложения, вам логичнее собрать преднастроенный контейнер-окружение и маппить в него пользовательские «папки», чем ребилдить образ на каждый чих от пользователя.
В подходе контейнера приложения само приложение — это такая штука, которую совершенно не жалко потерять. Можно пересобрать, перезапустить и вообще делать миллион различных вещей в расчете на то, что все ровно то же самое можно пересобрать и воспроизвести из исходников за достаточно ограниченное время.
Вот с вещами вроде постгреса подход не работает.
Нельзя вот просто так взять persistent volume, на котором работал 9-й постгре и примонтировать его к контейнеру 10-го. А если вы попрыгали с бубном и примонтировали таки, вы уже не сможете по-быстрому откатиться на 9-ю версию.
Собственно структура хранения данных в РСУБД, как правило, очень сильно привязана к версии движка, поэтому вот эти вещи типа «быстрых переключений между версиями безо всяких проблем» — это из разряда сказок на ночь.
Бэкап уровня данных — хорошо. При этом забэкапить контейнер ОС (предположим LXD) с развернутым постгресом и данными до кучи — гораздо более простая в реализации и более быстрая с точки зрения «восстановления» или «отката» идея. Тем более, что базы данных вроде постгре имеет смысл использовать на датасетах такого размера, когда «накладные расходы 50МБ на бэкап самого постгреса» — это совершенно малозначимая вещь.
Как бы ни смешно это звучало, именно необходимость сборки из исходников — самый вероятный сценарий обоснованного использования постгреса в докере. Т.е. контейнер, который сам собирает постгрес из его исходников на гитхабе одной командой — норм идея. С одним нюансом — в проде такой подход так себе идея.
Т.е. вы наконфигуряли то, что вам надо, разложили скрипты в желаемом порядке настроили, а потом все это «окружение» скормили N контейнерам (нет, N мало, пусть лучше будет K), чтобы они оттуда заинитились и начали работать — нормальный подход.
Если же вы на N контейнеров (в этом случае N уже много, лучше ограничиться M) отдали volume на запись… Кхм, даже при M=2 это УЖЕ плохая идея. Предложить нескольким процессам одновременно писать в один файл — это идея хреновая, вне зависимости от контейнеризации. В рамках одного процесса писать в файл параллельно из двух потоков — уже говнокод, простите уж за откровенность. Не надо так делать, пожалуйста. Шарить persistent volume между несколькими контейнерами безопасно только в read-only режиме.
Вы точно уверены, что имеете понятие о том, что вы говорите?
Вот ЭТО — базовый докерфайл для нормального контейнеризованного постгреса. Вы вот прямо утверждаете, что принести ЭТО в свой контейнер, а потом поддерживать ЭТО в случае надобности изменений — это проще, чем написать docker-compose.yml? На фоне ЭТОГО
link: -postgres— сложно?И опять вы, вероятно, хотите видеть слезы ни в чем не повинных авторов подхода. «Схожесть» окружений в средах разработки, тестирования и эксплуатации достигается тем, что во всех этих средах запускаются ОДНИ И ТЕ ЖЕ образы контейнеров, заради этого, собственно, все и затевалось. Зачем писать отдельный образ, который будет «вести себя почти как боевой», если можно просто развернуть копию боевого. Заодно не понадобится аккуратно ручками носить изменения из одного докерфайла в другой, лежащий по соседству.
Не выдавайте, пожалуйста, свои личные фантазии за «полезные практики». Сколько-нибудь полезной практики ношения СУБД в одном контейнере с сервисом не существует в природе.
Собственно, если php «какает» в webroot, то «поднять N контейнеров с этим php и смонтировать в них вольюмом один webroot на всех» — заведомо хреновая идея, например.
Просто вот с ними все эти штуки вроде «простое увеличение количества реплик в statefulset приведет к автоматическому масштабированию» не работают. Тем более, что выше была идея именно потгре/мускуль в контейнер засунуть. Ну так вот — это плохая идея, и вот эти вещи так не масштабируются.
Связность сервисов/уровня данных обеспечивается на уровне пода, нет смысла городить все это внутри докера, не для того он. На уровне инициализации контейнера та же БД должна быть ссылкой, откуда ее взять. Не надо внутрь него движок базы данных тащить, плохая это идея.