LoginSignup
64
58

More than 5 years have passed since last update.

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

Posted at

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の2つのようです

Chef

特徴

言語にRubyを利用

メリット

・Rubyの採用により、繰り返し処理など、プログラミングらしい処理が書きやすい
・冪等性を担保するためのツールがそれなりに揃っています
・幅広い構成に対応するためのツール郡(Chef-Zero, Chef-Serverなど)

デメリット

・反映先の環境全てにChefがインストールされている必要あり
・Rubyに慣れていないと、すこし内容を見づらい

Ansible

特徴

言語にYAMLを利用

メリット

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

デメリット

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

その他

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

まとめ

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

64
58
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
64
58