入門 Chef Solo 第22章 Chef Server の様子を知りたい - 概要からセットアップまで

今日は Chef Server についての章です。本書は主に Chef Solo について書かれていますが大規模構成では Chef Server を使ったアーキテクチャも考慮する必要があるので Chef Solo との差異、や pros/cons については把握しておきたいところです。

  • Chef Solo
    • ローカルに存在するレシピを元にコマンドを実行
    • knife-solo もレシピの転送と ssh 経由のコマンド実行を warp しているだけでレシピが各ノードに存在することは変わらない
  • Chef Server
    • サーバにレシピを保持し、ノード一覧などもまとめて管理される
    • 管理対象のノードには Chef Client がインストールされ、自動的に Chef Server からレシピを取得して、必要に応じで自ら実行する
    • 通信は JSON over HTTPS で Client からの pull 型
    • Chef-Sever のノードには nginx と Erlang 製の erchef というデーモンが起動する
    • レシピ管理用のデータベースなどのミドルウェアも必要
    • 管理者が開発用のマシン(Work Station) から knife コマンドで Chef-Server にクックブックやノード追加などを送信すると、次に Chef-Client のチェックでそれが適用される
    • knife には Chef Server と接続するための登録を行なって署名ファイルを設定する必要がある
  • pros
    • 管理情報の一元化
      • 全ノードの情報を検索して連携した設定ができる
      • ブラウザからノード管理するUI
      • ノードに配布する各種ファイルの置き場所
  • cons
    • Chef-Server ノードが必要(管理すべきサーバが増える。セットアップもそれなりに手間がかかる)
    • 割とマイナーなミドルウェアを利用する必要がある(Chef-Server 自身の運用が大変そう)
      • Opscode(最近 Chef と改名しましたね)の提供する SaaS 版 Chef-Server があるのでアウトソースできる

まあ結論はわかっていましたが、やっぱりノード数、構成の複雑さのいずれかが大規模になってきたら Chef-Server を検討してみる必要がありそうです。

  • Vagrant の Multi VM 機能
    • ひとつの Vagrantfile で複数の VM を起動する
    • Vagrantfile に config.vm.define を複数書いておいて vagrant up するだけ