Собственно, триггерился я больше на идею «весь LAMP в одном контейнере, а чо нет?». Вот эта идея и прочие «эталонные реализации» с «постгресом внутри контейнера» — изначально очень плохая практика в 99% случаев, и я с ходу не могу придумать кейса, в котором такой подход хоть сколько-нибудь оправдан. Даже как «поиграться с локальным гитлабом» — достаточно «пахнущее» поделие. Натягивать СУБД на практики контейнеров приложений — это как «сова и глобус», в теории можно, но идея заведомо плохая.
А локальный кеш — почему бы и нет. С нюансом, опять же, в скорости «прогрева» кеша. В проде «прогревающийся» по 10-15 минут инстанс может вылезти боком, «на вырост» надо трейд-офф таки планировать.
а можно источник, откуда «запускать БД в Docker это нерекомендуемая практика»? или это вы так не рекомендуете делать?
Запуск БД в Docker — это, в первую очередь, достаточно бессмысленная практика.
Дело в том, что «контейнер приложения» — это такая штука, которая «сдохла, да и пофиг, рядом другую запущу» или «надо масштабироваться? Не проблема, запустим еще 158 инстансов». И вся эта возня с горизонтальным масштабированием, read-only слоями, отказом от бэкапов инфраструктуры и т.д. — она на базах данных не работает. Если вы поверх одного и того же persistent volume'а запустите две одинаковых СУБД, они просто превратят ваше хранилище в кашу, не больше и не меньше. БД просто масштабируются иначе, докер для них смысловой нагрузки не несет, только чуть-чуть лишнего оверхеда приносит.
А для отладочных целей, «чтобы не морочиться с доступом из compose» и тому подобное — да пожалуйста, не проблема.
для какого-нибудь apache вытаскивать webroot в volume тоже не рекомендуете? или вебсерверы тоже не стоит в контейнеры помещать?
Ну, сопсна, всякие «апачи» норм масштабируются, их можно. webroot — это, по факту, набор конфигов, которые апач читает на старте. Апач не генерит миллионы конкуррентных записей в вебрут, для него этот самый webroot — ридонли. Короче, не передергивайте, в случае с апачем все норм.
Честно говоря, сами БД в концепцию «12-факторных» приложений ложатся от слова «никак». Масштабирования БД по кластеру — это такая штука, которая средствами оркестрации контейнеров никак не решается, живите теперь с этим)
Нужно уточнить что такое докер контейнер. Это бизнес-единица, единица масштабирования сервиса, единица развертывания или что еще.
Чем бы вы докер-контейнер не считали, идея запихать сервис в один контейнер с БД — хреновая.
Единица масштабирования? Ок.
Представим кейс: есть внешнее апи, тяжелый воркер под ним и БД, откуда воркер данные берет/пишет. И все это в одном контейнере…
… И стал контейнер, как водится, тормозить. При этом выяснилось, что воркер не вывозит. Вот тупо два штуки запустить, и ок… Ан не так это и просто! Берем и перепиливаем весь контейнер с нуля!
База колом встала? Кластер бы поднять, да соседние контейнеры не трогать? Нельзя — у вас контейнер монолитный, перепиливаем с нуля.
Ну вот зачем это все, если можно было в самом начале просто один компоуз-файл написать?
Единица развертывания? Вы реально в прод-развертывании собираетесь этим рулить голым докером? У вас один фиг «в бой» оно пойдет из-под какого-нибудь k8s с вероятностью процентов 80. Т.е. все равно оркестрация будет, декомпозируйте задачу ДО того, как она стала вашей проблемой.
Ну вот определитесь уже, вам «моделировать взаимосвязи», «выращивать граф зависимостей» и т.д., или таки монолитный контейнер «все-что-нужно внутри». Как бы, один контейнер на все совершенно аналогично не решает каких-либо задач масштабирования, зависимостей и прочего. При этом компоуз хотя бы даст возможность отдать ровно ту же базу данных еще одному сервису в пределах окружения или расшарить данные между набором контейнеров, чего монолит сделать не даст.
Каждый раз, когда вы суете базу данных (либо любой иной контент-провайдер) для сервиса в тот же образ, в котором лежит сам сервис, где-то в мире плачет еще один разработчик SOA-архитектуры.
Короче, вообще непонятно, зачем:
1. Дублировать функционал готового контейнера с движком СУБД в свой «большой контейнер».
2. Прибивать сервис гвоздями-сотками к БД на локалхосте.
3. Отказываться заранее от возможности все это масштабировать и отливать структуру всего этого в бронзе.
При том, что все «плюшки» подхода «вжух и завелось» отлично работают в виде тупенького docker-compose.
а мы и не ерничаем… Мы, собственно, ровно в той же позиции, что и вышеозначенные мышки.
«Боль» в данном случае — это именно та цена, которую гугл просит за возможность «покушать кактус». Как опция предлагается возможность заплатить денег и кушать менее колючий, местами гладковыбритый подвид этого замечательного растения.
Болевой порог, собственно, у всех разный. Поэтому всем приходится самостоятельно определяться, где именно находится тот порог, после которого можно заплатить денег, чтобы испытывать меньшую боль. Либо, если боль действительно непереносима, просто перестать питаться кактусами и перейти на более здоровую диету.
При этом мышки, вместо того, чтобы предпринимать какие-либо действия, продолжают кушать, не забывая об этом плакать на всех профильных и не очень ресурсах. При этом все отлично понимают, что слезы мышек, пока они не выражены в потерях доходов хозяевами кактуса, особого значения не имеют. Вот массовый переход мышек на более здоровую/менее болезненную диету вполне может сподвигнуть производителя кактуса на выпуск несколько другой продукции, но зачем он будет это делать, если мышки, хоть и плачут, жрать не перестают?
Думаю, в такой современной ОС как Линукс всяко найдётся софтина для BBS. :)
Софтина есть, ок. А с магистралью что делать? Вот воткнули бы модем, все круто, типа… А ваш «стационарный телефон» вдруг, оказывается, подключен по цифровой линии…
Какбэ, в текущей ситуации на VPSке пользователя был создан левый пользователь. Так что вернее выглядит следующая ассоциация:
Ты купил пива, а дома, когда наливал его в стакан, заметил, что в бутылке плавает лягушка, а пена на пиве фиолетового цвета.
— Нет, быть не может, что говно попалось! — подумал ты. — Я же ДЕНЬГИ ЗАПЛАТИЛ!
Зажмурился, заткнул нос, постарался максимально абстрагироваться и таки выпил.
задача дизайнера как раз — создание прогресса, дизайнеры должны делать мир лучше — удобнее или красивее, это касается рекламы и услуг в том числе.
Очаровательные юношеские представления об обязанностях и высоком предназначении дизайнеров…
Дизайнер-профессионал, прежде всего, должен и обязан делать то, за что ему платят деньги. А платят, как правило, за действия, ведущие к «повышению конверсии». За «прогресс» и «лучший мир» мало кто готов платить.
Если дизайнер вдруг за деньги заказчика, вместо того, чтобы делать «потребление рекламного контента более регулярным, при этом максимально незаметно для пользователя», начинает «бороться с системой»… Ну, как бы, на мороз такого дизайнера.
«Лучший мир», «прогресс», «красота», «удобство» — это все пожалуйста, только в свободное от работы время.
Важно чтобы такое больше никогда не повторилось, а виновники были наказаны по всей строгости!
Такое — это наличие уязвимостей на сервере в принципе? Я вас разочарую, повторится, и не раз, и не только у 1Cloud.
А наказание виновников «по всей строгости» вам, простите, зачем?
Если честно, сам факт того, что услуга платная, вообще ничего не говорит о ее качестве, например. С вашей логикой любая услуга — так себе, просто по определению услуги.
Вы ничего плохого не сделали. У вас просто заведомо уязвимая позиция «мы заплатили деньги, значит, все хорошо, и ничего проверять не надо». При этом аргументация такой позиции у вас на уровне «вот в Digital Ocean» все хорошо, им мы доверяем.
Дело в том, что у того же DO тоже вполне себе обнаруживаются время от времени уязвимости, никто не без греха. И «пофиксить» их без вмешательства с вашей стороны тот же DO не всегда может. Потом вы пропустите письмо от DO с просьбой «нажать вот эти кнопки вот в такой последовательности» и будете писать ровно такой же пост, только уже про «плохой DigitalOcean».
Справедливости ради, вы в данный момент ведете себя не сильно лучше поддержки 1Cloud.
Вот это место:
По моему я четко объяснил, что какой-то сотрудник 1cloud имеет пароль от пользователя user и инжектит всякую дичь на сервер.
выглядит достаточно сомнительно.
Почему именно сотрудник 1cloud? Логичнее предположить, что пользователь — тупо шаблонный, и во всех контейнерах у него один и тот же пароль. Для того, чтобы одноразово подобрать пароль и потом использовать его на всех инстансах, совершенно не обязательно быть сотрудником 1Cloud. В конце концов сотруднику проще тупо «заинжектить дичь» напрямую в шаблон ОС, чтобы не «палиться» с логами авторизации при последующих коннектах с целью «заинжектить дичь».
Это не отменяет того факта, что у 1Cloud дыра в шаблоне контейнера размером не то что с футбольные ворота, а скорее с футбольное поле, но хотелось бы, чтобы вы, как человек вопрошающий, придерживались корректных формулировок.
Ну а вот это:
Вообще-то, если вкратце, то мы никому ничего не должны, и прямая обязанность 1cloud — предоставлять клиентам сервера без уязвимостей
вообще достаточно странная позиция.
«Мы не должны как-либо проверять качество получаемой нами услуги» — достаточно уязвимая позиция, например, вам не кажется? Это не ваша прямая обязанность, конечно, но оценка качества — нормальная позиция адекватного человека. При этом, если вы сами предоставляете услугу на базе сервисов 1Cloud третьей стороне, то проверка качества сервиса 1Cloud таки становится вашей прямой обязанностью, вы ведь принимаете на себя обязательство о качестве вашего сервиса уже перед вашим клиентом.
С вас — не получит. Более того, он даже и не рассчитывал. Получит он с заказчика рекламы, уже получает. Нормально получает, судя по капитализации. И при этом не первый год.
А локальный кеш — почему бы и нет. С нюансом, опять же, в скорости «прогрева» кеша. В проде «прогревающийся» по 10-15 минут инстанс может вылезти боком, «на вырост» надо трейд-офф таки планировать.
Докер — контейнер приложения.
LXD — контейнер ОС.
Запуск БД в Docker — это, в первую очередь, достаточно бессмысленная практика.
Дело в том, что «контейнер приложения» — это такая штука, которая «сдохла, да и пофиг, рядом другую запущу» или «надо масштабироваться? Не проблема, запустим еще 158 инстансов». И вся эта возня с горизонтальным масштабированием, read-only слоями, отказом от бэкапов инфраструктуры и т.д. — она на базах данных не работает. Если вы поверх одного и того же persistent volume'а запустите две одинаковых СУБД, они просто превратят ваше хранилище в кашу, не больше и не меньше. БД просто масштабируются иначе, докер для них смысловой нагрузки не несет, только чуть-чуть лишнего оверхеда приносит.
А для отладочных целей, «чтобы не морочиться с доступом из compose» и тому подобное — да пожалуйста, не проблема.
Ну, сопсна, всякие «апачи» норм масштабируются, их можно. webroot — это, по факту, набор конфигов, которые апач читает на старте. Апач не генерит миллионы конкуррентных записей в вебрут, для него этот самый webroot — ридонли. Короче, не передергивайте, в случае с апачем все норм.
Чем бы вы докер-контейнер не считали, идея запихать сервис в один контейнер с БД — хреновая.
Единица масштабирования? Ок.
Представим кейс: есть внешнее апи, тяжелый воркер под ним и БД, откуда воркер данные берет/пишет. И все это в одном контейнере…
… И стал контейнер, как водится, тормозить. При этом выяснилось, что воркер не вывозит. Вот тупо два штуки запустить, и ок… Ан не так это и просто! Берем и перепиливаем весь контейнер с нуля!
База колом встала? Кластер бы поднять, да соседние контейнеры не трогать? Нельзя — у вас контейнер монолитный, перепиливаем с нуля.
Ну вот зачем это все, если можно было в самом начале просто один компоуз-файл написать?
Единица развертывания? Вы реально в прод-развертывании собираетесь этим рулить голым докером? У вас один фиг «в бой» оно пойдет из-под какого-нибудь k8s с вероятностью процентов 80. Т.е. все равно оркестрация будет, декомпозируйте задачу ДО того, как она стала вашей проблемой.
Короче, вообще непонятно, зачем:
1. Дублировать функционал готового контейнера с движком СУБД в свой «большой контейнер».
2. Прибивать сервис гвоздями-сотками к БД на локалхосте.
3. Отказываться заранее от возможности все это масштабировать и отливать структуру всего этого в бронзе.
При том, что все «плюшки» подхода «вжух и завелось» отлично работают в виде тупенького docker-compose.
Ну и замечательно. Зачем стремиться к вещи недостижимой в пределах биологического вида? Тем более, вредной для этого вида?
«Боль» в данном случае — это именно та цена, которую гугл просит за возможность «покушать кактус». Как опция предлагается возможность заплатить денег и кушать менее колючий, местами гладковыбритый подвид этого замечательного растения.
Болевой порог, собственно, у всех разный. Поэтому всем приходится самостоятельно определяться, где именно находится тот порог, после которого можно заплатить денег, чтобы испытывать меньшую боль. Либо, если боль действительно непереносима, просто перестать питаться кактусами и перейти на более здоровую диету.
При этом мышки, вместо того, чтобы предпринимать какие-либо действия, продолжают кушать, не забывая об этом плакать на всех профильных и не очень ресурсах. При этом все отлично понимают, что слезы мышек, пока они не выражены в потерях доходов хозяевами кактуса, особого значения не имеют. Вот массовый переход мышек на более здоровую/менее болезненную диету вполне может сподвигнуть производителя кактуса на выпуск несколько другой продукции, но зачем он будет это делать, если мышки, хоть и плачут, жрать не перестают?
Софтина есть, ок. А с магистралью что делать? Вот воткнули бы модем, все круто, типа… А ваш «стационарный телефон» вдруг, оказывается, подключен по цифровой линии…
Ты купил пива, а дома, когда наливал его в стакан, заметил, что в бутылке плавает лягушка, а пена на пиве фиолетового цвета.
— Нет, быть не может, что говно попалось! — подумал ты. — Я же ДЕНЬГИ ЗАПЛАТИЛ!
Зажмурился, заткнул нос, постарался максимально абстрагироваться и таки выпил.
Очаровательные юношеские представления об обязанностях и высоком предназначении дизайнеров…
Дизайнер-профессионал, прежде всего, должен и обязан делать то, за что ему платят деньги. А платят, как правило, за действия, ведущие к «повышению конверсии». За «прогресс» и «лучший мир» мало кто готов платить.
Если дизайнер вдруг за деньги заказчика, вместо того, чтобы делать «потребление рекламного контента более регулярным, при этом максимально незаметно для пользователя», начинает «бороться с системой»… Ну, как бы, на мороз такого дизайнера.
«Лучший мир», «прогресс», «красота», «удобство» — это все пожалуйста, только в свободное от работы время.
Такое — это наличие уязвимостей на сервере в принципе? Я вас разочарую, повторится, и не раз, и не только у 1Cloud.
А наказание виновников «по всей строгости» вам, простите, зачем?
Дело в том, что у того же DO тоже вполне себе обнаруживаются время от времени уязвимости, никто не без греха. И «пофиксить» их без вмешательства с вашей стороны тот же DO не всегда может. Потом вы пропустите письмо от DO с просьбой «нажать вот эти кнопки вот в такой последовательности» и будете писать ровно такой же пост, только уже про «плохой DigitalOcean».
Вот это место:
выглядит достаточно сомнительно.
Почему именно сотрудник 1cloud? Логичнее предположить, что пользователь — тупо шаблонный, и во всех контейнерах у него один и тот же пароль. Для того, чтобы одноразово подобрать пароль и потом использовать его на всех инстансах, совершенно не обязательно быть сотрудником 1Cloud. В конце концов сотруднику проще тупо «заинжектить дичь» напрямую в шаблон ОС, чтобы не «палиться» с логами авторизации при последующих коннектах с целью «заинжектить дичь».
Это не отменяет того факта, что у 1Cloud дыра в шаблоне контейнера размером не то что с футбольные ворота, а скорее с футбольное поле, но хотелось бы, чтобы вы, как человек вопрошающий, придерживались корректных формулировок.
Ну а вот это:
вообще достаточно странная позиция.
«Мы не должны как-либо проверять качество получаемой нами услуги» — достаточно уязвимая позиция, например, вам не кажется? Это не ваша прямая обязанность, конечно, но оценка качества — нормальная позиция адекватного человека. При этом, если вы сами предоставляете услугу на базе сервисов 1Cloud третьей стороне, то проверка качества сервиса 1Cloud таки становится вашей прямой обязанностью, вы ведь принимаете на себя обязательство о качестве вашего сервиса уже перед вашим клиентом.