オープンソースなシステム自動管理ツール Puppet

第18回 Puppetのスケーラビリティ向上テクニック

この記事を読むのに必要な時間:およそ 2 分

複数台構成でのスケーラビリティの向上

複数台構成でのスケーラビリティの向上は,基本的には単一構成の場合の最後に解説した,mod_proxy_balancerを利用したやり方と全く同じです。振り分け先が同一ホスト上のpuppetmasterdではなく,リモートホスト上のpuppetmasterdに変わるだけです。ただし,servertypeにmongrelを指定した場合,puppetmasterdは127.0.0.1でみバインドしますので,リモートからアクセスできるように,bindaddressオプションでバインドアドレスを明示的に指定する必要があります。

# puppetmasterd --servertype mongrel --bindaddress 0.0.0.0

Apache+Mongrelの複数台構成例

Apache+Mongrelの複数台構成例

ただし,⁠基本的には単一構成の場合と同じ」と書きましたが,SSL証明書の扱いに以下のような問題があります。

  • Puppetクライアントが直接リクエストするのはApacheである。
  • しかし,初回リクエスト時に実際に署名するのは,Apacheからリクエストをプロキシされる,複数あるPuppetサーバのいずれかである。
  • Puppetサーバは初回起動時にCA証明書を各々自動的に作成する。
  • したがって,Puppetクライアント毎に証明書のIssuerがバラバラになってしまい,動作に問題が発生する。

これを解決するための方法はいくつか考えられますが,一番簡単な方法は,Puppetサーバ追加時,puppetmasterdを起動する前に,Apacheが動いているホスト上にある,/etc/puppet/ssl/ca以下をすべて新規Puppetサーバにコピーすることです。こうすることで,Apache上にあるCAファイルと同一のものがすべてのPuppetサーバで利用されるため,どのPuppetサーバで署名をしても,Issuerが同一になります。

ただし,この方法には以下のような問題もあります。

  • 同じIssuerで,同じシリアル番号なのに,Subjectが異なる証明書ができてしまう。
  • 証明書のRevocationが面倒。

こういった問題はありますが,検証してみた限りではPuppetの動作には特に問題はないようです。

Apache以外にも,PoundNginxを利用する方法についての解説が,Puppet Wikiにありますので,文末の参考URLを参照してみてください。

最後に

Puppetの連載は今回で最後ですが,いかがでしたでしょうか。Puppetを実運用で利用するための基本的な情報はほぼ網羅できたのではないかと思います。今後は,まだまだ英語でも情報が少ない,効率的な運用ノウハウを追求し,またみなさまと情報共有していきたいと思います。

参考URL

著者プロフィール

宮下剛輔(みやしたごうすけ)

(株)paperboy&co.技術責任者。 社内ではサーバ周りからアプリケーション開発まで幅広く関わる一方,個人的にはPerlプログラミングを趣味として,サーバ管理用ユニットテストスイート Assurer(アシュラ)をオープンソースで公開したり,CPAN AuthorPlaggerコミッタとして活動している。また,YAPC::Asia 2007 Tokyo等の技術系カンファレンスでスピーカを務めるのも最近の楽しみのひとつ。共著書に『MASHUP++』がある。

URLhttp://mizzy.org/