Work.Дыбр

[dzz]

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

:)

Comments

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]

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