Chef Serverを使って実際にベアメタルマシンへの自動構築を行う

連載 :

2014年1月22日(水)

第2回では、Chefの使用イメージをつかむためchef-soloを使用しました。chef-soloは各ノードに設定されたレシピをそれぞれのマシンに配布する必要があるため、構築・運用台数が多くなってくると、レシピとノードの関連付け設定が大変になります。一方、Chef Serverはレシピやノードの管理を一元化できるため、台数の多い環境でも管理が簡単です。

第3回では、オープンソース版Chef Serverの基本的な仕組みと使用イメージ、特徴について説明した後、Chef Serverを活用したベアメタルマシン（何も書き込まれていない状態のマシン）に対する自動構築方法についてご紹介します。

Chef Serverの基本的な仕組み

まず、Chef Serverの基本的な仕組みについてご紹介します。

（1）Chefの構成要素

Chef Serverを使用するには、次の3つの構成要素を理解する必要があります。以下、順にご紹介しましょう。

（a）Workstation

Workstationは、CUIツールのKnifeを使用してクックブック作成やChef Serverの設定を行う操作端末です。Chef Serverの設定とは、認証やレシピとノードの関連付け等の設定を指します。

（b）Chef Server

Chef Serverは、内部DBを持ち、クックブックやノードのデータを1元管理するサーバです。

（c）ノード

ノードは、chef-clientによって構築・設定変更が行われるマシンです。chef-clientは、ノード上でレシピにもとづいてシステム構築・設定（状態）変更を行うエンジンです。

図1：Chef Serverのアーキテクチャ（クリックで拡大）

（2）Chef Serverを使用した自動構築の流れ

Chef Serverを使用してレシピを適用する流れは以下の通りです。

（a）レシピの作成

Workstationでクックブックを作成します。クックブックの作成は、第2回でご紹介した通りKnifeを使用します。

（b）レシピのアップロード

Knifeを使用して作成したクックブックをChef Serverにアップロードします。

図2：レシピの作成とアップロード（クリックで拡大）

（c）レシピとノードの関連付け

Chef Serverでノードオブジェクト（論理インスタンス）を作成し、アップロードしたクックブックとオブジェクトとの関連付けを行います。これはChef Server上で行われる論理的な設定です。

図3：レシピとノードの関連付け設定（クリックで拡大）

（d）レシピにもとづいた構築・設定

ノードでchef-clientを実行します。chef-clientには、あらかじめノード名を設定しておきます（デフォルトは、FQDN）。chef-clientは、ノード名をキーにしてChef Serverにリクエストを行い、自身に関連付けられたクックブックとランリストを取得した後、レシピにもとづいて構築・設定を行います。

図4：chef-clientの実行（クリックで拡大）

設定変更を行う場合は、Workstationでレシピ（またはクックブック）を修正後Chef Serverにアップロードしchef-clientを実行します。すると、chef-clientが修正されたレシピを取得し設定変更を行います。

Chef Serverの特徴

Chef Serverには、次の特徴があります。

システム構成・状態管理の一元化
セキュアなノード管理
グラフィカルなインターフェース

こちらも順にご紹介しましょう。

1. システム構成・状態管理の一元化

Chef Serverは、レシピとノードの関連付け設定を一元管理することができます。第2回でご紹介した各ノードのランリストや個別設定を行うJSONファイルはChef Serverで管理されます。Chef Serverを使用して、ランリスト設定の他、ノードの一覧表示や各ノードの設定確認を行うことができます。

次の例は、Knifeを使用して既に設定してある“chefclient01”ノードの設定値を表示したものです。設定済みのレシピは“Run List:”の行で確認します。

$ knife node show chefclient01
Node Name:    chefclient01
Environment: _default
FQDN:         chefclient01
IP:           192.168.5.72
Run List:     recipe[resolver], recipe[ntp], recipe[yum], recipe[apache]
Roles:
Recipes:
Platform:     centos 6.4
Tags:
$

また、Chef Serverを使用して各ノードのOSやネットワーク等、ノードの状態に関するデータを収集して確認することもできます。収集されるデータには、カーネルやCPUに関する詳細なデータの他、ネットワークやメモリの使用率も含まれます。以下の例は、Knifeを使用してノード関連データの詳細を一覧表示したものです。

