Playbookを秘伝のタレ化しないために考えていること
お久しぶりです、村です。
最近、自分や他人が作成したPlaybookを運用する機会が増えてきました。 そこで、Playbookを作成する際、運用目線的にはどうすれば良いのか、ぼんやり考えていることを書こうと思います。
問題
他人が書いたPlaybook(およびその周辺環境)を見ていて困ったことはこの辺です。
- 実行手順がわからない
- 渡す引数は何が必須?
- サーバ全台に無邪気に適用していいんだっけ
- 改修やリファクタが結構しんどい
- なんかイケてないから直したいけど、影響箇所が多すぎて直せない
- これ何でこんな書き方してるんだ?
...最終的に誰も手をつけたくなくなっていることがあります。
PlaybookはYAMLだし、コードほど行数やファイル数が膨らむこともそうないので根気強く読める人がいればいいのですが、 担当者が離任したりして秘伝のタレ化...みたいな事態は珍しくない気がします。
ゴール
- 作成したPlaybookが長く運用できること
- Playbookが属人化しないこと (そもそもPlaybookは長く使うものじゃないというツッコミはこの際無視します・・・笑)
対象読者
- Playbookを書いている人
- Playbookを運用している人
解決策?
当たり前のことが多いですが、この辺をすることで少しはよくなる気がします。 思いつき次第追記していこうと思います。(結構漏れている気がするので...)
Playbookの情報を記述しよう
- どの環境で、どういう手順で実行できるかを残しましょう。
- 誰にでも実行できるわけではないPlaybookは属人化しやすいです。
- リポジトリのREADMEとかに残すのもいいと思います。
↓こんな感じ
# README ## 概要 Webサーバ新規構築用Playbookです。 ## 変数 - var1: (説明1) - var2: (説明2) - var3: (説明3)
シンプルさ・読みやすさを保とう
- 読みにくいものは秘伝のタレ化しやすいうえ、改修しにくいです。
- 例えばjinja2テンプレート以下でfor文を回す、みたいな記述はできるだけやめましょう。。。
- Ansibleの機能をうまく使用してシンプルに・わかりやすく書きましょう。
- 前のバージョンのドキュメントですが、おすすめです。
手作業の手順書を残そう
- Ansible実行環境が障害に陥った際、最後に頼るのは手作業であるから、です。
- いつでも実行環境があり、必ずジョブが成功すれば良いのですが、そういうわけにはいかない時もあります。
- また、手作業の手順書から思わぬヒントを得られたりすることもあります。(あるいは後継者がスマートなPlaybookを書いてくれるかもしれません)
テストを作成しよう
- Playbookでの変更をチェックするようなテストを作成すれば、必要な変更を変えないような改修が容易になります。
- Playbook作成時(もしくは作成前)にテストコードを書き始めましょう。
終わりに
- 初めてこのトピックで書いたものの、手順書とは違い正解がない気がしていて、公開前からツッコミを恐れています。。。
- Ansibleは広く知られたツールだと思いますので、この辺多くの人が考えていることかなと思います。
- 是非ワイワイ議論したいのでTwitterなりでお声掛けください。
