いますぐ実践! Linuxシステム管理

いますぐ実践! Linux システム管理 / Vol.245 / 読者数:2433名

こんばんは、うすだです。

先日、某大学のオープンカレッジの最終日を迎えまして、 途中何度か欠席してしまいましたが、修了証をいただける程度には出席できました。

終わった後、講師や生徒の方々と軽く飲みに行ったのですが、 普段接点のない職種のひとの話を伺うことができて、たいへん有意義でした。

ちょうど向かいに座ったひとは、あまりに基礎的な内容だったため、 実務に活かすには至らなかったと、ややご不満のご様子でした。

いただいた名刺には、「ザ・取締役」の文字が輝いていました。
そして、さらに話を伺っていると、わたしより1つ年下であることが判明しました。
その後は、なるべく敗北感を感じないよう、年下のふりをしていました。

1時間ちょいくらいでしたが、いろんな意味で、勉強になりました。

というわけで、40過ぎのザ・平社員が、今回もはりきってまいります。

今回のお題 - Puppet でシステムを集中管理する ジェダイの復讐

前回、前々回と、Puppet についてご紹介しました。

Vol.243 - Puppet でシステムを集中管理する
http://www.usupi.org/sysad/243.html
Vol.244 - Puppet でシステムを集中管理する 帝国の逆襲
http://www.usupi.org/sysad/244.html

前回発行してから今日に至るまで、 読者様がひとりも増えないという状況に陥っておりました。

ですが、そのような凍てついた空気は無視して、今回は、 3部作の集大成ということで、管理の面から見て必要な機能を、 いくつかご紹介したいと思います。

30分毎ではなくサーバから都度設定する

前回までの設定では、 サーバ(puppetmasterdを動かしている管理する側)に設定が集約されるものの、 その設定をクライアント(puppetdを動かしている管理される側)へ反映するタイミングは、 クライアント側に任されていました。 (具体的には、30分毎にクライアントが確認をします。)

ですが、サーバの設定を変えたら全クライアントへ即座に反映させたり、 ちょっとずつ反映したい、ということもあるのではないかと思います。

そんなときのため、「puppetrun」というコマンドがあります。puppetrunを使うと、 サーバからクライアントへ、可及的速やかに反映すべしという指令を出すことができます。

そのためには、puppetrun の指令を受け付けるよう、 puppetdを設定する必要があります。
まず、設定ファイル「/etc/puppet/auth.conf」に、以下を追加します。

path /run
method save
auth yes
allow サーバ名

上記は、サーバからの指令を許可するための設定です。

allowでは、直球でサーバ名を指定する他、 「*.usupi.org」のような指定もできます。
ちなみに、バージョン3.0.0以降では、 「allow_ip」でIPアドレスによる指定もできるようです。

ただ、auth.conf に以下のエントリがある場合は、 それよりも手前に記述する必要があります。

# this one is not stricly necessary, but it has the merit
# to show the default policy which is deny everything else
path /
auth any

コメントにもありますが、上記はすべてを拒否する設定なので、 これより後に書いた設定は有効になりません。

さて、auth.conf に設定を書いたら、puppetd を再起動します。
その際、外部からの指令を受け付ける 「--listen」オプションを指定して puppetd を起動する必要があります。
また、「--no-client」オプションを指定すると、30分毎の確認をしなくなり、 puppetrun で指令があったときだけ反映するようになります。

Ubuntuなどをお使いの貴兄は、「/etc/default/puppet」の DAEMON_OPTS に、 それらのオプションを指定します。
(--no-clientを指定するなら、--server=サーバ名 の指定は不要です。)

  DAEMON_OPTS="--server=サーバ名 --listen"
  もしくは
  DAEMON_OPTS="--listen --no-client"

CentOSなどでは、「/etc/sysconfig/puppet」の PUPPET_EXTRA_OPTS に、 それらのオプションを指定します。

  PUPPET_EXTRA_OPTS="--listen --no-client"

そして、puppetdを再起動します。

  agent# service puppet restart

