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

[Bobeg]

ух ты. мэйнфреймы. а ими кто-то пользуется до сих пор?

[Bobeg]

Ну то есть основа и есть в самом Linux, а надстройки могут быть разные, не толко Docker.

имплементаций контейнеров несколько, но на память я помню только докер.

[Bobeg]

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

А chroot зачем?

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

но главное что теперь любое обращение к директории "/" начнется с того места на которое указал чрут.
с этого и начинается виртуализация файловой системы внутри контейнера.
сие есть удобно поскольку решает проблему длл и шаред обжект хелла раз и навсегда и позволяет этих контейнеров иметь много
и единовременно. и значительно эффективней чем полная ОС виртуализация.

a у питона есть устройство под названием virtualenv.

[zVlad]

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

А chroot зачем?

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

но главное что теперь любое обращение к директории "/" начнется с того места на которое указал чрут.
с этого и начинается виртуализация файловой системы внутри контейнера.
сие есть удобно поскольку решает проблему длл и шаред обжект хелла раз и навсегда и позволяет этих контейнеров иметь много
и единовременно. и значительно эффективней чем полная ОС виртуализация.

a у питона есть устройство под названием virtualenv.

А чем оказался плох подход с home directory и environment parameter, который добавляется ко всем другим фолдерам приложений?
У меня на МФ в .profile есть такие строки:

WAS_HOME=/WebSphere/V7R0/SysTestCell/wsnodea/AppServer
WEBSPHERE_HOME=$WAS_HOME
JAVA_HOME=/usr/lpp/zWebSphere/V7R0/java/J6.0/
PATH=$JAVA_HOME/bin:$PATH

И везде где надо эти HOME добавляются, направляя приложения по правильным путям.

[Bobeg]

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

А chroot зачем?

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

но главное что теперь любое обращение к директории "/" начнется с того места на которое указал чрут.
с этого и начинается виртуализация файловой системы внутри контейнера.
сие есть удобно поскольку решает проблему длл и шаред обжект хелла раз и навсегда и позволяет этих контейнеров иметь много
и единовременно. и значительно эффективней чем полная ОС виртуализация.

a у питона есть устройство под названием virtualenv.

А чем оказался плох подход с home directory и environment parameter, который добавляется ко всем другим фолдерам приложений?
У меня на МФ в .profile есть такие строки:

WAS_HOME=/WebSphere/V7R0/SysTestCell/wsnodea/AppServer
WEBSPHERE_HOME=$WAS_HOME
JAVA_HOME=/usr/lpp/zWebSphere/V7R0/java/J6.0/
PATH=$JAVA_HOME/bin:$PATH

И везде где надо эти HOME добавляются, направляя приложения по правильным путям.

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

[zVlad]

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

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

[Bobeg]

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

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

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

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

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

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

[M. Ridcully]

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

А chroot зачем?

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

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

[Bobeg]

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

А chroot зачем?

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

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

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

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

[Мальчик-Одуванчик]

А чем оказался плох подход с home directory и environment parameter, который добавляется ко всем другим фолдерам приложений?

Тем, что иногда некоторые версии одной библиотеки не могут сосуществовать одновременно в операционной системе.
Например мой Линкус часто ругается, когда я пытаюсь установить более старую версию библиотеки, когда уже стоит новая.

[zVlad]

А чем оказался плох подход с home directory и environment parameter, который добавляется ко всем другим фолдерам приложений?

Тем, что иногда некоторые версии одной библиотеки не могут сосуществовать одновременно в операционной системе.
Например мой Линкус часто ругается, когда я пытаюсь установить более старую версию библиотеки, когда уже стоит новая.

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

[Мальчик-Одуванчик]

А чем оказался плох подход с home directory и environment parameter, который добавляется ко всем другим фолдерам приложений?

Тем, что иногда некоторые версии одной библиотеки не могут сосуществовать одновременно в операционной системе.
Например мой Линкус часто ругается, когда я пытаюсь установить более старую версию библиотеки, когда уже стоит новая.

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

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

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

[zVlad]

А чем оказался плох подход с home directory и environment parameter, который добавляется ко всем другим фолдерам приложений?

