ダメSE uramonの奮闘記

インフラ関連技術など

Chef Clientのインストール・・・その前に(knife bootstrapの準備)

Chef

　前回、Chef Serverをインストールしたので、今度はChef Clientのインストールについて考えたい。

　通常は、Chefで構成管理をするといっても、OSのインストール、Chefのインストールは事前に実施しておかなければならない。サーバ台数が増えてきたとき、これは面倒。

　これらを全て自動化するには、PXEブートとkickstartを組み合わせて使用する等の工夫が必要である。今回は、ここまではやらないが、Chef Clientのインストールを極力省力化すべく、knifeの『bootstrap』なる仕組みを使いたいと思う。

 

knife bootstrapのフロー

　bootstrapは、本来Chef Clientにログインして実行すべき以下の作業をChef Serverからknifeを使用してリモート実行できるというもの。

 

 

 

① Chef Clientのインストール

　対象のホストにChef Clientをインストールする。今回は、インターネット非接続環境を想定して、事前にRPMファイルをダウンロードしておき、それを利用する。

 

② 鍵の作成

　Chef Serverの公開鍵をChef Client側に設定する。具体的には、Chef Server側の"/etc/chef-server/chef-validator.pem"の内容をChef Client側の"/etc/chef/validation.pem"にコピーする。

 

③ Chef Clientの定義ファイルの作成

　Chef Clientの定義ファイル(/etc/chef/client.rb)を作成する。

 

 bootstrap環境を作成する

 　まずは、bootstrapのテンプレートファイル(ERB)をChef Server上の任意のディレクトリに作成する。ファイルの内容は以下の通り。

bash -c '
<%= "export http_proxy=\"#{knife_config[:bootstrap_proxy]}\"" if knife_config[:bootstrap_proxy] -%>

if [! -f /usr/bin/chef-client ]; then
   tmp_dir=$(mktemp -d) || exit 1
   pushd "$tmp_dir"

  cp /tmp/chef-11.4.0-1.el6.x86_64.rpm "$tmp_dir"
  rpm -ivh chef-11.4.0-1.el6.x86_64.rpm

   popd
   m -r "$tmp_dir"
fi

mkdir -p /etc/chef

awk NF > /etc/chef/validation.pem <<'EOP'
<%= validation_key %>
EOP
chmod 0600 /etc/chef/validation.pem

cat > /etc/chef/client.rb <<'EOP'
<%= config_content %>
EOP

cat > /etc/chef/first-boot.json <<'EOP'
<%= first_boot.to_jason %>
EOP

<%= start_chef %>

 

　次回はChef Clientをインストールしてみる。

 

Chef Serverをインストールしてみる

Chef

　今回は、Chef SoloではなくChef Serverをインストールしてみたいと思う。

 

Chef Serverのインストールフロー

    

 

① Chef Serverのパッケージ準備

　今回は、Ver11のRPMを利用してインストールする。OPSCODE社のホームページから、RPMをダウンロードしておく。

　ちなみに、今回選んだ環境とバージョンは以下の通り。

  [Operating System] Enterprise Linux

  [Version] 6

  [Architecture] x86_64

  [Chef Version] 11.4.0-1

 

② Chef Serverのインストール

　まずは、先ほどダウンロードしたRPMでChef Ｓｅｒｖｅｒをインストールする。

# rpm -ivh chef-server-11.0.6-1.el6.x86_64.rpm
  ：
  Thank you for installing Chef Server!

  The next step in the install process is to run:

  sudo chef-server-ctl reconfigure

　

　Centos6でデフォルトで起動しているqpidd（AMQPプロトコルをApacheに実装させる為のデーモン）を停止する。

※停止させないとRabbitMQが起動できず、この後のChef Serverの起動に失敗する。

# service qpidd stop & chkconfig --del qpidd
   ：
   [1]+   終了                  service qpidd stop

 

　"chef-server-ctl"コマンドでChefの初期設定を行う。

# chef-server-ctl reconfigure
   ：
   chef-server Reconfigured!

 

　Chef Serverを起動する。

# chef-server-ctl restart
  ：
  ok: run: rabbitmq: (pid 16441) 0s

 

③ knifeの初期設定

　knifeコマンドを使用し、knifeの初期設定を行う。

　3行目のURLは、http～ではなく、https～なので注意が必要。あと、ポート番号も4000ではなく、443(省略可能)である。又、6行目、8行目のパスは、/etc/chef/～ではなく、/etc/chef-server/～なので、こちらも注意。細々とトラップが。。

　どうやらこれらは前バージョンまでの情報で、互換性を保つ為にデフォルト値になっているらしい。

