Cfengine を使用してインフラ管理を自動化する: 第 1 回 サーバーとクライアントをインストールする

Cfengine はデータ・センターの自動化ソリューションとして、世界のさまざまな組織で一般的に使われています。Cfengine は非常にスケーラブルであり、ラップトップ PC やデスクトップ PC、組み込み機器からメインフレームに至るまで、何万台ものマシンに対応することができます。この多用途で柔軟な技術を使用してデータ・センターの問題を解決する方法を学びましょう。

Joanne Icken, Advisory Software Engineer, IBM

Joanne Icken は IBM のソフトウェア・エンジニアであり、企業のアプリケーションをサポートする中で、システム管理、分散環境、クラウド技術の活用などを経験してきています。



Todd Palmer, Advisory Software Engineer, IBM

Todd Palmer は IBM Innovation System チームのソフトウェア・エンジニアとして、構成管理と自動化のソフトウェアを実装しています。その前はIBM Watson Research の Information System Client Engineering Team で働いていました。



2011年 6月 03日

はじめに

今日の IT データ・センターが提供する (保守を含む) サービスは、さまざまなタイプのサーバー・ハードウェアおよび、さまざまなオペレーティング・システム (いくつかのバージョンを含む) の上で実行され、セキュアかつスケーラブルで安定しているものでなければなりません。こうしたサービスでは効率が重要視され、管理者はサポートを最小限にとどめるために、サービスを完全自動化する必要があります。この 2 回連載の記事、「Cfengine を使用してインフラ管理を自動化する」では、システム管理と IT 管理の自動化フレームワークである Cfengine について詳しく探ります。

この連載の第 1 回では、Cfengine 3 Community Edition の概要、そして Cfengine のポリシー/ディストリビューション・サーバーとクライアントの作成および構成方法について説明します。第 2 回ではその続きとして、さまざまなサービスのサポートにかかわる多くの日常的なタスクを Cfengine を使用して実行する方法について説明します。

この記事では前提として、ベースとなる UNIX または Linux オペレーティング・システムを既にインストールしてあり、Cygwin と Linux をパッケージ化するためのコマンドを理解しているものとします。


構成管理と Cfengine

適切な構成管理によって、IT プラットフォームおよび IT 製品のパフォーマンス特性、機能特性、物理特性、そしてそれらの環境に関して一貫性を確立、維持することができます。また、セキュリティー機能が適切であるかどうかを判断したり、セキュリティー機能が適切に適用されていることを確実にしたりするためにも構成管理が使用されます。構成管理は複雑な作業であり、構成管理に使用できるツールは数多くあります。

Arusha Project (ARK) などの一部のツールは Cfengine と組み合わせることができます。他にも似たようなシステム管理の概念を用いるツールがありますが、それらのツールはそれぞれ異なるプログラミング言語で作成されています。例えば Puppet は Ruby で作成されており、REST 呼び出しを使用します。Synctool はPython で作成されており、SmartFrog は Java 技術をベースとしています。それら以外にも、opsi (Open PC Server Integration) など、Windows 専用に作成されたツールもあります。IBM Systems Director や、最近買収された IBM BigFix にも構成管理ツールがあります。

Cfengine は、コンピューター・システムを自動化するための GNU オープンソース構成管理フレームワークです。Cfengine は軽量であり、ほとんどすべてのプラットフォームを対象としてビルドすることができます。Cfengine は一般的なプラットフォームのすべて (AIX、Linux、UNIX、Apple、Windows など) において、ネイティブで実行することができます。

IT Infrastructure Library (ITIL) は、世界の IT サービス管理で最も広く採用されている手法です。ITIL ではサービス提供の鍵となるプロセスとしてナレッジ管理を定義しています。ナレッジ管理により、適切な知識を持った人であれば、ビジネスに求められるサービスを確実に提供し、サポートすることができます。その前提となるのは、サービスによってもたらされる価値を明確に理解した上で、必要に応じて入手可能な関連情報とともに、サービスを効率的に提供することです。Cfengine 3 は管理ライフサイクルのあらゆるフェーズにおいて、ナレッジ管理を重視しています。Cfengine は、指定された構成を使用することによって、確実にパッケージ、構成ファイル、ファイル・アクセス権を適切なものにすること、そしてお使いの環境で確実にプロセスが実行されるようにすることができます。

