4.9.2.1 監視抑止
連携テンプレートを使用することにより、JP1/IMのシステム管理機能との連携が可能になり、JP1/IMの設定ファイル「共通除外条件拡張定義ファイル（common_exclude_filter.conf）」の取得と適用ができます。これにより、Ops IのワークフローからJP1/IMに対するジョブを実行することが可能で、特定条件のイベント監視の抑止および、抑止解除の制御ができます。例えば、メンテナンス中、サーバを停止させたい時にアラートが発生しないようにしたい場合などで活用できます。
JP1/IMとの連携のため、Ops Iでは以下の内容を提供します。（以下、これらを総称して「連携テンプレート」と呼びます。）
- JP1/IMのイベント監視抑止などの内容が定義されたWorkflowなどのYAMLファイル
- Workflowの定義で使用するOps I提供部品
- JP1/IMとの連携機能を実装したPlaybook
提供するYAMLファイルについては「連携テンプレートの取得と登録」を参考にしてください。また、playbookについては「認証情報およびジョブテンプレートのAWXへの登録」の手順5.を参考にしてください。Ops I提供部品については、一覧を次に示します。
| Ops I提供部品 | 説明 |
|---|---|
| im.apply_common_exclusion_conditions_file | 共通除外条件拡張定義ファイル※への適用 |
| im.get_common_exclusion_conditions_file | 共通除外条件拡張定義ファイル※の取得 |
| im.set_common_exclusion_conditions_valid | 共通除外条件定義の有効/無効を切り替え |
Ops I提供部品の各パラメータには、ワークフローのYAMLファイルで定義するものと、ワークフロー実行時にGUIから入力するものがあります。以下の説明に従って作業してください。
次に、JP1/IMの連携テンプレート実行の流れを以下に示します。
JP1/IMの連携テンプレートは以下の流れで実行されます。
①、②、③はJP1/IMの連携テンプレートを使用します。①および③のPlaybookは実行内容にあわせてカスタム可能です。
①ワークフローを実行
②JP1/IMに対するジョブ実行のためのOps I提供部品を実行
③自動化（AWX）のジョブテンプレートを実行
Playbookがコントロールプレーンに登録されます。
④JP1/IMにある中継サーバから③のPlaybookを取得
⑤Playbook実行により、Playbookに定義されたJP1/IMコマンドを実行
GitLabと中継サーバとの間で、JP1/IMの共通除外条件拡張定義ファイルの取得又は更新が行われます。
（1）前提条件
連携テンプレートを実行するユーザーはそれぞれ必要なロールを付与してください。Ops Iのロールの詳細は「Ops Iロール」を参照してください。
JP1/IMは以下の条件が満たされている必要があります。この条件は、「JP1/AJS3」のジョブ管理機能との連携と同じ条件です。
| サポートOS | 前提条件 |
|---|---|
| Windows Server | ・Ops Iの中継サーバからJP1/IMのサーバにWinRMを使用して接続することができる。
・PowerShell 5.1以上がインストール済みである。・.NET 4.0以上がインストール済みである。 |
また、連携テンプレートにおいて、jcochfilterコマンドを使用するために、以下の条件が満たされている必要があります。
- JP1/IMの共通除外条件の動作モードを拡張モードにしてください。拡張モードに設定していない場合は、共通除外条件拡張定義ファイル（common_exclude_filter.conf）が存在しないため、JP1/IMの連携テンプレートが使用できません。
- JP1/IMの追加共通除外条件は、使用しないでください。Ops Iから共通除外条件を変更すると、JP1/IMの共通除外条件拡張定義ファイル（common_exclude_filter.conf）を上書き更新するため、JP1/IMで追加した設定以外の内容が削除されます。
- JP1/IMの共通除外条件は、JP1/IM - ViewおよびJP1/IMのコマンドで変更しないでください。変更する場合は、Ops Iを使用した運用で実施してください。Ops IとJP1/IMで同時に操作した場合に、ファイルアクセスが競合して処理が正常に動作しない可能性があります。
（2）JP1/IMの連携テンプレート実行のための設定
JP1/IMの連携テンプレート実行のための設定を説明します。
設定項目は以下になります。
「中継サーバの設定」を参考に、AWXのインスタンスグループと中継サーバの接続設定を行います。
接続設定後に、ノード一覧画面で該当の中継サーバのノードのステータスが「Ready」になっていることを確認してください。
「組織管理」を参考に、AWXを使用するために必要な、AWXの「組織」を作成する。
【c. JP1/IMの接続情報・認証情報をシークレット管理へ保存】
まず、自動化（AWX）からシークレットにアクセスするための認証情報を取得します。作成方法は「自動化からシークレットにアクセスするための認証情報の取得」を参照してください。
次に、「AWXの「組織」の作成」で作成した組織に対して、Ops I提供部品の実行に必要なシークレット情報の登録を行います。用途ごとに必要なシークレット情報の設定内容を示します。
それぞれのSecrets Engines、Secretの作成方法は以下を参照してください。
- Secrets Engines：「Secrets Engines作成」
- Secret：「Secretの作成」
キーは以下を設定してください。
- access_token（GitLabのリポジトリにアクセスするためのアクセストークン。GitLabアクセストークンの詳細は「GitLabアクセストークン取得方法」を参照してください。）
キーは以下を設定してください。
- password（AWXアクセス用のOps Iのパスワード）
- user_name（AWXアクセス用のOps Iのユーザー名）
キーは以下を設定してください。
- logical_host_name（論理ホスト名）※任意
- manager（JP1/IM - Managerが稼働するIPアドレス）
- password（JP1/IMのサーバのOSのパスワード）
- user_name（JP1/IMのサーバのOSのユーザー名）
キーは以下を設定してください。
- username（Ops Iアクセストークンを取得するユーザー名）
- password（Ops Iアクセストークンを取得するユーザーのパスワード）
- domain（Ops IのFQDN（例："テナント名.ops-integration.com"））
キーは以下を設定してください。
- opsi_token（API「GET /documents」、「GET /container-items」、「POST /container-items/{id}/files」が実行できるユーザーのOps Iトークン）
- opsi_domain（Ops Iのドメイン名）
「自動化」を参考に、JP1/IMの連携テンプレート実行に必要な以下のAWXの設定を行います。
認証情報タイプ「HashiCorp Vault Secret Lookup」
認証情報タイプ「ソースコントロール」
認証情報タイプ「IM Credential type」
名前は「JP1/IMの接続情報・認証情報をシークレット管理へ保存」の手順3.で登録したJP1/IMのシークレットのパスを指定します。（例：secrets/im/host0001）
タイプの詳細は②と同様に①で登録したVaultの認証情報を指定します。その他のフィールドは「（表）外部シークレット管理システムのメタデータ入力一覧」を参考にしてください。「logical_host_name」への入力は任意です。
認証情報タイプ「OpsI Credential type」
名前は「JP1/IMの接続情報・認証情報をシークレット管理へ保存」の手順5.で登録したOps Iクレデンシャルのシークレットのパスを指定します。（例：secrets/opsi/user/opsi_token）
タイプの詳細は②と同様に①で登録したVaultの認証情報を指定します。その他のフィールドは「（表）外部シークレット管理システムのメタデータ入力一覧」を参考にしてください。ただし「username」と「password」はここでは使用しないため、入力は不要です。
「中継サーバ使用手順」を参照してください。
また、オプションにあるチェックボックス「起動時のリビジョン更新」のチェックは任意ですが、チェックするとplaybookを更新したときに自動で更新後のplaybookを実行します。
---
ansible_connection: winrm
ansible_ssh_port: 5986
ansible_winrm_transport: basic
ansible_winrm_server_cert_validation: ignore
ansible_user: "{{ lookup('env','im_user_name') }}"
ansible_password: "{{ lookup('env','im_password') }}"
ジョブテンプレート登録の入力項目について以下に示します。
（表）ジョブテンプレート登録の入力項目
| 項目 | 説明 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| 名前 | 任意の名前を設定します。 Ops I提供部品に定義しているデフォルト値を以下に示します。ジョブテンプレート名を変更する場合は、WorkflowのYAMLファイルに定義するジョブテンプレート名と一致させてください。
|
||||||||
| ジョブタイプ | 実行を選択します。 | ||||||||
| インベントリー |  アイコンをクリックし、上記3.で登録したインベントリーを選択します。 |
||||||||
| プロジェクト | アイコンをクリックし、上記2.で登録したプロジェクトを選択します。 |
||||||||
| 実行環境、インスタンスグループ、認証情報 | 「中継サーバ使用手順」を参照し設定してください。 | ||||||||
| Playbook | 「system」グループの「system」リポジトリに登録されている、実行したいJP1/IMジョブテンプレート提供部品のPlaybookを設定します。 「（表）actionのリスト（JP1/IM連携用Ops I提供部品）」のPlaybook nameを参考に、設定してください。 また、Playbookをカスタマイズしたい場合は、「system」グループの「system」リポジトリよりダウンロード後カスタマイズし、Ops Iの任意のリポジトリ（YAMLファイルの管理が有効）にpushしたPlaybookをジョブテンプレートに設定することにより使用可能となります。 |
||||||||
| 起動プロンプト | 「認証情報」と「変数」のチェックボックスにチェックします。 |
（3）連携テンプレートの取得と登録
JP1/IMの連携テンプレートを実行するため、連携テンプレートを取得し、リポジトリに登録します。JP1/IMの連携テンプレートはWorkflow、Catalog、UI、およびDatamodelのYAMLファイルがzipファイルにまとめられてGitLabに格納されています。それぞれのYAMLファイルには、JP1/IMに対するジョブを実行するための内容が定義されています。ユーザーは、実行するジョブやシークレット情報など必要に応じて、カスタマイズします。
GitLabの以下の場所から、JP1/IMの連携テンプレートを取得します。systemリポジトリは、GitアプリケーションのExploreタブに表示されます。
| グループ | リポジトリ | ディレクトリ | ファイル名 |
|---|---|---|---|
| system | system | integration templates/JP1 | JP1_integration_templates.zip |
Ops I提供部品をワークフローから実行するため、以下の通りWorkflowのYAMLファイルのactionにOps I提供部品、inputにパラメータを定義します。パラメータにはそれぞれ「シークレットの作成」で作成したシークレット情報を定義します。シークレットは、常に最新のシークレットのバージョンのものを設定してください。
Ops I提供部品とパラメータの詳細については、「（表）actionのリスト（JP1/IM連携用Ops I提供部品）」を参照してください。
| ラベル | 説明 | |
|---|---|---|
| action: | 実行するJP1/IMのOps I提供部品 | |
| input: | 各パラメータに対して、「JP1/IMの接続情報・認証情報をシークレット管理へ保存」で設定した以下の値を入力します。 | |
| awx_vault_～ | "awx_vault_～"で始まるパラメータにAWXアクセス用のシークレットのSecrets Engines名とシークレットへのパスを定義します。 | |
| im_vault_～ | "im_vault_～"で始まるパラメータにJP1/IMのサーバアクセス用のシークレットのSecrets Engines名とシークレットへのパスを定義します。 | |
| job_template_～ | "job_template_～"で始まるパラメータにAWXのジョブテンプレートの情報を定義します。 | |
Ops I提供部品を定義したWorkflowのYAMLファイルと、取得したCatalog、UI、およびDatamodelのYAMLファイルを任意のリポジトリに登録します。リポジトリにはYAMLファイルの管理が有効である必要があります。リポジトリのYAMLファイルの管理については「リポジトリ管理」を参照してください。また、登録先のリポジトリのディレクトリは、取得したJP1/IMの連携テンプレートのフォルダ構成と同じである必要があります。リポジトリのディレクトリ構成について以下に示します。
登録するYAMLファイルには依存関係があります。すべてのYAMLファイルを同時にGitLabに登録する場合は、依存関係を意識する必要はありませんが、1つずつYAMLファイルを登録する場合、Script、Datamodel、UI、Workflow、Catalogの順番で登録してください。ここでの「登録」は、GUIでの操作ではcommit、CUIでの操作ではpushを指します。
（4）共通除外条件拡張定義ファイルの格納先
JP1/IMの連携テンプレート「共通除外条件拡張定義ファイル取得」実行時に取得したファイルの格納先を準備します。
定義ファイルの格納について推奨する内容を示します。
■ ユーザーグループ
- 定義ファイルを編集するため、リポジトリ管理画面を表示、操作できる以下のPre-Installedロールが割り当てられているユーザーが所属するグループであること。
・System Administrator
・Site Reliability Engineer - リポジトリ管理画面でリポジトリ一覧を表示するため、GitロールのMaintainerが割り当てられているユーザーグループであること。
- Ops Iが複数のシステムを管理していて複数のJP1/IMがある場合、適切なロールが割り当てられたユーザーグループ、リポジトリにそれぞれ格納する。
■ コンテナ名、コンテナアイテムフォルダ名、コンテナアイテムフォルダ内のディレクトリパス
- コンテナ名：JP1/IM
- コンテナアイテムフォルダ名：Common Exclusion Conditions File
- コンテナアイテムフォルダ内のディレクトリパス：JP1/IMのサーバごとにディレクトリを分ける
jp1im_B/common_exclude_filter.conf …
（5）中継サーバのプロキシ設定
中継サーバでプロキシを利用する場合、以下を実施してください。
【AWXのホストの修正】
---
ansible_connection: local
ansible_python_interpreter: '{{ ansible_playbook_python }}'
https_proxy: "{利用するプロキシのurl}"
【IPブロックの追加】
（6）連携テンプレートの実行と結果確認
「連携テンプレートの取得と登録」で登録したJP1/IMの連携テンプレートを、サービスカタログから実行します。実行ステップごとの詳細について以下に示します。
「共通除外条件拡張定義ファイルの取得と適用」を実行した場合を例として、実行ステップごとの詳細について以下に示します。入力情報および表示情報の詳細は「ワークフロー詳細画面の各入力項目」を参照してください。
| ステップ | 作業者 | 説明 | |
|---|---|---|---|
| 1 | サービスカタログ起動 | 申請者 | JP1/IMに対するジョブが定義されたカタログアイテムをクリックします。 |
| 2 | ワークフロー開始 | 申請者 | ワークフローのガイダンス画面が表示されます。内容を確認し、操作ボタンの「申請開始」をクリックします。 |
| 3 | 共通除外条件拡張定義ファイル格納場所の情報を入力 | 申請者 | ワークフローの申請画面より共通除外条件拡張定義ファイルの格納先を指定して、操作ボタンの「定義ファイル取得」をクリックします。 |
| 4 | 共通除外条件拡張定義ファイルを取得 | 自動実行 | JP1/IMから共通除外条件拡張定義ファイルを取得します。取得した定義ファイルは、指定したコンテナアイテムフォルダ内のパスに格納されます。 |
| 5 | 共通除外条件拡張定義ファイル更新 | 申請者 | 取得した共通除外条件拡張定義ファイルを更新します。詳細は「共通除外条件拡張定義ファイルの更新」を参照してください。 |
| 6 | 申請 | 申請者 | ワークフローの申請画面より、操作ボタンの「申請」をクリックします。 申請ボタンは共通除外条件拡張定義ファイル取得のステータスが「successful」で活性化します。 |
| 7 | 申請情報を確認 | 運用担当者 | 申請情報を確認し、確認結果に応じて操作ボタンの「確認完了」または、「却下」をクリックします。 |
| 8 | 申請情報の承認 | 運用管理者 | 申請情報を確認し、確認結果に応じて操作ボタンの「承認」または、「却下」をクリックします。 操作ボタンの「承認」がクリックされるとJP1/IMに対するジョブが自動実行され、更新した共通除外条件拡張定義ファイルが適用されます。 |
| 9 | ワークフロー終了後の確認 | 申請者 | ステップ1～8の内容をワークフロー操作画面で確認して、操作ボタンの「確認完了」をクリックします。 |
（7）共通除外条件拡張定義ファイルの更新
共通除外条件拡張定義ファイルは、監視抑止/抑止解除をjcochfilterコマンドで設定する際に使用するファイルです。ワークフロー実行で取得した共通除外条件拡張定義ファイルの更新例を以下に示します。
サーバのメンテナンス作業開始のため当該サーバの監視（イベント発生）を抑止したい場合、上図※内のdef～end-defの1ブロックを追加して、cnd（イベント条件）に当該サーバに一致する条件を記載します。
（8）ワークフロー詳細画面の各入力項目
ワークフローの詳細画面の各入力項目について説明します。この入力項目は、Ops I提供部品として提供されているパラメータが表示されます。各項目は、ステップによって表示や入力の可不可が切り替わります。
申請者入力項目について以下に示します。
| 項目 | 必須 | 説明 | |
|---|---|---|---|
| JP1/IMの接続情報 | Yes | 「JP1/IMの接続情報・認証情報をシークレット管理へ保存」の手順3.②で設定したJP1/IMのサーバアクセス用のシークレットへのパスを設定します。 | |
| 共通除外条件拡張定義ファイル格納場所 | － | 取得した共通除外条件拡張定義ファイルの格納場所を指定します。指定内容の詳細は「共通除外条件拡張定義ファイルの格納先」を参照してください。 | |
| グループパス | Yes | 格納先のグループパスを指定します。 | |
| リポジトリ | Yes | 格納先のリポジトリ名を指定します。 | |
| コンテナ名 | Yes | 格納先のコンテナ名を指定します。 | |
| コンテナアイテム名 | Yes | 格納先のコンテナアイテムフォルダ名を指定します。 | |
| ディレクトリパス | Yes | 格納先のコンテナアイテムフォルダ内のディレクトリパスを指定します。 | |
| ファイルURL | No | 申請者が定義ファイル取得ボタンをクリックした後、取得処理のステータスが「successful」になった場合に自動で入力されます。参照のみ可能な項目です。 | |
| 運用担当者・運用管理者宛てのコメント | No | 運用担当者および運用管理者宛てのコメントを入力します。 | |
その他の項目について以下に示します。
| 項目 | 必須 | 説明 | |
|---|---|---|---|
| 共通除外条件拡張定義ファイル取得 | － | 共通除外条件拡張定義ファイルの取得結果が表示されます。参照のみ可能な項目です。 | |
| ステータス | No | ステータスが表示されます。 | |
| 実行結果 | No | 実行結果が表示されます。 | |
| ジョブURL | No | ジョブURLが表示されます。 | |
| 差戻理由 | － | 運用担当者または運用管理者が差戻し理由を入力する項目です。 | |
| 差戻理由（運用担当者） | No | 運用担当者が差戻し理由を入力します。 | |
| 差戻理由（運用管理者） | No | 運用管理者が差戻し理由を入力します。 | |
| 共通除外条件拡張定義ファイル適用 | － | 共通除外条件拡張定義ファイルの適用結果が表示されます。参照のみ可能な項目です。 | |
| ステータス | No | ステータスが表示されます。 | |
| 実行結果 | No | 実行結果が表示されます。 | |
| ジョブURL | No | ジョブURLが表示されます。 | |