hacks/unix/Puppet

2011年03月11日

このエントリーをはてなブックマークに追加

エラーメッセージ

▼検証環境

  • Ubuntu 10.04.2 Server LTS
  • Puppet 2.6.4-2ubuntu1
    • storeconfigs = true
    • external_nodes = /etc/puppet/contrib/node_classifier
    • node_terminus = exec

▼puppet agent実行結果


err: Could not retrieve catalog from remote server: Error 400 on SERVER: E
xported resource File[/var/lib/puppet/modules/cluster/app/i-00000001] cannot
 override local resource on node $(puppet-agent-hostname)

原因と対応方法

▼背景

  • 関連するインスタンスのIPアドレスを登録・収集する為、storeconfigsを利用
    • IPアドレスを含んだファイルを、サーバ用途に応じたtagを指定してexport。DBであれば、tagにdbを指定。
      
        @@file { "${NODESDIR}/cluster/app/${hostname}":
          ensure => present,
          content => "${ipaddress}\n",
          tag => "cluster::app",
        }
      
    • 依存するノードのIPアドレスを収集する為、tag指定でcollect
      
      File <<| tag == "cluster::app" |>>
      
  • 次に挙げる状況を回避する為、puppet agent実行時の引数には「--fqdn サービスに紐づいた文字列」を指定していた。
    • IaaS環境であり、インスタンスのUNIXホスト名が同じ
    • UNIXホスト名が同一でも、処理させるマニフェストが異なる
    • 
      $ puppet agent -v -d --test --fqdn サービスに紐づいた文字列
      

▼原因

  • exportされたFileパス重複
    • export時のFileパスが、agentの『${hostname}』で一意に決まる物だった。
    • puppet agent実行するたびにfqdnが異なっており、fqdnに対するcollect結果のパスが既に存在していると、上書き出来ない。

▼対応方法

     
  • puppet agent実行時のfqdnを統一
    • サービスに紐づいた文字列生成は維持

あと書き

  • 本来あるべきpuppetの使い方を超えてるが故にハマってしまったのだろう。
  • 状況説明がとても難しい。

参考ページ




編集
@hansode at 13:10|PermalinkComments(0)TrackBack(0)

2011年01月27日

このエントリーをはてなブックマークに追加

masterのUNIXホスト名「puppet」から脱却

サーバのホスト名には管理用やサービス目的の名前をつけたい。puppetの設計では、masterのホスト名が「puppet」である事を期待している。だからと言って、UNIXホスト名に「puppet」を指定するのは、どうなのか。

自由にUNIXホスト名を指定しつつ、puppetのCNには「puppet」を指定する方法を今回は検証する。

▼検証環境

  • Ubuntu 10.04.1 LTS Server
  • puppet 2.6.3-0ubuntu1

▼前提条件

  • masterは起動してない
  • agentは起動してない
  • masterのホスト名が「puppet」であるものとする
  • agentのホスト名が「pclient」であるものとする

作業前に

certname変更方法は、helpには出て来ない。

今回はpuppetのソースコードを読んで発見した。

指定方法は2種類ある。

  • puppet.conf指定
  • 起動時オプション指定

作業内容

puppet.conf指定

mainセクションに「certname」を指定。

$ sudo vi /etc/puppet/puppet.conf
[main]
certname = 'puppet'
起動オプション指定

DAEMON_OPTSに「--certname」を追加

$ sudo vi /etc/default/puppetmaster
DAEMON_OPTS="--certname puppet"
共通作業

設定を反映させる為、masterを再起動

$ sudo /etc/init.d/puppetmaster restart

生成されたかどうかを確認

$ sudo find /var/lib/puppet/ssl/ -type f
...

指定した名前でpemが生成されていれば良い。更にagentからmasterへ接続して確認する事。

コード解析

/usr/lib/ruby/1.8/puppet/defaults.rb を読むと、起動オプションとして何を指定可能かが分かる。

▼certnameの場合

   190      :certname => {:default => fqdn.downcase, :desc => "The name to use when handling certificates.  Defaults
   191        to the fully qualified domain name.",
   192        :call_on_define => true, # Call our hook with the default value, so we're always downcased
   193        :hook => proc { |value| raise(ArgumentError, "Certificate names must be lower case; see #1168") unless value == value.downcase }},

デフォルトはFQDNである事が分かる。puppet/defaults.rbを観察してみると、他にも設定項目が多々ある事に気付く。

あと書き

helpやサンプルconfだけでなく、時にはソースコードから調査してみると、そこには新たな発見が待っている時もある。




編集
@hansode at 17:55|PermalinkComments(0)TrackBack(0)

2011年01月26日

