はじめに
今いる会社でインフラエンジニアとして仕事をしています。
何十台ものサーバをセットアップして顧客先に納品しているのですが、そのOS設定作業を今までシェルスクリプトで行なっていました。(時には手順書通りにコマンドうってセットアップ...みたいなこともありました。)
しかし、Ansibleというサーバ構成管理ツールの存在に気づき始めた人が社内に出て、今構築作業を行なっています。
なぜAnsibleを使うようになったのか話したいと思いますが、Ansibleの具体的な概要については割愛します。
なぜAnsibleに移行しようとするか？
設定するサーバ自体にコマンド打たなくても良い
今までのシェルスクリプト
シェルスクリプトで設定しようとすると...
設定するサーバの端末を開く
↓
シェルスクリプトがあるサーバをマウントし実行、またはUSBなどのメディアでシェルスクリプトを実行
↓
再起動したらその後に使うシェルスクリプトを実行するためまた最初から同じ作業の繰り返し...
となってしまっていて非効率であり、これが何十台・何百台のサーバをセットアップすることもありものすごく大変でした。
Ansibleで実装
ところが、Kickstartなどでネットワークスイッチ等繋いでOSインストールのときにIPアドレスが設定されてあれば、Ansibleサーバにネットワークの設定を記述するだけでサーバ毎に端末開く必要が無くなります。(hostsの設定)
また、Ansible自体に再起動後にまた設定作業を再開できる機能があるのも大きなメリットです。
冪等性の概念がある
今までのシェルスクリプト
ApacheやNTPなどミドルウェアの設定ファイルにsedコマンドで記述する処理をシェルスクリプトに書いていました。
しかし、また同じシェルスクリプトを実行しようとしたら、設定ファイルの記載が二重化されてしまうことが幾度かありました。
そのためにif-elseの条件分岐で対処していますが、もし〜されていたらを考えながらプログラミングするのは結構大変でした。
Ansibleで実装
Ansibleには何回同じ処理を実行しても結果が変わらない冪等性という概念があります。
サーバの定義を記述したAnsibleのPlaybookを実行してその後何回もやっても実行結果は変わることがありません。(少しだけ例外はありますが...)
なので、シェルスクリプトとは違い余計な処理をすることないのは大きなメリットです。
見やすさ・わかりやすさ
今までのシェルスクリプト
社内の人間によってスクリプトの書き方がバラバラであり、分割したモジュール毎の管理が面倒でした。
また、プログラム内の見やすさに関してもインデントでの区切りがなかったり不自然であったとしてもシェルスクリプト自体は動いてしまうのが難点でした。
Ansibleで実装
AnsibleのPlayBookはYAMLで記述するのでインデントを区切らないとエラーが起こって実行できなくなってしまいますので、PlayBookに書いて実装すると自然と見やすくなっていきます。
また、OS設定の項目が多くなった時もAnsibleにはRoleというモジュールが存在しているのでミドルウェアごとのインストール・設定やドライバ・FWのインストールなども分割して記述できるのでRoleのどこに何が書いているか明確になリます。
これにより設定するサーバに変更点があってもRoleの概念で当確の部分を修正しやすくメンテナンスが容易となっています。
その他
同じ構成管理ツールとしてPuppet、Chef、Chefの軽量版のItamaeなどが存在しています。
これらは以下のようなことがありAnsibleを採用しました。
- 社内のインフラエンジニアはプログラミングの経験が乏しいため他の構成管理の記述に必要な
Rubyを扱える人がいない→YAMLなら覚えることも少なく書きやすい - 他の構成管理ツールだとモジュールがやや複雑で優先度などもわかりにくい
- 他の構成管理ツールだと設定するサーバにエージェントのインストールが必要になる
問題点
IntelのNICドライバをインストールするときはいつもソースコードからmakeして行なっていましたが、RPM化しないとできなくなってしまいました。(もしかしたらソースコードからインストールできるのかもしれませんが...)
他のドライバも同様にAnsibleでのインストールの仕方が未確立なこともあり、その部分はシェルスクリプトで対処することになっています。