Cfengine には、長年使われている Community Edition と商用の Enterprise Edition という 2 つのエディションがあります。商用エディションには、Nova、Constellation、Galaxy など、いくつかの製品があります (「参考文献」を参照)。


ライフサイクル管理

Cfengine はシステムのライフサイクル管理に関し、BDMA (Build-Deploy-Manage-Audit) モデルに従っています。BDMA は、システム・ライフサイクルの 4 つのフェーズ、つまり Build (ビルド)、Deploy (デプロイ)、Manage (管理)、Audit (監査) で構成されています。ビルド・フェーズでは、ポリシーの変更計画、望ましい状態についてのプロミスの策定、そして提案されるプロミスのテンプレート作成を行います。すべてのマシンがこれらのプロミスを作成して維持すれば、システムはシームレスに機能することになります。

デプロイ・フェーズでは、自律的なクライアントすべてに対してポリシーを公開し、各クライアントはエージェントを実行します。クライアントが実行するエージェントは、公開されたポリシーの実装および長期にわたる保守を単独で行うことができます。

管理フェーズでは、自律的なエージェントがシステムを管理してくれるため、ユーザーは自動処理されない例外的なイベントのみを処理します。

そして監査フェーズでは、変更をローカルで監査、管理します。決定によってもたらされる結果は Cfengine の設計によって保証され、自動的に管理されます。

Cfengine をロールアウト・システムと考えてはなりません。ロールアウト・システムでは、エラーが発生した場合には完全な変更を強制的に除外して元に戻そうとしますが、Cfengine ではポリシーの改定履歴を公開することで、(元に戻ることなく) 常に先へと進んで行きます。状態の変更は個々のクライアントによってローカルで管理され、継続的に修復されることによってポリシーが遵守されます。

依存関係

Cfengine には、OpenSSL と BerkeleyDB V3.2 以降が必要です。オプションとして、PCRE (Perl Compatible Regular Expression) ライブラリー、OpenLDAP、そして PostgreSQL または MySQL のサポートを組み込むことができます。一部のデータベース機能は商用エディションでしか利用することができません。Windows の場合、Cfengine には Cygwin 環境が必要です。また、Subversion (SVN) などのバージョン管理ソフトウェアを使用して構成ファイルの変更を制御することもできます。

用語

  • プロミス — システムが従うべきものとして定義されるアクションまたはルール
  • バンドル — プロミスのグループ
  • ポリシー — 私達が管理できる実際のナレッジを定義するバンドル
  • クラス — 変数と属性のセットとして真/偽が評価されるプロミス
  • ポリシーはプロミスのバンドルで構成されます。
  • 鍵 — 公開鍵または秘密鍵のいずれかで、クライアントがサーバーにアクセスする際の認証に使用されます。各クライアントで cf-key を使って生成され、サーバーの鍵ストアにコピーされます。IBM では、サーバー鍵を使用するだけで十分なセキュリティーを実現することができます。

準備

Cfengine は任意の UNIX サーバーで実行することができ、また Cygwin 環境を利用することで、Windows でも実行することができます。UNIX サーバーでは、まず OpenSSL と BerkeleyDB をインストールし、続いて先ほど説明した他のパッケージをインストールします。Cfengine は通常、ディストリビューション・パッケージ (rpm や deb など) からインストールすることができます。あるいはソース・コードをダウンロードしてコンパイルすることもできます (「参考文献」を参照)。

ソース・コードから Cfengine をビルドしようとする場合には、gcc、flex、bison といったツールも UNIX/Linux サーバーにインストールする必要があります。Windows サーバーの場合には、まず Cygwin をインストールし、続いて gcc、flex、bison をインストールした後、コードをコンパイルしてインストールします。

Cfengine のベースとなるファイルは、Cfengine の作業ディレクトリーのサブディレクトリーである /var/cfengine にインストールされます。この作業ディレクトリーは Cfengine 自体の動作のために使用され、ビルド時に定義されます。このパスもセキュアなローカル・ファイルシステムとみなされます。コーディングされた構成ファイルは、すべての Cfengine サーバーの構成ディストリビューション・ポイント (/var/cfmasterfiles など) に配置されます。このパスは、通常、バージョン管理の対象となります。

ソース・コードから Cfengine をビルドする

Cfengine のリポジトリーからソース・コードをダウンロードします。非 root ユーザーとしてシステムにログインし、以下のコマンドを実行します。

