Вт, 19.03.2024, 11:49
Приветствую Вас Гость | RSS
Главная | Блог | Регистрация | Вход
Форма входа
Логин:
Пароль:
Поиск

Меню сайта

Категории раздела
Техническое [29]
Все о мейнфреймах и не только о них, но все-таки крепко связанное с техникой и инженерными моментами.
Разговорчики [25]
Обо всем остальном, не относящемся к технике.

Календарь
«  Май 2020  »
ПнВтСрЧтПтСбВс
    123
45678910
11121314151617
18192021222324
25262728293031

Архив записей

Наш опрос
О регистрации на сайте с помощью соцсетей.
Всего ответов: 24

Метки
EGL ODM бизнес правила программирование SOA arcati блоги журналы Каталог мейнфреймы журнал z/os Freeware VM bigdata nosql zOS MVS OS SLES zLinux мейнфрейм Хабрахабр 50лет документы хранилище Java EE liberty WebSphere z/VM Share history GitHub OS/VS S/379 сообщение Форум DFSORT Hercules VSAM отчётность Linux Analytics Accelerator Netezza IMS IBM IDC продажа CHKPT GSam XRST гипервизор KVM Shutdown #hollywar mainframe Вакансии Санкт-Петербург видео Выступления Dis нагрузка пример Assembler VM/ESA НИЦЭВТ Docker Sie Kubernetes OpenShift Environment RedBook RedHat рынок LHI vs XR instruction to clear GPR z Seies CPU performance семинар впечатление доступность ЦБ цены аутсорсинг BMC CMS ZVM санкции Rockwell история z13 мобильность DB2 Java Coupling Facility Parallel Sysplex WebSphere AS MVT ОС ЕС ссср Tape VTL Вакансия БЛОГ Линукс Новое статьи Люксофт Польша Работа Москва

Статистика

Главная » 2020 » Май » 22 » zOS в Docker

zOS в Docker
17:46

Коллеги!

Вот статья - https://www.ibmsystemsmag.com/IBM-Z/05/2020/running-ibm-z-os-docker-container 

Как думаете, не блажь ли это?..

Просмотров: 1153 | Добавил: akost | Теги: Docker, zOS | Рейтинг: 0.0/0 |


Всего комментариев: 11
11 ggv  
0
Я не по теме статьи, а по вымиранию и по геркулесу.
Да, мы до сих пор разрабатываем под геркулесом.
Уже дело к опытному внедрению, а мы всё на нём.
И уяснили, что это не то, что бы мы хотели, поэтому с нетерпением ждём дисковой стойки для запуска полноценной среды разработки и тестирования на родном железе.
Ключевое слово тестирование. Ибо бывает надо проверить пару вариантов, дабы выбрать, и на геркулесе это делать бессмыслено, перенос на железо в наших условиях операция не самая простая.
Про вымрут.
Пару лет назад пришла ко мне девочка, студент бауманки на тот момент, биомедицинские технгологии. Не программист ни разу.
Сказала, что хочет программировать и с чего бы начать.
ну мы с парнями насоветовали полную панамку про Яву да про С.
Она через какое-то время опять пришла и сказала, что им препождаватель рассказывал, что бывает такое ассемблер.
Тут уже я заинтересовался, начал пытать подробнее.
Забрали мы её к себе, и пользуясь присутствием у нас ныне покойного Владимира Ивановича Шурпенкова, который так мало у нас к сожалению, поработал, (легендарная личность, ещё во времена СССР был инструктором по HLASM) замутили курсы для всей команды.
Вы не поверите - ныне она наш ведущий системный программист. И cross memory services ей подвластны.
Конечно, постигает ещё, но уже полностью самостоятельно.
Много полезного сделала и ещё сделает. Если надо что-то экспериментальное быстро на COBOL + C + HLASM соорудить - это к ней.
Главное - задачи интересные дать и руки не выкручивать.
А молодёж достойная есть. Есть у нас и второй "студент".
Не всё так плохо.

3 nkv  
Если я правильно всё понял, то никаких проблем вроде здесь нет.

ZD&T это ведь то, что раньше называлось zPDT? Это решение только для разработки и тестирования. Более того, оно требует ключа, роэтому кто угодно эту штуку не запустит. Не ну понятно, что можно попробовать там считать по-настоящему, но ключ всё равно нужен. Раньше это работало только с железным ключом, а теперь ещё можно запуститься и с сервером лицензий.

Так что нельзя говорить, что это пойдёт в массы и будет работать вместо настоящего фрейма. Это сможет запустить только тот, у кого до этого был ключ ZD&T.

С другой стороны, сворачивая ZD&T в докер-контейнер, мы делаем установку мобильной. И это очень удобно. После этого нам не придётся каждый раз разворачивать это чудо с нуля. Всё что нужно - установить докер в свою любимую ОС и запустить там свой контейнер.

Не вижу проблем, но вижу упрощение своей жизни. Сам так делаю. smile