$ knife node show chefclient01 –l
・・・省略・・・ 
os:               linux
os_version:       2.6.32-358.el6.x86_64
platform:         centos
platform_family:  rhel
platform_version: 6.4
・・・省略・・・ 
$

2. セキュアなノード管理

Chef Serverはシステム構成や状態を管理しているため、悪意を持った者に操作されると危険です。そのため、Chef Serverは、Workstationやノードと通信を行う際に認証を行い、認証登録されたユーザーやノードからのみリクエストを受け付けます。

認証登録は、chef-validatorと呼ばれているクライアントの認証キーを仮使用することで容易に行えます。認証登録を行っていない状態でも、chef-clientをはじめて実行する時にchef-validatorの鍵を配布しておくと、chef-clientはその鍵を使用して自動で認証登録を行います。なお、chef-validatorの鍵は、認証登録が済んだら削除することが奨励されています。chef-validatorについては、下記のページが参考になります。

＞　About the chef-client

3. グラフィカルなインターフェース

Chef Serverのインターフェースは、CUIのKnifeの他にWebUIも提供されています。WebUIを使用すると、視覚的な操作が可能になります。例えば、第2回でご紹介した、ランリストなどのノード設定も視覚的に設定・確認することができます。次の図は、chefclient01ノードのランリスト設定をドラッグ＆ドロップで設定しているものです。

図5：Web UIによるランリストの設定（クリックで拡大）

ベアメタルマシンに対する構築

Chef Serverを使用してシステム構築・運用を行うためには、各ノードにchef-clientがインストール・設定されている必要があります。しかし、構築対象マシンの台数が多い場合、chef-clientの利用環境を人手で構築するのは大変です。そこで、この構築作業の自動化が重要になってきます。

図6：Chef Serverを使用した自動構築の流れ（クリックで拡大）

特に構築対象がベアメタルマシンであれば、OSのインストールやネットワークの設定も行う必要があります。

これらの作業を手動で行うと、OSのインストールをインストーラのGUIで対話的に行い、その後コマンド操作でアプリケーションのインストールや設定を行うことになります（図7の上部）。そこで、サイレントインストールやシェルスクリプトを使用して自動化します。

以下では、Red Hat系OSを対象としたネットワークブートとKickstartを組み合わせた方法をご紹介します（図7の下部）。

図7：chef-clientインストールの自動化（クリックで拡大）

まず、ネットワークブートとKickstartによるOSインストールに必要な全てのサービスやファイル等を格納したインストール用のサーバを用意します（下図のインストール用サーバ）。

図8：インストール用のサーバ（クリックで拡大）

次に、ネットワークブートやKickstartの設定を行い、OSやchef-clientを自動的にインストールするようにします。ネットワークブートとKickstartによるOSインストールの大まかな動きは下図の通りです。

OSインストールの細かな設定については、Chefからはなれてしまうため割愛し、参考資料をご紹介しておきます。

Red Hat Enterprise Linux 6 インストールガイド

図9：自動構築の流れ（クリックで拡大）

ここでは、OSインストール後のKickstartオプションであるShellスクリプトについて説明します。

（1）chef-clientのインストール

インストールサーバにchef-clientのRPMパッケージを格納したリポジトリを用意しておき、Yumコマンドを使用してchef-clientのインストールを行います。

（2）chef-clientの設定（認証登録、設定ファイルの配布）

インストールサーバのWebディレクトリにchef-clientの設定ファイル（client.rb）とchef-validatorの鍵（validation.pem）を格納しておき、Wgetコマンドを使用して所定の場所（上の例では、/etc/chef）に格納します。
chef-clientの設定ファイルでノード名を設定できるため、上の例ではechoコマンドを使用してホスト名を設定しています。（デフォルトはFQDN）

（3）chef-clientの実行

chef-clientコマンドを実行します。chef-clientが設定ファイルに記載されているChef ServerのURLにリクエストを行い、レシピを取得して構築を行います。

（4）chef-validator鍵の削除

認証登録用に取得したchef-validatorの鍵を削除します。

このようにして、ベアメタルマシンに対するchef-clientの利用環境を含めた自動構築ができるようになります。

Chef Server のインストールも簡単！

第2回でchef-solo/chef-clientのオムニバスインストーラをご紹介しましたが、Chef Serverも同様のインストーラが提供されています。例えばRed Hat系Linuxの場合、コマンド3行でインストールできます。簡単ですので、是非試してみて下さい。

