ミドルウェアの設定ファイルをどのようにバージョン管理すべきか

僕は最近インフラ屋さんになりつつあるのでミドルウェアの設定ファイルをどのようにバージョン管理すべきという話をちらほら考えてます。あ、実際に何かを試した訳ではないです。あしからず。

開発したアプリケーションのソースコードをバージョン管理しないというのは今時あり得ないでしょう。バージョン管理ツールに何を使うかは置いといて。

でも一方ではミドルウェアの設定ファイルをバージョン管理している現場は少ないのではないかと思います。少なくとも僕は見たこと無いです。

まあ僕自身がアプリ屋経験しか無いのでインフラ屋現場ではひょっとしたら違うのかもしれませんが、ここでは少ないという前提で話を進めます。

バージョン管理しないとどうなるかっていうと、例えば「○○サーバをDNSの設定に追加する」とかいうタスクがあってそれを完了したとして、後に振り返って見たときに具体的に何をしたのかわかりませんよね。実はその後も設定ファイルをがんがん編集してたんだけど障害が発覚して実はそれがこのときの作業ミスだったなんてわかりません。当然以前の状態に戻すなんてこともできません。人間SubversionみたくExcelで管理台帳付ける手もありますが気乗りしませんよね。

ちなみにミドルウェアの設定ファイルが何かっていうと、Apacheならhttpd.conf、MySQLならmy.cnf、PostgreSQLならpg_hba.conf、Tomcatならserver.xml、Hadoopならmapred-site.xml、BINDならnamed.conf、NTPならntp.conf、といったものです。

これらの設定ファイルの特徴として、ローカルマシンでは編集、動作確認がやりづらくてサーバマシンにsshでログインして編集、動作確認することが多いということがあげられます。

アプリケーションのソースコードをローカルではなくてサーバ上で直接編集して動作確認っていうことはやらないと思いますが、ミドルウェアの設定ファイルではそういうことは普通に行われると思います。

サーバ上で直接編集するにしても、昔ならRCSでバージョン管理、今ならgit使ったり、あるいは/etc以下の設定ファイルを管理するetckeeperを使う手もあります。

でも現実は面倒だからバージョン管理しない現場が多いでしょう。ファイルを変更する機会がそんなにないならそれでもいいと思います。無理にバージョン管理の仕組みを導入してみんなが混乱したら意味無いですし。

実はこういうのはミドルウェアの設定ファイルに限らずシェルスクリプトもそうかなーと思います。

ちなみにシェルスクリプトの開発環境の話は下記に書きました。

シェルスクリプトの開発環境 - wyukawa’s blog

バージョン管理の重要性って以下のような感じかなと思います。

アプリケーションのソースコード>>シェルスクリプト>>>>>ミドルウェアの設定ファイル

今回書いているミドルウェアの設定ファイルの管理については以前下記に書きました。

シンボリックリンクを使ってのデプロイ - wyukawa’s blog

これの元ネタは下記です。

WEB+DB PRESS Vol.62

簡単に言うとSubversionでミドルウェアの設定ファイルをバージョン管理してシンボリックリンクを使ってデプロイするというものです。なかなかスマートだと思います。

似たような話としてKickstartによって自動インストールするもののバージョン管理の話が下記の4章にあります。

サーバ／インフラエンジニア養成読本 [現場で役立つ知恵と知識が満載！] (Software Design ｐlus)

ちなみにこの4章は下記の特集1と同じです。

Software Design (ソフトウェア デザイン) 2011年 01月号 [雑誌]

この雑誌でもSubversionを使っています。その理由は下記です。ちょっと納得。まあブランチも使わないだろうしsvnでいいかも。パーミッション回りは何使っても面倒かもしれないけど。

gitはサブディレクトリや一部のファイルのみのチェックアウトをサポートしていない、svnでは簡単にできていたエクスポートが少し面倒（最初にチェックアウトする必要がある）、といった制限があるようでしたので、今回もsvnを使った手法を紹介します。

ミドルウェアの設定ファイルをバージョン管理しTrac/Redmineなどと連携することにより、どの時点ではどのように動いていたのかを後から追跡できどの時点にも戻せることから大きな意味があると思います。

ただし設定ファイルを直接本番環境のサーバで編集してコミットしない場合は上記のようなことはできません。アプリケーションのソースコードならそんなことはしないでしょうが、ミドルウェアの設定ファイルはえてしてやりがちだと思います。この辺はPuppet経由じゃなくて直接編集して後で上書きされてしまう問題と似てますね。

仕組みを作ってもそれをちゃんと運用できなければ（運用しやすい状態じゃないと）、つまり使う人が面倒臭がらずに使えないとダメです。だって面倒くさかったら抜け道探すもん。言い方を変えると面倒くささよりもメリットが上回らないとダメでしょう。

この辺のコストパフォーマンスの判断は、設定ファイルがどの程度変更される可能性があるかってことだと思います。そんなに変更されないなら大掛かりな仕組みはオーバースペックです。変更の頻度が大きいならやる価値はあるでしょう。