このエントリーをはてなブックマークに追加

node定義を静的から動的へ

ノード数が短期間に変化する環境があるとする。
変化する度に、node.ppを変更し、masterを変更するのは徐々に面倒になって行く。
昨今のクラウド環境では、劇的変化する事は十分に考えられる。

サーバAが追加されたので、node.ppを再定義し、masterを再起動、
サーバBが追加されたので、node.ppを再定義し、masterを再起動、
サーバCが追加されたので、node.ppを再定義し、masterを再起動、

動的定義出来れば、この手間を解決出来る。
puppetには、「external nodes」と言うものがあり、動的定義が可能だ。

今回は、「external nodes」を利用してみる。

▼検証環境

  • Ubuntu 10.04.1 LTS Server
  • puppet 2.6.3-0ubuntu1

▼前提条件

  • masterは起動してない
  • agentは起動してない

external nodesの概要

変更対象はmasterのみで、agentの設定変更は不要。

  • node定義を、マニフェストファイルではなく、外部プログラムで行なう
  • 外部プログラムの標準出力でnodeを定義する
  • 外部プログラムの出力フォーマットはYAML
  • 外部プログラム実行時には、agentのホスト名が引数として与えられる

ノード数が少なければ少ない程、メリットがない。

事前作業

master側: マニフェスト設定

動作確認目的なので、動作確認用マニフェストを定義する。

▼/etc/puppet/manifests/site.pp


import "templates"

▼/etc/puppet/manifests/templates.pp


class sample::task1 { exec { task1: command => '/bin/date > /tmp/task1' } }
class sample::task2 { exec { task2: command => '/bin/date > /tmp/task2' } }
class sample::task3 { exec { task3: command => '/bin/date > /tmp/task3' } }
master側: puppet設定

▼/etc/puppet/puppet.conf を修正

mainセクションに、external nodes用設定を追加。


[main]
external_nodes = /usr/local/bin/puppet_node_classifier
node_terminus = exec

▼external_nodes用スクリプト配置


#!/bin/sh
# Super-simple external_node script for versions 0.23 and later

cat <<"EOS"
---
classes:
  - sample::task1
  - sample::task2
  - sample::task3
EOS

exit 0

動的にと言いつつ、出力結果は1パターン。
まずは動作する事を確認する。


$ sudo chmod +x /usr/local/bin/puppet_node_classifier

ここで実行許可を付与し忘れると実行出来ないので要注意。

作業内容

master側

先の手順でマニフェストを変更したので、masterを再起動して反映させる


$ sudo /etc/init.d/puppetmaster restart
agent側

マニフェストを処理してみる


$ sudo puppet agent --no-daemonize -v -l console --test
info: Caching catalog for i-jmp5qx
info: Applying configuration version '1296037770'
notice: /Stage[main]/Sample::Task1/Exec[task1]/returns: executed successfully
notice: /Stage[main]/Sample::Task3/Exec[task3]/returns: executed successfully
notice: /Stage[main]/Sample::Task2/Exec[task2]/returns: executed successfully
notice: Finished catalog run in 0.34 seconds

マニフェストファイルではなく、
外部プログラムにて定義されたマニフェストが処理されたことを確認出来る。

外部プログラム改良アイディア

工夫次第で柔軟な構成管理を行えそうだ。

  • 実行可能であれば良いので、YAMLを出力するだけでなく、別の処理が可能
    • Puppetのレポーティング機能を使わないレポーティング機能を実装
  • 引数としてagentのホスト名が指定されるので、外部プログラム内で場合分けを行う
    • シェルスクリプトであれば、case文を使用すれば条件分岐可能
  • 外部プログラムとしてRubyスクリプトなどを指定
    • Railsのrunnerで何かを実行すれば、Webアプリとの連動は容易だろう。

あと書き

external nodesを利用すると、
サーバ管理DBに新サーバのエントリを追加するだけで意図した構成で立ち上がって来る。

しかも、エントリを追加した管理者は、Puppetの使い方を知らない。Puppetの事を知らずに済む。
Puppetに限らず、いつかそんな日がやって来る。

こんな仕組を作らずに居られない。

参考ページ




編集
@hansode at 20:15|PermalinkComments(0)TrackBack(0)

2011年01月24日

このエントリーをはてなブックマークに追加

push式

通常利用のpull式ではなく、masterからagentへpushしたい場合もある。

今回はpush式の設定を行なう。

検証環境
  • Ubuntu 10.04.1 LTS Server
  • puppet 2.6.3-0ubuntu1
前提条件
  • masterは起動してない
  • agentは起動してない
  • masterのホスト名が「puppet」であるものとする
  • agentのホスト名が「pclient」であるものとする

