ansible-role-infosvr

IBM InfoSphere Information Server環境の自動展開のためのAnsibleロールで、バージョン11.5と11.7の両方を含みます。

• リポジトリ（データベース）層
• ドメイン（サービス）層
• エンジン層
• 統一ガバナンス（「エンタープライズサーチ」）層（v11.7のみ）
• パッチ / フィックスパック

さらに、以下のエンタープライズエディションのモジュールも含まれ、以下の変数で無効化できます（例：使用許可がない場合や、インストール / 設定したくない場合）。

• 情報ガバナンスカタログ
• 情報アナライザー
• DataStageオペレーションコンソール
• DataClick
• イベント管理（データ品質例外コンソールとの統合）
• データ品質例外コンソール
• QualityStage
• 情報サービスディレクター
• FastTrack
• 情報ガバナンスダッシュボード（事前にCognos環境が必要）
• DataStage内のOptimマスキング
• v11.7でのみ提供される追加機能：
  • 新しい情報ガバナンスカタログ（UI）
  • ガバンスモニターダッシュボード
  • エンタープライズサーチ（ナレッジグラフを含む）
  • DataStageフローデザイナー
  • 機械学習用の用語分類（v11.7+）

現在、デプロイメントはDB2をバックエンドとしてサポートしており、バンドルされたDB2のインストールと設定、または既存のDB2の設定ができます。完全なWebSphereアプリケーションサーバーネットワークデプロイ構成またはWebSphereリバティプロファイル構成がインストールされます（詳しくは下記の変数を参照）。現在、このロールは既存のWebSphereインストールを設定することはできません。

Ansibleを初めて使う方へ。この簡単な紹介が役立つかもしれません。

要件

• Ansible v2.7
• すべてのサーバーへの「root」権限のあるネットワークアクセス
• Windowsクライアントマシンへの管理者アクセス
• AnsibleによるWinRMアクセスが設定されたWindowsクライアントマシン（詳細は http://docs.ansible.com/ansible/latest/intro_windows.html を参照）

ロール変数

インラインドキュメントについては defaults/main.yml を参照し、必要な主要変数の例については以下をご覧ください。デフォルトファイルには、バニラなv11.7インストールに含まれるデフォルト設定がすでにあるため、デフォルトを使用したくない変数（例：ユーザーのパスワード）だけを上書きすれば大丈夫です。

上書きが必要な最小限の変数は以下の通りです：

• ibm_infosvr_media_dir: インストールバイナリが既にダウンロードされているAnsibleホスト上の場所（例：Passport Advantageから）
• ibm_infosvr_media_bin 辞書: インストールに使用するバイナリの名前 (デフォルトでは最新のv11.7ファイルがここにあります。v11.5をインストールする場合は、v11.5ファイル名に置き換えが必要です)
• ibm_infosvr_ug_storage: kubernetesに使用する統一ガバナンス層の追加の生ストレージデバイス（未マウントでLVMグループに属さない等）
• ibm_infosvr_features 辞書: 使用したい機能（True）と使用したくない機能（False）を定義

最後に、さまざまな資格情報変数は、安全な環境を作成するために上書きする必要があります。 _upwd_で検索すると、defaults/main.yml内のすべてのパスワード変数が表示され、上書きが求められます。（他の変数への参照をAnsibleボールトを通じてさらに安全に置き換えることもできます。）

依存関係

情報アナライザーの設定では、IBM.infosvr-metadata-asset-managerロールが間接的に使用されており、import_roleディレクティブを利用しています。このロールは、循環依存を避けるために明示的に依存関係としてリストされていませんが、情報アナライザーの設定を行う予定がある場合はインストールするべきです。

例のプレイブック

次の例のプレイブックは、defaults/main.ymlのデフォルトパラメータを使用してIBM InfoSphere Information Serverの完全なインストールと構成を行います（および例えばgroup_vars/all.ymlに設定した上書き）。このロールは複数の層にわたるインストールを行うため、異なる層の早期ステップで失敗した場合に部分的なインストール/設定を避けるために、any_errors_fatalを使用するべきです。

---

