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

[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]

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

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

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

[zVlad]

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

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

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

В реальной жизни все происходит по разному. А в ваших проблемах виноват не сисадмин. Далеко не сисадмин.

[Palych]

У Вас нет примера script-a?

Честно говоря, ни разу докер руками не трогал.
Поисковик выдал это:
https://docs.docker.com/develop/develop ... practices/

[zVlad]

Начнем подведем итоги.

Вот мой проект резолюции:

Обосновательная часть резолюции:

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

Классический/централизованный - это подход реализуемый в zOS на IBM mainframe. Этот подход предполагает максимальную концентрацию сервисов под управление одной системы или небольшого их количества обединых Parallel Sysplex. Об этом подходе я пока ничего не скажу кроме то что он имеет место быть и уходить не собирается.

Неоклассический/распределенный - это подход главным принципом которого является распределение элементов конфигурации на отдельных, независимых, серверах. Предельное, желаемое, отношение это один сервис - один сервер. Результатом такого подхода оказались операционные системы упрощенного типа. В само деле зачем для простой нагруки городить sophisticated (или точнее созданной для управления сколь угодно сложных конфигураций) OS? И действительно популярные ОС для серверов это простые Unix/Linux. Простые потому что во-первых, даже в настоящее время для серверeрных частей ИТ используются комодити сервера физически не способные нести сложную конфигурацию, или даже простую, но обемную в смысле нагрузки. Для сложных и обемных конфигураций используются совокупность многих комодити серверов. Так делается в облаках. Во-вторых, даже если взять мощный сервер то грузить его сложной конфигурацией не позволяют системы хранения данных *ввод-вывод) и неготовность имеющихся ОС длы управления сложными конфигурациями.
Если посмотреть на эти пороцессы исторически то поначалу, когда сервера были еще маленькими, сложение мощностей нескольких серверов и разделением конфигурации на части (БД, сервер приложений, DNS sервера, domain (AD) и т.п сервера) позволяло поднимать более менее сложные конфигурации. Там где не хватало одного маленького сервера ставили несколько кластеризуясь. Потом мошность серверов выросла в разы за счет подьема тактовой частоты и за счет повышенуя уровня интеграции (эти два направления по разному работают). Тактовая частота давно уже уперлась на комодити серверах в 2.3 GHz (более высокие частоты требуют более дорогих, неприемлимых для комодити, решений), а уровень интеграции пока потихоньку растет, но что с этим делать в комодити серверах не очень понятно. Так или иначе в изначально гармоничной схеме назрел кризис. Минимальноразмерные сервера стали превышать потребности многих отдельных сервисов. На арене появились виртуальные машины и вернули гармонию в сферу ИТ основанную на распределенной обработке. Но как оказалось не надолго. Бороться с некоторыми проблемами даже виртуальные машины оказались не в состоянии.
И появились контейнеры и Docker-ы. Строго говоря сначала появились блокчаэйны, Хадупы и т.п. решения главной особенностью которых было обединения очень больших количеств комодити серверов в одно целое. БОльших чем позволяли кластеры. О них я говорить не буду здесь чтобы не загромождать тему о контейнерах и, кмк, микросервисах.

Продолжение следует.....

[iDesperado]

главную революцию, что принес докер - DSL язык описывающий конфигурацию, именно он убрал прослойку в виде админов и показал, что девелоперы без привлечения админа могут описывать и деплоить кофигурации. мне кажется вся эта идеология infrastructure as code, devops уже позже поперло.

[zVlad]

главную революцию, что принес докер - DSL язык описывающий конфигурацию, именно он убрал прослойку в виде админов и показал, что девелоперы без привлечения админа могут описывать и деплоить кофигурации. мне кажется вся эта идеология infrastructure as code, devops уже позже поперло.

Я много лет вижу сисадминов и DBA на распределенных системах безропотно выполняющих скрипты написанные девелоперами и вдруг оказывается что они были ненужной прослойкой.
В другой стороны действительно если оказывается что сисадмины это слуги девелоперов то нахрен они вообще нужны. Давно уже известно что девелоперы на распределенных системах лучше знают систему (а что там знать? Там все не о системах, а о программах выполняемых на компьютерах - там нет как таковых систем. И опять же получается что сисадмины не нужны.

[KinDzaDza]

В реальной жизни все происходит по разному. А в ваших проблемах виноват не сисадмин. Далеко не сисадмин.

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

[zVlad]

В реальной жизни все происходит по разному. А в ваших проблемах виноват не сисадмин. Далеко не сисадмин.

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

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

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

В реальной жизни все происходит по разному. А в ваших проблемах виноват не сисадмин. Далеко не сисадмин.

"Cистема обеспечения надежности выведет из строя все другие системы."

[iDesperado]

На форуме надо обвсуждать написанное участниками, а не самих участников. Сколько можно эту простую истину повторять?

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

[Bobeg]

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

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

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

В реальной жизни все происходит по разному. А в ваших проблемах виноват не сисадмин. Далеко не сисадмин.

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