事前作業

agent, master共に起動してない事が前提なので、

あらかじめpuppetを停止しておく。

master側
$ sudo /etc/init.d/puppetmaster stop
agent側
$ sudo /etc/init.d/puppet stop

作業内容

agent側
設定ファイル追加: /etc/puppet/namespaceauth.conf
$ sudo touch /etc/puppet/namespaceauth.conf

ファイルが存在する事に意味がある。

中身は空でよい。

設定ファイル追加: /etc/puppet/auth.conf
$ sudo vi /etc/puppet/auth.conf
path /run
method save
allow **puppet**

masterからの接続許可。

上記設定では、masterのホスト名が「puppet」の場合。

agentを起動
$ sudo puppet agent --no-daemonize -d -v -l console --no-client --listen
master側
kick(push)する
$ sudo puppet kick --host **pclient** --debug

agentへ向け、マニフェストの取得と処理を促す。

master, agent共にエラーが出なければ、agentがマニフェストを処理してくれる。

長期運用の場合、push式が良いのかpull式が良いのか悩み所。

あと書き

puppet-2.6系の情報が少ない。

今回のkick設定では、agentの/etc/puppet/auth.confが核心だった。Ubuntuの場合、agentのみインストールしている環境には/etc/puppet/auth.confが存在しない。/etc/puppet/auth.confは、puppetmaster-commonの管理対象だからだ。

同じ原因で悩む人がいない事を願う。

参考ページ




編集
@hansode at 20:45|PermalinkComments(0)TrackBack(0)

2011年01月19日

このエントリーをはてなブックマークに追加

やっとマニフェスト初心者へ

puppet環境構築しただけでは中身がない。
ようやくマニフェストを適用させてみる。

▼検証環境

  • Ubuntu 10.04.1 LTS Server
  • puppet 2.6.3-0ubuntu1

▼前提条件

  • masterは起動済み(apt-get install時に自動起動)
  • agentは起動してない
  • masterのホスト名が「puppet」であるものとする

▼要件定義

  • 内部ネットワークでの利用の為、自動署名とする
  • DNSは利用せず、/etc/hostsによる対応とする

接続確認

master編

▼自動署名設定


$ sudo vi /etc/puppet/autosign.conf
*

全内部ネットワークノードへ公開するので、「*」としておく。

agent編

▼/etc/hostsを修正


$ sudo vi /etc/hosts
> 192.0.2.30    puppet

IPアドレスは環境に合わせて修正する事。

▼masterへの接続テスト

この例では、--server には「puppet」を指定。
※masterのホスト名と一致する必要がある。


$ sudo puppet agent --no-daemonize -v -l console --server puppet --test
info: Creating a new SSL key for pclient
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for ca
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
info: Creating a new SSL certificate request for pclient
info: Certificate Request fingerprint (md5): 00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for pclient
info: Caching certificate_revocation_list for ca
info: Caching catalog for hadaka
info: Applying configuration version '1295421095'
info: Creating state file /var/lib/puppet/state/state.yaml
notice: Finished catalog run in 0.01 seconds

エラーが出なければ成功。

もしも、エラーの場合、--server に指定しているホスト名と、masterのホスト名が一致しているかを要確認。
※ホスト名とは、masterにて実行した「hostnameコマンド」の出力結果の事。

マニフェスト検証

master編

▼サンプル


$ sudo vi /etc/puppet/manifests/site.pp

# Create "/tmp/testfile" if it doesn't exist.
class test_class {
    file { "/tmp/testfile":
       ensure => present,
       mode   => 644,
       owner  => root,
       group  => root
    }
}

# tell puppet on which client to run the class
node pclient {
    include test_class
}

nodeには、agentのホスト名を指定する。
本サンプルでは、「pclient」としている。

▼masterにマニフェストを反映


$ sudo /etc/init.d/puppetmaster restart

masterを再起動

agent編

▼作成予定ファイルの存在有無確認


$ ls -la /tmp/testfile
ls: cannot access /tmp/testfile: No such file or directory

ファイルが無い事を確認。

▼テスト

作成したマニフェスト通りに処理されるか確認する。


$ sudo puppet agent --no-daemonize -v -l console --server puppet --test
info: Caching catalog for pclient
info: Applying configuration version '1295421861'
notice: /Stage[main]/Test_class/File[/tmp/testfile]/ensure: created
notice: Finished catalog run in 0.02 seconds

▼実行後の確認


$ ls -la /tmp/testfile
-rw-r--r-- 1 root root 0 2011-01-19 16:30 /tmp/testfile

ファイル生成に成功。

これ以降は、用途に合わせたマニフェストを作成して行く。


参考ページ




