自動化

2013年12月06日

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

Wakame Users Group Advent Calendar 2013 12/06担当 (2回目の登場)

Wakame2-logo-mini

「使ってみました/インストールしてみました」は他の方にお任せし、現場の悲鳴をお届けします。

2012/06末 こんにちは、『結合苦』さん

前エントリの継続RPMビルドする仕組み作りの裏では『結合苦』との戦いを繰り広げていた。

ファイル配置程度のインストール作業は、パッケージングによって軽減されていたが、コミッターは結合作業の事は気にせず、思い思いのタイミングで新機能をコミットして来る状況だった。当時の結合作業の大半は自分ひとりで行っていたので(そして今も)、システム結合に悩まされるのは自分ひとり。極度の結合苦に悩まされていた日々。

  • 「何故こうなったのか・・・」
  • 「何故こうなるのか・・・」
  • 「いっそのこと、開発を一時中断できないものか・・・」

苦い経験を踏まえ、後に実感した事は、

  • 「新たなRPMがビルドされてから結合するまでの時間が長ければ長い程、結合苦に陥る」

今となっては当たり前な着地点だが、当時は、それを身体で感じられなかった頃。結合苦を乗り越えたくて、早め早めに結合する作業へ挑み始めたのが、2012/06末。

2012/07 「インスタンス起動/破棄」連続成功への道

Wakame-VDCにおける結合成否の指標の1つ、それは、WebUIからインスタンス起動してインスタンスにログイン出来る事。もしもログイン出来なければ、容赦なく結合失敗と判断されてしまう。たかがログインの舞台裏には、幾つも前提条件が存在している。

  • インスタンスが起動している事
  • インスタンス管理エージェントが起動している事
  • APIサーバが起動してる事
  • WebUIが起動してる事
  • DBサーバが起動してる事
  • ○○・・・が起動している事

更に各コンポーネントが協調して動作する必要がある。

  • 起動順序通りに起動してる事
  • 各configが正しく設定されている事
  • 初期データが投入されている事
  • etc.

これ等は氷山の一角で、前提条件は他にも多々ある。何か1つでも条件が不足していると、ログイン可能状態にならないのは言うまでもない。動かない原因を1つ1つ分析し、動かすための組み合せを探って行く。とある組み合わせで動いていても、新たにビルドされて来た新機能入りRPMパッケージで入れ替えてみると、あっさり動かなくない。ふり出しへと戻される・・・。

2012/08 結合失敗回数と結合成功回数が、逆転する

原因を調査・分析、新たな動く組み合せを作っては、新たな変更によって壊れて行く。この泥臭い修復作業を、ただただ、繰り返す。何度か調査回数を重ねて行くと、似た調査パターン・コマンドセットに分類されて行く。例えばインスタンス作成失敗時エラーログに対するgrepコマンドの組み合わせ。そんな時はコマンドヒストリを駆使し、以前使ったコマンドを分析。少しずつ改良を重ね、手順を少しずつ確立させ、継続的に改善して行く。

  1. 調査手順を確立
  2. 調査手順を分析
  3. 手順を簡略化・単純化
  4. 内容によってはスクリプト化

結果、出来上がるのは、アプリケーション監視相当の仕組み。外堀が埋まって行った。

また、その当時、調査作業と並行してデプロイ作業改善も同時に進めていた。2012/07末にはパッケージ自動ビルドする仕組みを作り上げていたので、残り作業は、

  1. パッケージリポジトリを常時監視
  2. リポジトリが更新されていれば、新パッケージを関連ノードにインストール
  3. インストール後、プロセス再起動

この一連の流れを行うデプロイパイプラインの成長につれシステム全体が安定したのは、2012/08末の頃。 ただ、これは、特定環境におけるパイプラインであり、ポータブルなパイプラインを手に入れるまでには、まだ時間が必要だった。その辺の話は、別エントリに持ち越し。




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

2013年12月04日

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

Wakame Users Group Advent Calendar 2013 12/04担当

Wakame2-logo-mini

「使ってみました/インストールしてみました」は他の方にお任せし、現場から見た風景をお届けします。

お粗末な対応からパッケージング生活へ

「Wakame-VDC RPM化」の話が舞い込んで来たのは2012年03月。RPM化以前のパッケージデプロイ手順は、下記の通りで、大分お粗末なものだった。

  1. ビルドサーバでbundle update等を半手動実行
  2. ビルドサーバからアプリケーションサーバへrsyncによる半手動デプロイ
  3. 依存関係に従い、プロセス再起動

少なくとも半年以上は同様のお粗末な対応でその場をやり過ごし続けていた。やがて、RHEL系の構築需要が高まり、政治的圧力も手伝い、RPM化が本格始動したのが2012年03月。ここからパッケージング生活へとシフトして行く。

RPM化へ向けて生きた参考材料収集

参考にしたのは、openstack-rhel。

