GitやDockerと連携するPuppet運用テクニック、filebucketによる自動バックアップ、GUIのPuppet Dashboard:新人インフラ技術者のためのサーバー構築/運用自動化入門(終)(1/2 ページ)
サーバー構築の自動化で利用される技術、自動化ツールとして「Kickstart」「Puppet」を紹介し、構築から運用まで、システムライフサイクル全体にわたる運用管理の自動化についても解説する連載。今回は、filebucketによる自動バックアップやGitやDockerと連携する運用テクニック、GUIのPuppet Dashboardなどを紹介する。
前回の『作業手順書はもういらない! Puppetにおける自動化の定義書「マニフェスト」の書き方と基礎文法まとめ』までで、Puppetの運用について一通り学ぶことができました。連載最終回の今回は、K男さんとR子さんの日常の小ネタあるある形式で、運用に役立つPuppetのTipsを紹介します。
転ばぬ先の杖――filebucketによる自動バックアップ
R子 キャー!(泣)
K男 どうした!?
R子 間違ってマニフェスト適用しちゃって、大事なファイルを消しちゃったんですぅ(泣)
K男 そんなときは「filebucket」から戻せるけど……後でお説教だ!(怒)
Puppetには、「filebucket」という、fileリソースが対象のファイルを変更する前に自動的にバックアップする機構があります。この機構をagent/master型の運用で使うと、agentノードで変更する前のファイルがmaster側に保管されるようになり、変更前ファイルの集中管理が可能になります。図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
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- エンタープライズでもInfrastructure as Code――Chef 12/Chef-Zero/Knife-Zeroの基礎知識とインストール
エンタープライズ向け機能が充実してきたChefを使って高速かつ精度の高いサーバーインフラを構築/管理する方法について解説する連載。初回は、Chef 12、Chef Solo、Chef Server、Chef-Zero、Knife-Solo、Knife-Zeroの概要と、Chef-ZeroをKnife-Zero経由で利用するCookbook開発環境の構築について解説します。 - PowerShell Desired State Configuration(DSC)とは(前編)
Windows OSの設定や構成を変更する場合、GUIの管理ツールを使うのが一般的である。だが台数が多かったり、構成変更や以前の構成への復旧などが頻繁だったりするとGUIでは非常に面倒だし、間違いもしやすくなる。こんな場合はPowerShell DSCを使ってインフラ構築作業を自動化するとよい。 - JobSchedulerの機能と設定〜基礎編
本連載では運用管理の一要素である「バッチジョブ管理」に着目し、より効率よいバッチジョブ管理を実現するためのツールであるオープンソースの「JobScheduler」について解説します。 - DevOps実践に有用なZabbixの機能〜自動化機能で運用負荷削減
ますますクラウド化が進む環境において、システムにはより迅速な対応が求められるようになっています。変化の早いシステムを適切に運用していくためにはどうすればいいのでしょうか? この記事では、クラウドやDevOpsを前提としたITシステムの「運用」に求められることを整理し、そういった運用に対して、オープンソースの統合監視ツール「Zabbix」がどのように有効活用できるかを紹介します。 - 工数削減だけじゃない、自動化ツールの真のメリット
運用自動化というと「人員削減」「コストが掛かる」といったネガティブな見方をする向きも多い。だが仮想化、クラウド時代において運用自動化とはそれほど単純なものではない。国内ベンダ4社のツールに真の意義を探る。 - 運用自動化ツールは経営の武器へ
運用自動化というと「コスト削減」「効率化」といったイメージが強いが、攻めの経営を支える武器となるものでもある。後編では外資ベンダー3社の運用自動化ツールを紹介する。