編集
@hansode at 16:45|PermalinkComments(0)TrackBack(0)
このエントリーをはてなブックマークに追加

再インストール

検証作業を進めてみると、
Ubuntu 10.04にパッケージングされているpuppet-0.25.4が良くないと分かった。
更に言えば、最新リリースブランチの2.6系でもない。

こう言った理由により、今回はアップグレードする事を選択。

▼検証環境

  • Ubuntu 10.04.1 LTS Server
  • Puppet 2.6.3-0ubuntu1

▼要件定義

  • Puppet-2.6系をインストール
  • Ubuntu nattyにはpuppet-2.6系が存在するので、nattyのpuppetパッケージを利用出来るように設定
  • puppetを除いたパッケージは、lucidのパッケージを継続

作業前状態確認

▼pinの設定確認


$ apt-cache policy puppet
puppet:
  Installed: (none)
  Candidate: 0.25.4-2ubuntu6
  Version table:
     0.25.4-2ubuntu6 0
        500 http://jp.archive.ubuntu.com/ubuntu/ lucid/main Packages

作業前のpuppetパッケージのpin設定を確認。

事前準備

nattyのパッケージを扱う為の設定作業を行なう。

▼デフォルトリリースをlucidの物とする

※ファイルは新規作成


$ sudo vi /etc/apt/apt.conf.d/99default-release
APT::Default-Release "lucid";

▼pin設定:全パッケージ編

※ファイルは新規作成


$ sudo vi /etc/apt/preferences.d/00default
Package: *
Pin: release a=lucid
Pin-Priority: 1

特に指定がない限り、lucidが対象となる

▼pin設定:puppet編

※ファイルは新規作成


$ sudo vi /etc/apt/preferences.d/99puppet
Package: puppet, puppet-common, puppetmaster, puppetmaster-common
Pin: release a=natty
Pin-Priority: 1001

puppet関連パッケージは、nuttyのパッケージを対象とする

▼nuttyのapt-lineを追加

※ファイルは新規作成


$ sudo vi /etc/apt/sources.list.d/ubuntu-natty.list
deb http://jp.archive.ubuntu.com/ubuntu/ natty main restricted
deb http://jp.archive.ubuntu.com/ubuntu/ natty multiverse

設定反映

事前準備の設定を反映し、変化を確認する。

▼ローカルaptキャッシュを更新


$ sudo apt-get update

▼pinの設定確認


$ apt-cache policy puppet
puppet:
  Installed: (none)
  Candidate: 2.6.3-0ubuntu1
  Version table:
     2.6.3-0ubuntu1 0
        500 http://jp.archive.ubuntu.com/ubuntu/ natty/main Packages
     0.25.4-2ubuntu6 0
        500 http://jp.archive.ubuntu.com/ubuntu/ lucid/main Packages

Virsion tableフィールドにnattyのpuppetが追加されている事を確認。

作業内容

puppet関連パッケージはnattyをインストールする。

インストール時には、「パッケージ名/natty」を指定する。
省略した場合は、lucidのパッケージがインストールされる。

または、-t nattyとしても良い。
インストール対象数が多く、しかも全てがnattyの場合は、-t nattyが便利。

▼インストール: master編


$ sudo apt-get install puppetmaster/natty puppetmaster-common/natty puppet-common/natty

▼インストール: agent編


$ sudo apt-get install puppet/natty puppet-common/natty

これでpuppet-2.6系環境が整った。


参考ページ




編集
@hansode at 12:50|PermalinkComments(0)TrackBack(0)

2011年01月17日

このエントリーをはてなブックマークに追加

まずはインストール

必要に迫られたので、いよいよPuppetを触り始める。

長らく検証対象にノミネートしていたけど、実行に移すまでは至らなかった。
しかし、今回はいよいよ検証する。

▼検証環境

  • Ubuntu 10.04.1 LTS Server
  • Puppet 0.25.4-2ubuntu6

作業内容

puppetマスター編

▼インストール


$ sudo apt-get -y install puppetmaster
puppetクライアント編

▼インストール


$ sudo apt-get -y install puppet

▼必要に応じて起動設定


$ sudo cp -pi /etc/default/puppet /etc/default/puppet.0
$ sudo vi /etc/default/puppet

$ diff /etc/default/puppet.0 /etc/default/puppet
4c4
< START=no
---
> START=yes

システム起動時の起動対象となる。
まだマニフェストが無い状態なので、自動起動対象にしても大した意味はない。


debパッケージのおかげでインストール作業は実に簡単。
次回は起動と初歩的な設定を行ってみる。


参考ページ




編集
@hansode at 22:05|PermalinkComments(0)TrackBack(0)