Docker for zOS. Что это и зачем?

[zVlad]

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

В том что контейнеры придуманы по делу я никогда и не сомневался. Мне лишь интересна реализация того о чем Вы говорите. И еще интересно почему это надо было делать в виде какой-то надстройки над системой, а не в самой системе, как это сделано было в MVS сто лет назад.
Одно у меня есть обяснение - что срубить бабок побольше и дать возможность другим делать такие же "контейнеры" и тоже рубить бабки, как это собствено и IBM делает.

линукс прошел свою отдельную эволюцию, в которой контейнеризация появилась достаточно поздно.

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

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

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

Я перечитываю эту тему год спустя и после трехдневного воркшопа от Микрософт по контейнерам. Кстати таких слов как namespace and chroot в лекциях не использовалось вообще.
Отдельно отмечу что Ваши коментарии здесь мне полезны и сейчас.
На воркшопе я ждал что будет сказано и будет ли сказано вообще о такой теме важной для любой ОС как управление нагрузками (Workload Management). Да, было сказано. Но только традиционное для ОС на Интел - как ограничить контейнер по использованию памяти и CPU. Это слишком мало. Кроме того количество нодов для контейнеров (кластеризация) это вопрос решение которого возлолежено на человека, т.е. вынесено за пределы возможностей ОС.
Что касаемо МФ, zOS и Докера на/в zOS, то в одном инстансе zOS могут быть установленны несколько (больше одного) инстанса Докера (например Продакшн, Девелопмент, QA, sandbox), каждый со своим набором выполняемых контейнеров и с помощью компоненты zOS под названием WLM сделать так чтобы ожидаемый уровень производительности Продакшн не зависил от того что происходит в Девелопмент, QA, sandbox, а также возможно в DB2 инстансах, WebSphere и так далее тоже выполняемых в этой же zOS.

[zVlad]

А под линуксом это chroot ÷ namespaces ÷ cgroups

А chroot зачем?

Dear Mustrum,
chroot сообщает шеллу или коллинг процессу где теперь у нас будет рут фолдер.
фор мор информейшен ран [man chroot]

Это все через Linux namespaces делается.
Я не думаю, что Docker как-то использует chroot.

Собсна простой поиск показывает что Вы правы. Как говорят люди на стаковерфлоу,
для изоляции файлсистемы используется mnt namespace, которое по своему эффекту похоже на то что делает чрут.
Но потом начинается изоляция по процессам, нетворку, юзерам, хостнейму и по шаред мемори через ipc namespace.

И как выясняется кернел это всё умеет.
Докер сам ничего не придумывает.

Аналогом namespace в MVS (я говорю MVS, а не zOS потому что именно MVS создает системную основу в zOS) следует считать (считать приближенно, не буквально) address space.
Так же как повидимому в случае namespace address space это изолированная копия ядра со всем своим, если хотите хоумдиректори и библиотеками. Ресурсы (если хотите файловая система) у каждого address space свои.
Что касаемо хостнаме в смысле нетворкинга, то и с этим все ок. В одном инстансе zOS может быть более одного TCP/IP stacks. Но и до этого для целей изоляции приложений в смысле нетворкинга есть решения. В наших zOS выполняются разные приложения и нужды иметь больше одного TCP/IP stack не возникало. Например, мы раним в одном zOS апп сервера, базы данных, Web servers и другие сетевые приложения на одном stack просто используя разные диапазоны портов.

P.S. На воркшоповских лабах после каждого запуска контейнера предлагалось выполнить команду hostname. Он всегда был другой и отличался от имени хост системы. Тоже и с IP address в ipconfig. Честно говоря не впечатляет.

[zVlad]

