ansible-role-infosvr-import-export

IBM InfoSphere Information Serverのコンテンツと構造のインポートおよびエクスポートを自動化するためのAnsibleロールです。

Ansibleが初めてですか？この簡単な紹介が役立つかもしれません。

要件

• Ansible v2.8以上
• IBM InfoSphere Information Server環境へのdsadmの権限を持つネットワークアクセス
• インベントリグループ名がIBM.infosvrのロールと同じように設定されている
• （使いやすくするために、IBM.infosvrのロールがインストールされ、設定されていること）
• コントロールマシンにjmespathがインストールされている（このロールはjson_queryモジュールを利用しているため、このライブラリが必要）

このロールは、少数のセットアップタスクを自動化するために、権限昇格をオプションで利用します。あなたの環境で権限昇格が許可されていない場合は、事前に手動でこれらの前提条件が満たされていることを確認し、defaults/main.ymlの変数ibm_infosvr_impexp_priv_escalateをFalseに変更してください（これにより、rootへの権限昇格の試行がスキップされます）。

権限昇格をFalseに設定した場合、ロールを実行する前にターゲット環境で以下の作業が行われていることを確認してください：

• python-requestsライブラリのインストール（例：yumを使用）
• python-lxmlライブラリのインストール（例：yumを使用）
• curlのインストール（例：yumを使用）
• ドメイン層の{IS_HOME}/ASBServer/logsディレクトリは、ロールを実行するユーザーが書き込み可能でなければなりません（そのディレクトリ内の各.logファイルも同様）

（dsadmへの権限昇格は主に運用メタデータの処理とDataStageプロジェクト変数の抽出および読み込みに使用されます。これらを使用しない場合、権限昇格は不要かもしれません。）

ロール変数

defaults/main.ymlにはインラインのドキュメントがあります。主要な必要変数については以下の例を参照してください。さまざまなオブジェクトタイプに対する期待されるアクション変数やサブ構造については、下記のドキュメントを参照してください。

デフォルトでは、このロールは自己署名証明書のSSL検証を行います。これは、IBM.infosvrのget_certificate.ymlタスクを使用して取得した場合に有効です（下記の実例プレイブックを参照）。これはibm_infosvr_openigc_verify_selfsigned_sslという変数によって制御されます。適切に署名され、信頼されたSSL証明書のみに対して検証を行いたい場合は、この変数をFalseに設定することで自己署名証明書が信頼されなくなります。

例プレイブック

このロールは、Information Server内のさまざまなアセットタイプをエクスポートおよびインポートする機能を含んでいます。このロールは別のプレイブックにインポート可能で、関心のある変数だけを提供することでインポートまたはエクスポートするアセットを制限できます（空の変数は、そのアセットタイプの処理をスキップします）。

ロールに提供される最初のレベルの変数は、実行する広範なアクションを定義し、指定された順序に関わらず常にこの順序で実行されます：

1. gather - 環境の詳細を取得する（例：バージョン番号）
2. export - 環境からファイルにアセットを抽出する
3. merge - 複数のアセットファイルを1つのファイルに統合する
4. ingest - ファイルから環境にアセットを読み込む（importはAnsibleで予約された変数であるため、ingestを使用）
5. progress - ワークフローを通じてアセットを移動する（ワークフローが無効な場合は何もしません）
6. validate - 客観的なアセット数を用いて、環境が期待される状態にあるかを検証する

欠落している変数は、そのアクションセットを単にスキップします。

例えば：

---

- name: Information Serverの変数を設定
  hosts: all
  tasks:
    - import_role: name=IBM.infosvr tasks_from=setup_vars.yml
    - import_role: name=IBM.infosvr tasks_from=get_certificate.yml

