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

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

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

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

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

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

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

[Palych]

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

Надо бы пояснить что такое сложные конфигурации.

[Bobeg]

например такая гадость как мирроред репликейтинг лоад балансед сервер сойдет за сложную конфигурацию?

[Boriskin]

Надо бы пояснить что такое сложные конфигурации.

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

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

[Bobeg]

микросервисная кошкина колыбель.

[Boriskin]

микросервисная кошкина колыбель.

Хорошо, если микро...