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

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

Вы все таки делаете упор на пакетирование. Я же о другом (см. выше). В принципе я понимаю о чем Вы говорите. Мой коллега по GoldenGate с Linux стороны бизнеса не смог работать с двумя разными иснталяциями GG в одной системе.
В zOS, в одном инстансе, можно ранить хоть сколько DB2 разных версий, CICS, не говоря уже о любых других, third party, приложениях. Делается это на раз.

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

[M. Ridcully]

Как работает Docker? Как эти прелести реализованны? Почему это невозможно в одной системе и возможно в одной и той же (Linux), но только под Docker. Почему бы не сделать Docker составной частью всех Linix? Или придумать другой Linux, с Docker-ом, и всем перейти туда? У меня есть варианты ответов, но хотелось узнать мнения других кто с этим работает.

Родные средства Линукса (namespaces and cgroups) + надстройка (container runtime, images, etc).

[M. Ridcully]

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

[zVlad]

У меня есть конкретный пример: второстепенное тестовое приложение, которое корректно работает под Ubuntu, но не хочет работать в CentOS из-за единственной сторонней библиотеки.
....

Ваш упор на возможность использования разных библиотек в контейнерах напомнило мне о JCL - язык управления заданиями (пакетами, если хотите). С помощью оператора JCL DD с именем STEPLIB (или JOBLIB) можно програме "подсунуть" любую библиотеку вместо системной библиотеки вызовов (LINKLIB), и ассовиированных с ней. E'to ne znachit chto sistemney ne budut rassmatrivat'sya, e'to znachit lish' chto pervoj(-ymi) budet prosmatrivat'sya biblioteka (-ki) perechislennye v STEPLIB/JOBLIB.
Вообще DD - это опеартор связи программы с ресурсами, которые в zOS в программах задаются в виде символических имен разрешаемых в момент запуска программы на выполнение через одноименные операторы DD.
Кроме ресурсов с помощью JCL операторов можно еще многое другое, что изменяет умалчиваемую конфигурацию системы, указать. Например, можно указать что этот пакет надо выполнять не в том узле где он запускается, а в другом, но что, например, вывод задания надо ппослать в первый узел или в третий. Под узлами здесь понимаются узлы JES - Job Entry System (JES2).

Если это все чем замечательны контейнеры в Docker, то на МФ это было всегда так. В OS/360, MVS, OS/390, zOS.

Я так подозреваю что Dockers писался глядя на zOS. Кстати, несколько месяцев назад Dmity67 давал ссылку на статью в ХАБР. Там молодой человек (из Литвы кажется) рассказывал про как он програмируиет на Ассемблер в MVS и про то что они командой пишут нечто для zOS. Мне сейчас кажется это весьма вероятным что пидали они именно zCX - Docker for zOS.

[zVlad]

Вот текст из доцументации zOS v2.4 (первой версии zOS где zCX is available. К стыду моей конторы мы на zOS 1.13. С 30-го сентября прошлого года zOS 2.5 is available):

How is zCX similar to and different from Linux?

IBM zCX is a virtual Docker software appliance that includes all the necessary software components to allow a user to deploy and manage Linux on Z Docker images (e.g. s390x architecture) inside z/OS. The software appliance includes a commercial Linux kernel supported and maintained by IBM and provides the Docker command line interface (CLI) to implement a fully functional Docker environment. Users log in to the zCX instance through Secure Shell (SSH), and run in a Bash shell as they would on any Linux platform.

This Linux environment is tailored to support the Docker CLI, and is not intended to be a general purpose operating environment. Users are prevented from performing most root operations, so that the kernel remains properly configured for running Docker. If users need a fully functional Linux environment, they should create a Docker image with whatever Linux distribution they need,and run it through the Docker CLI.

One exception to the root authority restriction is the ability of the primary zCX instance administrator (admin) to create, delete, and modify additional users and their passwords. In this way, these primary instance administrators can create the population of Docker administrators and users that fit their needs.

[zVlad]

Еще хочу сказать, не отвечая никому, что с появлением zCX у меня автоматом появилась новая сфера для работы. zOS я знаю, и Linux я тоже знаю. Как администратора zCX меня возьмут на ура. И конкурентов у меня будет не много. Правда и потенциальных работодателей тоже будет, пока, мало. Рынок я не изучал.

[zVlad]

А вот еще интересная цитат из документации ( я выделел главное с моей точки зрения. Особое внимание следует уделить VSAM, но об этом коротко сказать невозможно):

What can you do with zCX?

IBM zCX allows you to bring "Dockerized" Linux applications as close as possible to your enterprise z/OS resources without first having to port lots of open source infrastructure to z/OS. For instance,applications that communicate over TCP/IP with z/OS data or services can take advantage of z/OS's high speed SAMEHOST networking that is only available to processes running on the same LPAR.

Since IBM zCX instances run in a regular z/OS address space, they inherit many of the same qualities of service as other z/OS processes. All of the capabilities z/OS provides through VSAM and the TCP/IP stack to enable encryption, disaster recovery, and dynamic workload relocation, can all be applied to the zCX instance without disruption of the Linux applications running inside. In this way, IBM zCX enhances the Linux deployment environment in ways that other platforms can't.

From a Linux perspective, IBM zCX supports a large population of Docker images that allow z/OS to integrate more tightly with common pipelines and workflows that the open source community has created over the last several years. This allows z/OS to participate in common devops and automation environments through projects like Jenkins and Github, or for data science and analytics purposes through Jupyter and Jupyterhub. There are also assortments of languages, build frameworks,and web servers that can be built into Docker images and deployed on IBM zCX to enable much fuller z/OS participation in the open source arena with the agility that modern enterprises require.

[idle0]

У меня есть конкретный пример: второстепенное тестовое приложение, которое корректно работает под Ubuntu, но не хочет работать в CentOS из-за единственной сторонней библиотеки.
Печалька в том, что основные приложения у нас заточены на СentOS и запускать Ubuntu или VM c ней только для этого приложения - ну такое себе. Удобнее запаковать и из-под докера.

Понятно. И все таки. Как работает Docker? Как эти прелести реализованны? Почему это невозможно в одной системе и возможно в одной и той же (Linux), но только под Docker. Почему бы не сделать Docker составной частью всех Linix? Или придумать другой Linux, с Docker-ом, и всем перейти туда? У меня есть варианты ответов, но хотелось узнать мнения других кто с этим работает.

Как работает Довер в zOs вам вряд ли кто расскажет

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

[M. Ridcully]

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

А chroot зачем?

[iDesperado]

помнится я уже где-то тут показывал этот документ и восхищался абсурдностью самой идеи хранить данные на МФ. посмотрите, 2/3 затрат на x86 это Incremental Db2 access. задача крутится на ширпотребе в $20к, но Incremental Db2 access тянет на пол миллиона баксов.
докер пришел четко с противоположной от МФ стороны - на кластере какие-то узлы, надо запускать задачи. вот докер контейнер и обеспечивает изоляцию среды созданной докером, не создавая дорогой реальной виртуализации. у нас используется лишь для тестов, т.к. хадуп не умеет в докер. я пишу тесты на винде, делаю коммит в гит, гитлаб собирает аппликацию и где-то уже на линуксах прогоняет интегрейшен тесты, и каждому тесту поднимает с докера какой-то набор софта. при миграции в облако это будет жить уж на кубере в кластере и толкаться с задачами соседних команд.

[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 добавляются, направляя приложения по правильным путям.

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