# rpm -vih chef-server-11.0.8-1.el6.x86_64.rpm
# chef-server-ctl reconfigure
# chef-server-ctl test

Chef Serverのインストール要件は、以下のページが参考になります。
＞　System Requirements

気をつけておきたいこと

最後に、実際にChef Serverを使い始めた方のために、気をつけておきたいことを2点ご紹介します。

（1）ノード設定と認証は別々に管理されていること

Chef Serverは、個別設定やレシピの関連付けを行うノード設定と認証設定を別々に管理します。WebUIやKnifeを使用してこれらの設定を行う際には、図“Chef Client WebUIのNodesとClients”に示す様に表示が似ているため、初めは混同しやすいと思いますので違いを理解しておきましょう。

図10：Chef Client WebUIのNodesとClients（クリックで拡大）

（a）ノード設定

ノード設定では、各ノードの個別設定値やランリストの設定を行います。Chef Serverは、各ノードのJSONファイルを一元管理します。WebUIでは、Nodesタブ。Knifeでは、nodeサブコマンドで設定を行います。

（b）認証設定

chef-clientの認証登録・削除を行います。chef-clientの認証登録を行うと、認証のための暗号鍵が生成されますので、それをノードに配布します。配布された鍵を使用することで、chef-clientはChef Serverから認証登録済みのクライアントとして承認されます。なお、この登録は既にご紹介したchef-validatorの鍵を使用すると簡単に行うことができます。WebUIでは、Clientタブ。Knifeでは、clientサブコマンドで設定を行います。

（2）ノード再構築時における認証の再登録

検証環境では同じ環境を何度も作り直すこともよくあると思いますが、初期構築時に認証登録を行ったユーザーが登録されたままの状態で再登録を試みるとHTTP 403(Forbidden)のエラーになります。

このような時の対応方法には、認証リストの再登録と認証キーの再作成があります。Knifeコマンドを使用する方法とWebUIを使用する方法をそれぞれでご紹介しましょう。

対応方法（1）：認証リストの再登録

再度chef-validatorの鍵を使用してchef-client認証登録をやり直します。再登録のためには、認証登録済みchef-clientのリストから対象のchef-clientを削除する必要があります。削除方法は以下の通りです。

Knifeコマンドを使用する場合は、“client delete”サブコマンドを使用します。

$ knife client delete ＜chef-client名＞
Do you really want to delete ＜chef-client名＞? (Y/N) Y
Deleted client[＜chef-client名＞]
$

WebUIを使用する場合は、赤枠部分の“Delete”をクリックして削除します。

図11：chef-clientの一覧（クリックで拡大）

対応方法（2）：認証キーを再作成する

認証キーを再作成します。作成後、秘密鍵（PRIVATE KEY）を対象ノードに配布します。（/etc/chef/client.pemのファイル名で配布します。）

Knifeコマンドを使用する場合は、“client reregister”サブコマンドを使用します。

$ knife client reregister ＜chef-client名＞ 
-----BEGIN RSA PRIVATE KEY-----
・・・省略・・・ 
-----END RSA PRIVATE KEY-----
[knife01@knife ~]$

WebUIを使用する場合は、図の赤枠に示す通り“Clients”タブの“Edit”から“Private Key”にチェックを入れて“Save Client”をクリックします。クリックすると“Public Key”と“Private Key”が表示されますので、“Private Key”の部分を対象ノードに配布します。

図12：chef-clientの認証再登録（クリックで拡大）

上記2点の注意事項以外にも、よく起こりがちなエラーと対策をコミュニティのWikiで紹介しています。エラーが出た時は参考にするとよいでしょう。

＞　Common Errors

最後に

Chef社（2013年12月にOpscode社から社名を変更）は、Microsoft社やIBM社といったOSベンダーの他、Cisco Systems社やJuniper Networks社といったネットワーク機器ベンダーとも協力して開発を進めている様なので、筆者は今後、Chefによる自動化の範囲は広がっていくと期待しています。3回の連載でChefの概要からChef Serverを使用した自動構築の方法までご紹介しましたが、いかがでしたでしょうか。Chefに興味を持って試してみたい！と思って頂ければ嬉しいです。

※記載の会社名、製品名は、それぞれの会社の商標もしくは登録商標です。