ibm.infosvr-openigc

ansible-role-infosvr-openigc

OpenIGCオブジェクトをIBM情報サーバー内の情報ガバナンスカタログに展開するためのAnsibleロールです。

Ansibleが初めてですか？この簡単な紹介が役立ちます。

要件

Ansible v2.6.x
コントロールマシンに事前にインストールされている必要があるユーティリティ:
- zip
- curl

このロールは特権昇格を使用せず、主にコントロールマシン自体で実行されます（環境内の関連APIに直接生成ファイルをプッシュするだけです）。

YAMLベースの入力には高度なJinjaテンプレートを使用しているため、最近のJinja配布が含まれているAnsibleのバージョン（v2.4は不十分で、v2.6.xが必要）を使用する必要があります。v2.7ではuriモジュールがファイルの送信をサポートしていますが、証明書機関をオーバーライドする機能は提供されていないため、自己署名証明書の検証を可能にするために、現在もcurlに依存しています。

ロール変数

インラインドキュメントについてはdefaults/main.ymlを参照し、必要な主な変数の例については以下をご覧ください。

このロールは、例えばtasks_from=setup_vars.ymlを使って最初にIBM.infosvrをインポートするプレイブックを使用することにより、IBM.infosvrロールから変数を自動的に再利用しようとします。

デフォルトでは、IBM.infosvrのget_certificate.ymlタスクを使用して自己署名証明書を取得していれば、自己署名証明書に対してSSL検証を行います（以下のプレイブック例を参照）。これはロールのibm_infosvr_openigc_verify_selfsigned_ssl変数で制御されます：正しく署名された信頼できるSSL証明書のみを検証する場合は、この変数をFalseに設定すると、自己署名ドメイン階層証明書は信頼されなくなります。

サンプルプレイブック

このロールは、主にOpenIGCオブジェクト（バンドルや資産インスタンス）の展開のために、必要に応じて他のプレイブックにインポートされることを目的としています（そのため、Ansible v2.4.xとimport_roleモジュールが必要です）。

---
- name: 情報サーバーの変数を設定
  hosts: all
  tasks:
    - import_role: name=IBM.infosvr tasks_from=setup_vars.yml
    - import_role: name=IBM.infosvr tasks_from=get_certificate.yml

- name: OpenIGCバンドルおよび資産を読み込む
  hosts: ibm_information_server_engine
  roles:
    - IBM.infosvr-openigc
  vars:
    bundles:
      - /some/directory/<BundleId>
    assets_as_xml:
      - /some/directory/asset_instances-<BundleId>.xml
    assets_as_yaml:
      - /some/directory/assets.yml
    flows_as_xml:
      - /some/directory/lineage_flows-<BundleId>.xml
    flows_as_yaml:
      - /some/directory/lineage.yml

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

以下は、このロールによって現在サポートされているすべてのアクションとオブジェクトタイプ、およびその期待される構造を説明します。プレイブックで変数がリストされている順序に関係なく、以下にリストされている順序で読み込まれます。

`bundles`

この変数を通じて提供されるディレクトリのリストは、バンドル形式である必要があり、以下の構造を含む必要があります：

<BundleId>：ポイントするルートディレクトリは、バンドル自体と同じ大文字小文字を区別する名前を持つ必要があります。
- asset_type_descriptor.xml：バンドルを説明するXML（すべてのクラス、関係/包含など）
- i18n：ラベルを含むディレクトリ
  - labels.properties：翻訳可能なクラスおよび属性ラベルのセット
- icons：バンドルによって定義された各クラスごとに2つの.gifファイルを含むディレクトリ：
  - <ClassId>-icon.gif：クラスの16x16ピクセルの表現、.pngファイルも可能ですが、名前は.gifである必要があります。
  - <ClassId>-bigIcon.gif：クラスの32x32ピクセルの表現、同様に.pngファイルも可能ですが、名前は.gifである必要があります。

`assets_as_xml`

この変数を通じて提供されるXMLファイルのリストは、完全に動作する資産インスタンスXMLファイルで、すでに生成されたもの（例：下記の変数による）か、手動で作成されたものです。

`assets_as_yaml`

この変数は、上記のassets_as_xmlで必要とされるXML形式を学ぶよりも、資産インスタンスを指定するためのより便利で読みやすい方法として提供されます。

この変数を通じて提供されるYAMLファイルのリストは、有効な資産インスタンスXMLを生成するために使用され、自動的に読み込まれます。各YAMLファイルの構造は次のようになります：

---

bundleId: $<BundleId>
contains:
  - class: <ClassName>
    name: <name>
    contains:
      - class: <NestedClassName>
        name: <name>
        contains:
          ...