Тем, что иногда некоторые версии одной библиотеки не могут сосуществовать одновременно в операционной системе.
Например мой Линкус часто ругается, когда я пытаюсь установить более старую версию библиотеки, когда уже стоит новая.

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

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

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

И это решается с помощью контейнеров (namespace)?

[Bobeg]

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

[zVlad]

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

Я не привык думать облегченными дефинициями. По крайней мере в плане ОС. На данный момент я понимаю контейнер как маинипуляция namespaces, их комбинацией. Контейнер основан на фиче Linux - namespaces. Не все из них мне понятны, но некоторые весьма понятны. Например, Mount (mnt), and Network(net).
Network(net) в zOS rеализуется элемнетарной возможностью MVS выполнять несколько инстанцес одного и того же приложения. В данном случае TCPIP. Их можно запускать больше одного в одной MVS и направлять разные приложения на разные TCPIP stacks, каждый из которых имеет все свои конфигурации.
Mount? Поскольку в zOS есть Unix, то и возможность иметь руты смонтированные на разные filesystems вроде бы могло бы понадобиться. Но на данный момент я не могу ничего сказать как с этим обстоят дела в zOS. Надо почитать и подумать. До сих пор проблем с необходимостью Mount не испытывал.
Остальные namespaces мне кажутся слишком экзотическими, если не сказать надуманными.

[zVlad]

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

В системе виртуальных машин на МФ изначально присутствовали две группы OS для VM. Одна группа это OS способных выпоняться на реальной машине. Их называют гостевые OS. В их число попадает и сама VM. T.e. VM можноз запистить на виртуальной машине и ве ней поддержитаь виртуальные машины на которых тоже можно запускать VM и т.д. Я работал с вторым уровнем, не более.
Другую группу ОС для VM представляли ОС, которые могли выполняться только под VM. На реальной машине они выполняться не могли. На реальной машине они не могли работать потому что использовали системные вызовы в HyperVisor (называется CP - Control Program in VM). В этой группе есть CMS (Conversational Monitoring System), i GCS (Group Control System). CMS - OS для инфивидуального пользования, типа shell, но другое. GCS это подмножество MVS для выполнения VTAM приложений.
И был/есть механизм хранимых систем с "разделяемыми сегментами", и "разделяемые сегменты. Как следует из названий что-то раделялось между витуальными машинами. Т.е. не в каждой машине было "все свое" от той или иной ОС, а только то что нельзя разделить, или то что мы хотели бы чтобе было не такое как у других. Другими словами мы могли создать CMS1, CMS2, CMS3 и т.д. и каждая из них была бы в чем то уникальной, может даже не из той версии ВМ что у нас сейчас, а из ранней. Никогда этого правда делать не приходилось, но теоритически, зная как создавались хр. системы могу утверждать что это было возможно. Кроме того можно было и "рут" (в кавычкам потому что это был т.н. резидентный диск, где хранились "библиотеки" и разширение системного диска) в разных виртуальны машинах разные.
Вообщем, кмк, это был практически полный аналог возможностей namespace Mount и не только. Иначе говоря в VM были/есть специальные системы, разработанные только для виртуальных машин и имеющих облегченный вид за счет использования системных вызовов к CP вместо бодания с реальной машиной. Системы такие можно создавать/конфигурировать под разные запросы и разных версий.
GCS s VTAM похож на Network(net).
В zOS вся проблематика решаемая с namespaces и Docker's решана по другому, и лучше чем в VM. Тем не менее IBM обе системы подддержывает наравне. А я когда то был ярым фанатом VM в противоположность, в антогонизм с MVS. A сейчас я поинимаю что VM и МВС это детский сад и МГУ.

[Мальчик-Одуванчик]

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

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

И это решается с помощью контейнеров (namespace)?

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

[zVlad]

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

Это шедевр. Реально. Я распечатаю и повешу на стенку.
Я хотел написать больше, но не буду. Все и так очень даже понятно.

[Flash-04]

