■ はじめに
Ansible のターゲットホストの情報を定義するインベントリファイルは、INI 形式の他にも YAML 形式でも定義できす。
この記事では、2つの例をとって ini と YAML を比較しながら YAML でのインベントリファイルの書き方を説明します。
- 動作確認環境
- Ansible 2.7.8, 2.3.0
■ 簡単な例
はずは簡単な例です。1つのグループに2つのホストが所属し、ホスト個別の変数、グループ共通の変数を定義します。
ini の場合
ini で書く場合は以下のような例です。
[junos] junos01 ansible_host=172.16.1.1 junos02 ansible_host=172.16.1.2 [junos:vars] ansible_network_os=junos ansible_connection=netconf
ansible-inventory コマンドの --graph オプションでは、グループとホストの関係が以下のように表示さます。
$ ansible-inventory -i inventory01.ini --graph @all: |--@junos: | |--junos01 | |--junos02 |--@ungrouped:
YAML の場合
YAML で書く場合は以下のようになります。
all: children: junos: # junos グループ hosts: # junos グループのホスト junos01: ansible_host: 172.16.1.1 # ホスト変数 junos02: ansible_host: 172.16.1.2 # ホスト変数 vars: # junos グループ変数 ansible_network_os: junos ansible_connection: netconf
以下のような特徴があります。
- すべてのホストや、グループが暗黙的に所属する
allグループをトップに定義する - グループの定義の配下には、所属させたいホストを
hosts、所属させたい子グループをchildrenで定義する - ホスト変数は、ホスト名配下に定義する
- グループ変数は
vars配下に定義する
対応
■ 少し複雑な例
次に、簡単な例にもうひと工夫した少し複雑な例です。
先ほどとは、junos という一つのグループのみでしたが、同じレベルに ios グループを加えます。さらにこれら2つのグループの親グループ router も定義します。
別途、どのグループにも所属しないホスト web01 も定義します。
ini の場合
ini で書く場合は以下のような例です。
web01 ansible_host=127.16.0.1 [router:children] junos ios [junos] junos01 ansible_host=172.16.1.1 junos02 ansible_host=172.16.1.2 [junos:vars] ansible_network_os=junos ansible_connection=netconf [ios] ios01 ansible_host=172.16.2.1 ios02 ansible_host=172.16.2.22 [ios:vars] ansible_network_os=ios ansible_connection=network_cli
ansible-inventory コマンドの --graph オプションでは、グループとホストの関係が以下のように表示さます。
$ ansible-inventory -i inventory02.ini --graph @all: |--@router: | |--@ios: | | |--ios01 | | |--ios02 | |--@junos: | | |--junos01 | | |--junos02 |--@ungrouped: | |--web01
YAML の場合
YAML で書く場合は以下のようになります。
all: hosts: # グループに所属しないホストの情報（ungroupedグループ所属と同義） web01: # ホスト web01 ansible_host: 172.16.0.1 # ホスト変数 children: router: # router グループ children: junos: # junos グループ（routerの子グループ） hosts: # junos グループのホスト junos01: ansible_host: 172.16.1.1 # ホスト変数 junos02: ansible_host: 172.16.1.2 # ホスト変数 vars: # junos グループの変数 ansible_network_os: junos ansible_connection: netconf ios: # ios グループ（routerの子グループ） hosts: # ios グループのホスト ios01: ansible_host: 172.16.2.1 # ホスト変数 ios02: ansible_host: 172.16.2.2 # ホスト変数 vars: # ios グループの変数 ansible_network_os: ios ansible_connection: network_cli
前述の簡単な例に加えて、以下のような特徴があります。
- どのグループに所属しない（
ungrouped）ホストは、all配下のhostsに定義する routerグループの配下に子グループjunosとiosを定義する
■ 補足
注意点: 型判定が微妙に異なる
変数の値の型判定が ini と YAML で異なります。
例えば、ini 内の True は真偽値と判定されますが、 true も文字列です。一方で、YAML 内では True も true も真偽値です。パース処理に違いによるものです。
どちらが良いか
Ansible としては、YAML のイベントリファイルのほうが新しい機能です。 既存の ini のイベントリファルがあるのであれば、無理に YAML に移行する必要も無いと思います。Playbook も インベントリも YAML に統一したい、という事情がある場合は YAML に移行することを検討されるのがよいのではないでしょうか。
また、イベントリファル内で、複雑な変数（リストやディクショナリなど）を定義したい場合は YAML の方が適しています。
既存の ini のイベントリファイルを YAML にした場合の雰囲気を掴むには
既存の ini のイベントリファルがあって、それを YMAL で書く場合の雰囲気を掴むには以下のコマンドを利用できます。
ansible-inventory -i インベントリファイル名 --list --yaml
例えば以下の ini のイベントリファルがあったとします。
[junos] junos01 ansible_host=172.16.1.1 junos02 ansible_host=172.16.1.2 [junos:vars] ansible_network_os=junos ansible_connection=netconf
出力結果は以下のようになります。
all: children: junos: hosts: junos01: ansible_connection: netconf ansible_host: 172.16.1.1 ansible_network_os: junos junos02: ansible_connection: netconf ansible_host: 172.16.1.2 ansible_network_os: junos ungrouped: {}
厳密には、インベントリファイルの形式変換用のコマンドではなく、インベントリファイルを解析して、各ホストにどのような変数が適用されるかなどを確認するコマンドです。例えばグループ変数は、実際に所属するホストの変数に展開されて表示されます。
ini と YAML 間の一致を確認する方法
ini から YAML に以降した場合、正しく書き換えできたかが気になると思います。その場合は、以下の2コマンドの出力結果が同じであることを確認します。
ansible-inventory -i iniのインベントリファイル名 --listansible-inventory -i YAMLのインベントリファイル名 --list
お好みで --yaml オプションを加えても大丈夫です。
■ まとめ
YAML 形式のインベントリファイルの書き方をご紹介しました。必要に応じて使い分けるときの参考にしていただければ幸いです。