そうしましたら、サーバからpuppetrunコマンドを実行します。
「--host」オプションとクライアント名を指定(複数の指定もOKです)して実行すると、 クライアントに指令が渡り、設定の反映が行われます。

  master# puppetrun --host=クライアント1 --host=クライアント2 ...

ただ、やりとりに TCP のポート8139番を使うため、 iptables などで制限している場合は、開けてあげる必要があります。
(前々回言い忘れていましたが、サーバへの接続には 8140番を使います。 ですので、こちらも同様に開けないといけないです。)

テンプレートを使う

さて、集中管理するとはいえ、設定ファイルの中身が完全に共通、 というわけにはいかないこともありますよね。

そんなときには、テンプレートを使います。

たとえば、postfixの設定ファイル /etc/postfix/main.cf の myhostname と mydomain を、クライアント毎に分けたいとしましょう。

まず、サーバ側で、main.cf のテンプレートファイルを用意します。
テンプレートファイルの置き場所は、「/etc/puppet/templates/」です。
その直下に main.cf を置いて、myhostname と mydomain を以下のように記述します。 (ちなみに、直下である必要はありません。)

  myhostname = <%= hostname %>.<%= mydomain %>
  mydomain = <%= mydomain %>

お察しの通り、「<%= 名前 =>」の部分が、実際の値に置き換わります。 ここでは、hostname には同名の fact の値が入り、 mydomain には変数の値が入るものと思ってください。

そしてマニフェスト(/etc/puppet/manifests/site.pp)に、 以下のような postfix の設定を追加します。

$mydomain = "usupi.org"

file { '/etc/postfix/main.cf' :
    mode => 644,
    content => template("main.cf"),
    notify => Service['postfix'],
}

service { 'postfix' :
    ensure => 'running',
    enable => 'true',
}

template の中のパスには、 /etc/puppet/templates/ を起点とした相対パスを指定してください。 (直下の場合は、ファイル名だけで済みます。)

そして、前述の puppetrun の実行や、クライアントのpuppetdの再起動を行うと、 テンプレートファイルから生成された main.cf がクライアントに渡って、 postfix が再起動されます。

ちなみに、テンプレートは、 Ruby の ERB という標準ライブラリを使って実現されています。
「<%」と「%>」で囲まれた部分が、Ruby のスクリプトとして実行されたり、 結果がそのまま挿入されたりします。

ですので、変数の値を挿入するだけでなく、いろいろな操作ができます。
詳しくは、下記などをご覧ください。

Rubyist Magazine - 標準添付ライブラリ紹介 【第10回】 ERB
http://magazine.rubyist.net/?0017-BundledLibraries

 

…ただ、 それでも1つのテンプレートファイルに集約するのは難しいこともあると思います。 そんなときは、潔く、テンプレートファイルを分けてしまいましょう。

  ...前略...

  $postfix_main_cf = $osfamily ? {
      'Debian' => 'main.cf.deb',
      default  => 'main.cf.rh',
  }

  file { '/etc/postfix/main.cf' :
      mode => 644,
      content => template($postfix_main_cf),
      notify => Service['postfix'],
  }

  ...後略...

タグ付けする

puppetrun で都度反映できるようになりましたが、特定のリソースだけを反映したい、 ということも多々あるのではないかと思います。

そんなときは、リソースにタグをつけておくと、指定したタグだけを反映する、 という操作ができるようになります。

たとえば、前述のpostfixの main.cf のリソースに対して、 「postfix」というタグをつけるには、以下のように記述します。

file { '/etc/postfix/main.cf' :
    mode => 644,
    content => template($postfix_main_cf),
    notify => Service['postfix'],
    tag => 'postfix',
}

「tag」というパラメータを使って、タグ名をつけます。

そして、「--tag」オプションとタグ名を指定して puppetrun を実行すると、 main.cf の反映と postfix サービスの再起動だけが行われます。

  master# puppetrun --host=クライアント --tag=postfix

ちなみに、上記では main.cf にしかタグをつけていませんが、notify によって、 postfix サービスの再起動も行われます。

クラス分けする

あとひとつだけ、お付き合いください。

