AnsibleによるCICSアプリケーションのデプロイ

## はじめに
Ansibleはオープンソースの構成管理ツールであり、インフラ構成管理のデファクトスタンダードです。あらゆるプラットフォームを対象にインフラ構築やアプリケーション・デプロイメントなどの操作の自動化を可能とします。
2020年3月にはRed Hat Ansible Certified Content for IBM Zが提供され、z/OSの操作をAnsibleで管理できるようになっています。ここではz/OS上のCICSアプリケーション開発において、Ansibleを使ってアプリケーションをデプロイする方法を紹介します。

## z/OS上でのAnsibleの使用
Red Hat Ansible Certified Content for IBM ZはAnsibleでz/OS上の操作を可能とするモジュールを提供します。2023年1月現在、以下のコレクションが提供されています。
・IBM z/OS core collection
・IBM z/OS CICS collection
・IBM z/OS IMS collection
・IBM Z System Automation collection
・IBM z/OSMF collection
・IBM Z HMC collection
ここでは、CICSアプリケーション・デプロイのために使用するコレクションIBM z/OS core collectionとIBM z/OS CICS collectionについて紹介します。

なお、上記z/OSコレクションを使用するための前提条件は以下の通りです。
###### コントロール・ノード(Control Node)の前提条件
・Ansible 2.9 以降
・Python 2.7 以降
・OpenSSH
###### ターゲット・ノード(Managed Node)の前提条件
・z/OS V2.3 以降 (z/OS OpenSSHを含む)
・IBM Open Enterprise SDK for Python V3.8.2 以降
・IBM Z Open Automation Utilities (ZOAU) V1.1.0およびV1.1.1
・CICS TS V4.2 以降 (z/OS CICS collectionを使用する場合)
#### IBM z/OS core collection
IBM z/OS core collectionはz/OS上でのJCLの編集や実行、MVSシステムコマンドやTSOコマンドの発行、データセットの操作、Jobのアウトプットの確認などを可能とするモジュールを提供します。以下にIBM z/OS core collectionが提供するモジュールの一覧を示します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673930/863d289d-e753-1a33-16a5-a57dea65de41.png)
例えば、z/OS上でJCLをサブミットする場合、以下のようなplaybookを用意して実行します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673930/264fbda3-877b-ec51-662c-95b1b4f7d020.png)
z/OS上でMVSコマンドを実行する場合、以下のようなplaybookを用意して実行します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673930/05840582-ad9f-3972-a93a-64f55ea313cb.png)

#### IBM z/OS CICS collection
IBM z/OS CICS collectionはCICSの資源や定義の照会や操作することを可能とするモジュールを提供します。以下にIBM z/OS CICS collectionが提供するモジュールの一覧を示します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673930/7941388a-c26f-ec78-1f30-b97e2899cb40.png)
CICSのコレクションはすべてのモジュールに"cmci"と接頭語がついていますが、これは内部的にはCMCI (CICS Management Client Interface)というCICS資源管理をするためのHTTPのRESTfulインターフェースを使っていることを示しています。CMCIはCICS Explorerでも内部的に使用されており、CPSM (CICSPlex SM)のWUI (Web User Interface)リージョンに接続してCPSM管理されているCICSリージョン群をアクセスしたり、単体CICSリージョンに接続してCICSの資源を操作することが可能です。

例えば、CICSリージョンの情報を取得する場合、以下のようなplaybookを用意して実行します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673930/7c424279-a9a8-a031-1934-e3e385e90adf.png)
ここでは以下のようなパラメーターを設定しています。
| 項目名      | 説明　　　  |
|:-----------|:------------|
| cmci_host  | CMCIリクエストの接続先ホスト名 |
| cmci_port    | CMCIリクエストの接続先ポート番号 |
| scheme     | 接続プロトコル(HTTP/HTTPS)       |
| context       | 接続対象のCICSplex名 (単体リージョンの場合はCICSのAPPLID)|
| scope | 接続対象のCICSplex内のスコープ (単体リージョンの場合は不要)     |
| type     | アクセスしたいCICS資源タイプ (リージョン情報の場合CICSRegion) |