tar –zxf cfengine-x.x.x.tar.gz
cd cfengine-x.x.x
./configure --prefix=/var/cfengine 
   --sbindir=/var/cfengine/bin --localstatedir=/var/cfengine
   --with-workdir=/var/cfengine --with-openssl=/usr make

今度は root ユーザーに切り換え、以下のコマンドを実行します (バイナリー・ファイルは /var/cfengine/bin にあります)。

make install 
make installcheck

ポリシー/ディストリビューション・サーバーに Cfengine をインストールする

root ユーザーとしてシステムにログインし、以下のコマンドを実行します。

mkdir –p /var/cfengine/masterfiles
cp cfengine-x.x.x/inputs/update.cf to /var/cfengine/masterfiles
cp cfengine-x.x.x/inputs/promises.cf to /var/cfengine/masterfiles

promises.cf ファイルの mailto オプションを適切な E メール・アドレスに更新します。サーバーが接続元として受け付けるネットワークを promise.cf の body server control セクション (「サーバー制御本体」セクション) に追加します。

allowconnects => { "192.", "10.", "127.0.0.1" , "::1" };
allowallconnects => { "192.", "10.", "127.0.0.1" , "::1" };
trustkeysfrom => { "192.", "10.", "127.0.0.1" , "::1" };

すべての構成ファイルのポリシー・サーバーを新しいサーバー環境に更新します。

cp cfengine-x.x.x/inputs/failsafe.cf to /var/cfengine/masterfiles
cp cfengine-x.x.x/inputs/cfengine_stdlib.cf to /var/cfengine/masterfiles

Cfengine のコンポーネント

Cfengine のインストールにおいて注目すべきコンポーネントの一覧を以下に示します (注: Cfengine をバイナリー・パッケージからインストールした場合、またはコンパイルしてインストールする際に何らかのカスタマイズを行った場合には、ベース・ディレクトリーが以下とは異なる可能性があります)。

ディレクトリー

  • /var/cfengine/bin — Cfengine のバイナリー・ファイルがあるディレクトリー
  • /var/cfengine/inputs — Cfengine の構成ファイルがあるディレクトリー
  • /var/cfengine/outputs — Cfengine の実行レポートがあるディレクトリー
  • /var/cfengine/ppkeys — 認証鍵のあるディレクトリー
  • /var/cfmasterfiles — ポリシー・サーバーのマスター・ファイルがあるディレクトリー
  • /var/cfengine/repository — リカバリー用として Cfengine の重要なファイルのバックアップ (構成可能な名前と場所) を含むディレクトリー

バイナリー・ファイル

  • /var/cfengine/bin/cf-promises — プロミスの構文をチェックするコマンド
  • /var/cfengine/bin/cf-agent — システムの状態に関して共通バンドルとエージェント・バンドル内で作成されたプロミスを管理するコマンド
  • /var/cfengine/bin/cf-serverd — ポリシー・ファイルまたはデータ・ファイルをクライアントに配布し、cf-runagent からのリクエストに応答するためのサーバー (デーモン)
  • /var/cfengine/bin/cf-execd — cf-agent の実行をスケジューリングするデーモン
  • /var/cfengine/bin/cf-runagent — リモート・マシンで cf-agent を実行するコマンド
  • /var/cfengine/bin/cf-monitord — システムの状態に関する情報を収集するデーモン
  • /var/cfengine/bin/cf-report — Cfengine に組み込まれたデータベースのサマリー・レポートおよびその他のレポートを生成するコマンド
  • /var/cfengine/bin/cf-know — いくつかのプロミスから ISO 標準のトピック・マップ (ナレッジ・モデリング・エージェント) を生成するコマンド
  • /var/cfengine/bin/cf-key — すべてのホストで 1 度だけ実行され、セキュアな通信のための公開鍵と秘密鍵のペアを生成する鍵生成ツール

構成ファイル

  • /var/cfengine/inputs/promises.cf — cf-agent が使用するメインの構成ファイル
  • /var/cfengine/inputs/library.cf — 再利用可能なコードの集合を含むコミュニティー・ライブラリー (V3.1.x リリースの場合、コミュニティー・ライブラリーを使うのが最適です)

Cfengine ポリシー・サーバーを初めて起動する

サーバーで以下のコマンドを実行します。

