ansible個人的メモ＆Tips

ansibleを使い始めたので覚えておきたいことを個人的にメモ。

尚、本家のドキュメントしか情報ソースにしていません。本家のドキュメントは素晴らしく優秀です。
http://docs.ansible.com/

タスクのinclude

• includeでタスクを一纏めにして外部ファイルに書ける。これは、whenを付けてある条件時にのみ実行が可能。

- include: when_include.yml
  when: env_name == 'dev'

• また、タスクを纏めたファイルを作成し、変数値を分けて何度も実行できる。共通的な処理の切り出しに使える。

- include: supervisor_job.yml job_name=job1
- include: supervisor_job.yml job_name=job2
- include: supervisor_job.yml job_name=job3
- include: supervisor_job.yml job_name=job4
- include: supervisor_job.yml job_name=job5

上の例だとsupervisor_job.ymlの中で{{ job_name }}として変数値を参照可能。

• しかし、今のところ上の例を以下のようにwith_itemsで回すことはできないみたい・・・。

vars:
  job_names:
    - job1
    - job2
    - job3
    - job4
    - job5

tasks:
  - include: supervisor_job.yml job_name={{ item }}
    with_items: job_names

2015/12/21追記：

include + withはansible2.0で可能になった模様です。
http://qiita.com/t_nakayama0714/items/4bcca0dd70a228c5b73b
↑大感謝！

whenとwith_items

whenとwith_itemsを同時に指定した場合、
whenよりも先にwith_itemsが評価され、
with_itemsのループ各処理に対してwhen条件が評価される。
つまり、item変数値をwhen条件に含めることも可能。

- debug: msg="job1 only"
  with_items: job_names
  when: item == "job1"

command, shell

• リターンコードが0以外だとタスクがfail扱いになるので、適宜ignore_errors。
• 毎回changedになるので、好ましくない場合にはchanged_whenを使う。
• changed_when: Falseだと常にchangedにならない。以下のように記述すればリターンコードで制御できる。

- command: 'diff job1.conf job2.conf'
  register: ret
  changed_when: ret.rc != 0 # ファイルの差分がある場合にchanged
  ignore_errors: yes

• registerで実行結果を取れば、リターンコードや標準出力など様々な結果を使える。
  retにregisteしたら、ret.stdout.find('str')やret.stdout_lines、ret|changedなど色々便利。

めんどくさいので、when + with_items含めて例を。

コンフィグファイルをテンプレート通してリリースする時、リリース対象から消したファイルを実際に消すタスク。
（一旦全部消すとchangedの制御がアレだし、もっとスマートな方法はないものか・・・）

vars:
  configs
    - conf1
    - conf2
    - conf3

-------------------------------------

- name: release configs
  template: src=templates/{{ item }} dest=/etc/supervisor.d/{{ item }} mode=0644
  with_items: configs
# 全リリース後、差分を取ってなくなったファイルがあれば消す。
- name: list current configs
  shell: 'command ls -1 /etc/supervisor.d'  # リリース後のコンフィグファイルのリストを取る。
  changed_when: False
  register: config_list
- name: delete configs
  file: path=/etc/supervisor.d/{{ item }} state=absent
  with_items: config_list.stdout_lines      # コンフィグファイルそれぞれに対して、
  when: item not in configs                 # リリースするコンフィグ一覧から抜けているか判定。

リリース対象から外したいコンフィグファイルがある場合、
configsの変数からそのコンフィグを抜けば、
このタスクを叩くと削除される。

ベストプラクティス構成での変数セット

普通にベストプラクティス構成を見てみると、host_vars、group_vars、roleごとのvarsしかない。
気づきにくい/やや不便なことがある。

• 全グループ全ホストで使う共通変数は、group_vars/all.ymlに記述すればよい。
• インベントリを例えば「staging」「production」などと書いて環境ごとに分ける場合、この環境ごとに変数を書きたいことがある。
  そんな場合はインベントリ自体に変数を書く。
  環境全体で使う場合には、グループ単位の変数ではなく[all:vars]とすればいい。

staging

[all:vars]
hoge=fuga
hogehoge=fugafuga

• しかし、この方法でインベントリに変数を書いていくと、host_varsやgroup_varsに変数を纏めていく構想に反していて気味悪い。そこで、

staging

[all:vars]
env_name=staging

と書いておき、playbookの方でvar_filesを記述。

staging.yml

- hosts: app_hosts
  sudo: yes
  vars_files:
    - "env_vars/{{ env_name }}.yml"
  roles:
    - supervisor

env_varsというディレクトリを掘りそこに環境ごとに変数を書いていくとすっきりする。