当時は既にGitHubのおかげでrpmspecファイルを探す事も簡単になっていた頃。それまでは、SRPMをダウンロードしてインストールする等の作業を必要としたが、GitHub登場により状況は一変した。プログラミングのソースコードだけでなく、パッケージングの領域までオープンになりつつあった。

2012/04/17 rpmspec初コミット

最初の wakame-vdc.repoをコミットしたのは、2012/04/17。この日付には意味があり、Wakame-VDCがリリースされたのは、更に2年前の2010/04/17。2歳のお祝いと、成長の証として、この日にコミット。

2012/07/20 継続的RPMビルド開始 (cron方式)

初コミットからしばらくの間は手動実行で間に合う回数だったが、コミット頻度に比例してビルド需要が高まる。とある時期から手動運用では間に合わなくなり始め、リポジトリの先頭コミットハッシュを監視し続ける簡単な仕組みを導入し、自動ビルドさせる仕組みを導入したのが2012/07/20。小さな変化だったが、手持ち作業に注力出来るようになり、自動化による恩恵を、ジワジワと身体で感じ始めた頃。

2012/08/24 RPMビルド結果メール通知

継続的RPMビルドが安定稼働し始めると、『ビルド結果がどうだったのか』それを知りたい!と言う需要が高まり、ビルド成否をメール通知を開始。この頃から『少なくとも帰る前にコミットするルール』が開発メンバー内で自然に定着し始める。RPM化着手してから半年弱の出来事。

自動化体質へシフトし始めた半年間

パッケージングをきっかけに得た事は、数知れず。

  • 継続的ビルドがどう言うものか
  • 何を気を付けるべきか、何を気を付けるべきだったか
  • 開発プロセスの改善とは

自動化による恩恵を身体で感し始めた半年間。その後の品質向上について検討可能な時期へとシフトして行く話は、別エントリに持ち越し。




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

2013年06月28日

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

継続的改善と自動化が品質を作り上げる

GW代休として、丸一週間お休みを頂いた。
今回の休暇は、いつもとは、一味も二味も違うものであった。

その要因は、自動化。

自動化による脱属人化

下記は、苦しみながら、この1年間で積み上げたWakame-VDCに関する自動化の一部で、今はJenkins(CIサーバ)さんが行っている。

  1. (誰かがSCMにコードをプッシュすると)変更を検知
  2. アプリケーションパッケージを生成
  3. パッケージリポジトリを再構築
  4. パッケージリポジトリから新規VMイメージをビルド
  5. ビルドされたVMイメージを起動
  6. VMに対し、スモークテストを実行
  7. テスト結果をチャットへ通知

ビルドが失敗した時は、ビルドを失敗させたコミッターが、失敗レポートを閲覧して対応する。
休暇中、一度だけビルドが失敗していたが、直ぐに修正され、自分に連絡が来る事は無かった。

これらの工程・処理に関しては、脱属人化に成功した。
自動化により、自分自身が一番助かっている。

身体で感じる重要性

CI環境は、作ってみない限り、その良さと意味が分からない事は、多々ある。
情報整理を兼ね、これまでの取り組み、支える技術等を書き綴ってみる事にする。

継続的インテグレーション入門 開発プロセスを自動化する47の作法
ポール・M・デュバル スティーブ・M・マティアス アンドリュー・グローバー
日経BP社
売り上げランキング: 132,948



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

2013年01月14日

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

Bash + Vagrant ⇒ Bagrant

これまでに何度も仮想マシンイメージを作って来て、どこか面倒臭さを感じていた。そんな中、Vagrantに出会い、ソレが欲しかったモノの1つであると感じ、調査・検証・評価。そして、bash実装する事にした。

Bagrantの機能
  • Bagrantfileで仮想マシンを定義
  • bagrantコマンドで仮想マシンをビルド・起動・停止
  • ハイパーバイザーはKVM
利用ライブラリ

自作したvmbuilderのみ。

使い方

詳細はhansode/bagrantを参照の事で、起動までは、下記手順で行える。

  1. Bagrantfileを作成 $ bagrant init
  2. 仮想マシンイメージをビルド $ bagrant build
  3. 仮想マシンを起動 $ bagrant up

また、hansode/bagrant-boxがBagrantfileを含んだテンプレート集となっているので、Bagrantfileを自作したい方の参考になるはず。

開発期間

移植作業だったので、結構あっさりと実装出来た気がする。

  • 設計: 3日(主にVagrantの調査)
  • 実装: 2日
今後の予定

開発した動機がそうであるように、何か機能追加される事があったら、自分自身が欲しいと思ったタイミング。

あとがき

これも、まだ、自動化したかった事の1つでしかない。

フィードバックなど

もしBagrantに興味がある方がいらっしゃいましたら、ご一報下さい。

続きを読む


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

2012年11月01日

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

複数ディストリビューション対応へ向けて

ギーク達はfedora対応を希望

前回のエントリに反応してくれたギーク達は、CentOSよりもfedora対応を希望していた。『fedora対応…!』と思ったけども、fedoraを使ってないので良くわかってない。それよりは、複数ディストリビューション対応への準備体操として、CentOS 5対応に着手してみた。

