はじめに
ここまでの一連の記事では、Wazi aaSのサーバーを立てる際に、Stock Imageと呼ばれる製品提供の出来合いのz/OSイメージを使用していました。
このStock Imageを使用する方法の他に、既にオンプレ環境にあるz/OSのイメージ(SYSRESボリュームを含む)を吸い上げてそれを元にWazi aaSサーバーを作成するという方法も提供されています。それを実現するためにはWazi Image Builder(WIB)という製品を使用する必要があります。
ここでは、Wazi Image Buildr(WIB)を使用して既存のオンプレ環境のz/OSイメージをコピーしてWazi aaSサーバーを作成する方法について見ていきます。
※当記事は2024年2月時点のWazi Image Builder V14をベースとしています。
関連記事
Wazi aaS: クラウド上でのメインフレーム開発環境構築 - (1) 概要
Wazi aaS: クラウド上でのメインフレーム開発環境構築 - (2) 仮想サーバー作成
Wazi aaS: クラウド上でのメインフレーム開発環境構築 - (3) ネットワーク構成
Wazi aaS: クラウド上でのメインフレーム開発環境構築 - (4) Wazi aaS への接続
Wazi aaS: クラウド上でのメインフレーム開発環境構築 - (5) Stock Iamge確認
Wazi aaS: クラウド上でのメインフレーム開発環境構築 - (6) Stock Iamge基本操作/カスタマイズ
Wazi aaS: クラウド上でのメインフレーム開発環境構築 - (7) Wazi Image Builder
Wazi aaS: クラウド上でのメインフレーム開発環境構築 - (7)' Wazi Image Builder - Trouble Shootingメモ
Wazi aaS: クラウド上でのメインフレーム開発環境構築 - (8) Wazi aaS仮想サーバーの複製
Wazi aaS: クラウド上でのメインフレーム開発環境構築 - (9) TerraformによるWazi aaS仮想サーバーの管理
WIB概要
IBM Documentation - Wazi as a Service - Wazi Image Builder
WIBは既存のz/OS環境(SYSRES含む)のVolumeを抽出し、Wazi as a Service用カスタム・イメージを作成するためのツールです。
出来合いのStock Imageを使う場合、z/OSやミドルウェアなどが一式揃った環境が提供されることになるので新機能のテストなどを行う場合や研修、デモ環境として利用する分には便利ですが、既存の開発/テスト環境に合わせてカスタマイズする場合にはそれなりに手を入れる必要があるかもしれません。
そこで、z/OSイメージ(SYSRES)を含め必要なVolumeイメージをまとめてごそっと既存環境からコピーし、それを元にIBM Cloud上にWazi aaSの仮想サーバーを作成するオプションが提供されています。その機能を提供しているのがWIBです。
WIBを使用すると、コピー元となる既存z/OS環境からVolumeイメージの情報を吸い上げ、それを元にIBM Cloud上に"カスタム・イメージ"と呼ばれるWazi aaS仮想サーバー作成の元となるリソースを作成することができます。
IBM Cloud上では、製品提供のStock Imageを使用するのではなく、カスタム・イメージを使ってWazi aaS仮想サーバーを作成することで、既存z/OS環境の複製が作成されることになります。
WIBの実体としては、主に以下のコンポーネントで構成されます。
- Extraction Utlility: コピー元となるz/OS上にセットアップするユーティリティーで、Volumeの情報を吸い上げる機能を提供。
- ストレージ・サーバー: 吸い上げたz/OSのVolume情報を蓄えておく場所。実体としてはsftpサーバー。
- WIBサーバー: IA/Linux上に構成されるWebアプリケーション・サーバー。各種操作のコントロールを行う。実体としてはLiberty+PostgreSQLで実装されている。
WIB構成
ここでは細かな構成手順については記載しませんが、どのような構成が必要かという点を整理します。詳細はマニュアル等ご確認ください。
全体像
Source (コピー元z/OS環境)
上の図の右側部分がコピー元となるz/OS環境を表しています。以下のような環境準備が必要となります。
サポートされるz/OSはV2.4, V2.5のみです(2023年時点)。また、コピー対象となるz/OSにはFix Category: IBM.TargetSystem-RequiredService.AlternateHypervisors のPTFを適用しておく必要があります。
以下の機能をセットアップし利用できるようにしてておく必要があります。
- SSHサーバー
- sftpクライアント
- Java
- Extraction Utility (WIB提供のVolume抽出用ユーティリティー)
ネットワークの要件として、以下の構成が必要です。
- WIBサーバーからz/OS UnixにSSHで接続できること
- z/OS Unixからsftpクライアントを使用しストレージ・サーバー(sftpサーバー)に接続できること(SSH接続)
WIBサーバーからSSH経由でVolume情報取得指示がなされてユーティリティーが実行されるので、ユーティリティー実行ユーザーを準備しておく必要があります。
抽出対象のTCP/IPの構成については、コピー先のWazi aaS環境の作法に従ってカスタマイズをしておく必要があります。
TCP/IP構成
SYSRESを含むz/OSのVolumeイメージをコピーしてIBM Cloud環境に持っていった場合、ネットワーク関連の構成に注意が必要です。IBM Cloud上にWazi aaS環境を作った場合にはTCP/IP経由でしかz/OSにアクセスできませんので、IBM Cloud環境に持って行った場合のことを想定して一部のIPLPARMの構成を整えておく必要があります。
具体的には、最低限以下のような構成をしておく必要があります。
TCP/IPの構成情報として以下の値は変数化しておき、IEASYMxxにて値を指定するようにしておく必要があります。変数名は以下で固定です。
- HOME IPアドレス: HOMEIPADDRESS1
- デフォルト・ルート: DEFAULTROUTEADDR
- ネーム・サーバー: NAMESERVERADDR1
...
DEVICE OSA02P0 MPCIPA
LINK OSALINK IPAQENET OSA02P0
HOME
&HOMEIPADDRESS1 OSALINK
BEGINRoutes
ROUTE DEFAULT &DEFAULTROUTEADDR OSALINK MTU 1492
ENDRoutes
...
...
TCPIPJOBNAME TCPIP
DATASETPREFIX TCPIP
NSINTERADDR &NAMESERVERADDR1
RESOLVEVIA UDP
RESOLVERTIMEOUT 5
RESOLVERUDPRETRIES 1
ALWAYSWTO NO
...
...
SYMDEF(&HOMEIPADDRESS1.='192.168.xxx.xxx')
SYMDEF(&DEFAULTROUTEADDR.='192.168.xxx.129')
SYMDEF(&NAMESERVERADDR1.='192.168.xxx.xxx')
...
Wazi aaS仮想サーバーのネットワーク構成については末尾で補足します。
WIBサーバー/ストレージ・サーバー
上の図の真ん中の層がWIBの中核をなす部分です。
WIBサーバーはLinux(RHEL or Ubuntu)上にインストール/構成する必要があります。すなわち、Linuxのサーバーがどこかに必要ということになります。これはオンプレ環境でもよいですし、IBM Cloud上の仮想サーバーとして準備してもよいです。
WIBサーバーのインストーラーはPassport Advantageにより入手する必要がありますので、別途ライセンスの契約が必要になります。
ストレージ・サーバーは一般的なsftpサーバー機能があればよいだけなので、Linuxに標準で提供されるSSHサーバー機能がそのまま使用できます(sftpはSSHプロトコルを使用したファイル転送プロトコルなので、SSHサーバー機能に内包されています)。これもオンプレ環境でもよいですし、IBM Cloud上の仮想サーバーとして準備してもよいです。
吸い上げたz/OS Volumeイメージを保持しておくものなので、対象のVolumeのサイズに応じてそれなりに大きなディスク空き容量を確保しておく必要があります。
WIBサーバーとストレージ・サーバーは別々のサーバーとして立てることもできますが、同一のLinux上に構成することも可能です。構成/管理の簡素化という観点では1つにまとめてしまうのがよいでしょう。
Target (コピー先IBM Cloud環境)
WIBサーバーでは、Wazi aaS仮想サーバーの元になる"カスタム・イメージ"をIBM Cloud上に作ることが目的ですので、その過程でIBM Cloud上の操作を行うことになります。そのためIBM Cloud上に以下のようなリソースを準備しておく必要があります。
- IBM Cloudアカウント
- リソース・グループ (一時的に作成されるリソースや、最終成果物を保持するリソース・グループ)
- IBM Cloud OBject Storage (一時的にVolume情報を蓄えておくのに必要)
- アクセス用ユーザー(各種操作を行うユーザー) / API Key
- ネットワーク関連構成 (Wazi aaSインスタンスを作成するVPCやサブネットなど)
※補足
WIBを使用してカスタム・イメージを作る際、IBM Cloud上では一時的にLinuxの仮想サーバー作成され、そのうえでデータ加工用のPythonプログラムが稼働します。この一連の操作はWIBサーバーからterraformを利用して行われます。この時ICOS(IBM Cloud Object Storage)が一時的なデータ保管用に使用されます。そのため、ICOSへのアクセスやVPC, Subnet, VSIなどを作成権限のあるAPI Keyが必要となります。
内部的に実行されるterraformの処理については末尾で補足します。
WIB利用の流れ
WIBサーバーを構成するとブラウザのUIが提供されます。ブラウザからWIBサーバーにアクセスすると管理コンソールが使用できますのでそこから各種操作を行うことになります。
大まかな流れとしては、以下のような操作を行うことになります。
- 設定: ストレージ・サーバー、ソース環境(z/OS)、ターゲット環境(IBM Cloud)の各種情報を設定する
- コンポーネントとイメージの作成: ソース環境(z/OS)からVolumeを抽出しIPL情報のカスタマイズを行い、z/OSの"イメージ"を作成する (ここで作成するのはWIB上での管理対象としての"イメージ"です)
- デプロイメント: "イメージ"情報を元に、IBM Cloud上にカスタム・イメージを作成する
- Wazi aaS仮想サーバーの作成: "カスタム・イメージ"を元にWazi aaS仮想サーバーを作成する
WIB管理コンソール画面イメージ
基本的にはこれを左側から実施していくイメージとなります。
(1)設定
ストレージ・サーバーの情報設定
WIB管理コンソールのメニューの「ストレージ」をクリックしてストレージ・サーバーの情報を設定します。
例:
ソース環境(z/OS)の情報設定
WIB管理コンソールのメニューの「ソース環境」をクリックしてコピー元となるz/OS環境の情報を設定します。
例:
ターゲット環境(IBM Cloud)の情報設定
WIB管理コンソールのメニューの「ターゲット環境」をクリックしてコピー先となるIBM Cloud環境の情報を設定します。
例:
リソース・グループとして"default"以外を指定した場合は、追加で以下の対応が必要となります。
WIBサーバー導入時に作成される/opt/ibm/wib/liberty/usr/servers/wib-server/terraform/variables.tfファイルを編集し、variable "cos_resource_group" 以下の defaultの値を、
ターゲットのICOS が属しているリソース・グループ名に変更します。
...
variable "cos_resource_group" {
type = string
default = "Default"
description = "Resource group of the COS instance"
}
...
...
variable "cos_resource_group" {
type = string
default = "resource-group01"
description = "Resource group of the COS instance"
}
...
(2)コンポーネントとイメージの作成
WIB上では、既存z/OS環境のVolume情報を、"コンポーネント"および"イメージ"という単位で管理します。
用語の整理(以下はあくまでWIB上での管理単位です)
コンポーネント: 特定の意味のあるVolumeのまとまりを指します。この"コンポーネント"が既存z/OS環境からVolumeを抽出する際の単位となります。例えば、IPLに必要なz/OSイメージのみが含まれたVolume群、CICS関連のデータが含まれたVolume群、などの単位で抽出することになります。"コンポーネント"は、SYSRESを含む"システム常駐ボリューム"というタイプと、SYSRESを含まない"ボリューム"というタイプの2種類に分類されます。"コンポーネント"を作成する際、SSH経由でz/OSに接続しExtraction Utilityが実行され、圧縮されたVolume情報がsftpサーバーに転送されることになります。
イメージ: sftpサーバー上に抽出された"コンポーネント"をまとめたものを"イメージ"と呼びます。この"イメージ"が、Wazi aaS仮想サーバーのカスタム・イメージの単位となります。"イメージ"にはSYSRESを保持する"コンポーネント"(システム常駐ボリューム) を1つ含める必要があります。ターゲットのイメージに含められるボリュームのトータル・サイズの上限は16TBです。
コンポーネントの作成
WIB管理コンソールのメニューの「コンポーネントの作成」をクリックし、z/OSのVolume情報を"コンポーネント"として抽出します。
抽出されたコンポーネントの例:
コンポーネントの作成が完了すると、抽出されたVolumeごとのファイル(.gz)がsftpサーバー上に保持されているのが確認できます。
sftpサーバーのファイル例
[root@admsvr01 /home/ftpuser1/WIB_test01]# ls -laR
.:
total 0
drwx------. 3 ftpuser1 ftpusers 17 Jun 7 19:23 .
drwx------. 3 ftpuser1 ftpusers 80 Jun 7 09:20 ..
drwxr-xr-x. 3 ftpuser1 ftpusers 21 Jun 7 19:23 zos
./zos:
total 0
drwxr-xr-x. 3 ftpuser1 ftpusers 21 Jun 7 19:23 .
drwx------. 3 ftpuser1 ftpusers 17 Jun 7 19:23 ..
drwxr-xr-x. 3 ftpuser1 ftpusers 21 Jun 7 19:23 SYSZ25A
./zos/SYSZ25A:
total 4
drwxr-xr-x. 3 ftpuser1 ftpusers 21 Jun 7 19:23 .
drwxr-xr-x. 3 ftpuser1 ftpusers 21 Jun 7 19:23 ..
drwxr-xr-x. 2 ftpuser1 ftpusers 4096 Jun 21 02:22 volumes
./zos/SYSZ25A/volumes:
total 14202384
drwxr-xr-x. 2 ftpuser1 ftpusers 4096 Jun 21 02:22 .
drwxr-xr-x. 3 ftpuser1 ftpusers 21 Jun 7 19:23 ..
-rw-r--r--. 1 ftpuser1 ftpusers 157519898 Jun 21 02:22 MN25C1_2023-06-21_02_22_10.gz
-rw-r--r--. 1 ftpuser1 ftpusers 3416911622 Jun 13 19:10 MN25S2_2023-06-13_18_44_13.gz
-rw-r--r--. 1 ftpuser1 ftpusers 1858700307 Jun 19 03:03 MN25T1_2023-06-19_02_54_29.gz
-rw-r--r--. 1 ftpuser1 ftpusers 2402552082 Jun 19 03:15 MN25T2_2023-06-19_03_03_37.gz
-rw-r--r--. 1 ftpuser1 ftpusers 1938148103 Jun 19 03:49 MN25U1_2023-06-19_03_39_50.gz
-rw-r--r--. 1 ftpuser1 ftpusers 4605273593 Jun 19 03:39 MN25U2_2023-06-19_03_16_55.gz
-rw-r--r--. 1 ftpuser1 ftpusers 86037997 Jun 19 03:16 MN25W1_2023-06-19_03_16_26.gz
-rw-r--r--. 1 ftpuser1 ftpusers 78075867 Jun 11 21:06 ZM5D2E_2023-06-11_21_06_27.gz
コンポーネント作成処理のまとめ
ここで行われた処理を図で整理すると以下のようなイメージとなります。
イメージの作成
WIB管理コンソールのメニューの「イメージの作成」をクリックし、複数の"コンポーネント"をまとめて"イメージ"を作成します。
ここでは、WIB上でどのコンポーネントをどのイメージとしてまとめるか、という操作を行っているだけで、まだIBM Cloudに対する操作は行われません。従ってここの処理は特に時間はかからずにすぐに完了するはずです。
デフォルトだと、抽出元のz/OS環境が稼働していた状態のIPL情報が設定されています。IBM Cloud上で稼働させる際にはLOADPARMなど変更したい場合もありますので、その場合はここでカスタマイズができます。
適宜IPL情報をカスタマイズしていきます。
確認
(3)デプロイメント(カスタム・イメージの作成)
"デプロイメント"というと、仮想サーバーが作成されることを想像するかもしれませんが、この操作ではそこまでは行わず、WIB上で作成した"イメージ"を元にIBM Cloud上に"カスタム・イメージ"を作成する操作を意味します。
WIB上で作成した"イメージ"をIBM Cloud上にデプロイする、という意図だと思いますが、個人的にはネーミングがかなり紛らわしいと感じます...。結果的にはIBM Cloud上に "カスタム・イメージ" (+ "ブロック・ストレージ・スナップショット")が作成されることになります。
デプロイメント処理(カスタム・イメージ作成)
WIB管理コンソールのメニューの「イメージをデプロイする」をクリックし、カスタム・イメージを作成します。
処理が完了すると、IBM Cloud上に以下の2つのリソースが作成されることになります。
- カスタム・イメージ: 仮想サーバー作成のベースとなるbootに必要な情報
- ブロック・ストレージ・スナップショット: 仮想サーバーに追加するストレージ(データ・ボリューム)の元になる情報
IBM Cloudのコンソールから生成されたリソースを確認します。
カスタム・イメージ:
ブロック・ストレージ・スナップショット
デプロイ処理(カスタム・イメージ作成処理)のまとめ
ここで行われた処理を図で整理すると以下のようなイメージとなります。
上の図の①～⑥の処理が内部的に行われます。これらについて補足します。
- ①VolumeファイルをICOSに転送: WIBサーバーは、デプロイ対象の"イメージ"に含まれるVolumeファイルをsftpサーバーから読み取り、ICOSのバケットに転送する
-
②devmapファイルなど補助ファイルをICOSのバケット上に生成
----- Terraform経由で以降の処理が実行される ---- -
③カスタム・イメージ作成用に、一時的にIA/Linuxの仮想サーバーを作成
- nn-build という名前でdefaultリソース・グループに仮想サーバーが作成される
- その他、SSH Key, サブネット、浮動IPアドレス、セキュリティー・グループ等も作成される (いずれもdefaultリソース・グループ)
- ④カスタム・イメージ作成用プログラム実行: 仮想サーバー上でVolumeファイルを元にカスタム・イメージを生成するプログラム(Python)が実行される
-
⑤カスタム・イメージが生成される: 以下の2つのリソースが作成される
- Custom Image: defaultリソースグループにnn という名前で作成される
- Block Storage Snapshot: defaultリソースグループにnn-data という名前で作成される
- ⑥一時的に作成したリソースを削除: ③で一時的に作成されたカスタム・イメージ作成用仮想サーバー、サブネット、浮動IPアドレスなどを削除
※これらはWIBサーバーでの"デプロイメント処理"の中で内部的に実行される処理ですので、ユーザーが直接意識して操作するものではありません。
(4)Wazi aaS仮想サーバーの作成
ここまでの手順で、"カスタム・イメージ"、"ブロック・ストレージ・スナップショット"が作成されましたので、あとはこれを元に一般的な仮想サーバー作成と同様の手順でWazi aaS仮想サーバーを作成することができます。
以下は、IBM CloudのコンソールからVirtual Server for VPCの作成画面を選択し操作する例です。
ロケーション/詳細
ロケーションや名前、リソースグループ等を指定
イメージおよびプロファイル
「イメージの変更」をクリックすると以下の画面が開くので「IBM Z, LinuxONE - s390xアーキテクチャー」を選択し、「カスタム・イメージ」タブから先に作成したカスタム・イメージを選択します。
「プロファイルの編集」をクリックすると以下の画面が開くので適切なプロファイルを指定します(最小要件は 2 vCPUs x 16 GB RAMです)。
SSH鍵
今回のシナリオだと既存z/OSのVolumeを持ってくることになるので、ここで指定したSSH鍵は使用されないのですが、仕様上SSH鍵を指定しないと仮想サーバーの作成ができないので、ダミーでもよいので適当な鍵を作成して指定します。
ストレージ
ブート・ボリュームの鉛筆アイコンをクリックし、適当な名前を指定します。
データ・ボリュームの作成をクリックします。以下の画面で、"スナップショットからインポート"を有効化し、先の手順で作成された"ブロック・ストレージ・スナップショット"を選択します。適当な名前も指定します。
ネットワーク
仮想サーバーを作成するVPCを指定します。
インターフェースの鉛筆アイコンをクリックし、インターフェースの設定を適宜変更します。固定のIPアドレスを割り当てたい場合は事前に予約済みIPを作成しておき、それを指定します。
仮想サーバー作成
各種設定を行ったら、右がわのメニューから「仮想サーバーの作成」をクリックしてサーバーを作成します。
仮想サーバーが作成されたら、他の仮想サーバーと同様一覧に表示されるのでそこから管理可能です。
仮想サーバーの起動/停止
起動
IBM Cloudの管理コンソールから他の仮想サーバーと同様「開始」メニューを選択することでサーバーが開始されます。Wazi aaSの場合、WIBでイメージ作成時に指定したLOAD PARMに従いIPLされることになります。マスターコンソールで各種リプライコマンドを投入する必要がある場合や、起動状況を確認する必要がある場合は、IBM Cloudから「シリアル・コンソール」に接続し操作する必要があります。
参考:
シリアル・コンソール
IPL
起動方法はコピー元のVolumeの状態(IPLPARM等)にも依存しますので、コピー元の作法に従って起動して下さい。
停止
IBM Cloudの「停止」メニューをいきなり実行してしまうと、z/OS上のサブシステムが稼働したままいきなり電源OFFしてしまうイメージとなり、次回起動に影響が生じる場合があります。そのため、z/OS上の各種サブシステムを停止し、アドレス・スペースが全て無くなった状態にしてからIBM Cloudの「停止」処理を行ってください。
停止方法はコピー元Volumeの状態にも依存しますので、コピー元の作法に従って停止して下さい。
参考:
シャットダウン
補足
Wazi aaS仮想サーバーのTCP/IP構成について
IBM Cloud上に構成されるWazi aaS仮想サーバーのネットワーク観点のイメージとしては以下のようになると思われます。
※Wazi aaSの内部実装は明確に記載されているものは無いので、あくまで推測です。類似製品であるZD&TやWazi Sandboxがこのような構成になっているのでWazi aaSも恐らくこれに類似した構成になっているものと推察しています。恐らくzLinuxをベースとしてその上にz/OSのエミュレーターが稼働しているという実装になっているものと思われますが、残念ながらベース環境にアクセスできない状況であり完全にブラックボックスのため実際の構成を確認する術はありません...
WIBで抽出するVolumeに含まれるTCPIP ProfileではIPアドレスなどを変数として定義しておく必要があります。これは、Wazi aaS仮想サーバーを作成する際にその部分を上書きできるようにするためです。
IBM Cloud上に作成されたWazi aaS仮想サーバーの中身を見ると、変数が以下のように置き換わっているのが確認できます。つまり、いずれのサーバーも固定で172.26.1.2というIPアドレスが割り当てられます(ここは実際に確認できる所)。
...
SYMDEF(&HOMEIPADDRESS1.='172.26.1.2')
SYMDEF(&DEFAULTROUTEADDR.='172.26.1.1')
SYMDEF(&NAMESERVERADDR1.='172.26.1.1')
...
恐らくベースのOSではTAP(仮想インターフェース)が作成されておりそこに172.26.1.1のアドレスがアサインされることになると思われます。
外部との接続に使用するIPアドレスは、接続するサブネットのIPアドレスのレンジに合わせてアサインしたものを使用します。上の例でいうと10.244.64.0/24です。
TAPと外部接続用のNICの間で何らかのルーティングのメカニズムが使われており、z/OSと外部とのTCP/IP通信が実現されているものと思われます(この辺りは実機確認できないので推測)。
ちなみにZD&TやWazi Sandboxだとベース環境にアクセスできるのでその辺りの構成は実機で確認できますが、iptablesやhaproxyが使われています。ですので恐らくWazi aaSも同じような構成が行われているのではないかと推測しています。
参考:
ZD&Tネットワーク構成
Wazi Sandbox ネットワーク構成
このような仕組みによって、外部からアクセスする時には各仮想サーバーのインスタンス毎に個別のIPアドレスが利用できるということになると思われます。
つまり、上の図の例で言うと、仮想サーバー(1)に接続したい場合は10.244.64.5にアクセスする、仮想サーバー(2)に接続したい場合は10.244.64.6にアクセスすればよい、ということになります。
terraformで実行される処理について
上で示したWIBによるカスタム・イメージの作成処理(デプロイ処理)では、terraform経由で結構えげつない処理が行われています。
本来は直接意識する必要は無いはずですが、詳しい内容がマニュアル上にはほとんど記載されておらず、設定やら問題判別やらを行う際に困ることもあると思うので、解析できた処理内容について少し補足しておきます。
terraformというのは主にクラウド上のリソースの管理(作成/構成変更/削除)などをコードベースで行うための機能を提供するOSSです。クラウド環境の作成/管理の自動化や、Infrastructure as Codeの実現のために用いられるツールです。
WIBサーバーをインストール/構成すると、一緒にterraform用の構成ファイルも展開されることになり、WIBのデプロイ処理では内部的にterraform経由でIBM Cloudに対する各種操作が行われることになります。このterraform関連の構成ファイルというのは、以下GitHubに提供されているものがそのまま利用されています。
参考: z/OS dev/test VPC Custom Image Builder
少なくともWIB V1.4ではここに提供されている構成ファイル、Pythonプログラムと同じものが提供されていました。
terraformが関わる部分を少しだけ詳しく図示したものがこちらです。
terraformで作成されるリソースの簡易的な相関図を以下に示します。
この処理では、z/OSのVolumeイメージから、最終的にはboot用のイメージ(カスタム・イメージ)と、それ以外のデータ・ボリューム(ブロック・ストレージ・スナップショット)を作成するのが目的です。これらを実際に行うコアになるロジックは、data_moverと呼ばれるPythonプログラムとして実装されています。このPythonプログラムを動かすために、IBM Cloud上に仮想サーバーを一時的に作成しているということになります。
やっていることとしてはこんな感じです。
- VPC, subnet, ssh_key, security groupなど仮想サーバーに必要なリソースを作成
- データ加工に必要なBlock Storageを準備
- VSI(Linuxサーバー)を作成しFloatingIPを割り当て
- Pythonプログラム(data_mover)がVSI上で稼働し、ICOSに転送されたz/OS Volume情報を元に、boot用の情報とデータ・ボリューム用の情報を作成する
- boot用のデータはICOS上のqcow2ファイルとして作成
- データ・ボリューム用の情報はブロック・ストレージに保持される
- 最終成果物作成
- ICOS上のqcow2ファイルからカスタム・イメージを作成
- データ・ボリューム用の情報からブロック・ストレージ・スナップショットを作成
- 最後に、最終成果物をterraform管理対象から除外し、data_mover稼働用に一時的に作成したVPC関連リソースを削除
作成するIBM Cloud上のVPCリソースについてはこの辺りで定義されています。
参考: vsi.tf
cloud-initという仕組みを利用して、作成されたVSIの初期化を行っていますが、ここでdata_moverのPythonプログラムを送り込んで実行させています。
参考: cloudinit_config.tf
処理の流れとしては、data_moverでz/OS Volume情報の加工を行った後に、カスタム・イメージやブロック・ストレージ・スナップショットの作成に進む必要がありますが、この順序性担保のために少しややこしい仕組みが使われているようです。
一般的なterraformのアーキテクチャーとしては、terraform管理のリソースであれば依存関係を指定でき、特定のリソースを作成する際に、前提となる(依存関係のある)リソースを指定できます。これにより順序性が担保できます。具体的にはdepends_onとい指定で他のリソースとの依存関係を指定できます(それをベースに図示したのが上の相関図です)。
ただ、ここでやりたいのはVSI上のcloud-init処理が終わってから後続処理を進めたいということなので、素直にterraformのdepends_onが使えません。そこでWIBで提供している定義ではどのようにしているかというと、time_sleepというリソースを作成しています。
参考: time_sleep: wait_for_cloudint
ここでは、terraformコマンドを投入しているマシンからssh経由でVSIに接続し、cloud-init status --waitというコマンドを実行しています。これにより、ここのリソースでdata_moverの処理が終わるまで待ちの状態を作っているようです。data_moverの処理が終わってから作成するリソースは、このtime_sleepリソースを依存関係として指定しておけばよいことになります。
data_moverを稼働させるVSIでは、cloud-initの処理でPythonプログラムを動かすために必要な環境を整えるために外部インターネットへのアクセスが必要になります。また、terraform実行マシン(ここではWIBサーバー)からSSH接続を行う必要があるということになります。そのため、FloatingIPをアサインしているということになります。