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

[zVlad]

Неожиданно для в zOS появились Docker containers.
Я начитал кой какой материал и хотел бы обсудить с желающими.

Доя начала вот ссылка в ней есть ссылка на статью с сравнением производительностей приложения Docker на мф и на х86. Не безспорное и слегка лукавое сравнение, но все же что то, с данными и цифрами.

https://www.ibm.com/support/z-content-s ... xtensions/

У меня есть мысли, если коротко то это не более чем коммерческий ход. Но хотелось бы обсудить на более высоком профессиональном уровне. Если конечно есть желающие. Мне не хватает материала из интернета о том как на самом деле работает Docker. Те обяснения что я нашел слишком условны и символичны. Хотелось бы найти человека понимающего как работает "это" внутри.
К сожалению, хотя доступен 90 trail, поставить на моих мф я это не могу. Наша версия zOS не соответствует требуемой, хотя один из мф, как железо, годится.

[Flash-04]

Это скорее всего для Unix-like environmen. По сути паравиртуализация, так как все процессы выполняются поверх одного и того же кернела. Но каждому контейнеру отображаются разные файловые системы. Linux давно имеет средства для этого получше, можно посмотреть на Proxmox как пример. Самой zos скорее всего тот докер нафиг не нужен.

[idle0]

А под эмулятором zOS + Docker запустить нельзя?

Зачем - потому что кто-то написал приложение которое работает под докером на разных платформах и хочет это запускать под zOS?

[zVlad]

А под эмулятором zOS + Docker запустить нельзя?

Зачем - потому что кто-то написал приложение которое работает под докером на разных платформах и хочет это запускать под zOS?

zOS + Docker это не эмулятор чего либо. Это zOS "и" ( Docker "в" zOS). Любые приложения под докером на других платфомах можно запустить под zOS. Конечно для этого надо что-то поделать, что-то взять для этого.

На DockerHub есть ряд приложений готовых для zOS. В именах пакетов должно быть "s390x".

[zVlad]

Это скорее всего для Unix-like environmen. По сути паравиртуализация, так как все процессы выполняются поверх одного и того же кернела. Но каждому контейнеру отображаются разные файловые системы. Linux давно имеет средства для этого получше, можно посмотреть на Proxmox как пример. Самой zos скорее всего тот докер нафиг не нужен.

На сколько я понял containers не только для Linux делают. В zOS есть Unix (не -like, а именно Unix), давно, с середины 90-x. Там выполняются Unix-like програмы. Я прям сейчас с Oracle GoldenGate работаю в zOS/Unix. Удовольствие не из великих, но за это мне деньги платят, в overtime.
Я оо другом хотел поговорить. Вот много написано что Containers это не Виртуализашн. Что не надо для каждого приложения (почему для каждого?) создавать VM и полноценную систему в ней. Тем не менне говорится о высокой изолюции приложений. Как это работает? Не на пальцах, не с помощью рисунков, а на самом деле.

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

У меня есть мысли, если коротко то это не более чем коммерческий ход.

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

[zVlad]

У меня есть мысли, если коротко то это не более чем коммерческий ход.

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

Это все здорово. Наверное. Но мне как системному программисту интесно узнать больше чем маркетинговские бла-бла-бла.
На первом же этапе изучения темы я сказал, себе увы - больше не с кем это обсуждать, сказал что это то что давно уже в MVS (zOS - нынешнее название включающее Unix). Приложения в MVs/zOS давным давно распространяюстаы в виде "готового к употреблению" пакета, но в MVS. Программа установки этих пакетов называется SMP/E.
Ладно с ним, с пакетированием, это всего лишь сопутствующая вещи.
Утверждается что container отличается от VM тем что не нужна полноценная OS, но в тоже время приложения изолированы друг от друга (и OS от них, я надеюсь) так как это достижимо в случае VM. В чем суть этой "изоляции", как она работает? Кроме того утцверждается что containers управляются одной системой с учетом, скажем так, "приоритетов". Что гибче и ближе к требованиям пользователя чем управление VMs.
Например в случае MVS каждый пользователь и каждое приложение выполняется со своим личным ядром и разделяемыми библиотеками как если бы они выполнялись в разных VM, но не с отдельными OS, а с одной и итой же, при этом ядро на самом деле одно, библиотеки одни и система управляет приложениями и пользователями в соответствии с единой политикой ("приоритетами"). Так оно было в MVS и есть с 70-x, и думаю что Docker ничего нового в этом плане не предлагает. Но хотелось бы узнать точнее как именно в случае с Linux это достигается. Ведь если MVS сразу (если не считать предшествинников OS/360, MFT, MVT, SVS и т.п.. Предшествинниками они являются только потому что в MVS вылии формально сохранены те же основные компоненты) написан исходя из свойст вновь предложенных в Docker (новое - хорошо забытое старое), то Linux, как таковой, написан исходя из совсем иных принципов и целей.