# knife configure -i
   WARNING: No knife configuration file found
   Where should I put the config file? [/root/.chef/knife.rb]
   Please enter the chef server URL: [http://ホスト名:4000] https://Chef ServerのIPアドレス
   Please enter a name for the new user: [root]
   Please enter the existing admin name: [admin]
   Please enter the location of the existing admin's private key: [/etc/chef/admin.pem] /etc/chef-server/admin.pem
   Please enter the validation client name: [chef-validator]
   Please enter the location of the validation key: [/etc/chef/validation.pem] /etc/chef-server/chef-validator.pem
   Please enter the path to a chef repository (or leave blank): /opt/chef-repo
   Creating initial API user...
   Please enter a password for the new user:
   Created user[root]
   Configuration file written to /root/.chef/knife.rb

 

④ Chefリポジトリ作成

　Chefリポジトリを所定のディレクトリ(今回は、/opt/chef-repo)に作成する。Githubからzipファイルをダウンロードして展開するだけ。

Chef ServerかChef Soloか・・・

Chef

　Chefには、『Chef Server』と『Chef Solo』という2つの形態があるらしい。

どっちを使ったらいいんだ・・・。

ということで、こちらの記事が大変参考になった。

運用視点でChef ServerかChef Solo + Knife Soloのどちらが良いか考えてみた

 

さてどっちだ・・・

　基本的には以下の考え方となるようだ。

【Chef Solo】

  • 対象サーバが数台、又は開発者向け単独マシンだけが対象の場合
  • 「まずはお試し」という場合

【Chef Server】

  • 対象サーバが数十台の場合(ただし、ネットワークセグメントが分かれており、1台のChef Serverが管理できる台数が制限されてしまう場合は注意)

 

目的や立場にもよる

　ざっくりと上記のような導入基準で考えれば良いのは分かった。ただ、自分達がどういう立場にあって、どういう目的でChefを導入するかによっても変わってくると思われる。

　情報システム部門、一次受けベンダー、二次受けベンダーでそれぞれ考えてみた。

 

■ 情報システム部門

　企業の情報システム部門なら、単純に上記の基準で導入を検討すればよいのではないだろうか。システム構築や運用をベンダーに委託するにしても、自社の資産としてChefを活用することができる。

 

■ 一次受けベンダー

　ユーザー企業からシステム構築や運用を委託された一次受けベンダーなら、ユーザーに対してChefによる運用の効率化を提案する、という形になるのではないだろうか。その場合も、上記の基準で検討すればよいと思う。

　ただ、システム構築に関しては、『Chefで工数抑えられたんでしょ』ということで買い叩かれる危険性があるかも。。

 

■ 二次受けベンダー

　二次受けベンダーの場合、Chefを大々的にセールスすると、前述のように、単純に買い叩かれる危険性があると思う。

　そこで、『システム構築の効率化』を目的にツールとしてChefを利用するという手がある。その場合、個人的にはChef Soloが適しているように思う。

Chefのアーキテクチャ

Chef

Chef(Ver11)のアーキテクチャを整理してみた。

Chef Server(API)

　Web UI やノード、クライアントから API リクエストを受け付ける HTTP サーバ。
　(以降、単に『Chef Server』と記す)

Chef Server(Web UI)

　Chef Serverのために用意されたウェブベースの管理コンソール。

PostgreSQL

　Chef Serverの主なデータ保存場所。

　Ver10までは、CouchDBだった。

RabbitMQ

　Chef Serverから受け取ったデータを保存してさらにChef Solr Indexerに転送する。

Chef Solr Indexer

　データをSolrに書き込む。

Solr

　Apache Solr 全文検索エンジンの軽量ラッパー。

　インフラの情報をメタデータで保持する。

Chefはじめました

Chef

仕事でChefを使うことになったのでそのメモ。そもそもChefってなに？

 

Chefって何？　　　　　　　　　　　　　　　　　　　　　　　　

　早速Google先生に聞いてみる。

OPSCODEという会社がこの製品を扱っているらしい。

WEBの説明によると、

『Chefは、インフラ環境をコードに変換できる自動化プラットフォームです。』

なんのこっちゃ。

もう少しググって見た。結局、、、

Chefは、Ruby製のサーバの構成管理ツールで、システムの設定・運用作業を自動化するオープンソースソフトのことらしい。

 

Chefのメリットは？　　　　　　　　　　　　　　　　　　　　

　ところで、Chefを使うと何が嬉しいのか？

 Chefが自動化してくれる、システム設定・運用作業とは、以下のようなものを指すようだ。

  • ソフトウェアのインストール～設定
  • OS、ソフトウェアのアップデートや設定変更
  • ネットワークの設定

　これらの作業に対して、以下のようなメリットがあるという。

  • サーバ1台1台に対する手作業からの開放(作業工数の逓減)
  • 手作業でのオペレーションミスの防止
  • サーバ間の環境差異の効率的管理
  • 構築・運用手順の「プログラム」としての再利用

　これから、色々といじってみたいと思う。続きは次回に。

 

参考になりそうなリンク