4 akost  
0
не, ну если кому-то что-то упрощает, то это, безусловно, хорошо.
но!
1) вместо эмулятора надо ставить докер, чтобы туда ставить содержимое контейнера, в который завернут эмулятор. и так, и эдак надо ставить приложение, не эмулятор, так докер.
2) это ж не попсовое приложение а-ля движок для сайта, который ты носишься по всему миру и ставишь в сотне экземпляров. это, считай, эмулятор архитектуры для запуска операционной системы. у того, кто купил лицензию, будут единичные (а может и вообще одна штука) установки этого продукта. при таком раскладе какая разница, докер это или нет?.. а вот то, что появилась дополнительная прослойка, никакого оптимизма не внушает.
3) и главное, для кого это? для приличных разработчиков, типа Рокета?)) так они нормальную машину купят. и облачный доступ к чужим мейфреймам стоит дешево. кто будет целевой группой для этого продукта?..

5 nkv  
Всё-таки это решение для разработки. Докер тут совсем не мешает.

Я и был той самой целевой группой, которая тестировала решения и писала софт. При этом у нас в ИБМ были и настоящие фреймы.

У разработчиков "типа Рокета" часто есть и то и другое.

Единичные - да, но при этом ZD&T отдаётся то одному юзеру, то другому. Гриша Власов не даст соврать, как мы это из рук в руки передавали.

ZD&T ставится не из репозитория. Для этого есть специальный скрипт, который норовит упасть, если что-то не так (зависимостей нет, например). Поэтому лучше один раз создать контейнер с установленным ZD&T, а потом просто запускать этот контейнер там, где понадобится, не разбираясь как установить очередной странный софт.

Поставить докер очень просто. Запустить контейнер - одна команда. Когда вам нужно запустить на очередном сервере комплект из ZD&T, SonarQube, Jenkins, JFrog Artifactory, то проще взять готовые контейнеры, чем строить всё с нуля.

Когда я был в лабе ИБМ, то нам приходилось менять серверы, создавать новую среду для разработки и т.п. Контейнеры нас сильно спасали. До ZD&T дело не дошло, но была мысль и его свернуть в докер, чтобы не мучиться с размножением и перемещением. Тем более, что нам бы понадобилось несколько ZD&T. Запускать бы их пришлось и на своих ноутах, а громоздить весь стек ZD&T я бы у себя не захотел.

6 nkv  
Кстати, об упомянутых приличных разработчиках smile Залез в нашу вики и нашёл документ об установке zPDT (how-to). Предлагается взять готовый образ Ubuntu с настроенным zPDT и запустить его в VMWare под мак или виндоус.

Имхо докер, всяко лучше будет. smile

7 akost  
0
ну что же, если это кому-то поможет - значит, решение было выбрано правильное. время покажет, чо как.

8 nkv  
Докер - очень удобная штука. И для разработки и для продакшн и для мелкого домашнего сервера. Далеко не всё имеет смысл сворачивать в докер, но зачастую решения на докере радикально уменьшают время разворачивания продукта и упрощают его внедрение и сопровождение. Обновление версии продукта занимает несколько минут, так как производится просто запуском нового контейнера.

Кстати, сейчас вот докер внутри z/OS появился. zCX называется. В реальности это - Ubuntu, работающая в адресном пространстве z/OS, внутри которой работает докер, в котором работают docker images ("как тебе такое Илон Маск"). Все docker images, работающие на zLinux, будут работать и здесь. Т.е., например, теперь в z/OS можно запустить Zabbix и ограничить его через WLM. Наши люди этим заинтересовались. Если дальше будут развивать это направление, то может получится довольно интересно.

9 akost  
0
это мы видели, осенью. Ubunta в адресном пространстве zOS. я, как VMщик, от такого начинаю чесаться во всех неприличных местах. вместо работы под PR/SM или под нормальным VM, нагородили слоеный пирог, куда более расходный по ресурсам, чем VM под VM под VM и так далее. и что при этом в качестве результата? чем докер под убунту в адресном пространстве zOS лучше или быстрее докера под убунту внутри полноценной виртуальной машины, где работает SIE и другие vm-овские погремушки?...

10 nkv  
Из удобств - быстрый обмен данными с локальными СУБД, workload management (WLM), защита средствами RACF. Опять же сисплекс и GDPS. За скорость не скажу, но часто она и не нужна.

Ну и ещё есть пользователи, которые всегда работали с z/OS, но боятся z/VM. Теперь они могут запускать у себя в z/OS Линукс-задачи. И для этого не требуется устанавливать z/VM и/или zLinux.

Моё имхо - IBM могло было бы довести до ума USS и обойтись без zCX. Но меня никто не спросил. Но и zCX совсем даже неплохо.

Система развивается и это хорошо. Новые возможности можно использовать или не не использовать. Хуже, когда этих возможностей нет.

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

2 akost  
0
все намного страшнее, я думаю.
у меня есть ощущение, что, пользуясь вашей аналогией, разработчики и архитекторы этого решения прицепили к велосипеду (или к мопеду) тяжелые колеса для движения по рельсам и всех убеждают, что это вот почти уже поезд и можно учиться на нем ездить.
с одной стороны вроде как Докеровское решение с zOS - это хорошо, прям как Геркулес от IBM, можно на приличном Intel запустить и писать задачи под zOS. но думается, что это больше убьет платформу, чем поддержит, потому что если есть свои администраторы и сильная инфраструктура с докерами и прочим, то с какой радости переться в zOS, если можно на хлеб заработать без всего этого???

Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]


Яндекс.Метрика