playbook を書く上で
- 「何をしたか」
- 「何を考えるか」
- 「何が辛かったか」
を忘れないように書いておく
当たり前のことも書いてある
- ansible 系の記事で 1 万回くらい言われてるけど, role は 必ず共通化する
- role が増えてくると管理がつらくなる
- production_nginx, staging_nginx のような role を作るのはアウト
- こういう場合は変数できりわけることを考える
- production_nginx, staging_nginx のような role を作るのはアウト
- いずれ捨てるつもりの role は切り分けても良い気もする
- e.g. バージョンアップによりインストール方法が変わるものとか
- もちろん ansible は変更にも対応しているが, immutable な構成にしておいた方が事故が少ない
- そのまま
- nginx role で使用するつもりだった location_path 変数を他の role で使われることを防ぐ
- td-agent role で nginx_location_path 変数が使われていたらおかしいことにすぐ気付ける
- 分ける方法は 2 種類
- prefix
- e.g. nginx_version, nginx_location_path
dict の key個人的にはこっちの方が好きただしこの場合はhash_behaviour: mergeは必須この設定がないと location_path だけ上書きしたいとき困る- (2018/05/28 追記) 公式ドキュメントにはっきりと非推奨とあったので, prefix で分けた方が良い
- prefix
nginx:
version: 1.13.12
location_path: /
- 複数の role にまたがるのが明白な変数は要検討
- e.g. project_name, env とか
- 個人的には project_name がそれ以外の意味を持たない時はそのまま使って良いと思う
- nginx の location_path に使用するのであれば
nginx.location_path: "{{ project_name }}"にするべきだと思う
- 基本は middleware ごとに role を作ると再利用性/共通化が捗る
- 変数が複数の role にまたがったりしたら粒度を考え直した方が良い
- td-agent の conf とか監視系の conf とかは結構難しい
- 例えば「nginx の error.log を td-agent で転送する」
nginx role で設定するのか td-agent role で設定するのか問題- td-agent role で設定するパターン
- td-agent role で td-agent の設定を行うだけなのでわかりやすい
- td-agent が nginx に依存する形になり if 分岐が増え playbook が汚くなりがち
- nginx role で設定するパターン
- nginx で td-agent の設定をするので, 少しわかりにくい
- nginx role が td-agent role に依存する
- 依存は増えるが, 複雑になりがちな td-agent の conf を綺麗に保てる
- 例えば「nginx の error.log を td-agent で転送する」
こんなにはっきり非推奨と書いてあったんですね.
であれば prefix で区切ったほうが良さそうです.
修正しておきます. ありがとうございます!