- name: install and configure IBM InfoSphere Information Server
  hosts: all
  any_errors_fatal: true
  roles:
    - IBM.infosvr
  pre_tasks:
    - name: update all OS-level packages
      yum:
        state: latest
        name: '*'
        exclude: docker*,kubelet*,kubectl*,kubeadm*
      become: yes
      when: ('ibm_information_server_clients' not in group_names)

プレタスクは、インストールを開始する前に、すべてのOSレベルのパッケージが最新であることを確認します。

期待されるインベントリ

以下のグループは、さまざまなコンポーネントのインストール場所を区別するためにインベントリ内で期待されるものです。もちろん、単一のサーバに複数のコンポーネントをインストールしたい場合は、同じホスト名を各グループに提供することで実現可能です。以下の例では、リポジトリとドメイン層の両方が「serverA」に配置されており、エンジン層は「serverB」に個別にインストールされ、統一ガバナンス層も独自のシステム「serverC」に配置されています。

[ibm_information_server_repo]
# リポジトリ層（データベース）のインストール先Linuxホスト (DB2)
serverA.somewhere.com

[ibm_information_server_domain]
# ドメイン（サービス）層のインストール先Linuxホスト (WebSphere)
serverA.somewhere.com

[ibm_information_server_engine]
# エンジン層のインストール先Linuxホスト
serverB.somewhere.com

[ibm_information_server_clients]
# クライアントアプリケーションをインストールするWindowsホスト、Windows専用ブローカー / ブリッジ用のメタデータインターチェンジサーバが設定された
client.somewhere.com

[ibm_information_server_ug]
# v11.7+の統一ガバナンス層がインストールされるLinuxホスト (kubernetes)
serverC.somewhere.com

[ibm_information_server_external_db]
# XMETAなどを展開するための既存のデータベースを保持するLinuxホスト -- ホストが指定されていない場合またはこのグループが完全にない場合、ibm_information_server_repoサーバにバンドルされたDB2をインストール
serverD.somewhere.com

[ibm_cognos_report_server]
# 既存のCognos BIインストールが存在するLinuxホスト (情報ガバナンスダッシュボード用)
cognos.somewhere.com

[ibm_bpm]
# 既存のBPMインストールが存在するLinuxホスト (現在は未使用)
bpm.somewhere.com

他のAnsibleインベントリと同様に、サーバに接続可能な十分な詳細を提供する必要があります（詳細は http://docs.ansible.com/ansible/latest/intro_inventory.html#list-of-behavioral-inventory-parameters を参照）。

タグ

パッチのインストール

このロールは、インストールされた環境をパッチやシステムパッケージで最新に保つことも目的としています。パッチを適用するには、vars/patches/[server|client]/<version>/<date>.ymlファイルに関連する詳細を入力するだけです。例えば、v11.7.1.0のサーバー側の修正はvars/patches/server/11.7.1.0/<date>.ymlに、v11.7.0.2のクライアント側の修正はvars/patches/client/11.7.0.2/<date>.ymlに入れます。<date>はパッチがリリースされた日付を意味します。一般的に、これらはFix Centralでの主要なパッチの入手可能性に基づいて、GitHub内で常に最新の状態に保たれています。しかし、既存のリストにはない中間修正またはその他の修正を適用したい場合は、以下の手順に従ってください。

• 各パッチは、ibm_infosvr_patch_definitionという名前の辞書であるべきです。
• 辞書には以下のキーを含める必要があります：
  • name: IBM Fix Centralに記載されているパッチ / フィックスパックの名前
  • srcFile: IBM Fix Centralからダウンロードしたパッチ / フィックスパックファイルの名前
  • pkgFile: srcFile内に含まれる.ispkgファイルの名前
  • versionId: パッチ / フィックスパックがインストールされた後に Version.xml に追加される installerId タグ
  • tiers: このパッチを適用すべき層のリスト（可能な値は domain と engine ） -- クライアントのパッチについては、これはクライアントであると暗黙に理解されるため、tiersは不要です。

例えば：

ibm_infosvr_patch_definition:
  name: is11700_ServicePack2_ug_services_engine_linux64
  srcFile: servicepack_11.7_SP2_linux64_11700.tar.gz
  pkgFile: servicepack_11.7_SP2_linux64_11700.ispkg
  versionId: servicepack_SP2_IS117_11700
  tiers:
    - domain
    - engine