Было еще два забавных момента на воркшопе.
Нас согнали на него волевым решением. Согнали и девелоперов и инфраструктурщиков (порой их сейчас называют ит-шники). Даже меня, мэйнфрэймщика, подключили.
И возник вопрос, так для кого же этот воркшоп? Сошлись в том что частично для одних, частично для вторых.
По ходу же воркшопа мне пришла навязчивая мысль что эта штука - контейнеры, докеры и кубернитис про то чтобы изжить инфраструктурщиков как класс. Не всех, а тех кто, как мы, оказались в фирмах выбравших облако как основу своей ИТ.
В самом деле. Если полностью окунуться в технологию облачности и контейнеров то роль онпремис инфраструктурщиков сводится к нулю. Достаточно будет своих девелоперов и облачных инфраструктурщиков.
У нас пока контейнерных приложений, кроме совсем обшего функционала типа почты, нет и нынешнему составу инфраструктирщиков ничто не угрожает, но потенциально есть угроза потерять сферу приложения и job security.
Кстати моя судьба в будущем если я останусь в этой фирме работать после того как оставшийся мэйнфрэйм будет покинут это встать в ряды системщиков на Линукс с последующими вовлечением в дела с Докерами. Поэтому меня и записали на воркшоп этот.

[Vladimir Kr.]

Docker, это небольшая часть девопса, просто докер - инфраструктуру не заменит.

можно несколько докеров поднять на одной машине, и задаваться вопросами о квотировании ресуров, а можно поднять кластер из кучи 'копеечных' машин. Например: https://mesos.apache.org/getting-started/ или lxd cluster. И докер там только первых шаг. Это если свое облако.

Или терраформ, если дальше в девопс.
Так что "изжить инфраструктурщиков как класс"? ну не одним девелоперам учить новое

[zVlad]

Docker, это небольшая часть девопса, просто докер - инфраструктуру не заменит.

можно несколько докеров поднять на одной машине, и задаваться вопросами о квотировании ресуров, а можно поднять кластер из кучи 'копеечных' машин. Например: https://mesos.apache.org/getting-started/ или lxd cluster. И докер там только первых шаг. Это если свое облако.

Или терраформ, если дальше в девопс.
Так что "изжить инфраструктурщиков как класс"? ну не одним девелоперам учить новое

А как в кластере обеспечить сбалансированную загрузку узлов?
Наверное все таки будет так что одни узлы упираются а другие простаивают. И картина эта меняется непредсказуемо. И выправлять это можно только вручную.
Если несколько докеров на одном сервере то тоже кроме ручного распределения квот на ресурсы больше механизма нет. Опять тот же результат - один докер не использует свои квоты, другому из не хватает.
День когда рассказывали про девопс я пропустил. Сломался телевизор и я занимался его ремонтом. Завтра пришлют материнку, надеюсь дело в ней.

[Vladimir Kr.]

А как в кластере обеспечить сбалансированную загрузку узлов?
Наверное все таки будет так что одни узлы упираются а другие простаивают. И картина эта меняется непредсказуемо. И выправлять это можно только вручную.

Узлы - обычные PC, ну может не совсем обычные, а Xeon с ECC. Так что квоты и прочее - наверное не очень важно.
Нагрузка - чаще всего откуда-то идет? load balancer, например, вот он и будет балансировать. Mezos вроде делает, балансировку.

Если кратко, то девопс делает Infrastructure-as-a-Code, вот скрипты этого кода, к девелопменту еще дальше, чем к админам.

[zVlad]

А как в кластере обеспечить сбалансированную загрузку узлов?
Наверное все таки будет так что одни узлы упираются а другие простаивают. И картина эта меняется непредсказуемо. И выправлять это можно только вручную.

Узлы - обычные PC, ну может не совсем обычные, а Xeon с ECC. Так что квоты и прочее - наверное не очень важно.
Нагрузка - чаще всего откуда-то идет? load balancer, например, вот он и будет балансировать. Mezos вроде делает, балансировку.

Если кратко, то девопс делает Infrastructure-as-a-Code, вот скрипты этого кода, к девелопменту еще дальше, чем к админам.

Чем бы узел не был за него платятся деньги. А если деньги платятся за простаивающие узлы то это плохо в любом случае.
Еще хуже когда при наличии простаивающих узлов есть узлы полностью забитые и это негативно влияет на внешние ожидания от сервисов.
Я не слышал никогда что эту проблематику как то нетривиально (т.е. непосредственно) решают в ИТ построенных на "несовсем обычных РС".
Load balancing вовсе не гарантирует исключения проблем про которые мы говорим. Его задача всего лишь более менее равномерно разбрасывать конекции по узлам. А что с ними дальше происходит LB до лампочки, это не входит в его задачу вообщe.


P.S. поиск в гугле "mezos" ничего интересного не показывает. Рестораны да едальни.