検証環境

インストール
$ git clone git://github.com/hansode/vmbuilder.git
実行方法
$ cd vmbuilder/kvm/rhel/6/
$ sudo ./vmbuilder.sh --distro-name=**centos** --distro-ver=**5**

実行してから約10分程度で実行したディレクトリ直下に仮想マシンイメージが作成される。

2012/11/01現在の対応ディストリビューション

distro-name と distro-ver に指定可能な組み合わせは下記の通り。

  • centos 5 (5.x)
  • centos 6 (6.x)
  • sl 6 (6.x)

新規追加されるタイミングは、今の所、自分が欲しいと思う時か、聞こえて来る周りからの声。

問題点

rhel6環境でrhel5を構築すると、仮想マシンイメージを作成可能ではあるが、rhel5環境としては不完全だ。

  • 今のvmbuilder.shの仕様では、ホスト環境のyumコマンドでゲスト環境を構築する
  • ゲスト環境におけるrpmdbのフォーマットは、ホスト環境に依存する

個人的に困ってないので、しばらくの間は保留扱い。

改善案

検証すべき項目

  • ホスト環境とゲスト環境を一致させる
    • 例) rhel5用仮想マシンイメージを構築する場合は、rhel5環境で行う
  1. post installフェーズで、rpmdbを変換するなどの対応をする
  2. yumコマンドかyum.confにrpmdbのバージョン指定する方法があれば、指定してみる

上記のうち、 1 が良さそうなので、対応手段は、構築フェーズを分ける事だろうか。

  1. ゴールとなる仮想マシンをビルドする為のビルド環境(1次chroot環境) を構築
  2. 構築されたビルド環境(1次chroot環境)にて、ゲスト環境(2次chroot環境)を構築
  3. ホスト環境にてマシンイメージ化

これで対応出来そうな気がするので、あとは検証・実装するだけの事。この辺をしっかり実装しておかないと、fedora対応も大変そう。

あとがき

環境差異が発生するとは面白い事。

フィードバックなど

希望するネタ等、フィードバック、大歓迎です。

続きを読む


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

2012年10月25日

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

コマンドラインで仮想マシンイメージを作ろう!

面倒臭かった。世の中に出回っているCentOS用仮想マシンイメージ作成手順が。

  1. インストールDVD(ISOファイル)を用意
  2. virt-installコマンドを多数のオプション指定で実行…
  3. VNC接続して…

この手順には問題・課題があり、幾つか挙げると、

  • 手作業が入るので多少なりとも作業ブレが発生
  • 自動化すべく、kickstartを使うとしても、ks.cfg作成などの準備作業が面倒臭い
  • libvirt依存、KVM依存
  • どうやってテストする…?

Ubuntuであれば、VMBuilderが上記の問題・課題を解決してくれる。

$ sudo apt-get install ubuntu-vm-builder
$ sudo vmbuilder [options]....

vmbuilderコマンド実行後、10分ほどで仮想マシンイメージを作成される。

vmbuilderのお手軽さを知っていると、CentOSにおいても同様・同等の事が出来る事を期待した。しかし、残念ながら、VMBuilderはubuntu用だった。ゆえに、VMBuilderではCentOS用の仮想マシンイメージを作成出来ない。VMBuilderに似たツールを探してみたが、満足の行く物は見つからなかった…。

無いなら…作ろう!そして作った。bashで!

検証環境

  • RHEL 6.X / CentOS 6.X / Scientific Linux 6.X
  • bash 4.00
  • git 1.7

※他にkpartxやpartedなどに依存するが、本エントリでは詳細な依存パッケージは省略。

インストール
$ git clone git://github.com/hansode/vmbuilder.git
実行方法

KVM環境がなくても、KVM用仮想マシンイメージを作成可能なのである。

$ cd vmbuilder/kvm/rhel/6/
$ sudo ./vmbuilder.sh

実行してから約10分。実行したディレクトリ直下に仮想マシンイメージが作成される。

⇒ centos-6.3_x86_64.raw

※2012/10/25 現在、 centos-6.3 がデフォルトセット。

動作確認

出来上がった仮想マシンイメージを軽く確認したくなる。その場合は、下記手順でkvm-ctl.shを実行。 ここで初めてKVMが登場する。kvm-ctl.shはkvmコマンドのラッパースクリプトなので、virsh系のコマンドは不要。依然として、libvirtに依存しないまま。

$ sudo ./misc/kvm-ctl.sh start --image-path=./centos-6.3_x86_64.raw

tcp/6901でVNCが口を開けてるので、VNCクライアントで接続する。

仮想マシンにログイン
  • user: root
  • pass: root

開発用途なので、脆弱なパスフレーズで良いものとしてる。

あとがき

これは、まだ、自動化したかった事の1つでしかない。

フィードバックなど

本エントリはインストール手順と実行手順に留めておき、次のエントリからは開発苦労話などを執筆予定。 希望するネタ等、フィードバック、大歓迎です。

続きを読む


編集
@hansode at 15:00|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)