インフラエンジニアのための構成管理

今回は、インフラエンジニアが誤解しがちかもしれない構成管理について、自分の経験をもとに書こうかと思います。

構成管理の目的とは？

数年前から構成管理やらInfrastructure as Codeやらその手のワードをよく聞くようになった。

Infrastructure as Codeとは、ざっくり言うとインフラもアプリのようにコードで構築できるようにするってこと。

例えば、webサーバを構築するのに、今まではOSをインストールして、ミドルウェアをインストールして、OSやミドルウェアの各種パラメータを設定してっていう作業を手動でやってきたけど、OSインストール後の作業をコード化して、特定のコマンドを実行すれば自動で構築できるようにする。（OSインストールは、VMテンプレートからクローンする前提です。）

で、これって実際どこまで普及しているのかしら。

少なくとも私はいろいろな現場を見て来てましたが、ちょっとだけ使ってる、一部の機能だけ使ってる、そんな感じでした。

そういう意味で、「すごい！本当に使えている」って思う現場はほとんどなかったです。

理由は結構いろいろあるみたい。

・いやいや、コード化するぐらいならとっとと手でやっちゃおうよ、工数勿体無いし。
・体系だって管理できる人いないし、作り込める人がいないし。
・そもそもサーバ作り直すことってそんなになくね？
・必要なら既存のVMのクローン取って、ちょこっと設定変更したら良くね？
・TeraTermのマクロで良くね？
・構成管理ってサーバの何を管理するのよ、パラメータなら詳細設計書（パラメータシート）に書いてあんじゃん。

正直、私も最初はこんな感じでした。

構成管理が目的ではなく、完全に構築自動化が目的になってる。ここが誤解しやすい一番のポイントな気がします。

ただ、実はそうじゃなくて

・Infrastructure as Codeは構成管理の手段であること
・構成管理とは設定値や設定ファイルではなく設定の履歴を管理すること

なんだなと。

このことを自分なりにやっと理解できた時にはじめて、その必要性も理解できました。

構成管理は、設定の履歴を管理することが目的なんだと。

例えば、ansibleで設定をコード化し、その各種ファイルをgitで管理することで設定の履歴を管理する。
ここで一番大事なのは、gitにちゃんと履歴を残すこと。

なぜ構成管理が必要なのか？

では、なぜそれが必要（大事）なのかです。

大きな案件になると、いろいろなグループの人達がサーバに対して様々な設定を行うので、誰がいつどのような要件でどんな設定をしたのか？が追えなくなったりします。

ましてや長い間運用してると、当時設定した人が居ないからわからないだとか、そもそも誰がどんな要件に基いてこの設定をしたのかわからないなんてことが、実はまあまああります。

金融や証券の案件でガチガチの運用してるシステムでも、数年経ってEOSL対応はじめたら、あれ？どうなっての？なんてあったりもします。そして、過去のチケットをひたすら漁るっていうね。

運用していく中で、またはEOSLなどによるリプレース時にそうならないためにも、構成管理なんですね。ちゃんとやっておけば我々インフラエンジニアを助けてくれます。

しかも、仮に壊されてもサクッと作り直せるし。

今回、こんな感じの内容ですが、インフラエンジニアの中には私のような人も居るかもしれませんので、そんな方に届けば幸いです。