Infrastructure as Code(IaC)について、今更ながら調べました

#Infrastructure as Code調べてみました
いまさらながら、Infrastructure as Codeについて調査しました。

##Infrastructure as Codeって？
インフラ構成をコードにしておくことです(そのまんま）。
ミドルウェアのインストールや、設定変更などを、
一度実行できれば、再利用性の高い「コード」にして、
バージョン管理できる形で残していこう、というのがキモだと思います。
組織でバージョン管理を利用していないとかだと、メリットを活かしきれません。

###メリット
####ヒューマンエラーが激減
都度、マニュアルに従ってやっていたのでは、
(僕のようないい加減な)人間だと、変更したのにマニュアルを更新しなかったり、
特定のサーバに対して変更しわすれていたり、ということが起こりえます。
また、マニュアルで管理している場合だと、日本語の意味がわからないことや、
手順が入れ違っている、といったミスも頻繁に起こりえます。
コードで記述されていれば、それも殆どなくなります。

内容がコードで記述されていることで、
詳細を追いやすくなることも重要なメリットです。
インフラを設定したひとがその場にいなければ、
それ以外の人がおいそれと設定を変更出来ない、ということが少なくなります。

####冪等性によって、重複した変更によるバグが減る
また、冪等性を考慮することで、インフラ設定の差分について考えることも少なくなります。
冪等性とは、同じ変更(コード)を、どの対象(サーバ)に適用しても、
結果が変わらない、という事を意味しています。
例えば、AnsibleでApacheの最新版をインストールするコードを走らせると、
一度目は、インストールを実行し、インストール完了後、OKのステータスを返却します。
再びコードを走らせると、最新版がインストールされている事を確認し、OKを返却します。
返される内容は、ともにOKのステータスです。
二重にコードを走らせても、無駄なサービスの停止など、問題が起きづらくなっています。

###デメリット
####ルールが増える
あるときにはコードを実行して変更し、あるときはCLIからコマンドを実行して...とやっていたのでは、
IaCのメリットを教授できなくなってしまいます。
一度、IaCでインフラを管理するようにしたら、
必ずコードを実行する形でインフラを変更すべきです。
また、メリットに上げた冪等性についても、考慮しなければなりません

####変更の適用に掛かる時間が増える
複数のサーバに、一括で変更を適用するならば良いのですが、
一つのサーバに変更を適用するのにも、
コードを書いて、実行して、とやっていると、
変更に掛ける時間はむしろ増えてしまいます。

####プロビジョニングツールを利用するならば、それなりに学習コストが掛かる
ツールを利用する場合には、
そのツールを利用するための基本的な知識を
チーム全体が持っていなければなりません。
例えば、Apacheの設定変更をする場合でも、
Apacheの知識だけではなく
+ツール(Ansibleや、Chefなど)の基本的な知識が必要、ということです。

###まとめ
時間や、ルールといったリスクはありますが、
環境構築に対してのリスクを減らす、という大きなメリットのための投資だと考えれば、
安いものではないかなと思います。
開発での、テストコードのメリット・デメリットにも近いかもしれません。
DevOpsでいうところのOpsから次々と出される要求に
柔軟に、安全に応えるためには、必要な投資だと感じます。

プロビジョニングツール

構成をシェルスクリプト等で管理することもできますが、
ツールを使った方が、より管理がしやすいです。
管理サーバから複数サーバに、一気に変更を適用できたり、
冪等性をある程度考慮したモジュールが揃っていたり。

現在、デファクトスタンダードとなっているのは、AnsibleとChefの２つのようです

###Chef
####特徴
言語にRubyを利用
####メリット
・Rubyの採用により、繰り返し処理など、プログラミングらしい処理が書きやすい
・冪等性を担保するためのツールがそれなりに揃っています
・幅広い構成に対応するためのツール郡(Chef-Zero, Chef-Serverなど)
####デメリット
・反映先の環境全てにChefがインストールされている必要あり
・Rubyに慣れていないと、すこし内容を見づらい

###Ansible
####特徴
言語にYAMLを利用
####メリット
・YAMLの利用により、記述がシンプル
・構成もシンプル。最低2ファイルで稼働
・反映先にAnsibleが入っていなくても、変更の適用が可能

####デメリット
・繰り返しや条件分岐は、Rubyに比べるとやりづらい
・シンプルさとのトレードオフで、大規模な構成になると、コードの管理に気を配る必要あり

###その他
IaaSなどのクラウド環境では、
ネットワークの構築など、プロビジョニングツール単体では対応が難しいものでも
組み合わせて対応できるようになることがあります。
(AWS CloudFormationなど)

###まとめ
小規模な構成で始めてみるなら、Ansibleの方がやりやすいかな、と感じました。
逆に大規模な構成 or 複雑な構成なら、
はじめからChefを利用している方が、その後の手間が省けるように感じました。