##はじめに
Exastro IT Automation(以下ITA)には、システムから設定値やファイルを取得してくる「収集機能」というものがあり、最近リリースされたv1.7.0では収集した値を比較できる「比較機能」が追加されたようです。
設計した値がちゃんと機器に設定されているか確認するのに便利そうなので、やってみました。
##収集機能・比較機能とは
収集機能とは、ITAで行った作業の実行結果となるインベントリ(YAMLファイルとして出力されたソースファイル)をシステムから取得し、その値をITAのパラメータシートへ自動登録できる機能です。
収集の流れとしては以下の図のようになります。
① ITAから自動化ソフトウェア(※1)を介して、作業対象システムのインベントリを取得する。
② あらかじめ設定しておいたインベントリとパラメータシートとの紐付けをもとに、ITAのパラメータシートへ収集した値が自動登録される。
※1 現在はAnsibleのみ連携可能ですが、将来的には他の自動化ソフトウェアとも連携する予定らしいです。
比較機能は、収集機能と合わせると以下のような活用ができます。
③ 期待値と実機から取得した値を比較する。
④ 取得した値同士を比較する。過去のある時点での値と、現在の値など。
##今回紹介するシナリオ
今回は以下4つのシナリオを紹介します。
収集機能は、パラメータ取得とファイル取得の2パターン。
比較機能は、取得したパラメータとファイルをそれぞれ別のデータと比較してみます。
- 【収集機能】パラメータ取得:ターゲットホストのOS情報を取得する
- 【収集機能】ファイル取得:ターゲットホストからSSL証明書を取得する
- 【比較機能】OS情報パラメータの比較
- 【比較機能】SSL証明書の比較
##作業手順
操作手順を案内していく前に、少しだけITAのUIについて説明します。
ITA画面は、まずログインして最初に下図のダッシュボードが表示されます。
そこにはボタンがいくつか表示されていますが、それぞれを「メニューグループ」と言います。
今回操作するメニューグループは、赤枠で囲ったものになります。
そして メニューグループ >> メニュー という階層になっており、メニューグループの下にいくつかメニューが格納されています。
例えば「基本コンソール」メニューグループだとこんな感じ。
「機器一覧」「オペレーション一覧」「Movement一覧」「ER図表示」のメニューが格納されていますね。ここから様々な操作を行っていきます。
今回紹介する操作手順では、 1.1 基本コンソール >> 機器一覧 というように、操作するメニューを示していきます。
また、メニューの中はこんな感じになっています(メニューによって異なります)。
頻出するのは**「登録」で、ここから各種データを登録したり、データ同士を紐付けたりしていきます。また「フィルタ」ボタンを押すと「一覧/更新」**に登録済みデータ一覧が表示されます。
…ただ、実際に操作していくと、いま自分が何のデータを登録しているのか、何と何を紐付けているのかなど、迷子になってしまうことも出てきます。
そんな時は 基本コンソール >> ER図表示 が役に立ちます。v1.7.0で新しく搭載された機能で、各メニューグループ・メニューの相関関係が示されます。
こんなふうに、紐づけが可視化されています。マウスオーバーすると、そのメニューの紐付けがオレンジになります。
紐付け関係がわからなくなってしまったら、これを見れば大丈夫そうです。
それではシナリオ1から説明していきます。
1. 【収集機能】パラメータ取得:ターゲットホストのOS情報を取得する
1.1 基本コンソール >> 機器一覧
まずはターゲットホストの接続情報を登録します。
登録画面はこのようになっているので、赤枠内の必須項目を入力。下表には今回設定した内容を書いています。
※ Ansible Towerは今回使いませんが、接続タイプは必須項目なのでデフォルトで入っています。
HW機器種別 | ホスト名 | IPアドレス | ログインユーザID | ログインパスワード > 管理 |
ログインパスワード > ログインパスワード |
Ansible利用情報 > Legacy/Role利用情報 >認証方式 |
---|---|---|---|---|---|---|
SV | targethost | 198.51.100.1 | root | ● | ******** | パスワード認証 |
1.2 基本コンソール >> オペレーション一覧
今回のオペレーションを登録します。
オペレーションは、ITAの自動作業一式を指します。これに、のちのち関連するすべてのデータを紐付けていきます。
今回は、後述しますがPlaybookのファイル名がGatherFacts.ymlなので、オペレーション名はGatherFacts1としました。
オペレーション名(任意の名称) | 実施予定日時(任意の時間)(※) |
---|---|
GatherFacts1 | 2021/04/22 17:09 |
※ 実施予定時間は情報として入力できるようになっているもので、タイマーではありません。 |
1.3 Ansible-Legacy >> Movement一覧
Ansible-LegacyのMovementを登録します。
Movementとは、ITAの自動作業の最小単位で、ジョブを表します。
今回はこのあとPlaybookに紐付けて、OS情報を収集するMovementとなります。
Movement名(任意の名称) | Ansible利用情報 > ホスト指定形式(プルダウンから選択) | Ansible利用情報 > ヘッダーセクション |
---|---|---|
GatherFacts | IP | (※) |
※ ヘッダーセクションには以下を入力
- hosts: all
remote_user: "{{ __loginuser__ }}"
gather_facts: yes
become: yes
ヘッダーセクションについて
ITAは、デフォルトではこのようなヘッダーセクションがついています。 ![20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/794820/1ed6747f-be3e-5a52-0412-95ae8e949ade.png) デフォルト値を変更する必要がない場合は、わざわざ入力する必要はなく空欄で良いのですが、今回はgather_factsを使ってOS情報を取得しようとしているため、 **gather_facts: no →gather_facts: yes** にしておく必要があります。1.4 Ansible-Legacy >> Playbook素材集
Playbookを登録します。
今回はこちらのPlaybookを使用しました。
YAMLファイルを生成し、OS情報を取得してくるという内容です。
- name: make yaml file
blockinfile:
create: yes
mode: 644
insertbefore: EOF
marker: ""
dest: "{{ __parameter_dir__ }}/{{ inventory_hostname }}/gatherfacts.yml"
content: |
ansible_architecture : {{ ansible_architecture }}
ansible_bios_version : {{ ansible_bios_version }}
ansible_default_ipv4__address : {{ ansible_default_ipv4.address }}
ansible_default_ipv4__interface : {{ ansible_default_ipv4.interface }}
ansible_default_ipv4__network : {{ ansible_default_ipv4.network }}
ansible_distribution : {{ ansible_distribution }}
ansible_distribution_file_path : {{ ansible_distribution_file_path }}
ansible_distribution_file_variety : {{ ansible_distribution_file_variety }}
ansible_distribution_major_version: {{ ansible_distribution_major_version }}
ansible_distribution_release : {{ ansible_distribution_release }}
ansible_distribution_version : {{ ansible_distribution_version }}
ansible_machine : {{ ansible_machine }}
ansible_memtotal_mb : {{ ansible_memtotal_mb }}
ansible_nodename : {{ ansible_nodename }}
ansible_os_family : {{ ansible_os_family }}
ansible_pkg_mgr : {{ ansible_pkg_mgr }}
ansible_processor_cores : {{ ansible_processor_cores }}
delegate_to: 127.0.0.1
なぜYAMLファイル?
ITAでは、収集結果ファイルはYAML形式に指定されているようです。そのためYAMLファイルを生成する必要があります。
また生成されたYAMLファイルは、以下の収集用のディレクトリに格納することになっています。
Playbookが用意できたら、登録画面から以下を入力します。
Playbook素材名(任意の名称) | Playbook素材 |
---|---|
GatherFacts | GatherFacts.yml |
1.5 Ansible-Legacy >> Movement-Playbook紐付
それでは登録したMovementとPlaybookを紐付けます。
Movement(プルダウンから選択) | Playbook素材(プルダウンから選択) | インクルード順序 |
---|---|---|
1:GatherFacts | GatherFacts | 1(※) |
※ インクルード順序とは、複数のPlaybookをMovementに紐付けた際に作業実行される順番です。今回は1つだけなので1とします。
1.6 Ansible-Legacy >> 作業対象ホスト
登録したオペレーション・Movement・作業対象ホストを紐付けます。
オペレーション(プルダウンから選択) | Movement(プルダウンから選択) | ホスト(プルダウンから選択) |
---|---|---|
1:GatherFacts1 | 1:GatherFacts | targethost |
これで、このオペレーションではどのホストへ何(Movement)を行う、ということが紐付きました。
1.7 メニュー作成 >> メニュー定義・作成
それでは、収集してきた値の受け皿となるパラメータシートを作成していきます。
「入力用」「代入値自動登録用」「参照用」メニューグループの中に「Gathered Facts」メニューを作成します。このメニューの中に「パラメータシート」の欄ができ、さらにその中の各項目に取得した値が入ります。
初めに説明した メニューグループ >> メニュー を自分で作るというわけです(「入力用」「代入値自動登録用」「参照用」メニューグループはデフォルトであるので、メニューだけ)。
メニュー定義・作成の画面は他のメニューと違ってこのようなGUIになっており、①基本情報・②対象メニューグループ・③項目の3つのエリアに必要な情報を入力するようになっています。
それでは入力していきます。
①基本情報は以下の3か所。
メニュー名(任意の名称) | 作成対象(プルダウンから選択) | 表示順序(※) |
---|---|---|
Gathered Facts | パラメータシート(ホスト/オペレーションあり) | 1 |
※ 表示順序はメニューグループ内のメニューの上から何番目に表示されるかを示します。
②対象メニューグループは作成したメニューが所属するメニューグループを指定するものですが、今回はデフォルト値にしておきます。
対象メニューグループの詳細はこちら
入力用 | 代入値自動登録用 | 参照用 |
---|---|---|
入力用 | 代入値自動登録用 | 参照用 |
今回はPlaybookの変数が17個あるので、これを17個作ります。左上の「項目」ボタンを押すと新規項目が作成されます。
なお、項目名はPlaybookの変数名に対応しているとわかりやすいです。
項目名(任意の名称) | 入力方式 | 最大バイト数(任意の値) |
---|---|---|
ansible_architecture | 文字列(単一行) | 128 |
ansible_bios_version | 文字列(単一行) | 128 |
ansible_default_ipv4 > address(※) | 文字列(単一行) | 128 |
ansible_default_ipv4 > interface(※) | 文字列(単一行) | 128 |
ansible_default_ipv4 > network(※) | 文字列(単一行) | 128 |
ansible_distribution | 文字列(単一行) | 128 |
ansible_distribution_file_path | 文字列(単一行) | 128 |
ansible_distribution_file_variety | 文字列(単一行) | 128 |
ansible_distribution_major_version | 文字列(単一行) | 128 |
ansible_distribution_release | 文字列(単一行) | 128 |
ansible_distribution_version | 文字列(単一行) | 128 |
ansible_machine | 文字列(単一行) | 128 |
ansible_memtotal_mb | 文字列(単一行) | 128 |
ansible_nodename | 文字列(単一行) | 128 |
ansible_os_family | 文字列(単一行) | 128 |
ansible_pkg_mgr | 文字列(単一行) | 128 |
ansible_processor_cores | 文字列(単一行) | 128 |
※ ansible_default_ipv4というグループを作り、その中にこの3項目を入れ込みます。
全部入力したらこんな感じで、項目がずらっと並んだ形になります。
OKなら作成ボタンを押します。
これで「入力用」「代入値自動登録用」「参照用」メニューグループの中に「Gathered Facts」メニュー(パラメータシート)が作成できました!
登録開始ボタンを押して、たくさん作った項目もきちんと出来ているか確認。
1.8 Ansible共通 >> 収集項目値管理
収集項目値管理では、収集項目(FROM)であるYAMLファイル名・変数名と、パラメータシート(TO)であるメニュグループ名・メニュー名・項目名を紐付けます。
入力する箇所はこちら。
収集項目(FROM)
パース形式(プルダウンから選択) | PREFIX(ファイル名) | 変数名 |
---|---|---|
YAML | gatherfacts | ※1 |
パラメータシート(TO)
メニューグループ:メニュー(プルダウンから選択) | 項目(プルダウンから選択) |
---|---|
代入値自動登録用:2:Gathered Facts | ※2 |
今回は変数が17個あるので、17個分登録します。下表のように、※1と※2を対応させます。
※1(変数名) | ※2(項目名) |
---|---|
ansible_architecture | パラメータ/ansible_architecture |
ansible_bios_version | パラメータ/ansible_bios_version |
ansible_default_ipv4__address | パラメータ/ansible_default_ipv4/address |
ansible_default_ipv4__interface | パラメータ/ansible_default_ipv4/interface |
ansible_default_ipv4__network | パラメータ/ansible_default_ipv4/network |
ansible_distribution | パラメータ/ansible_distribution |
ansible_distribution_file_path | パラメータ/ansible_distribution_file_path |
ansible_distribution_file_variety | パラメータ/ansible_distribution_file_variety |
ansible_distribution_major_version | パラメータ/ansible_distribution_major_version |
ansible_distribution_release | パラメータ/ansible_distribution_release |
ansible_distribution_version | パラメータ/ansible_distribution_version |
ansible_machine | パラメータ/ansible_machine |
ansible_memtotal_mb | パラメータ/ansible_memtotal_mb |
ansible_nodename | パラメータ/ansible_nodename |
ansible_os_family | パラメータ/ansible_os_family |
ansible_pkg_mgr | パラメータ/ansible_pkg_mgr |
ansible_processor_cores | パラメータ/ansible_processor_cores |
1.9 Ansible共通 >> 収集インターフェース情報
収集してきた値をITAのCMDBに登録する際のRESTAPIアクセスで必要になるため、RESTユーザー/パスワードを実行権限のあるユーザーで登録します。
「フィルタ」を押すと一覧で1行だけ表示されるので、その更新ボタンを押して以下の箇所を書き換えます。
今回はITAにadministratorでログインしており実行権限があるので、RESTユーザー:administratorでそのパスワードを入れています。
RESTユーザー | RESTパスワード |
---|---|
実行権限のあるユーザー | そのユーザーのパスワード |
更新ボタンを押します。
1.10 Ansible-Legacy >> 作業実行
登録したMovementとオペレーションを選択します。これですべての情報の紐付け完了です。
それでは実行ボタンを押してみます。
ちなみに…
Ansible-Legacy >> 作業管理 からも収集結果が確認できます。
「収集状況」という項目があるので、成功していればステータスが「収集済み」、失敗していれば「対象外」と表示されます。
1.11 入力用(参照用でもOK) >> Gathered Facts
値が収集されているか確認します。
「フィルタ」を押して一覧を表示し、該当パラメータを確認。
うまく収集できていれば成功です!
2. 【収集機能】ファイル取得:ターゲットホストからSSL証明書を取得する
ファイル取得も、流れとしてはパラメータ取得と同じで下図のようになります。
今回は事前にターゲットホストにtest.crtを置いておいたので、それを取得してきます。
2.1 基本コンソール >> 機器一覧
今回は1.1と同じターゲットホストになるので、このままでOKです。
2.2 基本コンソール >> オペレーション一覧
今回のオペレーションを登録します。
オペレーション名(任意の名称) | 実施予定日時(任意の時間)(※) |
---|---|
getSSL1 | 2021/04/23 17:10 |
※ 実施予定時間は情報として入力できるようになっているもので、タイマーではありません。
2.3 Ansible-Legacy >> Movement一覧
Movementを登録します。
この後Playbookに紐付けることで、SSL証明書を取得してくるジョブとなります。
Movement名(任意の名称) | Ansible利用情報 > ホスト指定形式 |
---|---|
getSSL | IP |
2.4 Ansible-Legacy >> Playbook素材集
Playbookを登録します。
今回はこちらのPlaybookを使用しました。
SSL証明書ファイル取得のためのYAMLファイルを作成 → SSL証明書ファイルを収集ディレクトリにコピーする という内容です。
- name: make yaml file
blockinfile:
create: yes
mode: 644
insertbefore: EOF
marker: ""
dest: "{{ __parameter_dir__ }}/{{ inventory_hostname }}/getSSL.yml"
content: |
SSL_file_name : {{ VAR_ssl_name }}
SSL_file : {{ VAR_ssl_name }}
delegate_to: 127.0.0.1
- name: get SSL file
fetch:
src: /etc/pki/tls/certs/{{ VAR_ssl_name }}
dest: "{{ __parameters_file_dir__ }}/{{ inventory_hostname }}/"
flat: yes
収集されたSSL証明書は、以下のディレクトリに格納されます。
Playbookが用意できたら、以下を登録します。
Playbook素材名(任意の名称) | Playbook素材 |
---|---|
getSSL | getSSL.yml |
2.5 Ansible-Legacy >> Movement-Playbook紐付
登録したMovementとPlaybookを紐付けます。
Movement(プルダウンから選択) | Playbook素材(プルダウンから選択) | インクルード順序 |
---|---|---|
2:getSSL | getSSL | 1(※) |
※ インクルード順序とは、複数のPlaybookをMovementに紐付けた際に作業実行される順番です。今回は1つだけなので1とします。
2.6 Ansible-Legacy >> 代入値自動登録設定
次に、Playbook内の変数(VAR_ssl_name)に具体値(test.crt)を代入します。
直接値を打ち込む方法とパラメータシートの値を代入する方法の2パターンあるようですが、今回は後者にします。
こちらのパラメータを仕込んでおきました。
~~~~~
メニュー作成 >> メニュー定義・作成
以下を入力してメニューを作成(メニュー作成の詳細は1.7や2.7を参照ください)。
※デフォルトのままで良い値は割愛しています。
メニュー名(任意の名称) | 表示順序 | 項目名(任意の名称) | 最大バイト数 |
---|---|---|---|
SSL証明書名 | 4 | ファイル名 | 128 |
入力用 >>SSL証明書名
作成したメニューへ。これがパラメータシートとなります。
ホスト名とオペレーションを選択し、ファイル名にtest.crtと入力。
ホスト名(プルダウンから選択) | オペレーション | パラメータ > ファイル名 |
---|---|---|
targethost | getSSL1 | test.crt |
~~~~~ |
さて、仕込ができたら、Ansible-Legacy >> 代入値自動登録設定 に行き、パラメータシートの項目名とPlaybookの変数、Movementを紐づけます。
パラメータシート(From) > メニューグループ:メニュー | パラメータシート(From) > 項目名 | 登録方式 | IaC変数(To) > Movement | IaC変数(To) > Value変数 > 変数名 |
---|---|---|---|---|
代入値自動登録用:SSL証明書名 | パラメータ/ファイル名 | Value型 | getSSL | VAR_ssl_name |
(すべてプルダウンから選択)
これで、VAR_ssl_nameとtest.crtがつながりました。
2.7 メニュー作成 >> メニュー定義・作成
それでは、1のシナリオ同様、収集した値の受け皿となるパラメータシートを作っていきます。
「入力用」「代入値自動登録用」「参照用」メニューグループの中に「SSL証明書」メニューを作成します。このメニューからSSL証明書がダウンロードできるようになります。
メニュー作成画面はこのようになっており、①基本情報・②対象メニューグループ・③項目の3つのエリアに必要な情報を入力します。
①基本情報は以下の3か所を入力。
メニュー名(任意の名称) | 作成対象(プルダウンから選択) | 表示順序(※) |
---|---|---|
SSL証明書 | パラメータシート(ホスト/オペレーションあり) | 2 |
※ 表示順序はメニューグループ内のメニューの上から何番目に表示されるかを示します。
②対象メニューグループは作成したメニューが所属するメニューグループを指定するものですが、今回はデフォルト値にしておきます。
入力用 | 代入値自動登録用 | 参照用 |
---|---|---|
入力用 | 代入値自動登録用 | 参照用 |
項目名(任意の名称) | 入力方式(プルダウンから選択) | 最大バイト数(任意の値) |
---|---|---|
ファイル名 | 文字列(単一行) | 128 |
ファイル | ファイルアップロード | 1000000 |
これで「入力用」メニューグループの中に「SSL証明書」メニュー(パラメータシート)が作成できました。
2.8 Ansible共通 >> 収集項目値管理
収集項目値管理では、収集項目(FROM)であるYAMLファイル名・変数名と、パラメータシート(TO)であるメニュグループ名・メニュー名・項目名を紐付けます。
収集項目(FROM)
パース形式(プルダウンから選択) | PREFIX(ファイル名) | 変数名 |
---|---|---|
YAML | getSSL | ※1 |
パラメータシート(TO)
メニューグループ:メニュー(プルダウンから選択) | 項目(プルダウンから選択) |
---|---|
代入値自動登録用:5:SSL証明書 | ※2 |
今回は変数が2個あるので、2個分登録します。下表のように、※1と※2を対応させます。
※1(変数名) | ※2(項目名) |
---|---|
SSL_file_name | パラメータ/ファイル名 |
SSL_file | パラメータ/ファイル |
2.9 Ansible共通 >> 収集インターフェース情報
収集してきた値をITAのCMDBに登録する際のRESTAPIアクセスで必要になるため、RESTユーザー/パスワードを実行権限のあるユーザーで登録します。
「フィルタ」を押すと一覧で1行だけ表示されるので、その更新ボタンを押して以下の箇所を書き換えます。
今回はITAにadministratorでログインしており実行権限があるので、RESTユーザー:administratorでそのパスワードを入れています。
RESTユーザー | RESTパスワード |
---|---|
実行権限のあるユーザー | そのユーザーのパスワード |
更新ボタンを押します。
2.10 Ansible-Legacy >> 作業実行
登録したMovementとオペレーションを選択します。これですべての情報の紐付け完了です。
それでは実行ボタンを押してみます。
作業状態確認で、ステータスが完了になれば作業完了です。
2.11 入力用 >> SSL証明書
値が収集されているか確認します。
「フィルタ」を押して一覧を表示し、該当パラメータを確認。
パラメータに値が収集され、SSL証明書(test.crt)がダウンロードできれば成功です!
3. 【比較機能】OS情報パラメータの比較
それでは比較をやってみます。
ITAに期待値を設定し、GatherFactsで収集した値と比較してみます。
3.1 基本コンソール >> オペレーション一覧
期待値となるオペレーションを登録します。
オペレーション名(任意の名称) | 実施予定日時(任意の時間) |
---|---|
GatherFacts101 | 2021/10/01 09:25 |
3.2 メニュー作成 >> メニュー定義一覧
Gathered Factsと全く同じメニューを作成し、「メニュー名」「表示順序」だけ変えます。
Gathered Factsを複製して一部変更していきます。
まず一覧のGathered Factsの「メニュー定義・作成」を押す。
「メニュー名」「表示順序」だけ空の状態で複製されるので、そこだけ入力。
表示順序は何番でもよいですが、今回はシナリオ順に従って3にしておきます。
メニュー名(任意の名称) | 表示順序 |
---|---|
OS情報 | 3 |
3.3 入力用 >> OS情報
それでは作成した「OS情報」メニューに値を入力します。
今回はaddressだけわざと違う値を入力しておきます。
パラメータ | 値 |
---|---|
ansible_architecture | x86_64 |
ansible_bios_version | 1.11.0-2.el7 |
ansible_default_ipv4__address | 198.51.100.2 |
ansible_default_ipv4__interface | eth0 |
ansible_default_ipv4__network | 198.51.100.0 |
ansible_distribution | CentOS |
ansible_distribution_file_path | /etc/redhat-release |
ansible_distribution_file_variety | RedHat |
ansible_distribution_major_version | 7 |
ansible_distribution_release | Core |
ansible_distribution_version | 7.8 |
ansible_machine | x86_64 |
ansible_memtotal_mb | 1771 |
ansible_nodename | abcd.localdomain |
ansible_os_family | RedHat |
ansible_pkg_mgr | yum |
ansible_processor_cores | 1 |
全部入力したら登録を押します。
3.4 比較 >> 比較定義
比較定義では、比較対象となる2つのメニューを選びます。今回は「Gathered Facts」と「OS情報」になります。
以下を入力します。
「全件一致」はパラメータシートの全項目を比較するという意味です。
★部分一致はこのシナリオの最後のTIPSで紹介しています!
比較定義名(任意の名称) | 比較対象メニュー1(プルダウンから選択) | 比較対象メニュー2(プルダウンから選択) | 全件一致(プルダウンから選択) |
---|---|---|---|
OS情報 | 代入値自動登録用:8:OS情報 | 代入値自動登録用:2:Gathered Facts | ● |
3.5 比較 >> 比較実行
それでは比較を実行します。
先ほど登録した「OS情報」の比較定義を選択し、比較ボタンを押します。
「基準日」とは、同じ比較定義を取得した日で比較するものなので、ここでは空白にしておきます。
すると、addressの値だけ赤色で出力され、差分有りということがわかります。
これで期待値と収集した値との比較が成功しました!
~TIPS~ 項目限定比較
以上はパラメータシートの項目すべてを比較する方法をご説明しましたが、項目を限定して比較する方法もあるようなのでご紹介します。
#####~TIPS~1 比較 >> 比較定義
比較対象となる2つのメニューを登録し、比較定義名を付けます。
ここでは「IPアドレス」としました。
「全件一致」は●を付けません。
比較定義名(任意の名称) | 比較対象メニュー1(プルダウンから選択) | 比較対象メニュー2(プルダウンから選択) | 全件一致(プルダウンから選択) |
---|---|---|---|
IPアドレス | 代入値自動登録用:2:Gathered Facts | 代入値自動登録用:8:OS情報 | - |
#####~TIPS~2 比較 >> 比較定義詳細
「対象カラム」で比較対象となる2つのメニュー項目を指定します。
比較定義名(プルダウンから選択) | 表示項目名(任意の名称) | 対象カラム1(プルダウンから選択) | 対象カラム2(プルダウンから選択) | 表示順 |
---|---|---|---|---|
IPアドレス [ 2:Gathered Facts-8:OS情報 ] | IPアドレス | 代入値自動登録用:2:Gathered Facts:3:パラメータ/ansible_default_ipv4/address | 代入値自動登録用:8:OS情報:33:パラメータ/ansible_default_ipv4/address | 1 |
#####~TIPS~3 比較 >> 比較実行
それでは比較を実行してみます。
先ほど登録した比較定義名「IPアドレス」を選択し、基準日は空白のまま比較ボタンを押します。
指定した項目だけ比較できていれば、成功です!
4. 【比較機能】SSL証明書の比較
では最後に、収集日が異なり内容に差分のあるSSL証明書同士を比較してみます。
なおITAの比較メニューグループでは今のところ、差分の有無だけわかるようになっており、具体的な差分箇所の表示まではできないようです。
4.1 基本コンソール >> オペレーション一覧
比較用のオペレーションを作成します。
オペレーション名(任意の名称) | 実施予定日時(任意の時間) |
---|---|
getSSL2 | 2021/04/28 12:19 |
4.2 内容の違うSSL証明書を用意しておく
今回は差分有りのファイルを用意したいので、Teratermでターゲットサーバの/etc/pki/tls/certs/に入り、SSL証明書(test.crt)の中身を一部書き換えておきました。
4.3 入力用 >>SSL証明書名
2.6と同様。オペレーションだけ比較用のgetSSL2にします。
ホスト名(プルダウンから選択) | オペレーション | パラメータ > ファイル名 |
---|---|---|
targethost | getSSL2 | test.crt |
4.4 Ansible-Legacy >> 作業実行
差分有りのSSL証明書を収集します。
Movementはシナリオ2と同じくgetSSLで、オペレーションだけ比較用のgetSSL2にします。
Movement(プルダウンから選択) | Operation(プルダウンから選択) |
---|---|
getSSL | getSSL2 |
実行ボタンを押して、収集。 |
4.5 入力用 >> SSL証明書
レコードが収集されているか確認します。
また、今回は基準日時(収集した日時)ベースで比較を行うので、基準日時を確認しておきます。
4.6 比較 >> 比較定義
比較定義では、比較対象となる2つのメニューを選びます。今回は両方とも「SSL証明書」になります。
比較定義名(任意の名称) | 比較対象メニュー1(プルダウンから選択) | 比較対象メニュー2(プルダウンから選択) | 全件一致(プルダウンから選択) |
---|---|---|---|
SSL証明書 | 代入値自動登録用:5:SSL証明書 | 代入値自動登録用:5:SSL証明書 | ● |
4.7 比較 >> 比較実行
それでは比較を実行します。
先ほど登録した「SSL証明書」の比較定義を選択し、比較対象となる2つの基準日時を入力します。
今回は以下の基準日時になっていたので、
getSSL1:2021/4/22 14:24
getSSL2:2021/4/22 14:32
この時点で収集されたファイルが反映されているであろう、以下の日時で比較してみます。
比較定義(プルダウンから選択) | 基準日1 | 基準日2 |
---|---|---|
SSL証明書 | 2021/4/22 14:30 | 2021/4/22 15:00 |
収集した時点と比較する時点は図にするとこのようになります。
入力したら比較ボタンを押します。
すると、「パラメータ/ファイル」が赤色で出力され、差分有りということがわかります。
これでファイル同士の比較ができました!
###補足:Conductorについて
今回はMovementひとつだけだったので、Ansible-Legacyの「作業実行」からMovement(ジョブ)を直接実行しましたが、ITAにはConductorというジョブフロー機能が搭載されており、これだと複数のMovementをつなげて実行することができるようです。他のMovementと連動させてより複雑な作業実行をしたい場合は、こちらを使えば良さそうです。
詳しくはExastroコミュニティサイトのこちらに載っています。
##収集比較機能の応用例
実作業では、活用できるシーンが色々とありそうです。
たとえば、Network機器のshow running-configコマンド結果をファイルで取ってくる、AWSでEC2リストを取ってくるなど。いちいち手作業でやる必要がないので、作業の効率化やミスの防止にもつながりそうです。
比較機能では、作業実行の前後で期待値と実際の値(実機から取得した値)を比較することで、 作業前には「変更したい箇所」だけが差分で現れること/作業後には差分があらわれないこと を比較してチェックする、といった使い方も出来そうです。
##関連リンク