このサイトでは、サーバー環境の構築を中心にアレコレとインストールしたり設定したりしています。
仕事でもこういう作業をやっていますので、Ansibleや Chefといったサーバー構築を自動化するツールには興味があります。
私も Ansibleでのサーバー環境構築にしばらく取り組んでいたことがあるのですが、思う所あって一時中断しています。
Puppet・Chefは既に存在していましたが、後発で Ansibleが出てきた頃に一気に人気が出て、雑誌でも取り上げられましたし、有償の講習会も開催されていましたし、ブログも良く書かれていましたね。
Ansibleの Playbookは公式から野良まで一杯公開されましたし、複雑な Playbookを集めた Ansible Galaxy ってサイトもできました。
Infrastructure as a Code って言って、今後はインフラもコードなんだ、インフラがプログラマに拓かれるんだって話でした。
インフラエンジニアもこれからはコードを書けないとって脅されましたね。
現在はそれから5年か6年くらいでしょうか、いやもっとかな、当時の勢いを余り感じません。
多分ですが、サーバーを作る時に何でもかんでも Infrastructure as a Code では無かったということなんだと思います。
Ansibleは OSのみではなくネットワーク機器にも対応していますが、ここではOS用途にのみ限定して書きますね。
まぁネットワーク機器でも変わらないとは思いますが。
Ansibleで初めて知った「冪等性」という言葉、Ansibleの世界では、同じ Playbookからは何度やっても同じ状態になる、そんな感じで使われていたと思います。
Ansibleは「環境を作る」ツールではなく、「環境を指定した状態にする」ツールであるということだったと記憶しています。
ちゃんとしたモジュールだと、現状を読み取ってから変更が必要なら変更が実行される、ように作られているはず。
Playbookを実行した際のメッセージも、それに準じたものになっていました。
これが Ansibleでの環境構築/運用は難しいかな？と思ってしまった理由の一つでした。
ただ設定をするだけじゃダメで、状態確認が必要なんですね。
誰かが作ってくれた完璧なモジュールを利用できるうちは良いのですが、これを自前で作るとなると、結構な手間のはずです。
その OSのシェルで動く設定変更ようのコマンドを羅列したスクリプトを書くよりも、工数が嵩むのは間違いありません。
更に Ansibleのお作法に沿ったリターンをするように作らなければいけませんし。
もう一つの理由は、当時やはりこの点を指摘していた人もいたので、そう思っていた人は私だけではないはずです。
一度 Ansibleで作った環境では、Ansibleの様なツールの利点を生かすためにはその後のいかなる変更も Ansibleでやるべき、となります。
Ansibleの Playbookがパラメータシートそのものになる、というような運用を行う場合はこうならざるを得ません。
さもなくば、Ansibleとそれ以外の方法での二重管理となります。
サーバー環境の構築まではそれ程問題にならないと思いますが、その後の運用を鑑みると、両手放しで取り入れるのには躊躇がありました。
Ansibleのようなツールは、管理対象や使用するシチュエーションは以下のようにある程度限定されると考えています。
- httpサーバーを立てるだけなどシンプルな環境を作る場合
- 幾つも同じ環境を作らなければならない場合
あれま、2つしかありませんでした。
これってマイクロサービスを提供する環境を作るのに適しているじゃない！
と思うのですが、程なくしてこの領分はコンテナが席巻してしまったので、同じ機能の OSを1から作る事自体がなくなってしまいましたよね。
時代の趨勢というか、諸行無常というか、時代の徒花までは行きませんが、出たばかりの頃にサーバーエンジニアの目には大変キラキラと見えていただけに、複雑な気持ちであります。
いずれここでも扱うかも知れませんが、数年を経て使われ方が変わっていったか、運用での問題は解決されているかを確認してからになると思います。
 | Ansible実践ガイド第3版 コードによるインフラ構築の自動化 （impress top gear） [ 北山晋吾 ] 価格:3,740円 |
 | Ansible構築・運用ガイドブック インフラ自動化のための現場のノウハウ [ 八木澤 健人 ] 価格:3,696円 |
 | Ansibleクックブック （impress top gear） [ 大嶋 健容 ] 価格:3,740円 |
