Work.Дыбр

[dzz]

Чем больше я погружаюсь в глубины контейнерных технологий, тем больше крепнет впечатление, что каждый второй в этой сфере разрабатывает свой стек для сборки, деплоя и управления докерами. Т.е. "вот 10 прекрасных средств для того, чтобы сделать A, Б и В, но если нужен шаг в сторону - напишите скрипт сами"

:)

Comments

[jno2004.livejournal.com]

И везде грабли разложены...

[dzz.livejournal.com]

Не без того. Плюс, из готовых решений что-то сильно избыточно, что-то не умеет registry, что-то не может шаблоны, и т.п. вот и думай :)

[bodeh.livejournal.com]

https://xkcd.ru/927/

[dzz.livejournal.com]

Таки да! :)))

Хм-ммм...

[de_nada]

Вот не зря я не люблю контейнеры, не зря...
Не, "готовить умею" в принципе (даже довелось поднимать из небытия сайт в контейнере Virtuozzo хрен знает скольки годов выделки (перед тем выковыряв его из быкапа хостера(!)), но не люблю.

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

С уважением.

p.s. Но ещё больше не люблю нынешнюю поросль т.н."дево-псов" и примкнувших к ним шепиловых т.н."разработчиков", которые нихрена не знают (и не желают знать) ничего о том, в какой именно среде должны совершаться их т.н."деплои" и выполняться их т.н."программы".
Не, мы пролитаем методичку-другую, распихаем по докер-контейнерам апача с нджинксом (ага, оба-двое!), кафку, постгрю с мариейдб (ага, обе-две!), ещё пару-тройку "тяжеловесных" софтин (не особо нужных для общей конь-цепции, зато модных), понавяжем бантиками докер-конфигов (до икоты путаясь с сетями внутри, между и наружу), обмазем всё это ямээлями плейбуков — и алга деплоить (не, не так — ДЕПЛО-О-О-О-ООИТЬ!!!1111) в прод.

А потом, получив бабосы за внедрёж, исчезнуть в тумане, оставив админов мыкаться с этим под невнятное мычание их ТП (в хорошем случае).

Ссссука, ну вот нахера везде пихать эти "эвергрины" контейнеров? Зла не хватает просто...

Re: Хм-ммм...

[dzz.livejournal.com]

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

На эти грабли уже налетали неоднократно, докеризация в данном случае вынужденная и я стараюсь проектировать её разумно. В каждом проекте по максимуму три контейнера — система верхнего уровня с nginx-ом и постгрей, мидлварь с redis-ом и рендерер. В облаке редис и постгрес вынесены и работают в интересах всех инстансов системы, как и рендерер.

Проблемы ИБ по большей части решаются внешним контуром, опыт есть.

Ну и расход оперативной памяти (а это недешёвый ресурс) у докеров заметно ниже по сравнению с полной виртуализацией.

P.S. "Микросервисников", пихающих по 100 контейнеров в системе, я сам тихо ненавижу, поскольку разгребал последствия такого архитектурного подхода.

:-/

[de_nada]

М-да, тут ещё и ""облако" у заказчика" затесалось...

Чтоб "не париться с версиями", необязательно докеризоваться — можно и "классической VM" прекрасно обойтись.

Аргумент, что для VM надо больше оперативы, он такой... скользкий, как по мне. :)
Из одной шкуры десять шапок не сошьёшь — только десять шапочек.
И памяти либо хватает, либо нет — безотносительно типа виртуализации.
Тем более, что у некоторых гипервизоров есть oversubscribing (и почти у всех ballooning), так что даже ситуативная "нехватка" памяти между VM может быть нивелирована.

И я не ратую вот прям за отдельную VM "для каждого скрипта" :)) — не, их, сервисы, тоже можно группировать по несколько на VMку и гибко сочетать их взаимодействие.
Скажем, у мну одна VM с SQL-сервером работает сразу на несколько сервисов, то же самое и с серверами терминального лицензирования и управления... а уж одна VM с реверс-прокси, прикрывающая туеву хучу хостов (а со SNI и расход "внешних" IP-шников резко снижается) вообще "классика жанра". :)

В общем, пока мне не доводилось нарываться на проблемные ситуации и задачи, не решаемые VM`ками и требующие непременно контейнеров. Наверно, специфика админа-инфраструктурщика. :)

Про ИБ внешним контуром соглашусь — сам придерживаюсь той же "кочки зрения", концепция "ломтиков сыра" рулит. :)
Хотя и тут у VM`ок преимущество: их собственные "бастионы" более "прозрачно" устроены и работают, нежели у грозди контейнеров. Т.е. в целом получается более гибко инфобезить, сочетая "внешний контур" и контуры VM`ок.

В общем, "всё сложно depend on"... :)))

С пониманием.

RE: :-/

[dzz.livejournal.com]

Как известно, хороший системный аналитик способен убедительно обосновать безусловное преимущество любого варианта перед любым :)))

У виртуалок (в частности, у ESXi) не так просто с реестром образов, как у докера, что несколько затрудняет обновление софта в нашем случае. Я рассматривал разные архитектурные варианты, в т.ч. виртуализацию, но пока контейнеры похожи на лучшее компромиссное решение задачки.

> В общем, "всё сложно depend on"... :)))

Это точно.

[jno2004.livejournal.com]

Вот выкатит вам заказчик условием деплой в вмы с альтом каким... Сразу докер ща щазье проканает