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

第10回 Puppet実践テクニック(その5)

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

本番フェーズ

本番フェーズでは,テストフェーズで動作確認がとれた設定ファイルとデータファイルを本番環境へデプロイします。

trunkからtagsへのコピー

まずはtrunkからtagsへコピーします。

$ svn cp http://svn.local/puppet/serviceA/trunk http://svn.local/puppet/servieA/tags/REL-20080117

この作業を「タグづけする」とも呼びます。この作業は,特定の時点でのスナップショットをとることにより,変更がされないことを保証するとともに,何かあった場合にすぐロールバックできるようにしておくという意味合いがあります。

デプロイサーバ上へのファイルのチェックアウト(はじめて本番環境へデプロイする場合)

弊社ではデプロイ用のサーバを社内に用意しており,このサーバ上にタグづけしたファイルをチェックアウトします。これははじめて本番環境へデプロイする場合にのみ行います。

$ svn co http://svn.local/puppet/servieA/tags/REL-20080117/conf /var/tmp/serviceA/puppet/conf
$ svn co http://svn.local/puppet/servieA/tags/REL-20080117/data /var/tmp/serviceA/puppet/data

デプロイサーバ上で新たにタグづけされたファイルへの切り替え(2回目以降の本番環境へのデプロイの場合)

2回目以降のデプロイの場合,過去にタグづけされたファイルがデプロイサーバ上のチェックアウトディレクトリに保存されています。これを新しくタグづけされたファイルに切り替えるために,svn switchを実行します。

$ svn switch http://svn.local/puppet/servieA/tags/REL-20080117/conf /var/tmp/serviceA/puppet/conf
$ svn switch http://svn.local/puppet/servieA/tags/REL-20080117/data /var/tmp/serviceA/puppet/data

ryncで本番サーバへアップ

チェックアウトしたファイルを,デプロイサーバから本番サーバへアップします。

$ rsync -auvz --exclude=.svn/ -e ssh --delete /var/tmp/serviceA/puppet/conf/ server.example.org:/etc/puppet/
$ rsync -auvz --exclude=.svn/ -e ssh --delete /var/tmp/serviceA/puppet/data/ server.example.org:/var/puppet/data/

puppetmasterdの再起動

本番環境のPuppetサーバ上のpuppetmasterdを再起動します。

$ sudo /etc/init.d/puppetmaster restart

一部のPuppetクライアントで動作確認

まずは,本番環境上の一部のPuppetクライアントで動作確認します。以下のように,Puppetサーバ上でpuppetrunを実行します。

$ sudo puppetrun --host staging.example.org

全Puppetクライアントへの適用

一部のPuppetクライアントでの動作確認に問題がなければ,全てのPuppetクライアントで新しいマニフェスト等を適用します。

$ sudo puppetrun --all --parallel 5

Archerによる一連の作業の自動化

弊社では,タグづけからpuppetmasterdの再起動までの一連の作業を株式会社モバイルファクトリーの松野徳大氏が中心となって開発している,Archerというデプロイツールで自動化しています。これにより,本番サーバへのファイルのアップロードからpuppetmasterdの再起動までコマンド一発で実行しているだけでなく,デプロイの完了をメールやIRCに自動で通知しています。

Archerのソースコードは現在,CodereposSVNリポジトリ上にあります。

テストと本番の差異の吸収

puppetmasterdが参照するLDAPサーバの設定など,テスト環境と本番環境とで,設定やマニフェストに差異が出てくる場合があります。このような場合,いちいちファイルの内容を書き換えるのは手間もかかりますし,修正漏れや修正ミスなどの危険性があります。

弊社では設定ファイルの差異は,テストと本番で別ファイルを用意し,テスト環境では以下のようにpuppetmasterdを実行して,テスト用の設定ファイルを読み込ませるようにしています。テスト用の設定ファイルもSubversionで管理しています。

$ sudo puppetmasterd --config /etc/puppet/puppet.conf.test

また,マニフェストの差異は,Facter変数を利用して,caseやセレクタでリソースの宣言内容を変えています。たとえば,テスト環境は.localというドメインを利用していますので,Facter変数$domainでテスト環境か本番環境かの区別ができます。

5回に渡り解説してきたPuppet実践テクニックは,今回で終了です。実践でPuppetを利用するために必要な知識は一通り解説できたと思います。次回はPRMやCftといったPuppet関連ツールをご紹介します。

著者プロフィール

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

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

URLhttp://mizzy.org/