Ansibleのグローバルスコープの変数をどこに定義するか

はじめに

Ansible の勉強をする中で、あまりにも変数を定義出来る箇所が多いので驚きました。ざっと数えても 20 パターンあるけど、あまり纏まった情報も見つからない…。

そこで、基盤構築のケースに応じた Ansible 変数定義のベストプラクティスを個人的に纏めていこうと思います。

今回は、「全ノード、全プレイブック共通のグローバルな変数を定義する箇所」に焦点を当てて紹介します。

前提

Ansible の利用ケース

個人で利用、というよりは数人以上のチームで利用する場合に焦点を当てています。
なので、個人で利用する場合には「そこまで縛らなくても…」と感じられる内容かもしれません。

ディレクトリ構成

当記事のAnsibleのディレクトリ構成は、公式のベストプラクティスのディレクトリレイアウトに沿う構成を前提に話を進めていきます。

実行環境

Windows端末上に Vagrantで CentOS を立ち上げ、localhost に対して Ansible を実行しています。

Software	Version
Windows	10(1709)
VirtualBox	5.2.4
Vagrant	2.0.1
CentOS	bento/centos-7.2
Ansible	2.3.0.1
Python	2.7.5

Ansible におけるグローバル変数

Ansible における変数スコープ

参考までに、Ansible には、3パターンの変数スコープがあります。以下に、Ansible実践ガイドから引用させて頂きます。

• Global :
  Ansible の実行全体に対して定義。プレイブックのどこからも参照できる。環境変数、エクストラ変数など。

• Play :
  個々のプレイ内で定義。プレイ内でしか参照できない。プレイ変数やタスク変数、ロール変数など。

• Host :
  各ターゲットノードに紐づく変数。インベントリ変数やファクト変数、レジスタ変数など。

以降、当記事では冒頭に述べたように Global なスコープの変数に焦点を絞って説明していきます。

グローバル変数のパターン

グローバルスコープの変数は、以下の4つのパターンで定義可能です。(参考 : 公式)

パターン	定義方法
ローカル定義したファクト変数	/etc/ansible/fact.d 配下の .fact 拡張子ファイル内で定義
環境変数	ターゲットノードより取得定義 (※)
エクストラ変数	ansible-playbook コマンド実行時に引数(-ｅ)に指定
グループ変数の応用	group_vars/all.yml に定義 (※※)

(※) 環境変数の定義

環境変数は、Ansible 実行時に収集される各ターゲットノードに紐づくファクト情報に含まれています。
(なら、ファクト変数と同様にスコープは Host じゃないかと思うのですが…)

一方で、environment ディレクティブを使用して以下の様に独自の環境変数を定義・参照することも出来ます。

この場合のスコープは Play (ディレクティブを定義したプレイまたはタスク単位)になります。

playbook.yml

- hosts: localhost
  environment:
    http_proxy: http://xxxx.xxx.xxx:8080
  tasks:
    - debug: var=ansible_env.http_proxy

このようにスコープ定義が使用方法によって変わるため、以降では環境変数についてはグローバル変数のパターンからは除きます。

(※※) group_vars/all.yml に定義

一方、「group_vars/all.yml 」については、以下の理由からグローバル変数のパターンに追加しました。厳密にはインベントリ変数の扱いなので、上記のスコープに当てはめると Host となります。

• group_vars配下の${ノード毎のグループ名}.ymlはどのプレイブックからも参照できる
• 暗黙で全てのノードは「all」グループに属するため、all.ymlは全ノード共通定義を意味する

グローバル変数のベストプラクティス

結論

個人的には、以下の条件下でグローバル変数を定義するのが良いと思っています。

■ Where : 「group_vars/all.yml」
■ When : 定義値にほぼ変更は発生しない見込みがあり、継続的・共通的に使用される時

• 定義

  group_vars/all.yml

  ntp_server: default-time.example.com
  
  

• 呼び出し

  playbook.yml

  ---
  - hosts: localhost
    tasks:
    - debug: msg="{{ ntp_server }}"
  
  ## 実行結果 ##
  # TASK [debug] *********************************************************************
  # ok: [localhost] => {
  #     "msg": "default-time.example.com"
  # }
  

Why

以下のような理由から、どちらかと言うと消去法的に選びました。

定義の管理のしやすさ

パターン	評価	理由
ローカル定義したファクト変数	△	Ansible の実行ディレクトリとは別のファイルで管理されている
エクストラ変数	✕	Ansible の実行ディレクトリから定義を探せない
group_vars/all.yml に定義	◯	Ansible の実行ディレクトリにあり、かつ1つのファイルに纏っている

エクストラ変数は、「コマンド引数に何を渡す」って情報を管理しなきゃいけなくなるのでチーム開発では特におすすめしないです。(個人で利用する分には良いと思います)

本来の使い方に即しているか

パターン	評価	理由
ローカル定義したファクト変数	✕	本来はターゲットノード情報のことを指す
エクストラ変数	◯	-
group_vars/all.yml に定義	◯	-

ファクト変数は、先程述べたように本来の役割はターゲットノード毎に取得される定義のため、グローバルではありません。
参考までに以下のように定義してグローバルな変数として呼び出せますが、おすすめしないです。

• 定義

  /etc/ansible/facts.d/test.fact

  [default]
  hardware = x86_64
  

• 呼び出し

  playbook.yml

  
  ---
  - hosts: localhost
    tasks:
      - debug: var=ansible_local.test.default.hardware
  
  ## 実行結果 ##
  # TASK [debug] *********************************************************************
  # ok: [localhost] => {
  #     "ansible_local.test.default.hardware": "x86_64"
  # }
  

おわりに

以上、「全ノード、全プレイブック共通のグローバルな変数を定義する箇所」 の定義パターンと、(個人的) ベストプラクティスとして group_vars/all.yml を紹介しました。

個人かチームか、やプレイブックの設計にもよると思いますので、「ここに定義した方が寧ろ良い」という意見があれば是非お願いします。