/var/cfengine/bin/cf-key
mkdir /var/cfmasterfiles/ppkeys
cp /var/cfengine/ppkey/localhost.pub /var/cfmasterfiles/ppkeys/root-<servername or ip>.pub
cp /var/cfengine/ppkey/localhost.priv \
/var/cfmasterfiles/ppkeys/root-<servername or ip>.priv
cp /var/cfmasterfiles/inputs/update.cf /var/cfengine/inputs/
cp /var/cfmasterfiles/inputs/failsafe.cf /var/cfengine/inputs/
/var/cfengine/bin/cf-agent –bootstrap

これで Cfengine ポリシー・サーバーが構成されました。リモート・クライアントに対して Cfengine を準備するためには、コマンド start cf-server を実行します。

ほとんどの環境では、構成によって cf-serverd を実行することができます。それ以外の場合には、皆さんのサーバー構成用に単独の構成ファイルを用意することが望ましいです。そうすることで、プロセスが突然異常終了した場合にも、外部プロセスはその構成ファイルから cf-serverd の場所を突き止めて再起動することができます。また、cf-serverd を再起動するためのウォッチドッグ・スクリプトを持つこともできます。コマンドラインから cf-serverd を実行するためには、以下のようにします。

/var/cfengine/bin/cf-serverd
/var/Cfengine/bin/cf-serverd –f
/var/cfmasterfiles/prod/server/server.cf

クライアントの初期設定

  1. /var/cfengine/inputs/failsafe.cf
  2. /var/cfengine/inputs/update.cf
  3. /var/cfengine/ppkeys/root-<server>.pub

Cfengine クライアントを初めて起動するときには、以下のコマンドを実行します。

/var/cfengine/bin/cf-key
/var/cfengine/bin/cf-agent –K –bootstrap

自分の環境用にバイナリー・パッケージを作成する

ここではクライアントを構成するための APT パッケージまたは RPM パッケージを作成します。1 つのパッケージには Cfengine のバイナリーが含まれ、もう 1 つのパッケージには、Cfengine をブートするために必要な最低限の構成ファイルとサーバーの公開鍵、そして上記の cf-key コマンドと cf-agent コマンドが含まれます。この 2 つのパッケージを作成できると、この 2 つのパッケージをインストールするだけで Cfengine によって簡単にクライアントを構成することができます。

ここでは Red Hat 環境用にバイナリー・パッケージを作成する方法について説明します (Debian パッケージを作成する方法については UbuntuForums.org を参照してください)。異なるディストリビューションの場合には、バイナリー・パッケージを作成するための要件が異なる可能性があります。バイナリー・パッケージを適切に作成する方法については、皆さんの環境用のドキュメントを参照してください。

RPM を用意する

RPM の先頭には、そのパッケージに関する情報を含む spec ファイルを置きます。リスト 1 は Red Hat RPM の spec ファイルの例を示しています。

リスト 1. Cfengine 3 の Red Hat RPM spec ファイル
%define debug_package %{nil}
%define bin_path \
"/bin:/usr/bin:/usr/sbin:/usr/bin/X11:/sbin:\
/opt/cfengine/bin:/
opt/cfengine/bin:/opt/freeware/bin/:/usr/gnu/bin"
Name : cfengine
Summary : A tool to maintain complicated networks
Version : 3.1.4
Release : 1
URL : http://www.cfengine.org
Vendor : %{__spec_vendor}
License : GPL
Group : System Environment/Client Management
Packager : <your name> <your email address >
Distribution : %{__spec_distribution}
Source : %{name}-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
%ifos linux
Requires : db4 openssl coreutils pcre
#libacl zlib libattr e2fsprogs-libs keyutils-libs
BuildRequires : db4 db4-devel openssl openssl-devel pcre-devel
#libacl libacl-devel openssl openssl-devel pcre-devel zlib zlib-devel
                libattr libattr-devel e2fsprogs-libs keyutils-libs libselinux libsepol
