Не-не-не, Девид Блейн! Меня не проведешь, еще раз проверил всю ветку. Я все еще в контексте, вы — выпали.
Мы обсуждаем вариант «поставка приложения вместе со своей postgresql-базой бандлом в одном докер-контейнере». И я утверждаю, что это говно идея, т.к. а) неприменимо в проде, б) неэкономно с точки зрения расхода ресурсов на несколько инстансов приложения, в) становится полным бредом при наличии в организации отдельного сервера БД, г) неконфигурируемо, д) заранее ведет к отказу от репликации, фейловеров БД, возможности использования кластеров.
На фоне этого ваше «никто не мешает настроить несколько инстансов БД, опубликовать их, например, на внешних портах хостов и связать их репликацией» подтверждает, что наличие отдельно стоящих БД — вполне себе нормальная практика, и вы согласны, что оно надо. При этом вы выпали из контекста, и не заметили, что в изначальном контексте фейловеры, кластеры и репликации недоступны, т.к. «только 127.0.0.1, только хардкор», «локалхоста хватит всем» и «настроить — это сложно».
Вот против этого подхода я и протестую. Приложение, тем более вроде ставшего «эталонным» в этом треде gitlab'а от omnibus, рассчитанное на многопользовательскую среду, да еще и с постоянным ростом базы и потенциальным ростом базы клиентов так «пакетить» — говно подход.
Чтобы операторы кубернетса «реализовывали функционал», нужен stateful-контейнер, отдельный, с БД. БД-на-локалхосте не вканает.
В случае же докер-контейнеров, которые прибиты гвоздями к конкретным машинам — никаких проблем настроить репликацию нет.
В смысле, вы локальную БД, засунутую в контейнер с приложением, без всяких проблем, например в кластер засунете? Или логическую репликацию поднимете на условиях, что слейв мастера не видит? Или фейловер на условиях, что клиент видит только один из серверов? Я что-то не знаю?
1) приложение принимает в текстовом конфиге, конфиг монтируется в контейнер.
Оно в текстовом конфиге только локальный файл-сокет принимает?
2) описан, но есть разные варинаты описания, например не из официального образа, а из своего с официальным мало общего имеющего.
И в чем суть проблемы? Постгре какой-то другой модели?
3) локально что хотите делайте, главное чтоб в гит репу не попадало
Вы неверно прочли, это вы представили docker-compose с образом, указанным разработчиками и прилагаемыми конфигами проблемой. Я как раз не вижу в этом проблемы. Вы либо берете, что вам сказали, либо смотрите в эти конфиги и поднимаете свой постгре с требуемыми настройками. В чем проблема?
4) а как ещё сделаете, чтобы записи в pg_hba.conf обновлялись при поднятии контейнера с приложением? Не, я знаю как: постгри в один контейне с приложением и с 127.0.0.1 доступ :)
Еще можно DNS воспользоваться (не надо про задержки, резолвер локальный), еще доступ по ключу, по паролю. В конце концов, если вы в изолированной подсети, поставьте пароли плейнтекстовые. Будет не хуже локального «127.0.0.1-можно-все».
5) в том-то и дело, что зашить можно только один по сути, 127.0.0.1 ну или вариации.
Зашить можно много чего, например, вплоть до «из локальной подсети можно» — прочтите доку по постгре, не айпишником единым, знаете ли.
Не в условиях докерной изоляции, а докером оборачивали уже существующую конфигурацию.
Т.е. «исторически сложилось» уравниваем с «нормальная практика»?
В предлах локалхоста в одном контейнере на постгри можно разрешить входящие с 127.0.0.1, разнося по разным контейнерам нужно динамически менять конфиги постгреса при поднятии контейнера приложения или прибивать ип-адреса гвоздями.
Или к DNS привязаться, или авторизацию по ключу настроить, или SSL включить. Довод «нам было сложно 1 раз настроить доступ к постгре, и мы решили прибить его гвоздями к локалхосту» — слабый аргумент, имхо. Экономия на спичках — это такое себе.
Если на проде крутится пресловутый гитлаб на одном «локалхосте» через файловый сокет, то...
У вас прод какой-то странный. Ну либо у вас проблемы.
Вот я про то и говорю, что именно про базы данных в любом мало-мальски энтерпрайзном окружении есть набор требований. Причем именно требование «носить базу с собой» не встречается нигде, а упаковка БД в контейнер ведет к невыполнимости требования о репликации.
Прикол в том, что docker и lxd — это абстракции ровно одного уровня. Два инструмента поверх lxc, один из которых затачивается на умелку снапшотит состояние системы и мимикрирует под ОС, второй построен на подходе «зато можно быстро пересобрать».
Чем тот, который «пересобрать» лучше, чем тот, который «сохранить состояние»?
Вот смотрите, я показал вам докерфайл, который считается «эталонным так надо делать» среди сторонников подхода «БД с приложением — это нормально». Более адекватных примеров такого подхода я вживую не видел, видел только вот этот конкретный пример как это бывает. И вы даже, вроде, со мной согласны, что конечному пользователю в таком виде продукт отдавать нельзя.
Покажите, пожалуйста, пример «хорошей практики» забандленной с приложением БД. В виде докерфайла. Возможно, я с вами и соглашусь, что «вот это норм, был неправ».
Смотри, контейнеры разные бывают. Есть, например, «контейнеры приложений» (они так и называются потому, что предназначены для запуска приложений в изолированном окружении) и контейнеры ОС (они так называются, потому что «прикидываются» операционной системой). При этом, что забавно, docker как контейнер приложения и тот же lxd в качестве контейнера ОС имеют совершенно одинаковый «оверхед» из-за того, что под капотом у них происходит примерно одно и то же.
Теперь мы попробуем представить постгре, запущенный в контейнере ОС. Мы перед обновлением бекапим целиком образ системы, с установленной версией постгре, с набором библиотек и т.д. Или даже тупо снапшотимся, что тоже работает. После этого при необходимости отката мы просто откатываемся на реальное предыдущее состояние системы, а не на пересобранный «такой же» образ. Это тупо быстрее, а контейнерная изоляция, тем более в случае «приложение в куче с БД» — это лишний геморрой.
При том, что я изначально спорил только с тем тезисом, что бандлить СУБД внутрь контейнера с воркером — хреновая идея. Тем более позиционировать ЭТО как конечный продукт (для конечного пользователя) и называть нормальной практикой. Оно будет работать в пределах локалхоста, и то до поры до времени.
Протащить gitlab в докер в виде единого образа в прод — можно.
Зачем этот ужас, предназначенный для «зазырь, ОНО ШЕВЕЛИТСЯ» тащить в прод?
Для серьезного продакшена такое решение никто не рекомендует (там нужен ha postgres, балансировщики, ha хранилище и пр.)
Стоп, а до этого был какой-то «несерьезный продакшен»? Они разные бывают?
Пример, когда «база» инкапсулирована Вам привели (про тесты)
Тест-кейсы — случай сильно отдельный, там и бОльшие извращения бывают. При этом помним, что либо констракт базы на запуске теста, либо read-only ДБ. Зачем это в прод-то тащить, пусть и в «несерьезный»?
Уверен, что можно накидать еще 100500 вариантов, когда изначальный тезис про моно-образ не верен (хотя бы потому что приложение может состоять из множества разнородных процессов), но мне уже попросту лень
Про разнородные процессы я особо и не спорил, и то есть к чему придраться. Я конкретно про СУБД в контейнере.
Вы делаете странное предположение что я тащу контейнеры из общего репозитория, для продакшена я такого никогда не делаю и вам не советую. У меня есть мой Dockerfile, из него собранный образ, и в нем совершенно точно лежит именно та версия которая работала до начала обновления.
Как только разрабочиков становится более одного, это уже не гарантировано истинно.
— не понял вас, что значит «поехать»? При копировании файлов владельцем у файлов могут поменятся права?
У вас один пользователь, в смысле?
я и не спорю что его так можно использовать, пока что не понял почему вы отказываете ему в функции фиксации состояния системы? Потому что вы используете готовые контейнеры и не можете полностью положиться на систему тегов?
Вот ЭТО — эталонный докерфайл, который считается «правильным подходом» сторонниками этой точки зрения. Там прямо так и написано apt install, при пересборке мы имеем последнюю версию того, что лежит в репозитории. Каждый раз. И вот это считается «хорошим тоном» отдать конечному пользователю. ОНО может сдохнуть тупо при перезапуске в определенных случаях. Под какой-либо сколько-нибудь автоматизированной оркестрацией это запускать просто опасно.
Да, я считаю, что в данном случае НИКАК нельзя положиться на систему тегов, например. Будете убеждать меня в обратном?
Сколько видел примеров, все сходятся на одном: автоматический апгрейд версии СУБД — хреновая идея. Тем более, что, если вы не разработчик этой субд (а 99,99% — НЕ), у вас эти апгрейды должны происходить раз в полгода-год-два-три по заранее определенному регламенту.
Делается, обычно, так: поднимается свежая версия СУБД, рядом с текущей, в нее копируются данные. Не дай Б-г вам делать апдейт на живом сервере. Вот это — слабоумие и отвага. Потом копия обкатывается, делаются необходимые миграции, тесты, эта копия тестируется на новой сборке софтины, а затем уже с танцами под бубенцы начинается непосредственно миграция.
В монолитном контейнере вы по дефолту смиряетесь, что контейнер обновляется целиком версия софта + версия базы. Одновременно.
И вот этот риск заради того, чтобы сэкономить день геморроя раз в пару лет? Нету смысла это автоматизировать, поэтому и не автоматизируют.
Дополнительно — всегда контейнер можно перезапустить НЕ ПО ТЕГУ, который действительно может уже иметь под собой другой образ, а по sha-сумме, которая гарантированно отличает образы и позволяет инстанцировать из образа «тот самый» контейнер
Смотрите, у вас был контейнер с 9-й версией постгри. Вы поверх того же датасета запустили контейнер новой версии с 10-й версией. Что-то пошло не так, миграции завалились или хз вообще что. Вы запускаете взад контейнер с 9-й версией… а миграции уже начаты, назад пути нет.
Т.е. мы сошлись на том, что «бандл» приложения вместе с БД в докер-контейнере — это игрушка для локалхоста, применимая в тех местах, где админа нет, а высоких технологий хочется?
Какая вообще разница между разными, но похожими Dockerfile или параметризованным (шаблонизированном) Dockerfile с разными путями сборки для dev/prod?
Огромная разница: первое — оксюморон и «не надо так делать», второе — ваша личная фантазия. Откуда «параметризованность» и «разные пути сборки» вдруг взялись? Пути — одинаковые, ветки репозитория — разные. Улавливаете?
и «когда не нужно» (например, в случае bundle пакета)
Неправда ваша. И приложение, и база должны, как минимум, использовать один способ подключения.
Ага, один способ подключения, который, согласно общепринятой практике, передается в контейнер с приложением в виде переменной окружения… Не я придумал, все так делают.
Если приложение по сети не умеет, то постгри нужно настраивать под приложение.
Ага, нужно настраивать, причем как под основного потребителя, так и под окружение, в котором он будет крутиться. Размерами кешей поиграться, кодировки выставить и все вот это. А вы монолит нахренячили со среднепотолочными значениями. Причем отобрали у потребителя возможность засунуть БД на свой, например, высокопроизводительный кластер баз данных. «Локалхоста же всем хватит».
Чем отличается от ситуации, когда я вам дам docker-compose в котором есть и postgre?
Тем, например, что я смогу передать другое подключение к постгре воркер-контейнеру. А то, которое «в бандле», не юзать.
Причём может быть не просто тупо в приложени строка с подключением передаётся, а постгри в докер-композе описан как сервис, причём не просто ссылка на офобраз и установка env параметров, а или свой образ, или с монтированием конфигов, или и то, и другое и что-нибудь третье типа генерации конфигов постгреса на лету. Тот же список разрешенных для коннекта айпишников.
По пунктам:
1. Если воркер-контейнер не принимает в качестве ключа конфигурации подключение к произвольному постгре-серверу, автор контейнера — рукожоп, например.
2. Постгри в композе описан как сервис? А есть другие варианты? В котором он описан не как сервис? Какой ужас, вас его еще и использовать заставляют?
3. Свой образ с монтированием конфигов? Отличная шпаргалка, каких конфигов авторы желают постгресу для нормальной работы? Не? Можно сконфигурять свой адекватно запросам?
4. Генерация конфигов постгреса на лету? Жуть какая! Не пользуйтесь ЭТИМ.
5. Список разрешенных для коннекта айпишников зашитый внутрь образа? Жуть, веский повод сменить образ, например.
Линукс прекрасно умеет в CoW и KSM, что в теории может существенно сэкономить память.
Как вы будете «экономить» память 11 раздельных кешей постгреса — большой вопрос.
А еще, допустим, большой вопрос, нафига я буду поднимать 11 локальных инстансов постгреса, при условии, что у меня, например, есть отдельный сервер под эти задачи.
Вот смотрите: у вас есть докер-образ, в который чудесный создатель софта вместе со своей 2-мегабайтной веб-мордой к базе данных впилил постгре. Где может бомбануть, вы понимаете, ок. Какое решение стоит применять в случае, если бомбануло — подскажете?
Мы обсуждаем вариант «поставка приложения вместе со своей postgresql-базой бандлом в одном докер-контейнере». И я утверждаю, что это говно идея, т.к. а) неприменимо в проде, б) неэкономно с точки зрения расхода ресурсов на несколько инстансов приложения, в) становится полным бредом при наличии в организации отдельного сервера БД, г) неконфигурируемо, д) заранее ведет к отказу от репликации, фейловеров БД, возможности использования кластеров.
На фоне этого ваше «никто не мешает настроить несколько инстансов БД, опубликовать их, например, на внешних портах хостов и связать их репликацией» подтверждает, что наличие отдельно стоящих БД — вполне себе нормальная практика, и вы согласны, что оно надо. При этом вы выпали из контекста, и не заметили, что в изначальном контексте фейловеры, кластеры и репликации недоступны, т.к. «только 127.0.0.1, только хардкор», «локалхоста хватит всем» и «настроить — это сложно».
Вот против этого подхода я и протестую. Приложение, тем более вроде ставшего «эталонным» в этом треде gitlab'а от omnibus, рассчитанное на многопользовательскую среду, да еще и с постоянным ростом базы и потенциальным ростом базы клиентов так «пакетить» — говно подход.
В смысле, вы локальную БД, засунутую в контейнер с приложением, без всяких проблем, например в кластер засунете? Или логическую репликацию поднимете на условиях, что слейв мастера не видит? Или фейловер на условиях, что клиент видит только один из серверов? Я что-то не знаю?
Оно в текстовом конфиге только локальный файл-сокет принимает?
И в чем суть проблемы? Постгре какой-то другой модели?
Вы неверно прочли, это вы представили docker-compose с образом, указанным разработчиками и прилагаемыми конфигами проблемой. Я как раз не вижу в этом проблемы. Вы либо берете, что вам сказали, либо смотрите в эти конфиги и поднимаете свой постгре с требуемыми настройками. В чем проблема?
Еще можно DNS воспользоваться (не надо про задержки, резолвер локальный), еще доступ по ключу, по паролю. В конце концов, если вы в изолированной подсети, поставьте пароли плейнтекстовые. Будет не хуже локального «127.0.0.1-можно-все».
Зашить можно много чего, например, вплоть до «из локальной подсети можно» — прочтите доку по постгре, не айпишником единым, знаете ли.
Т.е. «исторически сложилось» уравниваем с «нормальная практика»?
Или к DNS привязаться, или авторизацию по ключу настроить, или SSL включить. Довод «нам было сложно 1 раз настроить доступ к постгре, и мы решили прибить его гвоздями к локалхосту» — слабый аргумент, имхо. Экономия на спичках — это такое себе.
У вас прод какой-то странный. Ну либо у вас проблемы.
Чем тот, который «пересобрать» лучше, чем тот, который «сохранить состояние»?
Покажите, пожалуйста, пример «хорошей практики» забандленной с приложением БД. В виде докерфайла. Возможно, я с вами и соглашусь, что «вот это норм, был неправ».
Теперь мы попробуем представить постгре, запущенный в контейнере ОС. Мы перед обновлением бекапим целиком образ системы, с установленной версией постгре, с набором библиотек и т.д. Или даже тупо снапшотимся, что тоже работает. После этого при необходимости отката мы просто откатываемся на реальное предыдущее состояние системы, а не на пересобранный «такой же» образ. Это тупо быстрее, а контейнерная изоляция, тем более в случае «приложение в куче с БД» — это лишний геморрой.
При том, что я изначально спорил только с тем тезисом, что бандлить СУБД внутрь контейнера с воркером — хреновая идея. Тем более позиционировать ЭТО как конечный продукт (для конечного пользователя) и называть нормальной практикой. Оно будет работать в пределах локалхоста, и то до поры до времени.
Зачем этот ужас, предназначенный для «зазырь, ОНО ШЕВЕЛИТСЯ» тащить в прод?
Стоп, а до этого был какой-то «несерьезный продакшен»? Они разные бывают?
Тест-кейсы — случай сильно отдельный, там и бОльшие извращения бывают. При этом помним, что либо констракт базы на запуске теста, либо read-only ДБ. Зачем это в прод-то тащить, пусть и в «несерьезный»?
Про разнородные процессы я особо и не спорил, и то есть к чему придраться. Я конкретно про СУБД в контейнере.
Как только разрабочиков становится более одного, это уже не гарантировано истинно.
У вас один пользователь, в смысле?
Вот ЭТО — эталонный докерфайл, который считается «правильным подходом» сторонниками этой точки зрения. Там прямо так и написано apt install, при пересборке мы имеем последнюю версию того, что лежит в репозитории. Каждый раз. И вот это считается «хорошим тоном» отдать конечному пользователю. ОНО может сдохнуть тупо при перезапуске в определенных случаях. Под какой-либо сколько-нибудь автоматизированной оркестрацией это запускать просто опасно.
Да, я считаю, что в данном случае НИКАК нельзя положиться на систему тегов, например. Будете убеждать меня в обратном?
Делается, обычно, так: поднимается свежая версия СУБД, рядом с текущей, в нее копируются данные. Не дай Б-г вам делать апдейт на живом сервере. Вот это — слабоумие и отвага. Потом копия обкатывается, делаются необходимые миграции, тесты, эта копия тестируется на новой сборке софтины, а затем уже с танцами под бубенцы начинается непосредственно миграция.
В монолитном контейнере вы по дефолту смиряетесь, что контейнер обновляется целиком версия софта + версия базы. Одновременно.
И вот этот риск заради того, чтобы сэкономить день геморроя раз в пару лет? Нету смысла это автоматизировать, поэтому и не автоматизируют.
Смотрите, у вас был контейнер с 9-й версией постгри. Вы поверх того же датасета запустили контейнер новой версии с 10-й версией. Что-то пошло не так, миграции завалились или хз вообще что. Вы запускаете взад контейнер с 9-й версией… а миграции уже начаты, назад пути нет.
Огромная разница: первое — оксюморон и «не надо так делать», второе — ваша личная фантазия. Откуда «параметризованность» и «разные пути сборки» вдруг взялись? Пути — одинаковые, ветки репозитория — разные. Улавливаете?
Вот bundle пакет с postgre внутри — ересь.
Ага, один способ подключения, который, согласно общепринятой практике, передается в контейнер с приложением в виде переменной окружения… Не я придумал, все так делают.
Ага, нужно настраивать, причем как под основного потребителя, так и под окружение, в котором он будет крутиться. Размерами кешей поиграться, кодировки выставить и все вот это. А вы монолит нахренячили со среднепотолочными значениями. Причем отобрали у потребителя возможность засунуть БД на свой, например, высокопроизводительный кластер баз данных. «Локалхоста же всем хватит».
Тем, например, что я смогу передать другое подключение к постгре воркер-контейнеру. А то, которое «в бандле», не юзать.
По пунктам:
1. Если воркер-контейнер не принимает в качестве ключа конфигурации подключение к произвольному постгре-серверу, автор контейнера — рукожоп, например.
2. Постгри в композе описан как сервис? А есть другие варианты? В котором он описан не как сервис? Какой ужас, вас его еще и использовать заставляют?
3. Свой образ с монтированием конфигов? Отличная шпаргалка, каких конфигов авторы желают постгресу для нормальной работы? Не? Можно сконфигурять свой адекватно запросам?
4. Генерация конфигов постгреса на лету? Жуть какая! Не пользуйтесь ЭТИМ.
5. Список разрешенных для коннекта айпишников зашитый внутрь образа? Жуть, веский повод сменить образ, например.
Как вы будете «экономить» память 11 раздельных кешей постгреса — большой вопрос.
А еще, допустим, большой вопрос, нафига я буду поднимать 11 локальных инстансов постгреса, при условии, что у меня, например, есть отдельный сервер под эти задачи.