Не предохраняет в общем случае. Пример: на домашнем сервере Linux крутится докер с Frigate (это пакет обработки потокового видео с IP камер и распознавания образов типа: человек, машина и т.п.)
Докер использует TPU, но сейчас не об этом. Для ускорения масштабирования изображения используется Nvidia GTX 1070, так как при четырёх видеопотоках CPU грузится нехило. Как-то я обновил систему и обновились драйвера Nvidia. Что вы думаете? Докер "сломался". Пришлось лезть в него и обновлять драйвера ещё и там.

[Мальчик-Одуванчик]

Не предохраняет в общем случае. Пример: на домашнем сервере Linux крутится докер с Frigate (это пакет обработки потокового видео с IP камер и распознавания образов типа: человек, машина и т.п.)
Докер использует TPU, но сейчас не об этом. Для ускорения масштабирования изображения используется Nvidia GTX 1070, так как при четырёх видеопотоках CPU грузится нехило. Как-то я обновил систему и обновились драйвера Nvidia. Что вы думаете? Докер "сломался". Пришлось лезть в него и обновлять драйвера ещё и там.

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

[Boriskin]

Да, в контейнере приложение как раз поставляется с собственной средой исполнения и не конфликтует с имеющейся.

К этому можно лишь добавить, что наличие стандартных контейнеров на всех популярных операционках упрощает разработку - я девелоплю свой код в докере локально на маке, staging, dev & prod бегут в облаке на линуксе и все везде работает почти одинаково с локальным instance. Была бы винда - было бы практически идентично.

[Flash-04]

Ага, этом плане большое удобство. Даже network создаётся отдельно для докера и они друг другу не мешают (только если не решат делать мэпинг на один и тот порт в системе)

[Palych]

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

Я не привык думать облегченными дефинициями. По крайней мере в плане ОС. На данный момент я понимаю контейнер как маинипуляция namespaces, их комбинацией. Контейнер основан на фиче Linux - namespaces.

Строго говоря - наоборот: Докер создаёт абстракцию: виртуальную машину с минимальными затратами на виртуализацию. Как она будет реализована - не важно.
Докер позволяет полностью заскриптовать процесс создания ВМ, таким образом знания о том как машина должна выглядеть/работать находится не в самой ВМ, а в скриптах.
IBM решил реализовать абстракцию докера своими средствами, чтобы получилось лучше чем у других, но всем знакомо.
Посмотрим получится ли у них. Я лично думаю - в чём-то будет лучше, но не радикально. Вряд ли это будет высоко оценено. IBM скажет что пользователь не понял их гениальных решений, и вернётся к своей парадигме:
Не стоит прогибаться под изменчивого юзера,
Пусть лучше он прогнётся под нас.
Однажды он прогнётся под нас...

[zVlad]

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

Я не привык думать облегченными дефинициями. По крайней мере в плане ОС. На данный момент я понимаю контейнер как маинипуляция namespaces, их комбинацией. Контейнер основан на фиче Linux - namespaces.

Строго говоря - наоборот: Докер создаёт абстракцию: виртуальную машину с минимальными затратами на виртуализацию. Как она будет реализована - не важно.
Докер позволяет полностью заскриптовать процесс создания ВМ, таким образом знания о том как машина должна выглядеть/работать находится не в самой ВМ, а в скриптах.
IBM решил реализовать абстракцию докера своими средствами, чтобы получилось лучше чем у других, но всем знакомо.
Посмотрим получится ли у них. Я лично думаю - в чём-то будет лучше, но не радикально. Вряд ли это будет высоко оценено. IBM скажет что пользователь не понял их гениальных решений, и вернётся к своей парадигме:
Не стоит прогибаться под изменчивого юзера,
Пусть лучше он прогнётся под нас.
Однажды он прогнётся под нас...

Как я понимаю zCX (Docker в zOS) уже несколько лет как доступен и используется. Это уже не проект, а продукт. Если бы я мог его поставить я бы его разчехлил (есть 90 days trail). Но у нас все слишком старое и не поддерживается этим. Только по железу один МФ подходит, но ОС на нем не та.
У Вас нет примера script-a?

[KinDzaDza]

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

Это шедевр. Реально. Я распечатаю и повешу на стенку.
Я хотел написать больше, но не буду. Все и так очень даже понятно.

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