先日、社内勉強会のようななにかで Ansible のことを話しました。
当初は、role を使わずにプレイブックからプレイブックを include する方が簡単なのでよほど大きな構成にならない限りは role は使わないほうが良いよー
というコンセプトだったのですが、業務で Ansible を使っているうちに role の方がいろいろ捗るような気がしてきたので途中で方向性を変えました。
プレイブック１枚だけで完結する程度であれば role は不要かもしれませんが、分割したくなったらとりあえず role にしておけばいいと思います。
最後の方に書いていますが、あんまり複雑なことはしないほうが良いです。じゃないと、
- 手段と目的が逆転する
- Ansible を使うことそのものが目的になってる
- メリットが感じられなくなってモチベーションがダダ下がり
- プレイブックのメンテにかけるトータルの時間より手作業の方が短くね？
- そんな頻繁にサーバを再構築しないですしおすし
となり、やる気がゴリゴリ削がれていきます。
shell モジュール（とか command とか）はどうしても使わざるをえないことはありますが、ファイルの中身を弄くる系のモジュールはめんどくさいのでなるべく使わないほうが良いです。
また、今年のはじめの頃の Jenkins カンファレンスに参加したときに誰かが言っていましたが、
自動化であまり複雑なことをするとむしろ属人性を高める
と思います。
ssh で接続して vim である設定ファイルをちょっと変更して service XXX restart、ぐらいなら誰にでもできますが、ansible-playbook -i prod.ini all.yml と入力して Enter するのはなかなか誰にでもできる作業ではありません（心理的な意味で）。
スライドにはありませんが、role の中の files/ について。
例えば php.ini を置く場合、当初はサーバでのパスと同じようにディレクトリを掘っていました。
roles/
php/
files/
etc/
php.ini
が、ディレクトリ階層が無駄に深すぎじゃない？ と思ったので、次のようにフラットにしました。
roles/
php/
files/
php.ini
問題は、このディレクトリ以外のファイルも置きたい場合です。例えば php のエラーログをローテートするための logrotate の設定を置きたい場合、最初のサーバのパスそのままの構成であれば次のようになりますが、
roles/
php/
files/
etc/
php.ini
logrotate.d/
php
フラットにすると次のようになり、わけがわからなくなります。
roles/
php/
files/
php.ini
php
ローカルのファイル名とサーバのファイル名が一致している必要はないので、次のようにしてみました。
roles/
php/
files/
php.ini
logrotate
さらに /etc/php.d/ にもファイルをコピーしたい場合、流石にこいつらまでフラットに置くのはつらいので、次のようにしています。
roles/
php/
files/
php.ini
logrotate
php.d/
00-aaa.ini
00-bbb.ini
00-ccc.ini
この構成なら php.d/ に with_fileglob も使えますし（ただ、with_fileglob は滅多に使いません）。
前述の通り、with_fileglob は滅多に使いません。なぜなら・・・
ローカルのファイルを削除しただけでサーバのファイルも削除されることを期待してしまう
からです。
synchronize を使う案も考えましたが・・・
php.d/ には自分で管理しないファイル（yum install で配置されたものを放置）もあり、あとで php 拡張モジュールを追加したときに synchronize で消されてしまう事故があったので、使うのをやめました。
with_fileglob の対象となっているディレクトリからファイルを削除した場合、
なんらかの方法でサーバからそのファイルを削除しなければならない
ので、それなら with_items で１つ１つ指定しておいて、ファイルを削除したときには task の方も修正しなければならないようにしておいた方が事故りにくいです（task を修正しなければプレイブックの実行時にコケるので）。