containsサブ構造は、必要に応じて任意の回数ネストすることができ、資産のために必要な包含階層を作成できます。各サブ構造には、必ずclassとnameが定義されている必要があります。

さらに、バンドル定義およびすべてのオブジェクトのデフォルト属性セットによって許可される任意の数の追加属性も指定できます（例：short_description、long_description）。バンドル定義された属性には、単に$を前置する必要があります。例えば：

---

bundleId: $TestBundle
contains:
  - class: Folder
    name: level1
    short_description: 最上位のディレクトリ
    $filesystem: UNIX
    contains:
      - class: Folder
        name: level2
        short_description: ディレクトリ構造内の次のレベル
        contains:
          - class: File
            name: MyFile.txt
            short_description: /level1/level2/MyFile.txt内にあるファイル
            $encoding: UTF-8

この例では、TestBundleバンドルはFolderとFileを定義しており、Folderにはfilesystem属性が定義され、Fileにはencodingが定義されています。両方とも、IGC内のすべてのオブジェクトがこの属性を持っているため、short_descriptionを持つことができます。

複数の値を許可する属性については、単にその属性への値をYAMLリストとして指定します。この例では、バンドルに特有のusers_with_access属性が複数の値を許可するため、その属性の各値をYAMLリストの一部として指定します：

---

bundleId: $TestBundle
contains:
  - class: Folder
    name: root
    $users_with_access:
      - user123
      - user456
      - user789

最後に、namesショートカットは、包含階層の葉ノードに存在し、各ノードのnameのみを指定することで済む場合に使用されます。これにより、各葉ノードのために同じclassを繰り返し指定する必要がなくなります：

---

bundleId: $TestBundle
contains:
  - class: Folder
    name: root
    contains:
      - class: File
        names:
          - MyFile.txt
          - YourFile.txt
          - OtherFile.txt

`flows_as_xml`

この変数を通じて提供されるXMLファイルのリストは、完全に動作する系譜フローXMLファイルで、すでに生成されたもの（例：下記の変数による）か、手動で作成されたものです。

`flows_as_yaml`

この変数は、上記のflows_as_xmlで必要とされるXML形式を学ぶよりも、資産インスタンスを指定するためのより便利で読みやすい方法として提供されます。

この変数を通じて提供されるYAMLファイルのリストは、有効な系譜フローXMLを生成するために使用され、自動的に読み込まれます。各YAMLファイルの構造は次のようになります：

---

assets:
  - class: <FullClassName>
    name: <name>
    contains:
      - class: <NestedFullClassName>
        name: <name>
        id: <unique identifier>
        contains:
          ...

flows:
  - name: <意味があるコメント>
    within: <id>
    contains:
      - name: <意味があるコメント>
        from:
          - <id>
          - ...
        to:
          - <id>
          - ...
      - ...

assetsのcontainsサブ構造は、必要に応じて任意の回数ネストすることができ、資産に必要な包含階層を作成できます。各サブ構造には、必ずclassとnameが定義されている必要があります（実際、他の属性は使用されないため無視されます）。この場合、完全修飾クラス名を指定する必要があります。バンドルIDを含め、例えば$BundleId-ClassNameのようにします。これは、OpenIGCとネイティブ資産を系譜フローで組み合わせるために必要です（複数のOpenIGCバンドルにわたる系譜フローを作成することを可能にします）。

フローの一部として使用する資産には、flows変数内でどのようにそれを参照するかを指定するために明示的なid属性も含めてください。この識別子はYAMLファイル内で一意であり、スペースや他の特殊文字（.と_を除く）を含むべきではありません。idはフラットで一意な参照を提供するために必要で、nameは任意の含まれる構造によって異なるネストされた識別子です。

flows変数内の各nameは生成されたXMLのコメントとして使用されますが、IGC自体には実際には表示されません。

以下に例を示します：

---

assets:
  - class: $TestBundle-Folder
    name: root
    contains:
      - class: $TestBundle-File
        name: MyFile.txt
        id: MyFile.txt
      - class: $TestBundle-File
        name: YourFile.txt
        id: YourFile.txt
      - class: $TestBundle-File
        name: OtherFile.txt
        id: OtherFile.txt
  - class: $TestBundle-Command
    name: copy
    id: copy

flows:
  - name: ファイルを複製するためのコピーコマンド
    within: copy
    contains:
      - name: MyFileからYourFileおよびOtherへコピー
        from:
          - MyFile.txt
        to:
          - YourFile.txt
          - OtherFile.txt