「Immutable Infrastructure時代の構成管理ツール基盤SpecInfra」 by 宮下剛輔氏 #jawsdays – JAWS DAYS 2014 参加レポート Vol.06

佐々木大輔

2014.03.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

JAWS DAYS 2014 参加レポート、6発目は宮下剛輔氏のセッション「Immutable Infrastructure時代の構成管理ツール基盤SpecInfra」のレポートです！

「Immutable Infrastructure時代の構成管理ツール基盤SpecInfra」 by 宮下剛輔氏

こちらも立ち見いっぱいのセッションでした。座る事が出来た僕はラッキーです。

座席が遠く...右下にいらっしゃるのが宮下氏

当日お話頂いたスライドはこちらです。

サーバ構成管理とは

まずは「サーバ構成管理とは何か」からお話頂きました。サーバ構成管理とは「サーバの静的な状態を管理すること」であり、インストールされているミドルウェアやそのバージョン、設定、OSの各種パラメータなどを指すとのこと。

サーバ構成管理を行うためのツールとしてはChefやPuppet、Ansibleなどがありますが、サーバ構成管理ツールの基本原則として以下の4つを上げられていました。

宣言的→どうするかではない、何をしたいかで書くこと
抽象化→抽象された記述で書けること
冪等性→どんな状態でも終わったら同じ状態になっていること
収束化→勝手になってくれる、あるべき状態に収束すること

上述した構成管理ツールは皆その原則に準じてはいますが、Puppetは”状態”を記述しますがChefは”アクション”を記述するといったような、それぞれ書き方に特徴があるそうです。

Immutable Infrastructureがサーバ構成管理に与える影響

Immutable Infrastructureのように「構成を管理しない」ことが前提となった場合、サーバ構成管理はどうなるのか？

上記の4つの原則のうち、冪等性については「状態が不定だから実行が必要かどうか判断する必要があるが、Immutableなら毎回真っ新な環境を使うので状態は不安定じゃなくなる為、冪等性を考慮する必要が無い」、そして収束化については「不定な状態を一定の状態に収束することだが、Immutableなら状態が不定というのは無く適用前か適用後の2つだけしか無いため、収束という考え方自体がそぐわない」とのことでした。

つまり宣言的と抽象化の2つに特化した構成管理ツールが必要になるということですね。これは伊藤直也氏のセッションでもお話されていたことでした。

その答えとして、例えばゴールデンイメージ(一番確かなイメージ)を作っておくという手法もあるが、その場合再現可能な手順が残らず、そのイメージの状態を作った担当者がいなくあったり、そのイメージ自体が無くなったり使えなくなった場合に困るため、やはり手順は残しておく必要がある。そしてその手順はコードになっているほうが管理しやすく見通しが良いとのことでした。

しかしコードと言っても例えばShellやDockerfile(内容としてはShellscriptに近似)だと抽象化されておらず、OSに依存したコマンドなどが記述されていると汎用的に使えない問題が発生します。そこで冪等性と収束化の無いシンプルなツールが欲しい、ということで作ったのがconfigspecだそうです。(「当初ネタのつもりが意外と反応がよくてびっくりした」と仰っていました)

そしてそのconfigspecのコマンド実行部に使われているのが、今日の本題、SpecInfraです。

SpecInfra

SpecInfraは「汎用的コマンド実行フレームワーク」であり、実行形式の差異やOS・ディストリビューション毎のコマンドの差異を吸収してくれるフレームワークだそうです。元々はserverspecの一部だったものを分離し汎用的に使えるようにしたとのことでした。

SpecInfraの概要として宮下氏が提示されたのが以下の図です。

抽象化は二カ所で行われており、一つは「OS抽象化レイヤー」で、ここでは泥臭くOSの判別処理を行っているとのこと。書籍「入門Chef Solo」でも、「Chefの判別部分のコードはかなり泥臭い処理を行っている」という記述がありましたね。そしてもう1つが「実行形式抽象化レイヤー」で、実行がローカルで行われるのかSSHのような別環境で行われるのか、といったことを判別している箇所だそうです。