Митап «Да кому он нужен, этот ваш Kubernetes?» Все, о чем Вы боялись спросить, но хотели узнать

Ах если бы. Скорее, это суровая реальность: либо вы втыкаете по 3-4 контейнера на хост, либо тратите огромное количество усилий на подбор связки «ядро-докер-плагины», либо молитесь. В общем и целом, докер для ответственного продакшена малопригоден. Но мелочь и стейджинги в нем крутить - одно удовольствие, факт.

Причем здесь рашн? Это общемировая тенденция к отуплению (и вытекающему удешевлению) разработчиков. Собственно, отсюда и появился девопс.

либо тратите огромное количество усилий на подбор связки «ядро-докер-плагины»,

Есть такое дело. Но данный эффект проявляет себя в основном когда есть тяжёлая нагрузка на disk io. С переходом на ceph эта проблема исчезла. Хотя может и просто звёзды так совпали.

Кубернетес плох тем, что нужно переписывать софт под его идеологию...

А что используете как хостовую систему для кубернетес кластера?

Технари отвратительны. Прислуга буржуазии — глобалистов, вообразившая свое копошенме в символах без смысла, новым, высшим описанием мира. Не ведающие, что творят, и о чём говорят они, и что говорят им. Инвалиды, с детства прикованные к искаженной линзе техносферы.

Но ничего. Мечтайте о Марсе — но всё, что всегда было доступно вам, всего лишь игра теней из прошлых веков, симуляция Системы. Погребайте свою жизнь и разум под разнообразными «кубернетесами» — таких ещё будет много. Не дать продыху. Не дать оглядеться. Уютный, мёртвый мирок двоичной логики и причастности к фантазму Объективной истины мира. Когда Смерть заглянет вам в лицо в последний раз, познайте всё отчаяние от пустоты всего, что было вами сделано.

Дьявол ходит по земле. В каждом полупроводнике находит он частицу своей силы. В каждой душе, отравленной ядом науки, находит он своего слугу.

Схоронил.

Вообще контейнеры поощряют бардак и отсутствие унификации в ИТ-инфраструктуре, плодят дыры в безопасности (поскольку содержимое контейнеров же трогать низзя ни в коем случае, даже если разработчик туда запихал отруби мамонта)

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

и жрут в разы больше места на диске.

Официальный образ с перлом занимает 37 Мб https://hub.docker.com/r/library/perl/tags/

Есть образы на основе дистрибутива alpine. Чистый образ alpine https://hub.docker.com/r/library/alpine/tags/ занимает 2 Мб(!)

Образ с перлом на основе alpine - 11 Мб https://hub.docker.com/r/avastsoftware/alpine-perl/tags/

при этом ещё и работающие с ядром через слой контейнерной «абстракции», т.е. медленнее нормальных приложений

Нет, контейнеры системные вызовы ни как не проксируют, системные вызовы делаются напрямую в ядро. Контейнеры используют фичи типа namespaces и cgroup, которые находятся в ядре.

Содержимое контейнера описывается докер файлом, провести ревью докер файла гораздо проще чем иметь настроенный руками сервер, где кто-то кода-то что-то редактировал, но никто уже не помнит что и где

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

настроенный руками сервер, где кто-то кода-то что-то >редактировал, но никто уже не помнит что и где.

Ну руками сервера большими количествами уже редко настраивают, тоже используют систему «оркестрации» типа Ansible, Salt, Puppet ..

В пользу контейнеров, можно сказать что «бинарник» и всякие либы на серваке те же что у разработчика. Для отладки количество внешних эффектов резко сокращается.

Ну а так же можно довольно легко запускать приложения на разном стеке: где-то python, где-то java, где-то python3, где-то С++ и так далее.

Лично у нас были проблемы, когда мы запаковывали приложения в DEB и разным приложениям был нужен разные либы, например python-requests, и разные версии на один бокс не поставить.

Ну руками сервера большими количествами уже редко настраивают, тоже используют систему «оркестрации» типа Ansible, Salt, Puppet ..

