連載
» 2015年04月06日 05時00分 UPDATE

新人インフラ技術者のためのサーバー構築/運用自動化入門(終):GitやDockerと連携するPuppet運用テクニック、filebucketによる自動バックアップ、GUIのPuppet Dashboard (1/2)

サーバー構築の自動化で利用される技術、自動化ツールとして「Kickstart」「Puppet」を紹介し、構築から運用まで、システムライフサイクル全体にわたる運用管理の自動化についても解説する連載。今回は、filebucketによる自動バックアップやGitやDockerと連携する運用テクニック、GUIのPuppet Dashboardなどを紹介する。

[菅原亮, 岡本隆史,NTT OSSセンタ]
「新人インフラ技術者のためのサーバー構築/運用自動化入門」のインデックス

連載目次

 前回の『作業手順書はもういらない! Puppetにおける自動化の定義書「マニフェスト」の書き方と基礎文法まとめ』までで、Puppetの運用について一通り学ぶことができました。連載最終回の今回は、K男さんとR子さんの日常の小ネタあるある形式で、運用に役立つPuppetのTipsを紹介します。

転ばぬ先の杖――filebucketによる自動バックアップ

R子 キャー!(泣)

K男 どうした!?

R子 間違ってマニフェスト適用しちゃって、大事なファイルを消しちゃったんですぅ(泣)

K男 そんなときは「filebucket」から戻せるけど……後でお説教だ!(怒)


 Puppetには、「filebucket」という、fileリソースが対象のファイルを変更する前に自動的にバックアップする機構があります。この機構をagent/master型の運用で使うと、agentノードで変更する前のファイルがmaster側に保管されるようになり、変更前ファイルの集中管理が可能になります。図1にfilebucketの動作イメージを示します。

puppet5_1.jpg 図1 filebucketの動作イメージ

 ファイルはハッシュ値(MD5)で管理されていますので、複数世代の管理も可能です。ハッシュ値はマニフェストの適用時ファイルに変更があった際、デフォルトでは以下のようにagent側の「/var/log/message」へ記録されます。

Feb 10 14:26:20 agent01 puppet-agent[4779]: Applying configuration version '1423545900'
 :(中略)
Feb 10 14:26:20 agent01 puppet-agent[4779]: (/Stage[main]/Main/Node[agent01]/File[/etc/hosts]) Filebucketed /etc/hosts to puppet with sum f2009e174b91fd74688655a2b4e5f2cf
Feb 10 14:26:20 agent01 puppet-agent[4779]: (/Stage[main]/Main/Node[agent01]/File[/etc/hosts]/content) content changed '{md5}f2009e174b91fd74688655a2b4e5f2cf' to '{md5}a1817dc27a3185b0a36fd482c08d7785'
Feb 10 14:26:20 agent01 puppet-agent[4779]: Finished catalog run in 0.32 seconds

 filebucketの便利なところは、テキストファイルでもバイナリファイルでも関係なく使えるところです。テキストファイルの場合、diffの結果をログに記録できますので、手間を考えなければログを追って手作業で復元できますが、バイナリの場合はそもそも差分を記録できません。そこでfilebucketへバックアップするようにしていれば、ログに記録されているMD5値を使って、変更前のファイルを復元できるようになり、“転ばぬ先の杖”になります。

 ただし注意点としては、filebucketを使うにはログに記録された情報が必須なため、監視システムなどにより適切にログファイルが管理されていて、必要に応じて参照できることが前提条件になります。

 また、この動作は対象のファイルを元の状態に“ロールバック”するのではなく、元のファイルの内容をファイル名を指定して書き出す動作になります。対象ファイル名と同名での指定もできますが、復元されるのは内容のみで属性までは復元されません。そのため、復元後にユーザー側で属性を再設定するなどの操作は必要になります。

 それでは、filebucketの使い方を紹介します。filebucketは使う前に設定が必要です。agent/master型で運用する時、最初に実行される「site.pp」ファイルに、以下の内容を記述します。

filebucket { 'main':
  path   => false,
  server => '[Puppetサーバー名]',
}
 
