Infrastructure as Code

簡単にいうと、サーバインフラのコード化です。

Infrastructure as Codeの微妙なところ

Puppet、Chef、Ansibleとかでも基本的には、インフラのコード化を誰がやるのかっていうと基本人間がコーディングするって紹介が多いです。ただ、これだと規模が小さいシステムだと、コーディングにかかるコストに見合うのかって問題があります。

おそらく数百〜数千規模の超大規模なシステムだったり、Immutable Infrastructure（サーバインフラをスクラップ・アンド・ビルドで使い捨てる）なシステムであれば、コーディングにかかるコストをカバーできると思います。なので、システム規模が数十とか、昔からあるようなシステム構成で、とりあえずInfrastructure as Codeをやってみようとすると微妙になることがあります。

なぜなら、本当はサーバを楽して構築/構成管理するのが目的であって、サーバを構築/構成管理するコードを作ることが目的ではないから。

Infrastructure as Codeのあるべきかたち？

横展開はコード化した方がやりやすいのと、1台だけであれば手でやった方が早いのいいとこ取りができないかなと。
Master/Agent構成で例えばこんな感じです。

設定お試し用サーバ（以降、Agent）で、手で設定変更する。
Agent側はコード化対象のリソース一覧を受け取って、情報収集後、自分の定義をMaster側にあげる。
Master側は、受け取った定義を元に、Agentの構成管理を行う。
設定の横展開が必要な場合、展開元のAgentの定義を、展開先のAgentの定義にマージする。
展開先のAgentはマージ後の定義を反映して設定変更する。

インフラのコード化といいつつも、コードの細かい部分まで意識しなくてすむとかのイメージです。管理対象のピックアップと、横展開の意思決定に人が専念した方が、はるかに健康的かなと思います。

一言で言うと、若干の手作業を許容したゆるい構成管理ツールです。実運用的には、設定お試し用サーバは他サーバとの定義の乖離が大きくなったら使い捨てて作り直した方がよいかなと。厳格に構成管理を行うサーバについては、実績のある定義のみで設定変更を行うとか。例えば、本環境は物理サーバかVMとかでも、設定お試しはDockerコンテナで１台だけ作って、その設定を構成管理ツールの定義として取り出して本環境に横展開するとか。

こんな設計思想なツール、すでにあれば使ってみたいですが、なければ既存のPuppetとかに補助ツールを組み合わせて実現するしかないのかな…。Ansibleはエージェントレスなのと、Chefだと定義がプログラムぽいので。