- name: アセットの読み込みと検証
  hosts: all
  roles:
    - IBM.infosvr-import-export
  vars:
    isx_mappings:
      - { type: "HostSystem", attr: "name", from: "MY_HOST", to: "YOUR_HOST" }
    gather: True
    ingest:
      datastage:
        - from: /some/directory/file1.isx
          into_project: dstage1
          with_options:
            overwrite: True
      common:
        - from: file2.isx
          with_options:
            transformed_by: "{{ isx_mappings }}"
            overwrite: True
    validate:
      that:
        - number_of: dsjob
          meeting_all_conditions:
            - { property: "transformation_project.name", operator: "=", value: "dstage1" }
          is: 5
        - number_of: database_table
          meeting_all_conditions:
            - { property: "database_schema.database.host.name", operator: "=", value: "YOUR_HOST" }
          is: 10

これは、プレイブックが実行されている環境から環境の詳細を収集することから始まります。

その後、file2.isxから共通メタデータをインポートし（プレイブックの相対的なfiles/サブディレクトリに期待）、MY_HOSTからYOUR_HOSTにホスト名を変更し、同じ識別子を持つ既存のアセットを上書きします。その後、/some/directory/file1.isxからDataStageアセットをdstage1プロジェクトにインポートし、同じ識別子を持つ既存のアセットを上書きします。

変数の定義順序は重要ではありません：ロールは、オブジェクト間の依存関係に配慮して適切な順序でエクスポートとインポートを行います（つまり、共通メタデータとビジネスメタデータが関係性の前に読み込まれるなど）。ただし、特定のタイプ内で定義された複数のオブジェクトの順序は、あなた自身の依存関係によって影響を受ける場合があります。

最後に、プレイブックは読み込みが予想通りのアセット（対象環境におけるdstage1プロジェクト内の5つのDataStageジョブとYOUR_HOSTサーバー上のスキーマやデータベースの組み合わせでの10のデータベーステーブル）になったかどうかを検証します。

（progressやexportのアクションが指定されていないため、それらは実行されません。）

アクション（およびオブジェクト）構造

以下は、このロールでカバーされているすべてのアクションとオブジェクトタイプ、それに期待される構造について説明します。

1. gather - 環境詳細収集
2. export / merge / ingestメタデータアセットタイプ（上記のアクション同様、以下の順序に従ってこれらのオブジェクトタイプが抽出・読み込まれます）
   1. customattrs - カスタム属性定義
   2. common - 共通メタデータ （低レベルとして考慮し、可能な限りタイプ固有のオプションを使用して避けるべきです）
   3. logicalmodel - 論理モデルメタデータ
   4. physicalmodel - 物理モデルメタデータ
   5. mdm - マスターデータ管理モデルメタデータ
   6. database - データベースメタデータ
   7. datafile - データファイルメタデータ
   8. dataclass - データクラスメタデータ
   9. datastage - DataStageアセット
   10. ds_vars - DataStageプロジェクト変数
   11. infoanalyzer - Information Analyzerアセット
   12. openigc - OpenIGCバンドルとアセット
   13. extendedsource - 拡張データソース
   14. extensionmap - 拡張マッピング文書
   15. glossary - 用語集アセット
   16. relationships - メタデータの関係性
   17. omd - 運用メタデータ
3. progress - ワークフローの進行
4. validate - 検証フレームワーク

export、merge、ingestには、マッピングを適用してメタデータを環境間で変換することもできます（例：名前の変更、包含の変更など）。また、ほとんどのアセットタイプは、条件を使用して制限することも可能です。

これらの変数構造は、Ansibleがサポートする任意の形式で記述できます。例えば、これらはすべて同じで、あなたの個人的な好みによります：

var_name: [ { a: "", b: "", c: "" }, { d: "", e: "", f: "" } ]

var_name:
  - { a: "", b: "", c: "" }
  - { d: "", e: "", f: "" }

var_name:
  - a: ""
    b: ""
    c: ""
  - d: ""
    e: ""
    f: ""

ライセンス

Apache 2.0

著者情報

クリストファー・グローテ