Я так понимаю (поправьте если я не прав) что Docker это "Hypervisor", но не компьютера, а Linux. T.e. Docker некий посредник между Linux и "контейнерами". Контейнеры можно было назвать Linux VM, по аналогии с Java VM. Как это делается и есть вопрос поднятый в этой теме мной.

[idle0]

А под эмулятором zOS + Docker запустить нельзя?

Зачем - потому что кто-то написал приложение которое работает под докером на разных платформах и хочет это запускать под zOS?

zOS + Docker это не эмулятор чего либо. Это zOS "и" ( Docker "в" zOS). Любые приложения под докером на других платфомах можно запустить под zOS. Конечно для этого надо что-то поделать, что-то взять для этого.

На DockerHub есть ряд приложений готовых для zOS. В именах пакетов должно быть "s390x".

Я понимаю. Я спрашиваю можно ли запустить емулятор MF + zOS на PC/Mак? Если да - то там можно и поставить тот докер.

Если на родной MF нельзя

[idle0]

Я бы в вашем случае просто поставил docker на PC/Mac без zOS и поигрался бы с ним там

А уж потом можео думать зачем это в zOS

[zVlad]

....
Я понимаю. Я спрашиваю можно ли запустить емулятор MF + zOS на PC/Mак? Если да - то там можно и поставить тот докер.

Если на родной MF нельзя

Эмуляторов zOS не существует в природе. Эмуляторов z14 - минимальный уровень МФ требуемый для zCX (Docker) тоже нет в природе.

[zVlad]

Я бы в вашем случае просто поставил docker на PC/Mac без zOS и поигрался бы с ним там

А уж потом можео думать зачем это в zOS

Зачем это нужно в zOS и так понятно - для привлечения новых клиентов и для удержания существующих поглядывающих "налево". Добавим - чисто научный интерес, и как платформа для разработки многоплатформенных приложений для Docker.
Если смотреть из zOS, то даже Unix, который есть давно, не нужен был бы. Unix понадобился главным образом для выполнения TCP/IP stack без особых затрат на писанину на чисто мф средства и отслеживания всех изменений в стандартах. IBM WebSphere решено было разрабатывать как многоплатформенное приложение с единым кодом. DB2 for zOS остается чисто MVS приложением и не будет переписано в единый код.

P.S. Кстати WebSphere до версии 3.5 в zOS был MVS приложением.

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

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

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

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

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

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

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

[zVlad]

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

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

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

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

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

В zOS, в одном инстансе, можно ранить хоть сколько DB2 разных версий, CICS, не говоря уже о любых других, third party, приложениях. Делается это на раз. Просто так устроен zOS. Поэтому, как правило, много инсталяций zOS иметь не требуется, чем их меньше тем лучше. У нас, например, исторически Production и остальные инстансы приложения находятся в двух разных zOS на одном МФ. И это хуже чем если бы они были все в одной.

[zVlad]

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

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

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

Вы все таки делаете упор на пакетирование. Я же о другом (см. выше). В принципе я понимаю о чем Вы говорите. Мой коллега по 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 тянет на пол миллиона баксов.
докер пришел четко с противоположной от МФ стороны - на кластере какие-то узлы, надо запускать задачи. вот докер контейнер и обеспечивает изоляцию среды созданной докером, не создавая дорогой реальной виртуализации. у нас используется лишь для тестов, т.к. хадуп не умеет в докер. я пишу тесты на винде, делаю коммит в гит, гитлаб собирает аппликацию и где-то уже на линуксах прогоняет интегрейшен тесты, и каждому тесту поднимает с докера какой-то набор софта. при миграции в облако это будет жить уж на кубере в кластере и толкаться с задачами соседних команд.