Text＝田口 智大 日本アイ・ビー・エム システムズ・エンジニアリング
クラウドvsオンプレミス という極端な議論は落ち着きつつあり、適材適所でそれぞれを使い分けるという考え方が主流になっている。ただオンプレミス環境で使うにしても、従来どおりの使い方を継続するのではなく、クラウドネイティブの技術を取り入れた新しい使い方、いわゆる「Newオンプレミス」に変革していくことが求められている（『Gartner、オンプレミスに関する展望を発表』）。
オンプレミスの代表格であるメインフレーム、z/OSの世界でも、Newオンプレミスへの変革に向けて、OSSに代表されるようなオープン系で広く使われている技術が利用可能になっている。本稿では、オープンな技術の一例としてGitに着目し、z/OSの開発や運用でGitを活用する例を紹介する。
メインフレーム開発者にとってのGit解説
Gitに関する情報は豊富に提供されているので、ここでの詳述は避けるが、Gitにあまり馴染みのないメインフレーム担当者向けに最低限抑えておいたほうがよいポイントについて触れておく。
Gitとは、オープン系のプロジェクトでよく用いられる、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理の仕組みである。
並行開発、複数バージョン管理、変更履歴の共有などを容易に行えるのがメリットである。ソースはリモート・リポジトリで一元管理し、編集時はローカル・リポジトリにコピーして作業することからわかるように、分散型で管理される形態が大きな特徴となる（図表1）。
分散型ということで、Gitの構成要素としては主にサーバー（リモート・リポジトリ）側の機能を提供するコンポーネントと、クライアント（ローカル・リポジトリ）側の機能を提供するコンポーネントに分かれる。
Gitのサーバー機能を提供するものとしてはGitHub、GitLabなどがある。Gitサーバーの機能としては、Web上で提供されるサービスを利用することもできるし、オンプレミス環境にサーバーを構築することも可能である。
開発作業などを行うPC側（Windows、Mac、Linuxなど）では、Gitクライアント機能を使用してソース管理を行う。Gitクライアントでは、ローカル・リポジトリの管理やリモート・リポジトリとのやり取りを実行するコマンドなどが提供される。Git上に管理されているファイルを編集する際によく利用されるオペレーションを、図表2に示す。
Gitクライアント機能は、Visual Studio Code（以下、VS Code）やEclipseなどIDE（Integrated Development Environment、統合開発環境）のプラグインとしても提供されている。
またIDEだけでなく、JenkinsやAnsibleなど多様なツールがGitと連携するプラグインを提供しており、自動化しやすいので、GitはDevOpsの中心的な役割を担っている。
z/OSにおけるGitの位置づけ
z/OS版のGitクライアントとしては、以下が提供されている。これらを利用することで、外部のGitサーバー上に管理されているリソースをz/OSから扱える。
❶ Rocket Git―Rocket Software社提供のGit on z/OS
Rocket Software社は、「Rocket Open AppDev for Z」というツール群を提供している。
これはメインフレームのアプリケーション開発をサポートする各種ツールを集約しており、ここにz/OS版のGitクライアント機能が含まれている（本稿はRocket Gitを使用して試した結果をベースにしている）。
このRocket Gitは、IBMの有償製品であるDBB（Dependency Based Build）でもバンドルして提供している。また、z/OSをエミュレートする製品であるZD&TやWazi as a Serviceなどで提供されるz/OS環境には、このRocket Git（＋DBB）がすでにインストールされている。
◎参考サイト
❷ z/OS Open Tools―Git on z/OS
z/OS Open Tools Communityが進めている、z/OS上で稼働するOSSを提供するプロジェクトがある。この中でGitクライアント機能を提供するGit on z/OSが提供されている。
これらz/OS版のGitクライアントは、z/OS UNIX（z/OS UNIX System Service）上で稼働することになる。ローカル・リポジトリはz/OS UNIX上のディレクトリ／ファイルとして管理され、リモート・リポジトリ（GitHub／GitLabなど）とやり取りする。z/OS版Gitの利用イメージを、図表3に示す。
このようにz/OS上で直接的にGitを使う形態では、PCからはz/OS UNIXに接続して、z/OS UNIXのシェルでGitのコマンド操作（clone、commit、pushなど）を行う。
z/OS上のファイルの「編集」という意味では、VS CodeやEclipseのエディターを使用する方法がいろいろと提供されているが、Git操作についてはシェルのコマンドを使用する必要がある。
PC上ですでに提供されているVS CodeやEclipseなどIDEのGitのプラグインを使用したい場合、ローカル・リポジトリは各ユーザーのPC上で管理されることになる。
オープン系アプリケーションの開発であれば、言語としてJava、Node.js、Pythonなどを使用し、開発PCと実行環境（Linuxなど）間でのCPUアーキテクチャによる差異は少なく、単体テストレベルではPCだけで実行できる。つまりPCだけで、ある程度の開発が完結する。
一方でz/OSアプリケーションの開発では、言語としてCOBOL、PL/I、アセンブラなどが主であり、コンパイル／リンク、単体テストなどはPC上では実行できない。ここがオープン系の開発とz/OSの開発で大きく異なるポイントとなる。
そこで、Gitの管理やソース編集はPC上で行い、ビルド（コンパイル／リンク）や単体テストの部分だけはz/OS環境を利用する、という形態も考えられる（図表4）。
つまり、z/OSでGitを利用する形態として、大きく以下の2つのパターンが考えられる（その他は基本的にこれらの応用になる）。
・Rocket Gitのようなz/OS上で稼働するGitクライアントを直接使用する形態
・PCなど他のプラットフォームのGitクライアントを使って間接的にGitを活用する形態
図表4はアプリケーション開発を意識しているが、運用系のJCLをGitで共有したり、JenkinsやAnsibleなど自動化の仕組みと連携するなど、さまざまな活用場面が考えられる。
いずれの形態でも、z/OS UNIXを利用することが重要なポイントとなる。つまり、アプリケーション開発者や運用管理者がGitを活用できるインフラを整える場合、z/OS UNIXの運用管理が必須となる。
◎参考サイト
Rocket Gitの構成例
Rocket Gitのインストールは他のプロダクトと同様に、SMP/Eでのインストールが可能である。詳細は割愛するが、実体としてはz/OS UNIX上のファイルシステム上に各種ライブラリーが展開されることになる。
◎参考サイト
ここでは、Rocket Gitを使用する上での構成例を示す。まずGitを使用するシェルで、図表5のように環境変数を有効化する必要がある。
●図表5の補足
GIT_ROOT: Rocket Gitがインストールされたディレクトリを指定。
_BPXK_AUTOCVT: ガイドだとONを指定している例があるが、ALLを指定することを推奨（ALLだとUnicodeもサポートされるため）。
◎参考サイト
次に、Gitを使用するユーザーのホームディレクトリ下にGit利用に関する設定例が、図表6になる。ちなみにここでの.gitconfigファイルはUTF-8で作成し、タグ付けしておくことを推奨する（Jenkins連携の際に必要）。
●図表6の補足
http.sslverify=false
SSL通信時の証明書検査を行わないよう設定
credential.helper = chace –timeout=3600
パスワードを一定時間(3600sec)キャッシュする
◎参考サイト
取り扱うリポジトリごとに、コード変換の制御を行う必要がある。GitHubなどのリモート・リポジトリでは、基本的には各テキストデータはUTF-8で保持することが一般的である。
一方でz/OS上のローカル・リポジトリ（z/OS UNIX上）では、EBCDICコードページ（ibm-1047など）で保持する場合が多い。テキストファイルのエンコーディングは、.gitattributesファイルで制御できる。
一般的にはプロジェクトのルートにこのファイルを配置し、そのプロジェクト配下にあるファイルの文字コード属性などを指定する。取り扱う拡張子ごとに、ローカル・リポジトリ（z/OS UNIX上）とリモート・リポジトリ（Git Server上）の間で、コードページのマッピングを行う例を図表7に示す。
◎参考サイト
z/OSでのGitの活用例
ここではz/OSのリソースをGitで管理するパターンをいくつか解説する。
活用例1 z/OS上でGitクライアントを直接使用するケース
図表8は、z/OS上のリソースをz/OS上のGitクライアントを使って、外部にあるGitサーバー上で管理するシナリオである。
管理対象のリソースとしては、コード開発のフェーズであれば、ソースコードやビルド（コンパイル／リンク）に必要なJCL／スクリプト群、ビルド結果であるJOBLOGなどが該当する。
開発以外にも、フェーズによってテスト環境を整備するためのJCLや運用管理に関するスクリプトなど、ほかの環境やほかのユーザーのために共有して管理すると便利なものもある。結局はどう使うかという話なので、使いどころはさまざまな場面が考えられる。
図表8の例は、バグ修正のようなCOBOLのソースコードを個別に修正することを想定している。
操作の流れとしては、以下のようになる。
① Gitで管理されているソースをローカル・リポジトリ（z/OS UNIX上）に持ってくる（clone）。各リソースは、z/OS UNIX上のファイルとして管理される。
② COBOLのソースはMVSデータセット上に存在しないと都合が悪いので、z/OS UNIX上からMVSデータセット上にコピーする。必要に応じて、コピー先のMVSデータセットのアロケーションなども行う。
③ 編集／ビルド／単体テストなどのプロセスを回す。
④ 改修が終わったら、更新されたソースをz/OS UNIX上にコピーする。また、必要に応じてエビデンスとして改修後のJOBLOGなどもz/OS UNIX上にコピーする。
⑤ ローカル・リポジトリ（z/OS UNIX上）の更新されたファイルをGitサーバーに反映する（push）。
このように、z/OS UNIXを介してGitサーバーとデータをやり取りする。このz/OS UNIXとMVS間のやり取りは、なるべくスクリプト化しておくとスムーズであるし、自動化にもつながる。
z/OS UNIXの標準機能（シェル・コマンド）で、z/OS UNIXとMVS間でのファイルのコピーやJCLのサブミットなどを実行できる。ただしデフォルト機能だけを使うと、実行できる内容が限定的なので、ツールなどを使用することで、z/OS UNIXとMVS間のやり取りを効率よく実行できる。
たとえば、以下のような拡張ツールを使用することで、z/OS UNIXからMVSの操作が容易になる。
ZOAU
ZOAU（IBM Z Open Automation Utility）という無償で使えるユーティリティである。これはz/OS UNIX上でMVSを操作するためのシェル・コマンドやPython APIを提供している。
DBB
DBB（Dependency Based Build）という有償製品である。こちらはアプリケーションのビルド支援機能を提供するツールという位置づけであり、z/OS UNIXからMVS操作を行うためのGroovy／Java用のAPIが提供されている。
活用例2 PCをGitクライアントとして間接的に使用するケース
図表9のように、開発者のPCのGitクライアント機能を使って、いったんPC上にローカル・リポジトリをクローンし、PC上で編集作業を行う方法も考えられる。
COBOL、PL/I、JCLなどの編集作業はPC上のエディターでもある程度は可能であるが、実際にJCLを実行する、ソースをコンパイルする、COBOLの単体テストをする、といった場合はPC上だけでは実施できないので、z/OS上で実行する必要がある。この部分は活用例1でも示したように、z/OS UNIXを介してMVS上で操作することになる。
アプリケーション開発における個別のソース修正時のビルド（ユーザー・ビルドなどと呼ばれる）については、VS Code／IDzからDBBを使用した連携の仕組みが提供されている。
具体的には、zAppBuildというDBBを利用した汎用的なビルド用フレームワークが提供されており、それを使用すると、VS Code／IDzからビルド用のメニューを選択することで、z/OS UNIXへのファイル転送、必要に応じてMVSデータセットの作成、z/OS UNIXファイルからMVSデータセットへの転送、ビルド（コンパイル・リンク）実行、といった一連の処理を実行できる。
結果のJOBLOGをPC上にダウンロードするところまでカバーするので、あとはPC上のIDEのGit クライアント・プラグインの機能を使ってソース管理を行えばよい。
◎参考サイト
このような構成パターンの場合、DBBやzAppBuildを使用するので、それを前提としてz/OS側の設定や、リポジトリ上の構成ファイルの配置などを考慮する必要がある。
zAppBuildも汎用的なフレームワークを提供しているが、アプリケーションの作りによってはカスタマイズが必要になるので、Groovy、DBBのスキルが必要になる。
活用例3 Jenkinsとの連携
活用例2は、バグ修正のような一部のソースを開発者が個別に修正して単体テストを回すシナリオであった。図表10では、そのような修正が集積され、いったんそれらをまとめてリリースするために、IT環境で最新のソースをまとめてビルドする、というようなフェーズでの利用を想定している。
JenkinsのSSH経由で実行されるエージェントをz/OS UNIX上で稼働させられる。従って、ソース類と一緒にそれらをまとめてコンパイル／リンクするためのスクリプトをJenkinsのパイプラインに仕込んでおくことで、一括のビルド処理を自動化できる。
この一括でのビルド処理についても、DBBとzAppBuildを利用できる。前述した活用例2と同様にDBB、zAppBuildの設定、カスタマイズは必要になるので、GroovyやDBBのスキルが求められる。
Jenkinsを使えばパイプラインに指定した処理を自動化できるが、これは正確には、「Git上に管理されたパイプラインで指定した処理をz/OS UNIX上で実行できる」ということでしかない。
どのようなスクリプトを使って、何をどうパイプラインとして実行するかはアプリケーションの作り次第となる。アプリケーションの作りや運用フローによって何が自動化（スクリプト化）でき、どういうパイプラインを作成すればよいかは環境によって異なるため、利用環境に応じて、それぞれ設計・実装を検討していく必要がある。
◎参考サイト
活用例4 Ansibleとの連携
インフラ構成をコードとして管理する、いわゆるIaC（Infrastructure as Code）という考え方があり、その代表的なツールとしてAnsibleがある。最近はz/OSのインフラ操作をするためのAnsible用のモジュールも提供されており、そのモジュールを利用することでz/OSをAnsibleの管理ノードとして扱える。
たとえば、z/OS Core Collectionで提供されるモジュールを使用することで、テンプレートとして用意されたJCLのサブミットや、MVSコマンドの実行などをAnsible Playbookから容易に実行できるようになる。
z/OSのインフラ構成情報をAnsible Playbook（Yamlファイル）として定義できれば、複数の環境に対して同様のインフラ構成作業を効率よく自動化できる。
また、PlaybookやテンプレートとなるJCLなどはGit上で管理できるし、AWX（Ansible Tower）ではGitと連携するための機能も提供されている。
z/OS Core Collectionを使用する場合は、基本的にはz/OS UNIX上のPython、ZOAUを内部的に使用し、それをSSH経由で呼び出す。z/OS側ではSSH、Python、ZOAUのセットアップが必要になる（いずれも無償利用可能）。
Ansible／AWXについてもJenkinsと同様、ツールを入れさえすれば、何かが勝手に効率化・自動化されるわけではない。インフラ構成がYAMLでコード化しやすくなるので、何をどうPlaybookとして作るかは要件に応じて設計・実装を検討していく必要がある。
＊＊＊
このようにGitの利用シナリオは、いずれもオープン系で使われている仕組みをz/OSにどのように取り入れるかがメインとなる。つまり、旧来から実施しているフローをそのまま効率化するのではなく、プロセスや運用方法、使い方そのもの、あるいは考え方を変えていくことになる。
GitやJenkinsなどはツールにすぎないので、新しい仕組みに合わせて運用や管理方法を変えていく必要がある。それをどう変えるかは、アプリケーションや環境に応じてそれぞれ個別に検討する必要がある。オープン系とメインフレームの差異に関するもの、特に拡張子の考え方や文字コード変換については新たに考慮すべき事項も出てくるので注意してほしい。
またGitに限った話ではないが、すべてのケースでオープン系の技術を取り入れることが正しいわけではない。現行のフローに慣れている現場の担当者にとっては、仕組みが変わること、新たな仕組みを構築せねばならないこと、新たなスキルが必要とされること大きな負担になる場合もあり得る。
旧来から実施している開発／運用フローを変えたくない、あるいは変える必要がない場合であれば、無理にオープン系の技術を取り入れてやり方を変えたとしても、即時に大きなメリットは得られないかもしれない。アプリケーションの特性や運用の要件によっては、新しい仕組みだと不向きなケースもあるだろう。
ただ一昔前には、オープン系アプリケーションのプロジェクトでもGitによる管理に移行する際には 「従来のやり方を変える」ことに難色を示すケースをよく聞いた。しかし現在ではGitの使用が当たり前になっている状況を見るに、1周あるいは2周遅れで同じことがz/OSアプリケーション開発の現場でも起きているように思える。
現行のやり方を前提とした目の前の開発効率を重視するのか、若手技術者の確保・育成を見据えた長期的な目線での「Newオンプレミス」への変革を目指すのか、といった目的次第で、このあたりの技術適用の方法は変わってくるだろう。
オープンソースを活用することは、追加ソフトウェアのライセンスコスト不要で利用できる場合が多い。まずは試しに使ってみて、使いながらよりよい活用の方法を探っていき、知見を積み重ねていく、というアプローチもとりやすいので、ぜひ新しい仕組みの利用を積極的に検討してほしい。
本稿がメインフレーム開発環境のモダナイゼーションを検討するきっかけになれば幸いである。
著者
田口 智大氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
Technical Competency Center, Cloud Integration #2
シニアITスペシャリスト
1998年の入社以来、主にCICS関連製品（TXSeries、CTG、CICS TS）を中心に技術支援に携わる。近年はメインフレームのモダナイゼーションに関する技術情報を積極的に外部発信している。
［i Magazine・IS magazine］