Я не говорю что контейнеры единственный или лучший способ сделать infrastructure as code, про другие инструменты я не упомянул т.к. тут речь шла про контейнеры и с другими инструментами я не работал. Когда подправлял ansible playbook создалось впечатление, что у подобных систем порог входа выше, чем у докера т.к. там свой синтаксис, свои модули и т.д., а в докере можно использовать обычные linux команды они мне гораздо привычнее. Еще проблема может быть в том, что если делать ansible надо все делать ansible и что-то подправить из консоли уже нельзя, если для серверов это норм, то на девелоперской машине так сделать не получится + у девелопера может быть сразу несколько проектов. Тогда выходит, что нужна полноценная виртуалка с чистой осью на которой все будет делаться ansible. Или использовать в разработке докер + ansible, а на проде тот же ansible, но уже без докера.

погляди к появлению каких личностей приводят докеры:

docker под chroot, выдает ошибку failed to register layer

В облачных вычислениях это всё было уже лет 20 как. Планировщики ресурсов, MPI для собственно запуска, distributed shell'ы...

Не только было, но и есть. Вот только при чем тут MPI и к8с?

Почему они нужны бизнесу?

Именно потому, что ты описал выше: «бардак и отсутствие унификации в ИТ-инфраструктуре»

А что там будет дальше и как это администрировать - никого не волнует.

О, я смотрю любители проводить пятничные ночи на работе ради релизов подтянулись.

Ты сам то перестал цеплять контейнеры к dhcp серверу? Личности без докера сделают такую же хрень.

Лично у нас были проблемы, когда мы запаковывали приложения в DEB и разным приложениям был нужен разные либы, например python-requests, и разные версии на один бокс не поставить.

LD_LIBRARY_PATH. Не слышали?

Через пакетный менеджер не получится поставить несколько версий одной и той же библиотеки. Придется ставить руками так дебиан можно в слаку превратить постепенно :)

Библиотеки таскать с приложением как часть пакета.

Так делается например в software collections.

Но без изоляции это сложно тестировать и отслеживать.

Контейнейрные immutable-образы - это более простой, надежный и удобный формат для такого пакета.

Так делается например в software collections.

AFAIK, software collections гораздо более сложная вещь.

Но без изоляции это сложно тестировать и отслеживать.

Сложнее, чем контейнерный образ? Серьезно?

Контейнейрные immutable-образы - это более простой, надежный и удобный формат для такого пакета.

Контейнерные образы - это гораздо более сложный способ сделать то, что делают пакеты с включенными библиотеками. Окупается ли эта сложность - зависит от ситуации.

AFAIK, software collections гораздо более сложная вещь.

Ну так если разворачивать твою мысль там тоже простым LD_LIBRARY_PATH не обойдешься. Software collections - это идея о параллельной установке софта силами пакетного менеджера, доведенная до реальной, production-ready реализации.

Сложнее, чем контейнерный образ? Серьезно?

Конечно, отследить откуда случайное приложение на случайном языке подключает библиотеки, утилиты и бинарники непросто. В контейнере тебе дается гарантия что ты никаким образом случайно не попадешь на общесистемные библиотеки.

Контейнер - неизменяемая, изолированная среда, ты всегда и везде используешь ровно то, что один раз тщательно протестировал, без каких-то сторонних эффектов.

Контейнерные образы - это гораздо более сложный способ сделать то, что делают пакеты с включенными библиотеками

Ты с точки зрения разработчика конкретного приложения смотришь. Если смотреть на приложение как на черный ящик - ситуация иная.

AFAIK, software collections гораздо более сложная вещь.

Ну так если разворачивать твою мысль там тоже простым LD_LIBRARY_PATH не обойдешься.

Для меня LD_LIBRARY_PATH - это как бы метафора. Без собственно LD_LIBRARY_PATH я при необходимости обойдусь - вобью в бинарь относительный RPATH.

Конечно, отследить откуда случайное приложение на случайном языке подключает библиотеки, утилиты и бинарники непросто. В контейнере тебе дается гарантия что ты никаким образом случайно не попадешь на общесистемные библиотеки.

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

Ты с точки зрения разработчика конкретного приложения смотришь. Если смотреть на приложение как на черный ящик - ситуация иная.

Но речь-то шла именно о приложении. Понятно, что, если приходится иметь дело с «черными ящиками», то надо изолировать их и молиться.