JDKのアップデートもvars/patches/jdk/[server|client]/<major>/latest.ymlの下に含めることができます。<major>はメジャーリリースバージョン（11.5または11.7）です。この場合も、JDK情報を定義するためにibm_infosvr_jdk_definitionという1つの辞書を使用する必要があります。

11.5の場合に必要なキー：

• name: IBM Fix Centralに記載されているJDKの名前
• infosvr_filename: IBM Fix CentralからダウンロードしたJDKファイルの名前
• infosvr_extract_path: JDKファイルを抽出した際に作成されたパス
• versionInfo: このJDKのバージョンを特定するバージョン文字列（java -versionから）
• was_filename: v6 JDKを含むWebSphereアプリケーションサーバー（WAS）フィックスパックの名前
• was_offering: WAS JDK（v6）フィックスパック内の提供名
• jdk7_filename: v7 JDKを含むWASフィックスパックの名前
• jdk7_offering: WAS JDK（v7）フィックスパック内の提供名
• was_versionInfo: JDK（v6）のバージョンを特定するバージョン文字列（java -versionから）
• jdk7_versionInfo: JDK（v7）のバージョンを特定するバージョン文字列（java -versionから）

11.7の場合に必要なキー：

• name: IBM Fix Centralに記載されているJDKの名前
• infosvr_filename: IBM Fix CentralからダウンロードしたJDKファイルの名前
• infosvr_extract_path: JDKファイルを抽出した際に作成されたパス
• was_filename: JDKを含むWebSphereアプリケーションサーバー（WAS）フィックスパックの名前
• was_offering: WAS JDKフィックスパック内の提供名
• versionInfo: この（非WAS）JDKのバージョンを特定するバージョン文字列（java -versionから）
• was_versionInfo: この（WAS）JDKのバージョンを特定するバージョン文字列（java -versionから）

これらのJDKアップデートはリストではなく、単純な辞書です -- 各アップデートは前のアップデートを上書きするため、適用したいJDKの最新バージョンのリストのみを提供する必要があります。

更新を実行するには、次のようにupdateタグを使用します：

ansible-playbook [-i hosts] [site.yml] --tags=update

これにより、すでに適用されていないパッチが、リリースされた日付に基づいて順番に適用されます（古いものから順に）。ただし、オペレーティングシステムに対するシステムレベルのパッケージは更新されません。これが望ましい場合は、より広範なプレイブックでそのような更新を処理するようにしてください。

環境操作

環境操作を簡素化するために、いくつかのタグが提供されています。特に、複数のホストにまたがる場合に便利です。

• status: 構成されたさまざまなコンポーネントが動作しているかどうかを確認します（指定されたポートでサービスがリッスンしているか確認）。
• stop: 様々なホスト間で適切な順序で各コンポーネントを正常にシャットダウンします。基盤となるホスト自体はシャットダウンしません。
• start: 様々なホスト間で適切な順序で各コンポーネントを起動します。
• restart: stopを実行してからすぐにstartを実行します。

再利用可能なタスク

このロールには、すべてのインストールステップを実行することなく、情報サーバーインストールの特性を利用する必要がある他のロールに含めるための再利用可能なタスクも含まれています。

setup_vars.yml

情報サーバー環境をデプロイするために使用された設定変数は、後からsetup_vars.ymlタスクセットを使用して取得できます。例えば、次のようにプレイブックに含めることで可能です：

---

- name: setup Information Server vars
  hosts: all
  tasks:
    - import_role: name=IBM.infosvr tasks_from=setup_vars.yml

get_certificate.yml

情報サーバー環境のドメイン層のルートSSL証明書は、後からget_certificate.ymlタスクセットを使用して取得できます。例えば、次のようにプレイブックに含めることが可能です：

---

- name: setup Information Server vars
  hosts: all
  tasks:
    - import_role: name=IBM.infosvr tasks_from=setup_vars.yml
    - import_role: name=IBM.infosvr tasks_from=get_certificate.yml

このタスクセットは、setup_vars.ymlが既に実行されていることに依存しますので、同じプレイに含めることが価値あるかもしれません（上記の例のように）。ドメイン層のSSL証明書は、プレイブックを実行するコントロールマシンのパスに対して cache/__ibm_infosvr_cert_root.crtに保存されます。

ライセンス

Apache 2.0

著者情報

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