File { backup => main, }

 この設定は「filebucket」リソースによって、バックアップ先のサーバーを定義しています。path属性にfalseを設定するとserver属性で設定した先にバックアップします。

 通常はPuppetのmasterを設定します。先頭が大文字になっているfileリソースは、fileリソースが持つ属性のデフォルト値を定義するものです。バックアップするにはfileリソースでbackup属性を指定しなければなりませんが、このようにデフォルトのbackup属性値を指定することで、毎回指定しなくてもバックアップするようにできます。

 それでは簡単な例を紹介しましょう。前述のfilebucketを使うための設定に、以下のnode定義を追加します。

node agent01 {
  file {'/tmp/test.bin':
    ensure => present,
    source => "puppet:///extra_files/hosts",
  }
}

 ここでは分かりやすい身近な例としてhostsファイルを挙げましたが、実際の運用でこのようなhostsファイルの扱い方をするのは、さまざまな面であまり好ましくないかもしれません。hostsファイルに関してはhostリソースを使う方が好ましいでしょう。


 ここではsource属性からPuppetのファイルサーバー機能を使って、ファイルを取得するようにしています。ファイルサーバー機能の説明は本題でないため省きますが、以下のような内容を「/etc/puppet/fileserver」に記述して再起動すると、本例が動くようになります。

[extra_files]
  path /etc/puppet/files
  allow *

 ここでは多少実践的な例になるようファイルサーバー機能を使った例にしましたが、もしファイルサーバー機能を使わずに本例を試したい場合はsource属性の行を以下のように書き換えてください。

content => “192.168.xxx.254 puppet\n”,

 ファイルサーバー機能を使う場合は「/etc/puppet/files」ディレクトリ配下に、以下の内容を「hosts」というファイル名で保存します。

192.168.xxx.254 puppet

 hostsファイルの内容が同じであればPuppetを実行しても変化はありません。

 では、誰かが勝手にhostsファイルを書き換えてしまったシチュエーションを想定してみましょう。以下のように変更してしまったとします。

192.168.xxx.254 puppet
192.168.xxx.100 newserv

 悪いことに勝手に足されたエントリは大事な設定だったとします。マニフェスト側が変更されていなければ、大事な設定だとしてもPuppetは実行時に元へ戻してしまいます。そして元に戻されてしまったことが原因でトラブルが起きてしまったとしましょう。そのようなときはどうすればよいのでしょう。

 そのようなときは、最初にPuppet agentのログを確認します。以下に注目すべきログを抜粋しました。

 :
Feb 10 15:00:57 agent01 puppet-agent[26713]: (/Stage[main]/Main/Node[agent01]/File[/etc/hosts]) Filebucketed /etc/hosts to main with sum f2009e174b91fd74688655a2b4e5f2cf
Feb 10 15:00:57 agent01 puppet-agent[26713]: (/Stage[main]/Main/Node[agent01]/File[/etc/hosts]/content) content changed '{md5}f2009e174b91fd74688655a2b4e5f2cf' to '{md5}a1817dc27a3185b0a36fd482c08d7785'
 :

 2行目のログによりhostsファイルが書き換えられてしまったことが分かります。そして1行目でfilebucketにファイルを保管したと記録されており、MD5値は「f2009e174b91fd74688655a2b4e5f2cf」となっていることが分かります。中身を確認してみます。以下のように“filebucket”サブコマンドに、getオプションとハッシュ値を引数として指定します。

# puppet filebucket get f2009e174b91fd74688655a2b4e5f2cf
 
192.168.xxx.254 puppet
192.168.xxx.100 newserv

 元に戻される前、勝手に足されたエントリが入っています。このファイルをリストアしてみましょう。以下のように「filebucket」サブコマンドに、restoreオプション、リストア先ファイル名、ハッシュ値を引数として指定します。

# puppet filebucket restore /tmp/hosts.old f2009e174b91fd74688655a2b4e5f2cf

 また、マニフェストの実行に関係なく、指定したファイルをfilebucketにバックアップできる「backup」サブコマンドがあります。backupサブコマンドの引数はバックアップしたファイル名を指定します。

# puppet filebucket backup /etc/hosts
/etc/hosts: a1817dc27a3185b0a36fd482c08d7785

 さらに、以下のようにオプション「--local --bucket=[保管先へのフルパス]」を指定すると、ローカルのファイルシステムにfilebucketを作成してバックアップすることもできます。集中管理はできないですが、作業時の一時的なファイルの退避などに応用できます。

# puppet filebucket get --local --bucket=/tmp/bucket 6ed3aaaa8e394288a453a6e55ae6339b
       1|2 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。