Ну как разработчик часто ребилдящий контейнеры может вы слышали о практике помещения работы с часто изменяющихся вещей в докерфайле пониже, а редко — повыше, т. к. у докера есть кэширование слоёв.
Как крупный специалист в структуре докер-контейнеров вы, вероятно, в курсе, что нельзя заменить содержимое нижнего слоя без ребилда верхнего? Т.е. при тупом обновлении часовых поясов вы можете нарваться на обновления версии БД поверж живой базы. При протухании кеша во время ребилда докерфайла вы можете нарваться ровно на то же самое. Понимаете, принятая политика в отношении воркеров/фронтендов/интерфейсов и прочего — «release often». В отношении СУБД — не трогать без надобности, обновлять только в том случае, если есть реальная причина это делать, предварительно протестировать жизнеспособность решения. А вы все в один контейнер. Фи так делать.
Не только читать, а тратить время на освоение, на внедрение в существующие автоматизированные и не очень процессы.
Я чуть выше писал уже, docker-compose описан в документации к докеру. Просто вы к молотку инструкцию еще не до конца прочли, а уже в прод его притащили. Ай-ай-ай так делать.
Проводить аудит безопасности на каждый апдейт.
Я вот вам, например, и предлагаю, проводить аудит безопасности на само приложение, а не на приложение + СУБД.
Следить за лицензионной чистотой.
Т.е. за лицензионной чистотой постгре, упакованного внутрь контейнера с приложением следить не надо? Понимаете, при проверке «лицензионной чистоты» контейнера вам придется, по хорошему, проверять на лицензии все, что туда упаковано. Причем каждый раз заново. Вынесите СУБД в отдельный контейнер, и при пересборке проверяйте «чистоту» контейнера приложения, т.к. контейнер СУБД у вас иммутабелен.
Системы с требованиями к масштабированию, отказоусточивости и т. п. никто не отменял.
Контейнер приложения с упакованным внутрь постгресом ортогонален и масштабированию, и отказоустойчивости. Точнее не так, противоречит обоим требованиям.
Для описания окружения текстом, который можно хранить в репе приложения и воспроизводить на (почти) любой машине.
Т.е. bash-скрипт, обернутый построчно в набор странноватых конструкций и называемый докерфайлом, принципиально отличается от баш-скрипта, не обернутого набором странноватых конструкций?
Альтернатива докеру в этом смысле — баш скрипты провижна и деплоя, ну и ансибли с паппетами как их развитие, а не образы виртуалок. Докер проще и удобнее всего из этого.
Какбы, сильно не во всем проще. И применимость у него сильно Уже.
Ага. ФС контейнеров изолированы, у каждого свой IP в общем случае случайный.
И зачем вам, простите, прямой доступ к ФС вашей базы данных? А ns-резолвинг на уровне оркестратора не решает проблему «в общем случае случайных ip-адресов»? А возможность средствами оркестрации зафиксировать ip-адрес, чтобы он был не случайным? Вы из пальца не высасываете проблему на ровном месте?
Под разные машины с разными дистрибутивами Linux разных версий.
Повторю, эту проблему можно решить и без докера. При том, что полазить ручками в живой среде, настроить «как надо» проще в отладке, чем «написать докерфайл, который сделает как надо».
Забавно, но докер считается именно виртуализацией уровня ОС.
Загуглите уже, что ли, «контейнер приложения» vs «контейнер ОС». Докер не предполагает наличие внутри полноценного окружения ОС, например. Внутри у него ровно то, чтобы один запущенный процесс считал себя единственным в системе.
Спасибо, с виртуалками для приложений уже намучались. С другой стороны часто докер в виртуалке и вот для этого образа хорошо подходят.
Ну, видимо, стоит начать дробить ветки рассуждений. Начнем с выделения этого тезиса в отдельный ответ, для большей ясности и для определения собственно важности именно этого контекста.
Это не мы искусственно сокращаем, это вы предлагаете искусственно увеличить путём дробления одного докерфайла на несколько, да добавления докер-композ файла.
«Искусственно увеличить», «дробление одного докер-файла», «добавление докер-композ» — это все не я, например, предлагаю. Я, надеюсь, официальный портал разработчиков докера — достаточно авторитетный источник для поиска «true way» использования докера?
На всякий случай, если вы неосилятор, кратко изложу суть.
Часть первая: вводная.
Чо такое докер, с чем его едят, для чего он нужен и прочая лабуда, плюс как вкорячить на свою машину докер.
Часть вторая: самый первый контейнер.
Докерфайл, с чем его едят, как собрать и проверить «шевелится ли оно». Тут можно акцентировать внимание на том факте, что собранный контейнер прямо так и говорит «редис не найден». Рекомендаций положить редис внутрь не видно.
Часть 3: сервисы
О том, как правильно это запускать, крутить и чем собственно само понятие сервиса отличается от контейнера.
Начинается знаменательными словами: "поставьте docker-compose, напишите docker-compose.yml файл.". Это официальная позиция разработчиков докера. Нигде ни разу они не пишут «возьмите голый докер и запустите». Так делать не принято, официальная позиция разработчиков.
Так что композ — это не «лишняя сущность», а официальный «true way» от разрабов самого докера.
Часть 4: Swarm, собираем кластер.
Что такое swarm, как инитить, как запускать, как в него складывать docker-compose файлы. Замечаем, на всякий случай, что «редис все еще недоступен»
Часть 5: стек.
Что такое стек (группа взаимосвязанных сервисов, делящая между собой определенный набор ресурсов). Замечаем, что в официальном «хауту» прямо рекомендуют ресурсами рулить на уровне стека, т.е. на уровне оркестрации наборами взаимосвязанных контейнеров. Не в докерфайле. Вот именно здесь редис наконец-то появляется.
Часть 6: деплой.
Как развернуть один и тот же «стек» на разных инстансах от амазон-клауда до локальной машины.
«True way of using Docker (by developers)» — вот это оно. Если вы считаете оркестрацию лишней сущностью… хм, видимо, докеровский get-started вы осилили до 2 части включительно, 3-ю уже не осилили?
Может, приведете мне более авторитетный в области докерной контейнеризации источник, однозначно утверждающий, что бандлить СУБД в контейнер с приложением — это норма?
Учитывая, с каким энтузиазмом, песнями и плясками Google, Microsoft и RedHat его хоронят, не успеют.
Дело в том, что докер очень хорош для кейсов, когда надо время от времени «пересобрать». CI/CD — там ему самое место. При этом СУБД — не такая штука, которую можно просто так взять и «пересобрать» поверх имеющегося датасета, поэтому оно в докер ложится очень неохотно, с бубном, песнями и плясками вокруг костра.
Фактически докерфайл — набор консольных команд, нужных, чтобы получить из базового образа требуемый, если уж «утрировать». Собственно, мне и кажется удивительным, когда человек считает, что собрать последовательность команд в файл с определенной структуры — это сложнее, чем ручками единоразово вбить ровно те же команды в консоли, попутно ЧИТАЯ, что там внутри происходит, и не упало ли чего. Т.е. мотивация LXD-сложна, говно?
А на выходе мы имеем докерфайл, НЕ предназначенный для пересборки по необходимости. Он предназначен для того, чтобы один раз собрать образ и мутить с ним, и быть очень-очень осторожным с ключами --force-rebuild. Вот это НЕ то, для чего докер предназначен.
Ну вот СУБД ПЛОХО, ИЗ РУК ВОН ПЛОХО в философию докера ложатся. А в философию «а мы рядом еще и приложение положим» — это вообще писец.
Вот смотри, мне предоставили такой «гениально затюненный продукт», который у разработчика «прямо отлично работает на локалхосте». Что внутри, яхз, предположим. И я, как умная Маша, иду на честно купленную впс-ку с 256Мб на борту и запускаю там этот гениальный контейнер. Спасибо, товарищи разработчики, за наше счастливое детство, короче.
А насчет «заявленной нагрузки» и «минимальных требований» — нифига у них нету… «Нормальный универсальный контейнер же, чо нет?»
Я говорю, что утверждение, что 11х постгресов ест 11х памяти совершенно может не соответствовать действительно.
По крайней мере будет «близко к действительности» или, по крайней мере «сравнимо». Они же в «изолированном окружении» выполняются, как минимум слабо верится, что в изолированном контексте ядро может «расшарить» память между процессами.
К тому же, я с трудом представляю как эта конструкция уместится в одну физическую машину (или она очень большая?).
Ну, как бы в 96Гб + 16 ядер — чо бы и нет… Другое дело, что оно будет работать как гогно и заведомо хуже, чем 1 постгрес со всем этим великолепием в его полном распоряжении на 11 баз.
Т.к. запускать постгрес в условном контейнере с веб-сайтом так себе идея — выглядит как из пушки по воробьям.
О! Вот именно эту точку зрения я и отстаиваю, что говно вариант. А мне тут «нормальная практика, нормальная практика».
И потребляйте как DBaaS или standalone DB с прописыванием всех конф. параметров в потребляющих эту «услугу» сервисах.
Дык, я так и хочу. И утверждаю, что разработчик, который мне отдал докер-образ с зашитым внутрь вместе с приложением постгресом — м.дак и нихрена не понимает в том, как готовят контейнеры. А меня тут в 3 жала пытаются в обратном убедить, аргументируя это тем, что «вон гитлаб же упаковали, значит и нам всем так делать надо».
Если решение решает задачу (быстро, дешево, стабильно) — почему следует его выкидывать?
Конкретно по кейсу с «быстро» и «дешево» — соглашусь, пожалуй. Насчет «стабильно» — недоказуемо в принципе, и «чревато». И на «нормальную практику докеризации» вот прям вот никак не тянет. Я не против, внутри своих локалхостов/организаций/кластеров — пофиг на масштаб трагедии, не существенно в контексте нашего разговора, можно творить все, что угодно. Только на людях называть это «хорошей практикой» не надо.
Тогда уж лучше обмазаться systemd-юнитами и раскатать все через ansible/salt/puppet
А вот тут от «конечной цели» зависит. Если предположить, что вы хотите потестить какой-то сервис в пределах локалхоста с целью определить «стОит ли оно того» и потом «малой кровью» мигрировать это на нормальный кластер k8s, например, то, пожалуй, самый норм вариант. Ansible/salt/puppet/systemD вас не «изолируют», да и «подчищать» придется. К тому же рожать вот эту всю обвязку на «попробовать» — так себе занятие.
В общем «на пощупать» — compose нормальный и самый бескровный/с минимальным порогом вхождения вариант. Всяко лучше, чем в докер-образ СУБД зашить вместе с приложухой. В «боевом» развертывании, конечно, свят-свят)
Это лишь частный случай «одна база на все инстансы», когда «все» равно единице.
Мсье философ. Только он с логикой не дружит. При количествоИнстансов != 1 высказывание ложно, поэтому с «частным случаем» оно ничего общего не имеет.
Если вдруг когда-нибудь понадобится два инстанса процесса приложения, то контейнер «бандла» нужно будет разбить для обеспечения независимого масштабирования процессов приложения и процесов базы.
Ну вот, к слову, о «масштабируемости». Под масштабируемостью обычно подразумевается возможность изменить количество ресурсов путем изменения конфигурации, без привлечения разработчика. С вашим подходом «мы докер изучили, а остальное — сложна», масштабирование будет выглядеть как отдельный докерфайл для конкретного кейса, в котором вам что-то понадобилось. Дык, вы пишите уж по докерфайлу сразу на каждый инстанс, чтобы потом копипастить не пришлось!
независимого масштабирования процессов приложения и процесов базы
Вот эта часть — она в архитектуру и концепцию СУБД заложена ИЗНАЧАЛЬНО. Т.е. вы сначала поломали к хренам саму концепцию, а потом, «в случае чего», будете «героически преодолевать» собственные грабли, заботливо разложенные вами же в результате вашей «нормальной практики докеризации процессов». Гениально, зато вы всегда при работе, всегда есть за что денежку получать.
Да, если что под инстансом приложения или базы я подразумеваю конкретный экземпляр запущенный для конкретной цели в рамках одного развёртывания.
Вот! Мы становимся «предметнее». Ок, под инстансом мы подразумеваем конкретный экземпляр, запущенный в рамках развертывания. Предлагаю сразу остановиться на этой терминологии: развертывание — это логически определяемая штука, состоящая из инстансов приложения и их ресурсов. Теперь осталось понять, зачем вы подходом «база в бандле» уравниваете «развертывание» и «инстанс». Понимаете, разным инстансам приложения внутри одного развертывания может понадобиться доступ к общему инстансу БД. Это, как раз, называется «нормальная практика». Т.е. вы можете иметь 1 БД на развертывание, и при этом поднять несколько воркеров/веб-интерфейсов и т.д. и т.п. поверх этой БД, в порядке «балансировки нагрузки», «отказоустойчивости» и т.д. Вы же прибиваете каждый инстанс приложения к собственной БД, и даже внутри развертывания уже ничего не можете изменить.
Конечно, переписать все это можно, ага. Аккуратно смигрировать, проверить, что ничего не сдохло. А если вы этих «развертываний» 100500 навертели?
Понимаете, есть «инстанс приложения» — это уровень докера, есть «экземпляр развертывания» — это уровень ОРКЕСТРАЦИИ. Представьте себе приложение, которое хочет СУБД, кеш, очередь, продвинутую систему логгирования и еще 10 компонент, которые мне прямо сейчас в голову не приходят.
Вы, конечно, все это можете запихать в один контейнер, только вместо «оркестрации развертыванием» (вокруг которой уже есть достаточно обширный устоявшийся инструментарий) вы получите «оркестрацию процессами», вокруг которой копья ломают уже не одно десятилетие, а вот именно ее (все эти иниты, systemD и прочее) из вашего базового докер-образа отпилили за ненадобностью с мотивацией «докер не для этого». И вы эту оркестрацию начинаете писать на столь нежно нелюбимых вами шелл-скриптах. Отличный подход, так держать!
И база делиться между разными развёртываниями не должна.
База должна делиться, как минимум, между разными инстансами внутри одного развертывания. База внутри контейнера делиться не будет.
Это с одной стороны, а с другой — это уменьшение количества этих самых мест, поскольку не нужно бороться с дефолтной изоляцией контейнеров друг от друга.
SRSLY? Дефолтная изоляция? Тупой общий бридж с политикой iptables-разреши-все-все-все? Не, я, конечно, согласен, что с такой изоляцией надо бороться. Только не в ту сторону вы боретесь, ее усиливать надо.
Тупой docker-compose вам, хотя бы, на каждый неймспейс по отдельному бриджу даст, а голый докер. Ни один здравомыслящий человек не порекомендует вам голый докер в каком-либо виде наружу отдать.
Все приложения приемлемо работают в конкретной комбинации ресурсов, все эти минимальные требования, рекомендуемые требования и т. п. об этом. У нас они есть.
Дык, вы, получается, собираете конкретный контейнер под конкретную машину. Ну и нафига тут докер-то? Вам виртуализация уровня ОС нужна, например. LXD вам в руки, и никаких знаний там дополнительно не нужно. Запускаете виртуалку, цепляетесь к ней по ssh, рулите из консоли, «как настоящей». Нафига вам простыни докерфайлов?
От того, что мы сделаем два контейнера, один с СУБД, другой с nginx и php-fpm например, особо вероятность не уменьшится.
Зато появится возможность подебажить СУБД отдельно, подключиться к другой базе, не пересобирать все целиком с непредсказуемым результатом, если надо тупо обновить версию postgresql.
Docker is an open platform for developing, shipping, and running applications.
Developing, shipping and running, чуете.
Developing? В целях разработки — говно подход. Ребилдить весь контейнер вместе с БД при надобности изменения 3 строк в скрипте — говно подход, как разработчик говорю.
Shipping? Доставка приложение на железяку, аналогичную предыдущей? Нафига вы искусственно сокращаете количество target'ов для вашего shipping'а?
Running? Вот строго для «запустить»? Докер НЕ является хорошим инструментом для запуска stateful-приложений. Есть инструменты сильно лучше.
Docker enables you to separate your applications from your infrastructure so you can deliver software quickly.
Вот прямо буквами же написано «to separate your applications from infrastructure». Отделить приложения от инфраструктуры. Забандлить локалхост-онли СУБД = прибить нахрен гвоздями свое приложение к инфраструктуре. СУБД — stateful, по определению, она — ИНФРАСТРУКТУРА. И прямо в «предназначении» докера написано, что он призван ОТДЕЛИТЬ ее от приложения, а не забандлить внутрь.
Может и есть инструменты лучше по каким-то параметрам для каких-то конкретных юзкейсов, но по совокупности докер может и выигрывать.
По совокупности умелок работы со stateful-приложениями докер ни по какой совокупности не выигрывает ни у одной платформы оркестрации, и ни у одной системы изоляции уровня ОС.
Банально нежелание иметь зоопарк технологий для одной и той же задачи
Банальное нежелание что-либо изучать, банальное желание вкручивать шурупы молотком, потому что «с молотком мы уже умеем работать (в контексте ваших допущений о докере, конечно, нет, не умеете)», а инструкцию от отвертки еще читать надо.
и конкуренты не относятся к «все знают», а порог входа высок
Порог входа в LXD высок? Относительно порога входа в докер? Забавно, не знал, что 4 страницы текста осилить сложнее, чем 100500-страничный мануал с уточнением нюансов работы и пометками «не носите stateful в контейнере» через абзац.
В те же apt пакеты порог входа выше.
В sudo apt install выше?
Кому как. При разделении одного «локалхоста» на несколько как минимум растёт количество связей между контейнерами, причём растёт в бесконечное число раз: с нуля до минимум одного :)
Поймите уже, вы имеете не «никаких телодвижений» против «оркестрация контейнерами», а «оркестрация процессами» против «оркестрация контейнерами». По сложности примерно монопенисуально, тут соглашусь, если не вдаваться в детали. С той только разницей, что один раз удачно настроенный контейнер вы можете переиспользовать, тупо «заоркестрировав» его в другой неймспейс или в другой сервис. Удачное решение на уровне оркестрации процессами внутри докер-контейнера не переносится, копипаста не в счет.
При том сначала мы используем техглогию изолирующую контейнеры друг от друга
нихрена там не изолируется, о птичках если.
чтобы процессы не заметили, что они изолированы.
Цель докера, как раз, в том, чтобы процесс ЗАМЕТИЛ, что он изолирован. Процесс должен искренне считать, что в пределах системы он один, и тогда все хорошо, и докер тут красавчик. Как только внутри появляется оркестрация процессами, иниты и тому подобное — у докера проблема, хотя бы потому, что инит в докере искренне удивляется, какой такой другой инит вдруг убил его процесс, и на каких, собственно, основаниях.
А они и подключаютсяя через volume.
Подключение СУБД (постреса и ему подобных, не локальной и не ин-мемори) в качестве volume'а — это НЕ «подключение извне», это куцее локалхост-онли извращение.
А удаленно они могут «из коробки», без использования средств типа ssh?
Удаленно что? Установиться? Работать? При чем тут ssh? Какой кейс мы рассматриваем? Собственно, одно могу гарантировать, в контексте LXD любую хотелку, реализуемую в докере, реализовать можно.
зачем иметь две похожих в чём-то технологии в стэке, если от одной «избавиться» малой кровью не получится
Зачем иметь отвертку, если есть такой замечательный молоток?
Если нужны средства и уровня «локалхоста» и уровня кластера
«Средствами уровня кластера» вы, простите, что сейчас назвали? Докер? Средство уровня кластера — это k8s, голым докером вы там не обойдетесь.
Пускай одна немного лучше в случае локалхоста, но кластеры она совсем не умеет.
Докер тоже кластеры не умеет, тчк.
Мы не хотим разделять инструменты доставки на локалхостные и кластерные
Реализуемо в 2 вариантах: нефункциональное УГ либо перегруженный комбайн. Короче, не судьба.
мы не хотим поддерживать два процесса CI/CD
Когда вы утверждали, что сбандленная внутрь контейнера база — нормальная вещь для разработки, а для прода можно иметь отдельный докерфайл, два процесса CI/CD вас не смущали. Что изменилось? Когда вы собираете бандл из приложения + движок СУБД, какое отношение это вообще к CI/CD имеет?
мы хотим иметь возможность запускать несколько версий системы на одном физическом хосте.
Кто ж вам запрещает то? Хотите на одном хосте несколько версий ОС — системы виртуализации/изоляции уровня ОС вам в помощь, докер — нет, не в помощь. Хотите запустить несколько версий приложения — тем более в чем проблема, тут можно и докером. Осталось только понять, почему вы несколько версий приложения, каждая со своей БД хотите, а несколько версий/инстансов приложения с общей базой — нет.
Если человек быстро выполнил задачу по контейнеризации, причём быстрее и гораздо дешевле, чем сторонние профессионалы, то он достаточно компетентен.
Вах, до классики добрались. Про «Быстро, дешево, качественно — выбери два» слыхали? Оно правда!
Вы сами выбрали «быстро» + «дешево», зачем вы пытаетесь ЭТО выдать за «качественно»?
Практика показала, что лучше чем bash-скрипты.
Она же показала, что хуже, чем виртуализация, LXC/LXD, flatpak, snap. При этом докер отлично работает для доставки ЧАСТЕЙ/МОДУЛЕЙ распределенных stateful-приложений в условиях наличия оркестрации (compose, swarm, k8s — все вот это). При этом практика крупных корпораций подсказывает нам, что и для этих задач конкретно docker сильно не оптимален, и в том же k8s, например, от самого докера только build-фаза и осталась. Возможно, тоже не надолго.
Переводы разные могут быть. Мой, насколько я могу судить, ближе к оригиналу, чем то, что современным студентам дают под видом оригинала.
Латинский словарь говорит нам: ens с латыни может переводиться как «существующее, сущее, существо, вещь».
Русский словарь говорит нам:
Сущее — категория онтологии, чаще всего употребляющаяся в современной философии для обозначения как всей совокупности имеющихся наличных вещей, животных, растений, людей, так и для каждой отдельной вещи. Иногда слово «С.» употребляется как синоним «бытия», иногда (у М. Хайдеггера) как нечто противоположное бытию.
В разные исторические эпохи С. интерпретировалось различным образом.
… тут пропускаем про античность и средневековье и сразу переходим к новому, текущему пониманию, мы же на современный русский, а не на старославянский переводим…
В Новое время под С. понимается совокупность внешних причин, вещей и условий, и даже сам человек — вещь среди остальных вещей, хотя и центральная вещь. С. — то, что открывается нам в представлении, это сцена, на которой человек представляет, разыгрывает свои сценарии. Оно распадается на совокупность причинно-следственных связей; оно уже не захватывает, не угрожает, а становится «картиной мира», и отношение человека к нему теперь определяется мировоззрением.
Т.е. в современном понимании «сущее» — окружающая нас действительность, реальность.
Entia non sunt multiplicanda praeter necessitatem
Вот это нам говорит оригинал изречения. Постарайтесь заметить entia в самом начале. Это форма множественного числа слова ens.
Другими словами, вы считаете, что исходная фраза говорит о том, что без необходимости не нужно плодить «окружающие дествительности»? Или «параллельные реальности»? Или, может, вы, все таки, в латинском словаре после «ens — сущность» запятую не заметили и продолжение списка возможных от контекста переводов? Или таки не улавливаете разницу между i10n и l18n и искренне верите, что перевод легендарным «Промптом» — вершина эволюции переводов? Все таки «сущее», и вам лучше знать, и там вообще ничего общего с методологическим редукционизмом?
Если заворачивать каждый в отдельный контейнер, то там нужно много контейнеров и связи между ними настраивать.
Печаль-бида. Только что про SOA и MSA рассказывали, а теперь связи настроить сложно?
Та самая оркестрация.
Ага, та самая, которая абстрагирует вас от сложности ручного управления взаимосвязанными контейнерами и позволяет как-то продвигаться в сторону переиспользуемых контейнеров.
А если в один, то никакой особой оркестрации контейнеров не нужно
И докер тоже тут не нужен, вам LXC/LXD нужен.
а для совместной работы процессов внутри одного контейнера используются наработанные десятилетиями практики.
Вы бредите. Когда ж вы с 2008-го года «наработанные десятилетиями практики» наработать успели-то???
Вне зависимости от прода ограничение «25% памяти — постгресу» в докерфайле непереносимо. Т.е. «дистрибуцию», «масштабирование», «воспроизводимость окружения» и все вот это мы вычеркиваем, т.к. ничего воспроизводить, масштабировать и распространять вы не собираетесь. Остается только «изоляция». Т.е. вы хотите просто один раз это настроить, запустить, чтобы оно как-то работало и не подралось с соседями. Дык, для этого есть более другие, ГОРАЗДО более приспособленные под кейс инструменты. Возьмите, блин, LXD — это контейнер ОС, он ровно для этих случаев пилится. Это как виртуалка, только с изоляцией на уровне ядра, в смысле, с тем же оверхедом, что и докер. Зачем вы пытаетесь ВСЕ в докер запихать. Я, конечно, понимаю, что дай вам в руки молоток, вы все за гвозди посчитаете. Просто как доктор вам говорю: шурупы удобнее закручивать отверткой.
Нет, просто десятки серверов, разных версий. Максимум у некоторых реплика есть.
Т.е. у вас есть десятки серверов БД разных версий, некоторые с репликами, все это как-то балансируется, масштабируется и все вот это… А вы постгре в каждое приложение бандлите! Красавцы!
Далеко не все считают MSA хотя бы подмножеством SOA, не то что синонимами.
Ну вот зря они. Ничто, как водится, не ново под луной. Все с завидной регулярностью переизобретается. Микросервисы — это ровно переизобретенная SOA, только ближе к практическому применению на более узких кейсах + некоторый набор устоявшихся практик.
А кто говорит для каждого инстанса? это ваши фантазии. Одна база на все инстансы. Просто частный случай когда их всего один.
Вы говорите, что одна база для каждого инстанса же! Понимаете, забандленная в контейнер с приложением СУБД — это и есть одна база на ИНСТАНС. Или вы, в смысле, собираетесь один volume с файлами СУБД в несколько контейнеров подмонтировать, чтобы НЕСКОЛЬКО СУБД-ДВИЖКОВ с одним набором файлов работало? Кхм, вы точно ничем не больны?
У кого принято? А если база не постгри и вообще не сетевая?
Я же, вроде, достаточно четко говорил: постгри или любые СУБД того же уровня пихать в один контейнер с приложение — говно подход. Если база не сетевая — вопрос отпадает сам по себе, но это НЕ энтерпрайз-субд уровня постгри, это, как правило, sqlite. Вот она, как раз, отлично подходит для того, чтобы ее вольюмом в контейнер пихали. А постри — не подходит. Только, пожалуйста, sqlite тоже не монтируйте в 2 контейнера одновременно, она, как бэ, single-user БД.
Ну и, собственно, почему вы считаете, что база, прибитая к локалхосту — это отличный способ конфигурации. Что вы там на уровне подключения поконфигурировать можете? Вместо 127.0.0.1 в параметрах подключения localhost ввести?
Нет, в некоторых случаях показывает факт того, что собрано в условиях ограниченных ресурсов.
Конкретный кейс собран в условиях «вау, есть же докер! Давайте соберем образ, чтобы еще одну галочку поставить в графу СПОСОБЫ РАЗВОРАЧИВАНИЯ. Вот, например, наша техничка Алёна докерфайл набросала, я проверял, на моем компьютере запускается, давайте положим это на оф. сайт.» И не надо про ограниченные ресурсы. Не надо тратить и без того ограниченные ресурсы на выпуск говна.
И обучение docker-compose up включает в себя обучение docker run сначала.
1б) Зато это повод не говорить «это приложение не предназначено для контейнеров, поэтому помещать его в окнтейнер мракобесие» ))
Когда приложение хреново конфигурируется/работает в контейнерном окружении, я так и говорю, оно хреново работает в этом окружении. А если приложение само по себе хреново чувствует себя в контейнере, запихать его в контейнер с еще одним приложением — это не решение проблемы, а неиллюзорный способ выхватить граблями по лбу в самом непредсказуемом месте.
2) слишком категорично чтобы быть правдой. А если нас два пользователя всего: я и админ, и бандл собрано и сконфигурирован по по полному обоюдному согласию?
То, что вам обоим нравится, не делает это сколько-нибудь нормальной практикой. В виде бандла с базой внутри — оно может приемлемо работать в конкретной комбинации ресурсов, предоставляемых контейнеру на узком use-case'е, подходящим конкретно вам. Дистрибуция в таком виде становится бессмысленной, вариант подпадает под категорию «локальные извращения, которых можно было избежать, но было лень».
3) аргументы кроме «когда-нибудь пожалеете, когда ресурсов не станет хватать, отказоустойчивость решите сделать и прочие „когда-нибудь“» будут? Я такой бандл даже за технический долг не считаю. Работает, текущим требованиям удовлетворяет, кардинальных изменений не предвидится. И, главное, уже многократно окупил вложенное в него время. Будут новые требования, потребующие разбить всё по «процессам» — хоть с ноля разобьём, хоть на базе существующего. И ничего не потеряем.
У вас БД сбандленна внутрь контейнера приложения. Это неиллюзорная возможность потерять, например, историю телодвижений пользователей и начать все «с чистого листа». Вы просто оттянули наступление геморроя. При этом упаковать это в сратый docker-compose — дело получаса. Разгрести эту кашу при миграции — затянется на дни.
4.1) Докер тоже создан для автоматизации развёртывания приложений. Для решения одних и тех же задач часто создаются разные инструменты.
Докер создан заради возможности складывать окружение приложения в тот же репозиторий системы контроля версий, что и само приложение. Короче, вся эта хрень — заради воспроизводимости сборки/окружения. В остальных кейсах есть инструменты лучше.
4.2) Там не один apt install, там их много )) Проще разрабатывать и поддерживать, меньше зависит от окружения.
Разрабатывать и поддерживать ЭТО не проще. При этом воспроизводимость сборки и окружения в этом докерфайле не гарантирована. Докер хорош, действительно хорош для тех случаев, когда ребилд образа не ломает работоспособность приложения. Это не тот случай, тупой ребилд (который может случиться на автомате в любой системе оркестрации) запросто положит рабочий проект. Поэтому в каждой мало-мальски серьезной книжице по докеру/контейнерам приложений/оркестрации контейнерами большими чОрными буквами написано: не кладите ресурс внутрь контейнера, все stateful ресурсы должны подключаться к контейнеру извне. При этом часто рядом стоит пометка на полях для «особо одаренных», что базы данных целиком считаются внешними ресурсами и не должны быть внутри контейнера приложения, если, конечно, террористы не обещают убить вашу сестру в случае, если вы не забандлите ЭТО.
4.3) Меньше вероятность конфликтов при развёртывании как минимум.
Что касается конфликтов при развертывании на локалхосте — взгляните уж на snap и flatpak. Для локалхост-деплоя подходит гораздо лучше, изоляция ровно на тех же механизмах (да-да, все те же cgroups/namespaces), все те же «слои» фс, все то же самое, но плюс некоторое количество умелок, специфичных для локалхоста. Например, в них можно без боли упаковать GUI-приложение, например.
4.4) Чем кардинально отличается от apt пакета своего?
В том и дело, что ничем. В том и вопрос: нахрена городить огород с докером, если работает ваша вещь ровно на локалхосте и ни каких плюшек относительно локальной установки не дает? Только лишние юзерспейсные косяки с безопасностью добавляет, и геморрой на ровном месте порождает.
Одинаковые системные инструменты — факт. Те же cgroups, те же namespaces. А в целом продукт разный. Docker — это про «упаковать приложение», LXD — это «очень легкая виртуалка». Т.е. вы берете базовый образ, допустим, убунты, идете в консольку этой «виртуалки» по ssh или через локальный сокет, внутри ручками ставите, допустим, постгрес, снапшотите — вуаля, у вас новый образ системы postgres-on-ubuntu.
Т.е. у LXD внутрях полноценный инит и все вот это. А докер — запустить процесс, дождаться, пока сдохнет, убить окружение.
Что угодно принимает, но конфиг не предназначен для редактирования пользователями.
Можно поинтересоваться, какими средствами докера вы добились невозможности изменения конфига пользователем при запуске?
Любые изменения лежащего в репе конфига локально — «потеря гарантии».
Зачем его менять в репе, если его можно подсунуть при старте?
Одна из основных целей докерезации — минимизация проблем типа «а у локально работает» и «всё сделал по инструкции, но не работает».
Ложная индукция. Контейнеризация помогает в минимизации проблемы УМВР, в контексте разработки, т.к. максимально унифицирует окружение разработчика и прод. А вот в «всё сделал по инструкции, но не работает» она скорее мешает. В настройки безопасности локальной постгри рядовой пользователь залезть не может, ибо прав недостаточно. В настройки постгри, запущенной этим пользователем в контейнере — запросто.
Процесс конфигурирования не имеет ничего общего с официальным образом и документация по конфигурированию доступна только разработчикам.
Жуть какая, постгре хотя бы «той модели»? Гитлаб, условно, в принципе с постгре работает же? Собственно, в чем препятствие выкинуть к хренам «особенный постгре» и положить вместо него «обычный»? А, точно, он же на локалхосте…
Проблема в том, что такие пользователи активно пытаются навязать решение проблем с их постгрессом и их конфигурацией поддержке продукта как исправление ошибок.
Проблема в том, что вместо решения проблем вы пытаетесь настрать на них, закопать поглубже и делать вид, что их нет. Вместо того, чтобы протестить тупо линк до постгре-сервера и в случае отстутсвия сказать «ой, у вас ваша постгря отвалилась» вы предлагаете все в кашу захренячить в один контейнер. Не надо, блин, конечных пользователей имбецилами считать. Среди потребителей вашего продукта могут оказаться вполне вменяемые сисадмины, которые еще и вам подскажут, где косяк, и как по быстрому поправить… Хотя не, у вашего продукта таких не будет. Они посмотрят на постгре внутри, и, с криками «свят-свят» зарекутся к этому прикасаться в принципе.
Есть утверждённый регламент безопасности. Думаете веская причина для безопасников будет «мы, команда разработки, тут решили сделать себе жизнь проще немного и потому просим ослабить требования безопасности»?
Давно «прибить авторизацию к айпишнику, который может ручками выставить на свой бучек любая п… да, которая приперлась с ним в контору и воткнувшаяся в локалку» надежнее, чем «авторизация по доменному резолверу» или «авторизация по ssl-ключам»?
Нормальная практика для, как минимум, быстрой контейнеризации существующих приложений, требующая минимального обучения персонала.
Нормальная практика — это подход, в котором «быстрая контейнеризация существующих приложений» производится человеком, сколько-нибудь компетентным в вопросе. «Деплоить и доставлять» действительно, можно и обезьяне доверить, эта вещь приемлемо автоматизируется. А вот автоматизация процесса, как показывает практика, автоматизируется из рук вон плохо.
Просто использование докера в качестве средства быстрого разворачивания приложений без особых требований к масштабированию, отказоустойчивости, конфигурируемости и т. п.
Докер — хреновая обертка для доставки stateful-приложений. Если хочешь доставить на локалхост — самый-самый инструмент для кейса — docker-compose.
«Не следует множить сущее без необходимости» тоже слабый довод?
Множить сущее — это вы куда-то замахнулись. В оригинале про сущности было, например. Вы просто вместо того, чтобы средствами оркестрации рулить абстрагированными сущностями а-ля контейнер, почему-то предпочитаете помножить низкоуровневые сущности внутри контейнера. При том, что для оркестрации ресурсов на уровне контейнеров существует ряд решений, которые как-то развиваются и отлаживаются. А для оркестрации костылей внутри контейнера решений нет и не предвидится, рекомендуют подход «залей это лавой».
Реально? Запилить контейнер, внутри которого 25% памяти отдать постгресу, а что осталось — вебморде с обвязкой вокруг гита — это применимо в проде? Давно это норма?
б) соотвествует требованиям изоляции
Требования в студию.
в) во многих организациях десятки серверов БД даже для зависимых приложений или систем, не говоря о независимых.
Десятки серверов БД в кластере, с настроенной репликацией, фейловером и т.д. Это в целях отказоустойчивости делается, а также для повышения общей производительности БД. Ну еще в целях экономии денег на этом зоопарке, т.к. серверное оборудование дорогое, и отдавать пару процессорных ядер с 10 гектарами оперативки для работы 10 мажоров на гитлабе никто особенно не стремится. Совокупное кеширование может оказаться сильно дешевле.
Ну и тот же (микро)сервисный подход часто подразумевает свою базу для каждого (микросервиса)
Никогда, ни при каких условиях SOA (которую вы называете микросервисным подходом) не предполагала отдельную базу для каждого ИНСТАНСА сервиса. Бред это потому что, и противоречит логике.
г) иные способы конфигурации
Прибить базу к локалхосту принято читать как «отсутствие способов конфигурации»
д) не ведёт к отказу, а показывает ненужность или дорговизну на данном этапе развития приложения/системы.
Показывает факт того, что собрано это поделие на коленке по быстрому группой энтузиастов, которые торопились собрать поделие пока энтузиазм не утих.
Например, одно дело если у вас на поток поставлена контейнеразция приложений, а совсем другое если это разовая задача, требующая дополнительного обучения персонала даже для «всё в одном».
Т.е. docker run обучения персонала не требует, это все с рождения умеют, а docker-compose up — сверхсложная наука, которой по 6 лет в университете учат?
1) контейнеры появились раньше чем приложения, предназназначенные для контейнеризации ))
Это а) совершенно логично, б) совершенно не повод все в них пихать.
2) как миниум зависит от того, кто целевой пользователь, и есть ли другие варианты поставки
Отдать пользователю приложение со сбандленным постгресом, ограниченным в аппетитах среднепотолочными значениями — говно подход, вне зависимости от конечного пользователя.
3) Все хорошие практики обычно подразумевают что кому-то проще, сейчас или потом, за счёт других или незаметно для них — детали.
Еще раз, конкретно этот случай — говно решение, вне зависимости от того, кому проще.
4) упрощает развёртывание новых инстансов по сравнению с традиционными типа «apt install ...»
4.1. Есть масса способов «упростить развертывание новых инстансов». Не нравится apt install — велкам в appImage, snap, flatpak. Задачу доставки приложения призваны решить именно они.
4.2. Загляните в докерфайл. Чем оно лучше apt install, особенно если учитывать тот факт, что внутри там именно apt install + хренова уйма костылей вокруг, чтобы это хоть как-то завелось?
4.3. Чем для пользователя sudo apt install gitlab-ce сложнее docker run gitlab-ce:latest?
4.4. К вопросу о трейд-оффе. Если даже развертывание чем-то проще, вопрос обновления/закрытия уязвимостей начинает «цвести и пахнуть».
Видел я все это. И отлично понимаю, что postgresql — это штука, которая «в лоб» без набора костылей и подпорок не докеризуется в принципе. При этом вы группой товарищей дружно в голос мне утверждаете, что от того факта, что вы эту кучу костылей положите в один докерфайл с вашим приложением, ситуация станет чем-то лучше. Что это нормальная практика. И в качестве подтверждения размахиваете образом omnibus/gitlab со словами «серьезные дядьки так делают, и нам советуют».
А «серьезные дядьки» в докерфайле прямо пишут вот такое: echo "# Prevent Postgres from trying to allocate 25% of total memory". Там еще много замечательных вещей в докерфайле, я давал на него ссылку. И все утверждают, что все норм, так можно делать и «у меня все работает, не вижу проблемы».
Понимаете, postgresql сам по себе докеризуется через огромную хитрозаверченную жопу. При этом есть возможность не делать вид, что «проблема решена» путем обрезания доступной постгресу памяти в размере 25% памяти, доступной контейнеру и прибиванием его к локалхосту, а хотя бы попробовать прикрутиться к чему-то сколько-нибудь стандартному или, уж не до хорошего, поддерживаемому.
Ан нет, все дружно утверждают, что сложить костыли постгреса в один файл с костылями самого приложения, попутно отобрав у человека возможность сделать по-человечьи — это «нормальная практика», и «отдать постгресу 25% памяти» — это нормально для боевого прод-окружения.
Как крупный специалист в структуре докер-контейнеров вы, вероятно, в курсе, что нельзя заменить содержимое нижнего слоя без ребилда верхнего? Т.е. при тупом обновлении часовых поясов вы можете нарваться на обновления версии БД поверж живой базы. При протухании кеша во время ребилда докерфайла вы можете нарваться ровно на то же самое. Понимаете, принятая политика в отношении воркеров/фронтендов/интерфейсов и прочего — «release often». В отношении СУБД — не трогать без надобности, обновлять только в том случае, если есть реальная причина это делать, предварительно протестировать жизнеспособность решения. А вы все в один контейнер. Фи так делать.
Я чуть выше писал уже, docker-compose описан в документации к докеру. Просто вы к молотку инструкцию еще не до конца прочли, а уже в прод его притащили. Ай-ай-ай так делать.
Я вот вам, например, и предлагаю, проводить аудит безопасности на само приложение, а не на приложение + СУБД.
Т.е. за лицензионной чистотой постгре, упакованного внутрь контейнера с приложением следить не надо? Понимаете, при проверке «лицензионной чистоты» контейнера вам придется, по хорошему, проверять на лицензии все, что туда упаковано. Причем каждый раз заново. Вынесите СУБД в отдельный контейнер, и при пересборке проверяйте «чистоту» контейнера приложения, т.к. контейнер СУБД у вас иммутабелен.
Контейнер приложения с упакованным внутрь постгресом ортогонален и масштабированию, и отказоустойчивости. Точнее не так, противоречит обоим требованиям.
Т.е. bash-скрипт, обернутый построчно в набор странноватых конструкций и называемый докерфайлом, принципиально отличается от баш-скрипта, не обернутого набором странноватых конструкций?
Какбы, сильно не во всем проще. И применимость у него сильно Уже.
И зачем вам, простите, прямой доступ к ФС вашей базы данных? А ns-резолвинг на уровне оркестратора не решает проблему «в общем случае случайных ip-адресов»? А возможность средствами оркестрации зафиксировать ip-адрес, чтобы он был не случайным? Вы из пальца не высасываете проблему на ровном месте?
Повторю, эту проблему можно решить и без докера. При том, что полазить ручками в живой среде, настроить «как надо» проще в отладке, чем «написать докерфайл, который сделает как надо».
Загуглите уже, что ли, «контейнер приложения» vs «контейнер ОС». Докер не предполагает наличие внутри полноценного окружения ОС, например. Внутри у него ровно то, чтобы один запущенный процесс считал себя единственным в системе.
И чем, собственно, вас «виртуалки» не устроили?
«Искусственно увеличить», «дробление одного докер-файла», «добавление докер-композ» — это все не я, например, предлагаю. Я, надеюсь, официальный портал разработчиков докера — достаточно авторитетный источник для поиска «true way» использования докера?
Смотрим конкретно сюда:
Официальный гет-стартед докера от разработчиков.
На всякий случай, если вы неосилятор, кратко изложу суть.
Часть первая: вводная.
Чо такое докер, с чем его едят, для чего он нужен и прочая лабуда, плюс как вкорячить на свою машину докер.
Часть вторая: самый первый контейнер.
Докерфайл, с чем его едят, как собрать и проверить «шевелится ли оно».
Тут можно акцентировать внимание на том факте, что собранный контейнер прямо так и говорит «редис не найден». Рекомендаций положить редис внутрь не видно.
Часть 3: сервисы
О том, как правильно это запускать, крутить и чем собственно само понятие сервиса отличается от контейнера.
Начинается знаменательными словами: "поставьте docker-compose, напишите docker-compose.yml файл.". Это официальная позиция разработчиков докера. Нигде ни разу они не пишут «возьмите голый докер и запустите». Так делать не принято, официальная позиция разработчиков.
Так что композ — это не «лишняя сущность», а официальный «true way» от разрабов самого докера.
Часть 4: Swarm, собираем кластер.
Что такое swarm, как инитить, как запускать, как в него складывать docker-compose файлы.
Замечаем, на всякий случай, что «редис все еще недоступен»
Часть 5: стек.
Что такое стек (группа взаимосвязанных сервисов, делящая между собой определенный набор ресурсов).
Замечаем, что в официальном «хауту» прямо рекомендуют ресурсами рулить на уровне стека, т.е. на уровне оркестрации наборами взаимосвязанных контейнеров. Не в докерфайле. Вот именно здесь редис наконец-то появляется.
Часть 6: деплой.
Как развернуть один и тот же «стек» на разных инстансах от амазон-клауда до локальной машины.
«True way of using Docker (by developers)» — вот это оно. Если вы считаете оркестрацию лишней сущностью… хм, видимо, докеровский get-started вы осилили до 2 части включительно, 3-ю уже не осилили?
Может, приведете мне более авторитетный в области докерной контейнеризации источник, однозначно утверждающий, что бандлить СУБД в контейнер с приложением — это норма?
Учитывая, с каким энтузиазмом, песнями и плясками Google, Microsoft и RedHat его хоронят, не успеют.
Дело в том, что докер очень хорош для кейсов, когда надо время от времени «пересобрать». CI/CD — там ему самое место. При этом СУБД — не такая штука, которую можно просто так взять и «пересобрать» поверх имеющегося датасета, поэтому оно в докер ложится очень неохотно, с бубном, песнями и плясками вокруг костра.
Фактически докерфайл — набор консольных команд, нужных, чтобы получить из базового образа требуемый, если уж «утрировать». Собственно, мне и кажется удивительным, когда человек считает, что собрать последовательность команд в файл с определенной структуры — это сложнее, чем ручками единоразово вбить ровно те же команды в консоли, попутно ЧИТАЯ, что там внутри происходит, и не упало ли чего. Т.е. мотивация LXD-сложна, говно?
А на выходе мы имеем докерфайл, НЕ предназначенный для пересборки по необходимости. Он предназначен для того, чтобы один раз собрать образ и мутить с ним, и быть очень-очень осторожным с ключами --force-rebuild. Вот это НЕ то, для чего докер предназначен.
Ну вот СУБД ПЛОХО, ИЗ РУК ВОН ПЛОХО в философию докера ложатся. А в философию «а мы рядом еще и приложение положим» — это вообще писец.
А насчет «заявленной нагрузки» и «минимальных требований» — нифига у них нету… «Нормальный универсальный контейнер же, чо нет?»
По крайней мере будет «близко к действительности» или, по крайней мере «сравнимо». Они же в «изолированном окружении» выполняются, как минимум слабо верится, что в изолированном контексте ядро может «расшарить» память между процессами.
Ну, как бы в 96Гб + 16 ядер — чо бы и нет… Другое дело, что оно будет работать как гогно и заведомо хуже, чем 1 постгрес со всем этим великолепием в его полном распоряжении на 11 баз.
О! Вот именно эту точку зрения я и отстаиваю, что говно вариант. А мне тут «нормальная практика, нормальная практика».
Дык, я так и хочу. И утверждаю, что разработчик, который мне отдал докер-образ с зашитым внутрь вместе с приложением постгресом — м.дак и нихрена не понимает в том, как готовят контейнеры. А меня тут в 3 жала пытаются в обратном убедить, аргументируя это тем, что «вон гитлаб же упаковали, значит и нам всем так делать надо».
Конкретно по кейсу с «быстро» и «дешево» — соглашусь, пожалуй. Насчет «стабильно» — недоказуемо в принципе, и «чревато». И на «нормальную практику докеризации» вот прям вот никак не тянет. Я не против, внутри своих локалхостов/организаций/кластеров — пофиг на масштаб трагедии, не существенно в контексте нашего разговора, можно творить все, что угодно. Только на людях называть это «хорошей практикой» не надо.
Даже не спорю.
А вот тут от «конечной цели» зависит. Если предположить, что вы хотите потестить какой-то сервис в пределах локалхоста с целью определить «стОит ли оно того» и потом «малой кровью» мигрировать это на нормальный кластер k8s, например, то, пожалуй, самый норм вариант. Ansible/salt/puppet/systemD вас не «изолируют», да и «подчищать» придется. К тому же рожать вот эту всю обвязку на «попробовать» — так себе занятие.
В общем «на пощупать» — compose нормальный и самый бескровный/с минимальным порогом вхождения вариант. Всяко лучше, чем в докер-образ СУБД зашить вместе с приложухой. В «боевом» развертывании, конечно, свят-свят)
Мсье философ. Только он с логикой не дружит. При количествоИнстансов != 1 высказывание ложно, поэтому с «частным случаем» оно ничего общего не имеет.
Ну вот, к слову, о «масштабируемости». Под масштабируемостью обычно подразумевается возможность изменить количество ресурсов путем изменения конфигурации, без привлечения разработчика. С вашим подходом «мы докер изучили, а остальное — сложна», масштабирование будет выглядеть как отдельный докерфайл для конкретного кейса, в котором вам что-то понадобилось. Дык, вы пишите уж по докерфайлу сразу на каждый инстанс, чтобы потом копипастить не пришлось!
Вот эта часть — она в архитектуру и концепцию СУБД заложена ИЗНАЧАЛЬНО. Т.е. вы сначала поломали к хренам саму концепцию, а потом, «в случае чего», будете «героически преодолевать» собственные грабли, заботливо разложенные вами же в результате вашей «нормальной практики докеризации процессов». Гениально, зато вы всегда при работе, всегда есть за что денежку получать.
Вот! Мы становимся «предметнее». Ок, под инстансом мы подразумеваем конкретный экземпляр, запущенный в рамках развертывания. Предлагаю сразу остановиться на этой терминологии: развертывание — это логически определяемая штука, состоящая из инстансов приложения и их ресурсов. Теперь осталось понять, зачем вы подходом «база в бандле» уравниваете «развертывание» и «инстанс». Понимаете, разным инстансам приложения внутри одного развертывания может понадобиться доступ к общему инстансу БД. Это, как раз, называется «нормальная практика». Т.е. вы можете иметь 1 БД на развертывание, и при этом поднять несколько воркеров/веб-интерфейсов и т.д. и т.п. поверх этой БД, в порядке «балансировки нагрузки», «отказоустойчивости» и т.д. Вы же прибиваете каждый инстанс приложения к собственной БД, и даже внутри развертывания уже ничего не можете изменить.
Конечно, переписать все это можно, ага. Аккуратно смигрировать, проверить, что ничего не сдохло. А если вы этих «развертываний» 100500 навертели?
Понимаете, есть «инстанс приложения» — это уровень докера, есть «экземпляр развертывания» — это уровень ОРКЕСТРАЦИИ. Представьте себе приложение, которое хочет СУБД, кеш, очередь, продвинутую систему логгирования и еще 10 компонент, которые мне прямо сейчас в голову не приходят.
Вы, конечно, все это можете запихать в один контейнер, только вместо «оркестрации развертыванием» (вокруг которой уже есть достаточно обширный устоявшийся инструментарий) вы получите «оркестрацию процессами», вокруг которой копья ломают уже не одно десятилетие, а вот именно ее (все эти иниты, systemD и прочее) из вашего базового докер-образа отпилили за ненадобностью с мотивацией «докер не для этого». И вы эту оркестрацию начинаете писать на столь нежно нелюбимых вами шелл-скриптах. Отличный подход, так держать!
База должна делиться, как минимум, между разными инстансами внутри одного развертывания. База внутри контейнера делиться не будет.
SRSLY? Дефолтная изоляция? Тупой общий бридж с политикой iptables-разреши-все-все-все? Не, я, конечно, согласен, что с такой изоляцией надо бороться. Только не в ту сторону вы боретесь, ее усиливать надо.
Тупой docker-compose вам, хотя бы, на каждый неймспейс по отдельному бриджу даст, а голый докер. Ни один здравомыслящий человек не порекомендует вам голый докер в каком-либо виде наружу отдать.
Дык, вы, получается, собираете конкретный контейнер под конкретную машину. Ну и нафига тут докер-то? Вам виртуализация уровня ОС нужна, например. LXD вам в руки, и никаких знаний там дополнительно не нужно. Запускаете виртуалку, цепляетесь к ней по ssh, рулите из консоли, «как настоящей». Нафига вам простыни докерфайлов?
Зато появится возможность подебажить СУБД отдельно, подключиться к другой базе, не пересобирать все целиком с непредсказуемым результатом, если надо тупо обновить версию postgresql.
Developing, shipping and running, чуете.
Developing? В целях разработки — говно подход. Ребилдить весь контейнер вместе с БД при надобности изменения 3 строк в скрипте — говно подход, как разработчик говорю.
Shipping? Доставка приложение на железяку, аналогичную предыдущей? Нафига вы искусственно сокращаете количество target'ов для вашего shipping'а?
Running? Вот строго для «запустить»? Докер НЕ является хорошим инструментом для запуска stateful-приложений. Есть инструменты сильно лучше.
Вот прямо буквами же написано «to separate your applications from infrastructure». Отделить приложения от инфраструктуры. Забандлить локалхост-онли СУБД = прибить нахрен гвоздями свое приложение к инфраструктуре. СУБД — stateful, по определению, она — ИНФРАСТРУКТУРА. И прямо в «предназначении» докера написано, что он призван ОТДЕЛИТЬ ее от приложения, а не забандлить внутрь.
По совокупности умелок работы со stateful-приложениями докер ни по какой совокупности не выигрывает ни у одной платформы оркестрации, и ни у одной системы изоляции уровня ОС.
Банальное нежелание что-либо изучать, банальное желание вкручивать шурупы молотком, потому что «с молотком мы уже умеем работать (в контексте ваших допущений о докере, конечно, нет, не умеете)», а инструкцию от отвертки еще читать надо.
Порог входа в LXD высок? Относительно порога входа в докер? Забавно, не знал, что 4 страницы текста осилить сложнее, чем 100500-страничный мануал с уточнением нюансов работы и пометками «не носите stateful в контейнере» через абзац.
В sudo apt install выше?
Поймите уже, вы имеете не «никаких телодвижений» против «оркестрация контейнерами», а «оркестрация процессами» против «оркестрация контейнерами». По сложности примерно монопенисуально, тут соглашусь, если не вдаваться в детали. С той только разницей, что один раз удачно настроенный контейнер вы можете переиспользовать, тупо «заоркестрировав» его в другой неймспейс или в другой сервис. Удачное решение на уровне оркестрации процессами внутри докер-контейнера не переносится, копипаста не в счет.
нихрена там не изолируется, о птичках если.
Цель докера, как раз, в том, чтобы процесс ЗАМЕТИЛ, что он изолирован. Процесс должен искренне считать, что в пределах системы он один, и тогда все хорошо, и докер тут красавчик. Как только внутри появляется оркестрация процессами, иниты и тому подобное — у докера проблема, хотя бы потому, что инит в докере искренне удивляется, какой такой другой инит вдруг убил его процесс, и на каких, собственно, основаниях.
Подключение СУБД (постреса и ему подобных, не локальной и не ин-мемори) в качестве volume'а — это НЕ «подключение извне», это куцее локалхост-онли извращение.
Удаленно что? Установиться? Работать? При чем тут ssh? Какой кейс мы рассматриваем? Собственно, одно могу гарантировать, в контексте LXD любую хотелку, реализуемую в докере, реализовать можно.
Зачем иметь отвертку, если есть такой замечательный молоток?
«Средствами уровня кластера» вы, простите, что сейчас назвали? Докер? Средство уровня кластера — это k8s, голым докером вы там не обойдетесь.
Докер тоже кластеры не умеет, тчк.
Реализуемо в 2 вариантах: нефункциональное УГ либо перегруженный комбайн. Короче, не судьба.
Когда вы утверждали, что сбандленная внутрь контейнера база — нормальная вещь для разработки, а для прода можно иметь отдельный докерфайл, два процесса CI/CD вас не смущали. Что изменилось? Когда вы собираете бандл из приложения + движок СУБД, какое отношение это вообще к CI/CD имеет?
Кто ж вам запрещает то? Хотите на одном хосте несколько версий ОС — системы виртуализации/изоляции уровня ОС вам в помощь, докер — нет, не в помощь. Хотите запустить несколько версий приложения — тем более в чем проблема, тут можно и докером. Осталось только понять, почему вы несколько версий приложения, каждая со своей БД хотите, а несколько версий/инстансов приложения с общей базой — нет.
Да вот нифига.
Вах, до классики добрались. Про «Быстро, дешево, качественно — выбери два» слыхали? Оно правда!
Вы сами выбрали «быстро» + «дешево», зачем вы пытаетесь ЭТО выдать за «качественно»?
Она же показала, что хуже, чем виртуализация, LXC/LXD, flatpak, snap. При этом докер отлично работает для доставки ЧАСТЕЙ/МОДУЛЕЙ распределенных stateful-приложений в условиях наличия оркестрации (compose, swarm, k8s — все вот это). При этом практика крупных корпораций подсказывает нам, что и для этих задач конкретно docker сильно не оптимален, и в том же k8s, например, от самого докера только build-фаза и осталась. Возможно, тоже не надолго.
Латинский словарь говорит нам: ens с латыни может переводиться как «существующее, сущее, существо, вещь».
Русский словарь говорит нам:
Т.е. в современном понимании «сущее» — окружающая нас действительность, реальность.
Вот это нам говорит оригинал изречения. Постарайтесь заметить entia в самом начале. Это форма множественного числа слова ens.
Другими словами, вы считаете, что исходная фраза говорит о том, что без необходимости не нужно плодить «окружающие дествительности»? Или «параллельные реальности»? Или, может, вы, все таки, в латинском словаре после «ens — сущность» запятую не заметили и продолжение списка возможных от контекста переводов? Или таки не улавливаете разницу между i10n и l18n и искренне верите, что перевод легендарным «Промптом» — вершина эволюции переводов? Все таки «сущее», и вам лучше знать, и там вообще ничего общего с методологическим редукционизмом?
Печаль-бида. Только что про SOA и MSA рассказывали, а теперь связи настроить сложно?
Ага, та самая, которая абстрагирует вас от сложности ручного управления взаимосвязанными контейнерами и позволяет как-то продвигаться в сторону переиспользуемых контейнеров.
И докер тоже тут не нужен, вам LXC/LXD нужен.
Вы бредите. Когда ж вы с 2008-го года «наработанные десятилетиями практики» наработать успели-то???
Вне зависимости от прода ограничение «25% памяти — постгресу» в докерфайле непереносимо. Т.е. «дистрибуцию», «масштабирование», «воспроизводимость окружения» и все вот это мы вычеркиваем, т.к. ничего воспроизводить, масштабировать и распространять вы не собираетесь. Остается только «изоляция». Т.е. вы хотите просто один раз это настроить, запустить, чтобы оно как-то работало и не подралось с соседями. Дык, для этого есть более другие, ГОРАЗДО более приспособленные под кейс инструменты. Возьмите, блин, LXD — это контейнер ОС, он ровно для этих случаев пилится. Это как виртуалка, только с изоляцией на уровне ядра, в смысле, с тем же оверхедом, что и докер. Зачем вы пытаетесь ВСЕ в докер запихать. Я, конечно, понимаю, что дай вам в руки молоток, вы все за гвозди посчитаете. Просто как доктор вам говорю: шурупы удобнее закручивать отверткой.
Т.е. у вас есть десятки серверов БД разных версий, некоторые с репликами, все это как-то балансируется, масштабируется и все вот это… А вы постгре в каждое приложение бандлите! Красавцы!
Ну вот зря они. Ничто, как водится, не ново под луной. Все с завидной регулярностью переизобретается. Микросервисы — это ровно переизобретенная SOA, только ближе к практическому применению на более узких кейсах + некоторый набор устоявшихся практик.
Вы говорите, что одна база для каждого инстанса же! Понимаете, забандленная в контейнер с приложением СУБД — это и есть одна база на ИНСТАНС. Или вы, в смысле, собираетесь один volume с файлами СУБД в несколько контейнеров подмонтировать, чтобы НЕСКОЛЬКО СУБД-ДВИЖКОВ с одним набором файлов работало? Кхм, вы точно ничем не больны?
Я же, вроде, достаточно четко говорил: постгри или любые СУБД того же уровня пихать в один контейнер с приложение — говно подход. Если база не сетевая — вопрос отпадает сам по себе, но это НЕ энтерпрайз-субд уровня постгри, это, как правило, sqlite. Вот она, как раз, отлично подходит для того, чтобы ее вольюмом в контейнер пихали. А постри — не подходит. Только, пожалуйста, sqlite тоже не монтируйте в 2 контейнера одновременно, она, как бэ, single-user БД.
Ну и, собственно, почему вы считаете, что база, прибитая к локалхосту — это отличный способ конфигурации. Что вы там на уровне подключения поконфигурировать можете? Вместо 127.0.0.1 в параметрах подключения localhost ввести?
Конкретный кейс собран в условиях «вау, есть же докер! Давайте соберем образ, чтобы еще одну галочку поставить в графу СПОСОБЫ РАЗВОРАЧИВАНИЯ. Вот, например, наша техничка Алёна докерфайл набросала, я проверял, на моем компьютере запускается, давайте положим это на оф. сайт.» И не надо про ограниченные ресурсы. Не надо тратить и без того ограниченные ресурсы на выпуск говна.
А это, простите, нахрена?
Когда приложение хреново конфигурируется/работает в контейнерном окружении, я так и говорю, оно хреново работает в этом окружении. А если приложение само по себе хреново чувствует себя в контейнере, запихать его в контейнер с еще одним приложением — это не решение проблемы, а неиллюзорный способ выхватить граблями по лбу в самом непредсказуемом месте.
То, что вам обоим нравится, не делает это сколько-нибудь нормальной практикой. В виде бандла с базой внутри — оно может приемлемо работать в конкретной комбинации ресурсов, предоставляемых контейнеру на узком use-case'е, подходящим конкретно вам. Дистрибуция в таком виде становится бессмысленной, вариант подпадает под категорию «локальные извращения, которых можно было избежать, но было лень».
У вас БД сбандленна внутрь контейнера приложения. Это неиллюзорная возможность потерять, например, историю телодвижений пользователей и начать все «с чистого листа». Вы просто оттянули наступление геморроя. При этом упаковать это в сратый docker-compose — дело получаса. Разгрести эту кашу при миграции — затянется на дни.
Докер создан заради возможности складывать окружение приложения в тот же репозиторий системы контроля версий, что и само приложение. Короче, вся эта хрень — заради воспроизводимости сборки/окружения. В остальных кейсах есть инструменты лучше.
Разрабатывать и поддерживать ЭТО не проще. При этом воспроизводимость сборки и окружения в этом докерфайле не гарантирована. Докер хорош, действительно хорош для тех случаев, когда ребилд образа не ломает работоспособность приложения. Это не тот случай, тупой ребилд (который может случиться на автомате в любой системе оркестрации) запросто положит рабочий проект. Поэтому в каждой мало-мальски серьезной книжице по докеру/контейнерам приложений/оркестрации контейнерами большими чОрными буквами написано: не кладите ресурс внутрь контейнера, все stateful ресурсы должны подключаться к контейнеру извне. При этом часто рядом стоит пометка на полях для «особо одаренных», что базы данных целиком считаются внешними ресурсами и не должны быть внутри контейнера приложения, если, конечно, террористы не обещают убить вашу сестру в случае, если вы не забандлите ЭТО.
Что касается конфликтов при развертывании на локалхосте — взгляните уж на snap и flatpak. Для локалхост-деплоя подходит гораздо лучше, изоляция ровно на тех же механизмах (да-да, все те же cgroups/namespaces), все те же «слои» фс, все то же самое, но плюс некоторое количество умелок, специфичных для локалхоста. Например, в них можно без боли упаковать GUI-приложение, например.
В том и дело, что ничем. В том и вопрос: нахрена городить огород с докером, если работает ваша вещь ровно на локалхосте и ни каких плюшек относительно локальной установки не дает? Только лишние юзерспейсные косяки с безопасностью добавляет, и геморрой на ровном месте порождает.
Т.е. у LXD внутрях полноценный инит и все вот это. А докер — запустить процесс, дождаться, пока сдохнет, убить окружение.
Можно поинтересоваться, какими средствами докера вы добились невозможности изменения конфига пользователем при запуске?
Зачем его менять в репе, если его можно подсунуть при старте?
Ложная индукция. Контейнеризация помогает в минимизации проблемы УМВР, в контексте разработки, т.к. максимально унифицирует окружение разработчика и прод. А вот в «всё сделал по инструкции, но не работает» она скорее мешает. В настройки безопасности локальной постгри рядовой пользователь залезть не может, ибо прав недостаточно. В настройки постгри, запущенной этим пользователем в контейнере — запросто.
Жуть какая, постгре хотя бы «той модели»? Гитлаб, условно, в принципе с постгре работает же? Собственно, в чем препятствие выкинуть к хренам «особенный постгре» и положить вместо него «обычный»? А, точно, он же на локалхосте…
Проблема в том, что вместо решения проблем вы пытаетесь настрать на них, закопать поглубже и делать вид, что их нет. Вместо того, чтобы протестить тупо линк до постгре-сервера и в случае отстутсвия сказать «ой, у вас ваша постгря отвалилась» вы предлагаете все в кашу захренячить в один контейнер. Не надо, блин, конечных пользователей имбецилами считать. Среди потребителей вашего продукта могут оказаться вполне вменяемые сисадмины, которые еще и вам подскажут, где косяк, и как по быстрому поправить… Хотя не, у вашего продукта таких не будет. Они посмотрят на постгре внутри, и, с криками «свят-свят» зарекутся к этому прикасаться в принципе.
Давно «прибить авторизацию к айпишнику, который может ручками выставить на свой бучек любая п… да, которая приперлась с ним в контору и воткнувшаяся в локалку» надежнее, чем «авторизация по доменному резолверу» или «авторизация по ssl-ключам»?
Нормальная практика — это подход, в котором «быстрая контейнеризация существующих приложений» производится человеком, сколько-нибудь компетентным в вопросе. «Деплоить и доставлять» действительно, можно и обезьяне доверить, эта вещь приемлемо автоматизируется. А вот автоматизация процесса, как показывает практика, автоматизируется из рук вон плохо.
Докер — хреновая обертка для доставки stateful-приложений. Если хочешь доставить на локалхост — самый-самый инструмент для кейса — docker-compose.
Множить сущее — это вы куда-то замахнулись. В оригинале про сущности было, например. Вы просто вместо того, чтобы средствами оркестрации рулить абстрагированными сущностями а-ля контейнер, почему-то предпочитаете помножить низкоуровневые сущности внутри контейнера. При том, что для оркестрации ресурсов на уровне контейнеров существует ряд решений, которые как-то развиваются и отлаживаются. А для оркестрации костылей внутри контейнера решений нет и не предвидится, рекомендуют подход «залей это лавой».
Реально? Запилить контейнер, внутри которого 25% памяти отдать постгресу, а что осталось — вебморде с обвязкой вокруг гита — это применимо в проде? Давно это норма?
Требования в студию.
Десятки серверов БД в кластере, с настроенной репликацией, фейловером и т.д. Это в целях отказоустойчивости делается, а также для повышения общей производительности БД. Ну еще в целях экономии денег на этом зоопарке, т.к. серверное оборудование дорогое, и отдавать пару процессорных ядер с 10 гектарами оперативки для работы 10 мажоров на гитлабе никто особенно не стремится. Совокупное кеширование может оказаться сильно дешевле.
Никогда, ни при каких условиях SOA (которую вы называете микросервисным подходом) не предполагала отдельную базу для каждого ИНСТАНСА сервиса. Бред это потому что, и противоречит логике.
Прибить базу к локалхосту принято читать как «отсутствие способов конфигурации»
Показывает факт того, что собрано это поделие на коленке по быстрому группой энтузиастов, которые торопились собрать поделие пока энтузиазм не утих.
Т.е. docker run обучения персонала не требует, это все с рождения умеют, а docker-compose up — сверхсложная наука, которой по 6 лет в университете учат?
Это а) совершенно логично, б) совершенно не повод все в них пихать.
Отдать пользователю приложение со сбандленным постгресом, ограниченным в аппетитах среднепотолочными значениями — говно подход, вне зависимости от конечного пользователя.
Еще раз, конкретно этот случай — говно решение, вне зависимости от того, кому проще.
4.1. Есть масса способов «упростить развертывание новых инстансов». Не нравится apt install — велкам в appImage, snap, flatpak. Задачу доставки приложения призваны решить именно они.
4.2. Загляните в докерфайл. Чем оно лучше apt install, особенно если учитывать тот факт, что внутри там именно apt install + хренова уйма костылей вокруг, чтобы это хоть как-то завелось?
4.3. Чем для пользователя sudo apt install gitlab-ce сложнее docker run gitlab-ce:latest?
4.4. К вопросу о трейд-оффе. Если даже развертывание чем-то проще, вопрос обновления/закрытия уязвимостей начинает «цвести и пахнуть».
А «серьезные дядьки» в докерфайле прямо пишут вот такое: echo "# Prevent Postgres from trying to allocate 25% of total memory". Там еще много замечательных вещей в докерфайле, я давал на него ссылку. И все утверждают, что все норм, так можно делать и «у меня все работает, не вижу проблемы».
Понимаете, postgresql сам по себе докеризуется через огромную хитрозаверченную жопу. При этом есть возможность не делать вид, что «проблема решена» путем обрезания доступной постгресу памяти в размере 25% памяти, доступной контейнеру и прибиванием его к локалхосту, а хотя бы попробовать прикрутиться к чему-то сколько-нибудь стандартному или, уж не до хорошего, поддерживаемому.
Ан нет, все дружно утверждают, что сложить костыли постгреса в один файл с костылями самого приложения, попутно отобрав у человека возможность сделать по-человечьи — это «нормальная практика», и «отдать постгресу 25% памяти» — это нормально для боевого прод-окружения.