DevOpsのツール「Chef」は使い方（ノウハウ）以上に、なぜ使うかの理解（ノウホワイ）が重要です

Chefはどう使われているか、なぜ使うのかをしっかり解説

　近年、オンプレミスや仮想化サーバーからクラウドへのシステム移行が進んでいる。クラウドはパブリッククラウドにプライベートクラウド、そしてそのハイブリッドまで登場。関連するソフトウェアも商用製品からオープンソースまで多種多様になっている。そのため、インフラエンジニア^[1]が習得すべき新技術は増えるばかりだ。大変ではあるがその分、いち早く習得したエンジニアが得るアドバンテージも大きい。

　ITについて幅広く研修やトレーニングを展開する富士通ラーニングメディアでは、クラウド時代のインフラエンジニア向け研修コースも多数開講している（DockerやOpenStackなど）。うさぎ編集長こと市古編集長が今回体験受講したオープンソースのサーバー構成管理ツール「Chef」の研修コースもその1つである。

　研修コース名は「Chefで学ぶインフラコード化入門」。講師を務めてくださったのは、富士通ラーニングメディア ナレッジサービス事業本部 第二ラーニングサービス部 萬尚樹氏だ。

　このコースの主な対象者は、Linuxやスクリプトなど一定の知識や経験があるインフラエンジニア。パッケージのインストールやサービスの有効化、設定ファイルを書くなどの経験があると望ましいという。研修は1日コースで、Chefの概念解説から簡単な実習まで行う。

　Chefは一言でいえば「インフラをコード化するためのツール」。シェルスクリプトを書いた経験があるなら、Chefがシェルスクリプトとどう異なるのか、どう有用なのかよく理解できるだろう。萬先生は「インフラをコード化することでエンジニアの業務は変わります。どう変わるのかを実際に体験していただく」と話す。

　また、このコースの特徴は「テキストの第1章『Infrastructure as Code』に時間を使い、Chefの基本概念を念入りに解説するところ」（萬先生）だという。Chefに限らず、今や「どう使うか」といったノウハウならWeb検索である程度手に入る。しかし、大事なのは「いまChefはどう使われているか。なぜChefを使うのか」だ。最新の特徴を理解し、目的を正しく見定めないと知識だけ聞いてもきちんと身につかず忘れてしまうからだ。「ノウハウよりもノウホワイ（Know Why）です」と萬先生。これこそ研修コースを受ける醍醐味だ。

インフラを料理する「Chef」はDevOps環境で威力を発揮

　Chefの公開は2009年1月。すでに一定の評価と実績がある。Chefという名前は料理人を表す「シェフ」を由来としており、インフラを料理する感覚で構築していく。実際にはインフラの構成をコードで記述し、それを実行してインフラを自動構築する。Chefではインフラの構成を記述したコードを「レシピ」、レシピを集めたものを「クックブック」という。あらゆる用語が調理現場にまつわるものとなっているのだ。

　Chefは基本的にはクライアント・サーバー型のアーキテクチャになっており、Chefクライアントとなるノードが構成情報をサーバーにアップロードし、Chefサーバーはそれらを管理する。構成変更を行う場合はChefクライアントのノードがChefサーバーから構成情報を取得し、構成変更を実行する。1台だけで実行する場合には「Chef Zero」というローカルモードもある。

　Chefはデータセンターやテスト環境など、似たような環境を繰り返し構築するケースで特に有用だ。そのため、Chefの導入は主にディザスターリカバリ（災害対策）から始まったそうだ。

　最近では、インフラの構築作業にいっそうの効率化と時間短縮が求められている。仮想化環境では設定のテンプレートを使っても、各種設定を手動で設定すると作業期間は「数日」を必要としていた（オンプレミスではいわんやをや）。クラウドでは効率化が進んだものの、クラウド上で利用するアプリケーションの設定でそれなりに時間がかかる。

　そこでChefの出番となる。Chefを使うと、インフラの構築だけでなく、サーバーにインストールするアプリケーションも自動的に設定できる。効率化が大幅に進むというわけだ。

DevOpsはテスト駆動インフラ実現あってこそ

　ところが最近では、Chefの使われ方がさらに進化しているという。

「DevOpsへの理解が広まったこともあり、近ごろはテスト駆動インフラで使われる傾向が強まっています」（萬先生）

　DevOpsでは、アプリケーションのソースコードと、その実行環境であるインフラの設計を一緒に管理する。インフラがアプリケーションの一部になっていると考えてよいかもしれない。

　ここで課題になるのが、アプリケーション開発とインフラ構築の方法の違いだ。アプリケーション開発では「テスト駆動開発」と呼ばれる手法が一般的になってきている。テスト駆動開発は、コードの修正とテストを繰り返すことで、コードを洗練させる開発手法。仕様の追加や変更に対応しやすいというメリットがある。

　DevOpsでは、インフラ構築もこれに追従できなければならない。そこで、テスト駆動開発をインフラ構築に応用した「テスト駆動インフラ」が登場した。テスト駆動インフラでは、インフラが正しく構築されたかどうかを確認するためのテストを事前に作成し、それに合格するようにインフラを構築していく。

　ただし、テスト駆動開発がそれを支援するツールを必要とするように、テスト駆動インフラでもツールが必要だ。そのツールがまさにChefである。Chefはインフラの再構築がすぐできるので、レシピ（コード）の手直しとテスト^[2]を何度も繰り返すことができる。これにより、レシピは再利用や拡張がしやすい洗練されたものに仕上がっていく。つまり、Chef（などのサーバー構成管理ツール）があってのテスト駆動インフラであり、テスト駆動インフラあってのDevOpsなのである。

　ところで、サーバー構成管理ツールが持つ4つの原則には「宣言的」「抽象化」「冪等性（べきとうせい）」「収束化」がある。そしてこれらは……、おっと、この先は研修コースに参加してじっくり聞いてほしい。