JenkinsによるLinuxサーバの設定変更管理yggdrasilの運用事例

JenkinsによるLinuxサーバの設定変更管理yggdrasilの運用事例を@tkusukawaさんが公開されていたのでメモ。

【元ネタ】
JenkinsによるLinuxサーバの設定変更管理（yggdrasil）の徹底 - Qiita [キータ]

Home ・ tkusukawa/yggdrasil Wiki ・ GitHub

日々是精進。: yggdrasilを使ってみました。

ALMiniumによる yggdrasilサーバの構築: くすろぐ

Cacoo - yggdrasilの構成図

【1】JenkinsによるLinuxサーバの設定変更管理（yggdrasil）の徹底 - Qiita [キータ]の記事がとてもよくまとまっているので、分かりやすい。

yggdrasilとは、Linuxサーバの設定ファイルをSVNでバージョン管理するためのコマンド（SVNのラッパー）。
Apacheの設定ファイルhttpd.confをSVN管理したい時、.svnなどの余分なファイルができてしまうので、yggdrasil サーバーに設定ファイルを同期した後に、SVNリポジトリへコミットする。

ygg check コマンドを使えば、対象サーバーとSVNリポジトリの設定ファイルのDiffを確認できる。
そのコマンドをJenkinsで定期的に動かし、差分が発生したら、メールで通知する仕組みを説明している。

本番サーバーの環境構築で嫌な問題は、設定ファイルが開発サーバーと違うために、ファイル名に日付を入れてバックアップしがちでゴミファイルが増えてしまうこと。
更には、どの設定ファイルが正しく動いていたのか分からなくなるために、サーバーのリプレース作業でゴミファイルを削除した後に必ず本番障害が発生しやすい問題もある。

yggdrasilの開発や導入は、その問題意識を持っている状況から生まれたようだ。

(引用開始)
【問題は概ね変更の中にある】

サーバの設定変更の問題が月日が経ってから発覚した、という経験はないでしょうか？
例えば、HDDの残量低下のアラートを受けてトレンドを確認したところ一ヶ月以上前に突然増加し始めていた、というような問題です。

ソフトウェア開発でバージョン管理システムを使っていると、試行錯誤した場合でも、どの部分をどう変えたのかを全て差分確認し、修正してみたけど結局は修正する必要が無かった箇所や、デバック用に入れたコードの戻し忘れをコミット前にきっちりチェックすることが出来ますよね。

サーバ設定の試行錯誤でも同様の手法が使えたら素晴らしいと思いませんか？
これを実現するのが yggdrasil になります。
全ての設定ファイルがSVNの リポジトリに反映されていれば 、設定ファイルの変更箇所を漏らさず確認することが出来ます。
意図しない設定変更は事故の元です。
明示的にコミット操作を要求することで変更に対する責任を明確にし、意図していない設定変更が混入することを回避できることになります。
(引用修了)

JenkinsによるLinuxサーバの設定変更管理（yggdrasil）の徹底 - Qiita [キータ]では、異常を見張って正常性を維持してくれる有能な執事：Jenkinsを使うことで、本番サーバーとSVNリポジトリの設定ファイルを同期するようにチェックする運用を強いる。

【2】「問題は概ね変更の中にある」という言葉はとても意味深い。
IT技術の本質は、常に変更が発生する点にある。
変更が必ず発生するという前提条件の元で、変更したがために、あるべき姿から少しずつ離れて、ある限界を超えると障害となって初めて現れる。

バージョンアップしないシステムやソフトウェアは、死んだ状態に等しい。
昨今は、ハードウェアやサーバーの性能向上、WindowsOSのバージョンアップが激しいため、3年おきにシステムリプレースないしハードウェアリプレースという無駄な作業が発生しがち。

その時に、過去に動いたシステムは変えずにハードウェアだけそのまま移行する(リホスト)はとても簡単な作業に思えるが、実際は、設定ファイルのゴミ掃除があったり、JavaやOracle、MySQLなどのミドルウェアのVerUpのために、プログラムのリコンパイルが発生したりする。
すると、システムの回帰テストの作業工数が発生し、うまく動かない機能が必ず出てくる。

例えば、昨今は、Windows7以降はIE11がデフォルトになってしまったために、クライアントアプリが正常表示しなかったり、正常動作しないケースがある。
こういう保守作業は、SIやベンダーにとってもあまりお金にならないし、ユーザも安定稼働するために無駄なお金を使うので、正直嫌なものだ。

いわゆるレガシーマイグレーションの落とし穴については以前書いた。

レガシーマイグレーションという名のシステム移行はデスマーチになりやすい: プログラマの思索

システム移行の概念として、リビルド・リライト・リホスト・ラッピングの違いは抑えておくべき。

【3】サーバーの設定ファイルもバージョン管理しようという発想は、昨今のDevOpsで叫ばれている「Infrastructure as Code」にもつながる話だろう。

下記のBlogの内容が素晴らしい。

Infrastructure as Code - naoyaのはてなダイアリー

従来は、環境構築の手順書をExcelやVisioなどで作り、有識者でレビューした後に、環境を作り、構築テストを行なっていた。
だから、実際に作った後に初めて分かる障害も多かった。

でも、Chefのようなツールを使って、環境構築の手順そのものをプログラム化してしまえば、いつでも誰でも環境を再現できるようになる。
そして、環境構築プログラムそのものをコードレビューできるし、GitHubに入れて、Pull Requestを受け付けるようにすれば、複数人でテストしたソースをマージすることもできるようになる。
さらには、テスト自動化と継続的インテグレーションも入れれば、環境構築そのものもプログラミングと同じく、アジャイルに開発できる。

サーバー構築を構成管理とTDDで作業する時代になってきた: プログラマの思索

Chefのメモ: プログラマの思索

Chefで構築するRedmine環境: プログラマの思索

今後、DevOpsやクラウドは環境構築で必須の概念になるにつれて、クラウドデザインパターンというインフラ方式設計のベストプラクティス集も必要な知識になるだろうと思う。

クラウドデザインパターン～インフラ方式設計のベストプラクティス集: プログラマの思索

今後も考えてみる。