ExclusiveArch : i386 x86_64 ppc ppc64
%endif
%descriptionCfengine is the standalone, open-source datacenter 
management platform run by leading enterprises since 1993. 
Customize your IT systems, align to network, business and 
regulatory needs, monitor problems, automatically repair 
and maintain systems more effectively than with proprietary 
software. Cope with new and legacy systems and adopt on a 
phased basis. Cfengine yields reduced costs, improved 
efficiency and higher return on investment for the lowest 
cost of adoption in the industry!
Authors:
--------
Mark Burgess
%prep
[ -d %{buildroot} -a "%{buildroot}" != "" ] && rm -rf %{buildroot}
mkdir -p %{buildroot}
%setup -q
%build
export CFLAGS="-g -O2 -D_FORTIFY_SOURCE=0"
%configure \
--prefix=/var/cfengine \
--sbindir=/var/cfengine/bin \
--localstatedir=/var/cfengine \
--with-workdir=/var/cfengine \
--libdir=%{_libdir} \
--with-berkeleydb=%{_libdir} \
--with-openssl=/usr \
--with-pcre
make
make DESTDIR=${RPM_BUILD_ROOT} install
%files
%defattr(-,root,root)
%{_mandir}/man?/*
/var/cfengine/*
%{_libdir}/libpromises.la
%{_libdir}/libpromises.so*
%pre
export PATH=$PATH:%bin_path
%post
export PATH=$PATH:%bin_path

RPM のビルド・プロセス

  1. ソース・コードを /usr/src/redhat/SOURCES/ フォルダーにダウンロードします。
  2. spec ファイルを /usr/src/redhat/SPECS/ フォルダーに配置します。
  3. コマンド rpmbuild -ba /usr/src/redhat/SPECS/cfengine.spec を実行し、バイナリーの RPM とソースの RPM をビルドします。
  4. rpm -ivh <RPM name> を実行して新しい RPM をインストールし、テストします。RPM が削除できたかどうかをテストするためには rpm -e <RPM name> を実行します。

Cfengine を使用するための第一歩

cf-agent は初期化されると、ホストに関する多くの属性を認識します。これらの属性により、「hard classes (ハード・クラス)」が定義されます。プロセスが実行されると、定義が必要な他のクラスは「soft classes (ソフト・クラス)」として認識されます。初めて実行する場合、まず cron またはコマンドラインから cf-execd -F を実行します。cf-execd は cf-promise ファイルを読み取り、この cf-promise ファイルによって構文チェックが行われます。エラーが検出されると、cf-agent は現在の構成を破棄し、/var/cfengine/inputs/failsafe.cf という構成を実行しようとします。

図 1 は Cfengine のプロセスを図で説明したものです。

図 1. Cfengine のプロセス
この図は promise.cf からのフローとして、問題がない場合と、エラーが検出された場合に failsafe.cf に切り替わる様子を示しています。

構成のサンプル

Cfengine に慣れ親しんでもらえるように、リスト 2 から 6 には /var/cfengine/inputs に配置される構成ファイルのサンプルを示してあります。構文が正しいかどうかを検証するためには、cf-promises -f ./test.cf を実行します。この構成を実行するためには、cf-agent -Kiv -f ./test .cf を実行します。

リスト 2. failsafe.cf のサンプル
########################################################
# failsafe.cf
########################################################
body common control
{
 bundlesequence => { "update" };
 inputs => { "update.cf" };
 version => "1.2.3";
}
bundle agent failsafe
{
 classes:
  "failsafe" not => "bootstrap_mode";
}
リスト 3. promises.cf のサンプル
#######################################################
# Copyright (C) Cfengine AS
# This file is part of Cfengine 3 - written and maintained by Cfengine AS.
#######################################################
# promises.cf
#######################################################
body common control
{
 bundlesequence => { 
   "update",
   "garbage_collection",
   "main"
};
inputs => {
 "update.cf",
 "site.cf"
};
}
#######################################################
body agent control
{
 ifelapsed => "15";
}
#######################################################
body executor control
{
 splaytime => "1";
 mailto => "username@localhost.localdomain";
 smtpserver => "localhost";
 mailmaxlines => "30";
 # Instead of a separate update script, now do this
 exec_command => "$(sys.workdir)/bin/cf-agent -f failsafe.cf && 
         $(sys.workdir)/bin/cf-agent";
}
#######################################################
body reporter control
{
 reports => { "performance", "last_seen", "monitor_history" };
 build_directory => "$(sys.workdir)/reports";
 report_output => "html
}
#######################################################
body server control 
{
 allowconnects => { "192.", "10.", "127.0.0.1" , "::1" };
 allowallconnects => { "192.", "10.", "127.0.0.1" , "::1" };
 trustkeysfrom => { "192.", "10.", "127.0.0.1" , "::1" };
 # Makes updates and runs happen in one
 cfruncommand => "$(sys.workdir)/bin/cf-agent -f failsafe.cf && 
         $(sys.workdir)/bin/cf-agent";
 allowusers => { "root" };
}
#######################################################
# Server configuration
#######################################################
bundle server access_rules()
{
 access:
  "/var/cfmasterfiles"
  admit => { "192.", "10.", "127.0.0.1" , "::1" };
 roles:
  ".*" authorize => { "root" };
}
body action local_immediate
{
 ifelapsed => "0";
 action_policy => "fix";
}
#######################################################
## To avoid namespace conflict and reduce file footprint
#######################################################
body depth_search local_recurse(d)
{
 depth => "$(d)";
 xdev => "true";
}
body delete local_tidy
{
 dirlinks => "delete";
 rmdirs => "true";
}
body file_select local_days_old(days)
{
 mtime => irange(0,ago(0,0,"$(days)",0,0,0));
 file_result => "mtime";
}
body classes local_define(class,alert)
{
 promise_repaired => { "$(class)" };
 repair_failed => { "$(alert)" };
}
リスト 4. update.cf のサンプル
#######################################################
### update.cf – config file used by the base delivery system
#######################################################
bundle agent update
{
vars:
 "master_inputs" string => "/var/cfmasterfiles/inputs";
 "master_scripts" string => "/var/cfmasterfiles/scripts";
 "master_ppkeys" string => "/var/cfmasterfiles/ppkeys";
 "master_server" slist => { "localhost" };
 redhat|centos::
 "update_crontab" string => "/var/spool/cron/root";
 SuSE::
 "update_crontab" string => "/var/spool/cron/tabs/root";
 #define others as needed (darwin, macOSX should support below)
 (!SuSE).(!redhat)::
 "update_crontab" string => "/var/spool/cron/crontabs/root";
classes:
 "exec_fix" not => regline(".*cf-execd.*","$(update_crontab)");
files:
 "/var/cfengine/inputs" 
 handle => "update_inputs",
 comment => "Update the base inputs directory for client",
 perms => u_p("600"),
 copy_from => update_scp("$(master_inputs)","$(master_server)"),
 depth_search => recurse_svn("inf"),
 file_select => cf3_config,
 action => update_immediate;
 "/var/cfengine/scripts" 
 handle => "update_scripts",
 comment => "Update the base scripts directory for client",
 perms => u_p("750"),
 copy_from => update_scp("$(master_scripts)","$(master_server)"),
 depth_search => recurse_svn("inf"),
 file_select => cf3_scripts,
 action => update_immediate; "/var/cfengine/ppkeys" 
 handle => "update_ppkeys",
 comment => "Update the base ppkeys directory for client",
 perms => u_p("600"),
copy_from => update_scppubs("$(master_ppkeys)","$(master_server)"),
 depth_search => recurse_svn("inf"),
 file_select => cf3_pub,
action => update_immediate;
 exec_fix::
 "$(update_crontab)"
 handle => "update_cron",
 comment => "Ensure that cron entry exists",
 create => "true",
 action => update_immediate,
 edit_line => update_add2cron,
 classes => update_repaired("updated_cron");
commands:
 bootstrap_mode::
 "/bin/echo"
 args => "Running Bootstrap, version: $(sys.cf_version) Workdir is: $(sys.workdir) ",
 handle => "callback_bootstrap",
 comment => "Callback Bootstrap happened",
 action => update_immediate;
 failsafe::
 "/bin/echo"
 args => "Running Failsafe, version: $(sys.cf_version) Workdir is: $(sys.workdir) ",
 handle => "callback_failsafe",
 comment => "Callback Failsafe happened",
 action => update_immediate;
 !bootstap.!failsafe::
 "/bin/echo"
 args => "Running Normal, version: $(sys.cf_version) Workdir is: $(sys.workdir)",
 handle => "callback_normalrun",
 comment => "Callback Normal Run Happened",
 contain => update_root,
 action => update_immediate;
}
############################################
body perms u_p(p)
{
 mode => "$(p)";
}
body depth_search recurse_svn(d) 
{ 
 depth => "$(d)"; 
 exclude_dirs => { "\.svn" }; 
}
############################################
 add_cron::
 "Added a 15 minute schedule to crontab";
}
body file_select cf3_config
{
 leaf_name => { "^.svn", ".*\.cf" , ".*\.sh" };
 file_result => "leaf_name";
}
body file_select cf3_scripts
{
 leaf_name => { ".*\.sh", ".*.py" };
 file_result => "leaf_name";
}
body file_select cf3_pub
{
 leaf_name => { "^localhost*", ".*\.pub" };
 file_result => "leaf_name";
}
#########################################################
body copy_from update_scp(from,server)
{
 source => "$(from)";
 servers => { "$(server)" };
 compare => "digest";
 verify => "true";
 purge => "true";
 trustkey => "true";
}
body copy_from update_scppubs(from,server)
{
 source => "$(from)";
 servers => { "$(server)" };
 compare => "digest";
 verify => "true";
 purge => "false";
 trustkey => "true";
} body action update_immediate
{
 ifelapsed => "0";
}
body classes update_repaired(class)
{
 promise_repaired => { "$(class)" };
}
body action update_background
{
 ifelapsed => "0";
 action_policy => "fix";
}
body contain update_root
{
 exec_owner => "root";
 useshell => "true";
}
#########################################################
# bundle for bodies
#########################################################
bundle edit_line update_add2cron {
 classes: 
 "add_cron" not => regline("^#*[CF3 normal run]","$(edit.filename)");
 insert_lines:
 add_cron::
 "5,15,30,45 * * * * /var/cfengine/bin/cf-execd -F #CF3 normal run";
 reports:
add_cron::
 "Added a 15 minute schedule to crontab";
}
リスト 5. site.cf のサンプル
#######################################################
# Copyright (C) Cfengine AS
# This file is part of Cfengine 3 # site.cf - Site specific promises
#######################################################
bundle common g
{
vars:
 !failsafe||!bootstrap::
 "message" string => "All Looks good";
 bootstrap::
 "message" string => "Running bootstrap";
 failsafe::
 "message" string => "Running Failsafe";
}
#######################################################
# General site issues can be in bundles like this one
#######################################################
bundle agent main
{
### This would be a place to add something new!
commands:
 cfengine_3_1_4::
 "/bin/echo"
 args => "Example Command with message param: '$(g.message)'",
 handle => "echo_command",
 comment => "Example of the echo command",
 action => local_immediate,
 classes => local_define("cmd_1","life");
}
#######################################################
# Garbage collection issues
#######################################################
bundle agent garbage_collection
{
files:
 "$(sys.workdir)/outputs" 
 delete => local_tidy,
 file_select => local_days_old("5"),
 depth_search => local_recurse("inf");
}
リスト 6. テストを実行するサンプル
############################################################
#
# Simple test execution – test.cf
#
###########################################################
body common control 
{ 
bundlesequence => { "testbundle" }; 
} 
###########################################################
bundle agent testbundle 
{ 
vars: 
 "size" int => "46k"; 
 "rand" int => randomint("33","$(size)");
commands: 
 "/bin/echo" 
 args => "Hello world - $(size)/$(rand)", 
 contain => standard, 
 classes => cdefine("followup","alert");
 followup:: 
 "/bin/ls"
 contain => standard;
reports:
 alert::
 "What happened?";
}
###########################################################
body contain standard
{
 exec_owner => "mark";
 useshell => "true";
}
###########################################################
body classes cdefine(class,alert)
{
 promise_repaired => { "$(class)" };
 repair_failed => { "$(alert)" };
}

まとめ

この記事では、Cfengine 3 ポリシー/ディストリビューション・サーバーと Cfengine 3 クライアントを初期化する方法を学びました。インストールの方法にはバイナリー・パッケージをインストールする方法とソース・コードからコンパイルする方法があります。この記事ではダウンロードしたコードから環境に合わせてバイナリー・パッケージを作成する方法も学びました。また、Cfengine を実行するための構成ファイルのサンプルや、構成ファイルの正確性をチェックする方法、構成ファイルを皆さんの実行環境に適用する方法についても学びました。

この記事で取り上げた例は非常に単純ですが、この例を使用することで環境をテストすることができます。連載「Cfengine を使用してインフラ管理を自動化する」の第 2 回では、さらに多くのシステム管理タスクの例について説明します。

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Open source, Linux
ArticleID=664947
ArticleTitle=Cfengine を使用してインフラ管理を自動化する: 第 1 回 サーバーとクライアントをインストールする
publish-date=06032011