## CICSアプリケーション・デプロイのシナリオ
CICSアプリケーションの開発・テストにおいては、プログラム・ソースの作成/変更⇒コンパイル/連係編集⇒CICSへのデプロイ(PROGRAM NEWCOPY)⇒テスト実行⇒問題があったら再度プログラム・ソースの変更⇒コンパイル/連係編集⇒・・・、というサイクルが繰り返し行われます。このうち、プログラムをコンパイル/連係編集して、CICSでPROGRAM NEWCOPYを実施するのは、TSO/ISPFやSDSF、CICSなど画面を切り替えながらJCLやコマンドを実行していくことになりますので、1～2分あるいは数分の手間がかかり得ます。Ansibleを使用すれば、これがコマンド1つだけで実行でき、ソース修正後より素早くテストを実施できるので、何度も繰り返されるサイクルの中で時短ができ、より効率的に作業が進められることになります。

以下にAnsibleによる処理フローを示します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673930/e02b540f-90dd-0b7d-a9da-fe54be02b585.png "処理フロー")

1⃣では最初にCICS上のプログラムの状態を確認しています。ここではcmci_getモジュールを使ってINQUIRE PROGRAMコマンドを発行し、プログラム名、プログラムの状態(Enabled/Disabled)、プログラム・サイズを取得して表示します。より汎用的にするならば、プログラム資源が存在しなかった場合(プログラム定義がInstallされていなかった場合)にcmci_actionでプログラム定義をInstallしたり、プログラム定義もまだ作成されていない場合はcmci_createでプログラム定義の作成を行うなど、状況に応じてフローを分岐させてロジックを組み込むことも可能です。

2⃣ではAnsibleで標準提供されているtemplateモジュールを使い、事前に用意したコンパイル/連係編集のJCLテンプレートに対してプログラム名やソース・ライブラリーやロード・モジュール・ライブラリーの情報をセットして実行用のJCLを作成します。

3⃣では前ステップで作成した実行用JCLをzos_job_submitモジュールを使って、z/OSに転送してジョブをサブミットし、ジョブの実行結果を取得して表示します。リターンコードが4より大きい場合は実行エラーなのでplaybookの処理を終了します。

4⃣は、ジョブ実行が成功した場合に、cmci_actionモジュールでCICSに対してPROGRAM NEWCOPYコマンドを発行し、再度プログラム名、プログラムの状態、プログラム・サイズを取得して表示します。

## Ansible playbook例

上記の処理フローをAnsibleで記述したものが以下になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673930/1a3eca3d-cf47-43e9-35fb-1671dcfe786c.png "update_progray.yml")
z/OS上の環境情報は変数化して、cics_vars.ymlというファイルに記述してplaybookに読み込ませています。これにより、環境が変わった場合に、playbookを修正するのではなく、cics_vars.ymlだけ修正することで対応できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673930/b443ccab-becf-d72c-aa93-459478e59ad1.png "cics_vars.yml")
JCLのテンプレートは以下のようなものです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673930/2a2f5f94-7ff1-7981-535b-8ab04e5aed7b.png "complked.j2")
テンプレート中の{{pgmname}}はAnsible playbookの実行時の引数、{{pgmsor_ds}}と{{build_ds}}はcics_vars.ymlの変数から取得されて実行用JCLが作成されます。

## Ansible playbookの実行
Playbookの実行はansible_playbookコマンドで行います。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673930/f7c1c1b5-d282-dcb2-99cb-c85c0142b83f.png "コマンド")
update_program.ymlがplaybook名、EC01TERMがコンパイル/NEWCOPYするプログラム名、CT61C1A1がデプロイ先のCICSのAPPLIDです。

以下が実行例になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673930/b621dc25-bd82-9e33-2bdc-074ab83b2b32.png "実行例")
このケースではすべての処理が正常に終了し、全体として15秒程度で処理が実施されています。出力されているProgramSizeの表示をみるとプログラムのサイズが7232 byteから7304 byteが変わり、プログラムが更新されていることがわかります。

## まとめ
以上、AnsibleによるCICSアプリケーションのデプロイの例をご紹介しました。
プログラムのコンパイル/連係編集のジョブ実行とCICSへのPROGRAM NEWCOPYの手順自体はステップとしては少なく、それほど複雑ではないので手動でやってもあまり時間はかからず時短の効果は大きくありませんが、CICSリージョンの作成や多数のCICS資源を対象とした操作など、手順が多い、あるいは、複雑だが手順決まっているような操作はAnsibleで自動化することでアプリケーション開発者や運用管理者の負担を軽減することができ、効率的な運用が可能となると言えます。

## 参考URL
https://ibm.github.io/z_ansible_collections_doc/index.html
https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/daiki-shimizu1/2020/12/04/zos-ansible-001