Но речь-то шла именно о приложении. Понятно, что, если приходится иметь дело с «черными ящиками», то надо изолировать их и молиться.

Приложение переходит в статус черного ящика достаточно быстро. Практически сразу после выпуска.

Даже скорее так: не черным ящиком оно является исключительно для автора и только в период активной разработки.

Всё остальное время - изолируем и молимся.

не черным ящиком оно является исключительно для автора и только в период активной разработки.

Думаю, это профдеформация девопса.

Профдеформация девопса против профдеформации разработчика :)

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

Отсутствие разработчика - это важная часть этой проблемы. Иначе бы правильным решением было просто адаптироваться и выпустить новую версию софта, а не придумывать костылей ни с bundled-зависимостями, ни с чем либо ещё.

Профдеформация девопса против профдеформации разработчика :)

Но я-то прав! %)

Исходная проблема которую решает контейнер - это обеспечение работы приложения на тот случай когда разработчик приложения не может адаптировать его под целевую систему.

Ну, скорее не проблему отсутствующего разработчика, а проблему разработчика, который выпустил приложение ровно для одной версии одной системы. И пакет с включенными библиотеками тоже решает эту проблему, просто другими средствами. Что выгоднее - зависит от ситуации. Если разработчик пропал без вести, оставив критический бинарь, зависящий от libc5 - думаю, даже контейнер не поможетБ придется городить VM.

Пакетный менеджер не препятствует установке каких угодно файлов куда угодно. Но да, в дистрибутивах разные версии библиотек опакечивают редко. Тем не менее, никто не мешает сделать свой пакет deb, пихающий либу нужной версии в какой-нибудь /opt/libs/mylib/$version

И пакет с включенными библиотеками тоже решает эту проблему, просто другими средствами.

Что делать, когда выйдет бюллетень по безопасности с описанием уязвимости в «упакованной» куда угодно библиотеке и ссылками на эксплойты для эксплуатации уязвимости? Особенно это забавно может оказаться в том случае, если софт, упаковываемый в docker/статичный пакет - разрабатывается вполне себе открыто или какая-то его открытая версия есть на github, gitlab и т.п. В этом случае злоумышленнику достаточно знать: а) о «внезапной» (крайне предсказуемой) приверженности docker'у разработчиков приложения; б) о том, что нужные приложению библиотеки подключаются не извне (отдельным докер-слоем), а просто статично пакуются внутрь контейнера - и это тоже весьма предсказуемо, потому что разработчики как правило «выше этого», у них «более важные задачи» (чем забота о том, чтобы их приложение могло с минимальным ручным оверхедом работать с обновляемыми версиями библиотек).

При этом никакой реальной объективной проблемы с библиотеками общего пользования нет и в помине. Она реально просто придумана людьми, которые либо умозрительно делают заключение о том, что проблема может возникнуть, либо когда у них возникала такая проблема - даже не пытались разобраться в её причинах, свалив всё на «разные же версии». Почему так? Да потому что любые common used популярные библиотеки поддерживают ABI back compatibility на протяжении десятилетий. А если разработчик использует какую-то редкую библиотеку от Васи Пупкина - то здесь возникают вопросы совершенно иного характера (и её в общем-то можно упаковать в контейнер/пакет, предварительно всё-таки выяснив, почему вообще в проекте используется загадочная сторонняя библиотека).

И пакет с включенными библиотеками тоже решает эту проблему, просто другими средствами.

Что делать, когда выйдет бюллетень по безопасности с описанием уязвимости в «упакованной» куда угодно библиотеке и ссылками на эксплойты для эксплуатации уязвимости?

Нужно будет пересобрать пакет с исправленными библиотеками.

Ох пацаны. Контейнер с сервисом, который идёт в прод, - это байт в байт то самое, что было протестировано многочисленными тестами (конечно же при условии, что версия контейнерного движка и версия ядра на на stage/test хостах и prod хостах совпадают).

Конечно же это можно обеспечить другими средствами. Обмазаться виртуализацией и каким нибудь провижионером и системой управления конфигурацией (куда без них). Но это гораздо более тяжёлый процесс.