前述の main.cf と postfix サービスは、どちらも postfix に関連するリソースです。 じゃあ、これらをひとくくりにすると、すっきりしてよいのではないでしょうか。

というわけで、クラスという枠で囲ってしまいましょう。
書式は、以下の通りです。

  class クラス名 {
    ...内容...
  }

たとえば、前述の postfix のもろもろは、以下のようにできます。

class postfix {
    $mydomain = "usupi.org"

    $postfix_main_cf = $osfamily ? {
        'Debian' => 'main.cf.deb',
        default  => 'main.cf.rh',
    }

    file { '/etc/postfix/main.cf' :
        mode => 644,
        content => template($postfix_main_cf),
        notify => Service['postfix'],
    }

    service { 'postfix' :
        ensure => 'running',
        enable => 'true',
    }
}
include postfix

class で囲っただけですが、それだけだと読み込まれません。
最後の「include」で、その設定を取り込む必要があります。

クラスにすることで、クライアント毎にincludeできたり、 継承できたりなどの利点があるのですが、ここで言えるのは、以下の2つです。

まず、クラスの中で設定した変数は、その中でのみ有効です。
たとえば、マニフェストに以下を追加しても、

notify { 'variabletest' :
    message => "I used $mydomain and $postfix_main_cf",
}

実際に反映してみると、クラス外ではからっぽであることがわかります。

  (/Stage[main]//Notify[variabletest]/message) defined 'message' \
  as ' and '

それから、クラス名と同じタグ名が自動的につきます。
上記設定ではタグをつけていませんが、postfixタグを指定してpuppetrunを実行すると、 postfix クラス内のリソースだけが反映されます。

おわりに

以上、Puppet について、実際の管理に必須ではないかと言えるものを、 いくつか取り上げてみました。

いろいろ説明できておりませんが、あとは前回ご紹介した下記などを閲覧して、 あれこれ楽しんでみてください。

Puppet Documentation Index
http://docs.puppetlabs.com/puppet/

宿題の答え

前回の宿題は、

  複数の設定ファイルのいずれかが更新されたら、サービスを再起動する
  よう設定してみましょう。

でした。

実は、require や subscribe などは、複数指定できます。
たとえば、 main.cf か master.cf のどちらかが更新されたら postfix を再起動したいときは、 以下のように配列で指定します。

file { '/etc/postfix/main.cf' :
    mode => 644,
    content => template('main.cf'),
}
file { '/etc/postfix/master.cf' :
    mode => 644,
    content => template('master.cf'),
}
service { 'postfix' :
    ensure => 'running',
    enable => 'true',
    subscribe => [
        File['/etc/postfix/main.cf'],
        File['/etc/postfix/master.cf'],
    ],
}

main.cf か master.cf のいずれかが更新されたときに、 postfixサービスが再起動します。(両方更新されても、再起動は1回だけです。)

他でも同様に設定できます。before とかも、ぜひ試してみてください。

今回の宿題

今回の宿題は、

  Puppetの設定ファイルを、SCMで管理してみましょう。

です。

集中管理するということは、 変更管理も集中して行えるということになるのではないかと思います。

SCM(Source Code Management)は、 おそらくどれを使ってもできるだろうと思いこんでいますが、 それを確認するためにも、実践が必要ではないかと考えております。

ちなみにSCMは、個人的な嗜好により、 Mercurial か Subversion あたりを想定していますが、 もし万が一リクエストがございましたら、どしどしお寄せください。 (ご希望に沿えないこともございます。と予防線…。)

あとがき

今日…もとい、昨日は、参議院選挙でしたね。

思った通り…いえ、思った以上に与党が圧勝しましたので、 衆参のねじれが解消され、 停滞していたもろもろが進んでいくのではないかという期待が、 高まっているのではないかと思います。

個人的には、今後の日本の方向性が決まる大事な選挙だったと思っているのですが、 その割には投票率が伸びなかった(52.61% で戦後3番目に低い)ことに、 少し緊張をしております。

具体的には、アベノミクスもそうですが、憲法改正、消費税増税、TPP、 原発再稼働など、盛りだくさんのテーマだったのに、 盛り上がりに欠けたのはなんでかなーという疑問が、頭にこびりついています。

日本人は、周囲の意見に同調しやすく、 ある方向に傾くと一気にそちらへ流れていく傾向にある、という話をよく耳にします。

投票率の低さに関しても、日本人の特性を利用して意図的に操作されたのだとしたら… なんていう妄想が、何度か頭をよぎったりしております。

 

それはさておき、ちょうど一週間前、ここ愛知では、 「サマーセミナー」という催しがあり、結構著名な方々が、 講師としてたくさん参加されていました。

愛知サマーセミナー:::みんなでつくる夢の学校
http://www.samasemi.net/

わたしも市民としていくつか拝聴させていただいたのですが、 やや右よりの著名な方が、とある座談会で、憲法改正の推進派も反対派も、 第96条の改正は時期尚早だという意見で一致した、という話をされていました。

…おっと、そういう話があった、というだけにとどめておきます。

 

政治にはあまり触れたくないのですが、 どうしても書いておく必要があるように感じて、つい書いてしまいました。

いずれにしても、大人は、次の世代のために、責任を持って考え、 行動をする義務があると思います。よい未来を築くため、がんばりましょうー。

 

今回も、ここまで読んでいただき、誠にありがとうございました。
次回は、8月4日(日) の未明にお会いしましょう!

 

「いますぐ実践! Linux システム管理」の解除は、以下からできます。
http://www.usupi.org/sysad/ (まぐまぐ ID:149633)

バックナンバーは、こちらにほぼ全部そろっています。
http://www.usupi.org/sysad/backno.html

「栗日記」- はやく栗の季節が来ませんかね…暑い…。
http://www.usupi.org/kuri/ (まぐまぐ ID:126454)
http://usupi.seesaa.net/ (栗日記ブログ)
http://usupi.org/k/ (モバイル栗日記)
http://twitter.com/kuriking/ (栗つぶやき)
http://facebook.com/kuriking3 (栗顔本)


[バックナンバーのトップへ] [Linux システム管理のトップへ]

トップ

バックナンバー
    [日付順] [目的別]

プロフィール

▼ リンク

独学Linux
Linuxデスクトップ環境に関する情報が満載です。 メルマガもありますよ。
Server World
CentOS 6をサーバとしたときの設定例が、これでもかというくらいたくさん載っています。 CentOS以外のディストリビューション(Fedora, Ubuntu)も充実しています。
LINUXで自宅サーバーを構築・導入(Fedora9)
Fedora9のインストールの仕方から管理方法まで、詳しく載っています。 SearchManには情報がもりだくさんです。
マロンくん.NET
〜サーバ管理者への道〜
Linuxをサーバとして使用するための、いろいろな設定方法が載っています。 マロンくんもかわいいです。 なんといっても、マロンくんという名前がいいですね!!
日経Linux
今や数少なくなってしまったLinuxの雑誌。ニュースやガイドもあります。
Linux Square − @IT
@ITが提供する、Linux の情報が満載。 載っていない設定方法はないんじゃないでしょうか。
gihyo.jp…技術評論社
Linuxに限らず様々な技術情報が満載のサイト。 SoftwareDesign誌も、 ソフトウェア技術者は必見です。
SourceForge.JP Magazine
Linux に限らず、オープンソース関連の記事が網羅されています。
ITmediaエンタープライズ:Linux Tips 一覧
Tips というより FAQ 集でしょうか。わからないことがあれば覗きましょう。
IBM developerWorks : Linux
開発者向けですが、勉強になりますよ。
Yahoo!ニュース - Linux
Yahoo!のLinuxに関するニュース一覧です。
栗日記
システム管理とかと全然関係ありませんが、毎日栗の絵を描いています。
システム管理につかれちゃったとき、癒されたいときに、ご覧ください。:-)
WEB RANKING - PC関連
ランキングに参加してみました。押してやってください。

▼ 作ってみました

Add to Google

▼ せんでん




▼ 最近読んだ本

▼ 気に入ってる本