Pocket

Chef(knife-solo)でリモートサーバを管理する方法

  • add this entry to hatena bookmark

Chef(knife-solo)を使うと、作業端末から、リモートサーバの構成管理をする事が可能になります。

リモートサーバにログインせずに、作業端末からリモートサーバに対して、様々な作業や状態確認が出来るようになります。たとえば、以下の図のような感じです。

chef-solo_201403

このページでは、Chef作業端末からリモートサーバの管理をする方法を記載しています。

なお、リモートサーバを管理する内容としては、今回はシンプルに、リモートサーバのiptablesサービスを起動した状態にするレシピにしています。

1.Chef とは?

「Chef」をうまく使うと、サーバーの「あるべき」構成状態をプログラムで管理できるようになります。

もう少し補足した説明は、サーバーの構成状態をコードで管理できる自動化ツール「Chef」のご紹介 | ファンブライト に記載しています。(まだまだざっくり感はありますが・・・。)

2.Chef 利用環境

今回の Chef 利用環境は以下のような感じです。

  • Chef作業端末:CentOS
  • Chef管理対象ノード:CentOS

chef-summary_201403

基本的に、右側(青色)の「Chef作業端末」から作業を行います。

最初の画像で、左側(ピンク色)「Chef 管理対象ノード」にはログインしなくても良い、と記載していますが、実際には以下のような最初の準備作業が必要です。

  1. OSのインストール
  2. 「Chef作業端末」から自動認証でSSHログインする為の設定

3.Chef作業端末へのChefインストール

まずは、Chef作業端末に、Chef実行環境をインストールします。

ちなみに、Chef作業対象ノードへ、手動でChefをインストールする必要はありません。この辺も自動的に処理される事になります。(かなり便利です。)

まず、Chef作業端末にChefをインストールし、knifeの設定を行います。

$ curl -L http :// www. opscode . com / chef / install .sh | sudo bash
$ knife configure

次に、knife-solo を rubygems でインストールします。

$ sudo gem install knife-solo

実際には、私はここが一番苦しみました。理由は環境依存のところなので説明は割愛させていただきますが、ruby環境についてもっと勉強しないといけないと痛感しつつ、なんとか乗り切った感じです。

knife設定ファイル「~/.chef/knife.rb」に以下の設定を追加しておきます。

knife[:solo_path] = '/tmp/chef-solo'

4.Chef作業端末にChefレポジトリを作成する

次に、knife-solo で、Chef作業端末にChefレポジトリを作成します。

$ knife solo init chef-repo
Creating kitchen...
Creating knife.rb in kitchen...
Creating cupboards...
$ cd chef-repo
$ ls -1
cookbooks
data_bags
environments
nodes
roles
site-cookbooks
$

Chefレポジトリの内容は上記のようになります。

5.Chef作業端末にクックブックを作成する

Chef作業端末で、レシピやJSONファイル(ノード)を用意する為、クックブックを作成します。
クックブック名は今回は「test」にします。

$ knife cookbook create test -o site-cookbooks
** Creating cookbook test
** Creating README for cookbook: test
** Creating CHANGELOG for cookbook: test
** Creating metadata for cookbook: test
$

chef-repo/site-cookbooks 配下に test というクックブックが作成されます。この中にレシピなどを作成していく形です。

6.Chef作業端末にレシピを作成する

次に、iptablesサービスを起動した状態にするレシピを作成します。
「site-cookbooks/test/recipes/default.rb」がデフォルトで用意されている空のレシピファイルです。
このファイルに以下を追加します。

service 'iptables' do
  action [:enable, :start]
end

この内容は、iptablesの起動時設定をOnにして、iptablesを起動する内容です。

7.JSONファイルの作成

Chef管理対象ノードを定義したJSONファイルを用意します。
Chef管理対象ノード名「web」で名前解決が出来る場合、「nodes/web.json」というファイルを作成する事にします。
内容は以下のようになります。

{
  "run_list":[
    "recipe[test]"
  ]
}

このJSONファイルで、レシピ「test」を指定しています。
以上で、一通りの設定ファイルの準備が完了しました。

8.Chef管理対象ノードにChef-soloをリモートインストール

次は、Chef作業端末から、Chef管理対象ノードであるリモートサーバ「web」に対して、Chef-soloをインストールします。

$ knife solo prepare web
(中略)
Thank you for installing Chef!
$

標準出力を見ていると、s3に置かれているrpmをダウンロードしてインストールしているようです。
リモートサーバ「web」でrpmコマンドでChefインストール状態を確認してみます。

$ rpm -qa | grep chef
chef-11.10.4-1.el6.x86_64
$

現時点の最新バージョン「11.10.4-1」がインストールされています。

9.knife-soloを実行

まず、リモートサーバ「web」でiptablesの状態を確認しておきます。

$ sudo /sbin/chkconfig --list iptables
iptables        0:off   1:off   2:off   3:off   4:off   5:off   6:off
$ sudo /etc/init.d/iptables status
iptables: ファイアウォールが稼働していません。
$

OS起動時も停止したままで、iptablesは起動していません。

では、いよいよ、Chef作業端末から、リモートサーバ「web」に対してレシピを適用します。

$ knife solo cook web
Running Chef on web...
Checking Chef version...
Uploading the kitchen...
Generating solo config...
Running Chef...
Starting Chef Client, version 11.10.4
Compiling Cookbooks...
Converging 1 resources
Recipe: test::default
  * service[iptables] action enable
    - enable service service[iptables]

  * service[iptables] action start
    - start service service[iptables]

Running handlers:
Running handlers complete

Chef Client finished, 2/2 resources updated in 18.748052364 seconds
$

出力を見てみると「enable service service[iptables]」、「start service service[iptables]」と記録されています。

それでは、再度リモートサーバ「web」でiptablesの状態を確認してみます。

$ sudo /sbin/chkconfig --list iptables
iptables        0:off   1:off   2:on    3:on    4:on    5:on    6:off
$ sudo /etc/init.d/iptables status
テーブル: filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
2    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0
3    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
4    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
5    REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination
1    REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

$

OS起動時にiptablesが起動するようになっており、iptablesが起動しています。

Chef(knife solo)を実行した結果、コードに従ってインフラの設定が行われた事が確認できました。

なお、実行後に、リモートサーバ「web」上で、該当アカウントのホームディレクトリ配下に「chef-solo」が作成されている事が確認できます。

10.もう一度、同じレシピを実行

もう一度、「$ knife solo cook web」を実行してみます。レシピは変更していません。また、リモートサーバ「web」では、iptablesは起動しており、OS起動時に起動する設定になっています。

$ knife solo cook web
Running Chef on web...
Checking Chef version...
Uploading the kitchen...
Generating solo config...
Running Chef...
Starting Chef Client, version 11.10.4
Compiling Cookbooks...
Converging 1 resources
Recipe: test::default
  * service[iptables] action enable (up to date)
  * service[iptables] action start (up to date)

Running handlers:
Running handlers complete

Chef Client finished, 0/2 resources updated in 3.451527719 seconds
$

表示される内容は変わりましたが、エラーにはなっていません。

Chef管理対象ノードが、コード(レシピ)で定義された構成状態になっている事が確認された形です。

今回使ったレシピは非常にシンプルなものですが、Chefは実に様々な事が出来ます。今回の knife-solo の仕組みを使うと、とても便利な事も出来そうです。

 

Pocket

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です


*

チェックサイト RSS Feed読者登録はいかがでしょうか?RSS配信中です。