Oracle Solaris 11でのPuppetの初歩

Glynn Foster著

異機種データセンター全体でシステム構成を自動化する方法について説明します。


2014年6月公開

目次
Puppetについて
Puppetによるシステム管理の概要
PuppetによるOracle Solaris 11システムの構成
ステンシルによるその他の構成作業
まとめ
参考資料
著者について
この記事についてコメントする場合は、リンクをFacebookのOTN Garageのページに投稿してください。同様の記事を共有する場合は、FacebookまたはTwitterに投稿してください。みんなで議論しましょう。

Puppetについて

Puppetは、人気のあるオープンソースの構成管理ツールであり、Oracle Solaris 11.2に搭載されています。管理者は宣言型言語によって、1台のシステムまたは複数システムのセットに適用するシステム構成を記述することで、繰り返し作業の自動化、アプリケーションの迅速なデプロイ、データセンター全体の変更管理を行うことができます。仮想化環境を含めて、管理者が管理すべきシステムの台数は増え続けているため、これらの機能の重要性は増しています。さらに、自動化によって、手動での構成作業で起こりえる人為的なエラーを削減できます。

一般に、Puppet構成では、クライアント/サーバー・アーキテクチャが利用されます。この構成では、ノード（エージェント）が中央のサーバー（マスター）に定期的に接続し、構成情報を取得して適用します。Puppetマスターは、接続してくる各ノードにどの構成を適用するかを制御します。

Puppetによるシステム管理の概要

この記事では、Puppetによるシステム管理の基本について、単一のマスター（master.oracle.com）と単一のエージェント（agent.oracle.com）の例を用いて説明します。高度な構成管理オプションを含むPuppetの詳細については、Puppet 3 Reference Manualを参照してください。

Puppetのインストール

Puppetは、Oracle Solaris Image Packaging Systemリポジトリで、システムをマスターまたはエージェントとして定義できる機能を持つ単一のパッケージとして提供されます。リスト1の出力から分かるように、このパッケージはデフォルトではOracle Solaris 11メディアによりインストールされません。リスト1では、pkg infoコマンドを実行してシステムの情報を問い合わせています。

root@master:~# pkg info -r puppet
          Name: system/management/puppet
       Summary:Puppet - configuration management toolkit
   Description:Puppet is a flexible, customizable framework designed to help
                system administrators automate the many repetitive tasks they
                regularly perform.As a declarative, model-based approach to IT
                automation, it lets you define the desired state - or the "what"
                - of your infrastructure using the Puppet configuration
                language.Once these configurations are deployed, Puppet
                automatically installs the necessary packages and starts the
                related services, and then regularly enforces the desired state.
      Category:System/Administration and Configuration
         State:Not installed
     Publisher: solaris
       Version:3.4.1
 Build Release:5.11
        Branch:0.175.2.0.0.37.1
Packaging Date:April 14, 2014 08:03:48 PM 
          Size:3.87 MB
          FMRI: pkg://solaris/system/management/puppet@3.4.1,5.11-0.175.2.0.0.37.1:20140414T200348Z

リスト1

Puppetパッケージをインストールするには、リスト2のように、pkg installコマンドを利用します。

root@master:~# pkg install puppet
           Packages to install:3
           Mediators to change:1
            Services to change:2
       Create boot environment:No
Create backup boot environment:No

DOWNLOAD                                PKGS         FILES    XFER (MB)   SPEED
Completed                                3/3   18354/18354    56.1/56.1  216k/s

PHASE                                          ITEMS
Installing new actions                   21388/21388
Updating package state database                 Done 
Updating package cache                           0/0 
Updating image state                            Done 
Creating fast lookup database                   Done 
Updating package cache                           1/1 
root@master:~# which puppet
/usr/sbin/puppet

リスト2

マスターとエージェントの構成

Puppetをインストールできましたので、次にマスターとエージェントを構成します。この記事では、Puppetマスターとして動作するシステムと、エージェント・ノードとなるシステムの2台を利用します。実際には、数百、数千のノードが1台以上のマスター・サーバーと通信することになるでしょう。

Oracle Solaris 11にPuppetをインストールすると、リスト3のように、マスター用とエージェント用の2つのサービスを利用できるようになります。

root@master:~# svcs -a | grep puppet
disabled       16:04:54 svc:/application/puppet:agent
disabled       16:04:55 svc:/application/puppet:master

リスト3

PuppetはOracle Solaris Service Management Facility構成リポジトリと統合されているため、管理者はレイヤー構成（アップデート中にも構成を維持可能）を利用できます。Service Management Facilityステンシルは、Service Management Facility構成リポジトリに格納された構成と、従来のPuppet構成ファイル（/etc/puppet/puppet.conf）間をシームレスにマッピングします。

まずは、Service Management Facilityを用いてマスター・サービスを構成し、有効化します。

root@master:~# svccfg -s puppet:master setprop config/server=master.oracle.com
root@master:~# svcadm enable puppet:master
root@master:~# svcs puppet:master
STATE         STIME    FMRI
online        17:38:42 svc:/application/puppet:master

リスト4

リスト4から分かるように、Puppetマスター・サービスがオンラインになりました。次に、マスターの制御対象となるノードでの作業に切り替え、このノードを構成します。リスト5のように、config/serverの値を、マスターを指すように設定します。

root@agent:~# svccfg -s puppet:agent setprop config/server=master.oracle.com
root@agent:~# svccfg -s puppet:agent refresh

リスト5

この操作の実行後、リスト6のようにpuppet agentコマンドを--testオプション付きで実行して、接続をテストできます。さらに重要なこととして、この手順によって新しいSecure Sockets Layer（SSL）の鍵が作成され、エージェントとマスター間の認証リクエストがセットアップされます。

root@agent:~# puppet agent --test
Info: csr_attributes file loading from /etc/puppet/csr_attributes.yaml
Info:Creating a new SSL certificate request for agent.oracle.com
Info:Certificate Request fingerprint (SHA256):E0:1D:0F:18:72:B7:CE:A7:83:E4:48
:D5:F8:93:36:15:55:0A:B9:C8:E5:B1:CE:D9:3E:0A:68:01:BE:F7:76:47
Exiting; no certificate found and waitforcert is disabled

リスト6

再びマスターでの作業に切り替えると、puppet cert listコマンドにより、接続クライアントからの未処理の証明書リクエストを表示できます。

root@master:~# puppet cert list
  "agent.oracle.com" (SHA256) E0:1D:0F:18:72:B7:CE:A7:83:E4:48 :D5:F8:93:36:15:55:
0A:B9:C8 :E5:B1:CE:D9:3E:0A:68:01:BE:F7:76:47

リスト7

リスト7には、agent.oracle.comから来たリクエストが表示されています。このリクエストに問題がないと想定し、リスト8のように、puppet cert signコマンドを実行してこの証明書に署名します。

root@master:~# puppet cert sign agent.oracle.com
Notice:Signed certificate request for agent.oracle.com
Notice:Removing file Puppet:SSL:CertificateRequest agent at '/etc/puppet/ssl/ca/requests/solaris.pem'

リスト8

再びエージェントでの作業に戻り、リスト9のように接続を再テストして、認証が正しくセットアップされていることを確認します。

root@agent:~# puppet agent --test
Info:Caching certificate for agent.oracle.com
Info:Caching certificate_revocation_list for ca
Info:Caching certificate for agent.oracle.com
Info:Retrieving plugin
Info:Caching catalog for agent.oracle.com
Info:Applying configuration version '1400782295'
Notice:Finished catalog run in 0.18 seconds

リスト9

最後に、リスト10のように、エージェント・サービスを有効化します。

root@agent:~# svcadm enable puppet:agent
root@agent:~# svcs puppet:agent
STATE         STIME    FMRI
online        18:20:32 svc:/application/puppet:agent

リスト10

Puppetのリソース、リソース・タイプ、マニフェスト

Puppetでは、システムの構成を記述するために、リソースおよびリソース・タイプという概念を利用します。リソースの例には、システム上の実行中のサービス、ソフトウェア・パッケージ、ファイル、ディレクトリ、ユーザーがあります。各リソースはリソース・タイプとしてモデル化されます。リソース・タイプは高次の抽象概念であり、タイトルと、一連の属性および値によって定義されます。

Puppetは、クロス・プラットフォームの互換性を維持するように設計されており、プラットフォーム固有のプロバイダを用いて、似たようなリソースに対して異なる実装を作成できるようにしています。たとえば、Puppetによるパッケージのインストール時に、Oracle Solaris 11ではImage Packaging Systemを利用し、Red Hat Enterprise LinuxではRPMを利用することになります。この機能によって、管理者は共通の構成定義セットを用いて複数のプラットフォームを管理できます。このリソース・タイプとプロバイダの組合せは、Puppet Resource Abstraction Layer（RAL）として知られています。管理者は宣言型言語でシステム・リソースとその状態を記述でき、この情報はマニフェストと呼ばれるファイルに保存されます。

Oracle Solaris 11システムで利用できるリソース・タイプの一覧は、puppet resourceコマンドを--typesオプション付きで実行することで表示できます。

root@master:~# puppet resource --types
address_object
address_properties
augeas
boot_environment
computer
cron
dns
etherstub
exec
file
filebucket
group
host
interface
interface_properties
ip_interface
ip_tunnel
ipmp_interface
k5login
ldap
link_aggregation
link_properties
macauthorization
mailalias
maillist
mcx
mount
nagios_command
nagios_contact
nagios_contactgroup
nagios_host
nagios_hostdependency
nagios_hostescalation
nagios_hostextinfo
nagios_hostgroup
nagios_service
nagios_servicedependency
nagios_serviceescalation
nagios_serviceextinfo
nagios_servicegroup
nagios_timeperiod
nis
notify
nsswitch
package
pkg_facet
pkg_mediator
pkg_publisher
pkg_variant
protocol_properties
resources
router
schedule
scheduled_task
selboolean
selmodule
service
solaris_vlan
ssh_authorized_key
sshkey
stage
svccfg
tidy
user
vlan
vni_interface
vnic
whit
yumrepo
zfs
zone
zpool
root@master:~# puppet resource --types | wc -l
72

リスト11

リスト11から分かるように、このシステムでは現在、72個のリソース・タイプが利用できます。これらのリソース・タイプの多くはPuppetのコア部分に含まれるもので、Oracle Solaris 11のコンテキストでは意味のないものもあります。それでも、これらのリソース・タイプがあるということは、必要であればOracle Solaris 11以外のシステムをエージェントとして管理できるということです。これらのリソース・タイプの詳細情報を表示するには、リスト12のように、puppet describeコマンドを--listオプション付きで実行します。

root@master:~# puppet describe --list
These are the types known to puppet:
address_object  - Manage the configuration of Oracle Solaris ad ...
address_properties - Manage Oracle Solaris address properties
augeas          - Apply a change or an array of changes to the  ...
boot_environment - Manage Oracle Solaris Boot Environments (BEs)
computer        - Computer object management using DirectorySer ...
cron            - Installs and manages cron jobs.Every cron re ...
dns             - Manage the configuration of the DNS client fo ...
etherstub       - Manage the configuration of Solaris etherstub ...
exec            - Executes external commands.It is critical th ...
file            - Manages files, including their content, owner ...
filebucket      - A repository for storing and retrieving file  ...
group           - Manage groups.On most platforms this can onl ...
host            - Installs and manages host entries.For most s ...
interface       - This represents a router or switch interface....
interface_properties - Manage Oracle Solaris interface properties
ip_interface    - Manage the configuration of Oracle Solaris IP ...
ip_tunnel       - Manage the configuration of Oracle Solaris IP ...
ipmp_interface  - Manage the configuration of Oracle Solaris IP ...
k5login         - Manage the `.k5login` file for a user.Specif ...
ldap            - Manage the configuration of the LDAP client f ...
link_aggregation - Manage the configuration of Oracle Solaris li ...
link_properties - Manage Oracle Solaris link properties
macauthorization - Manage the Mac OS X authorization database.S ...
mailalias       - Creates an email alias in the local alias dat ...
maillist        - Manage email lists.This resource type can on ...
mcx             - MCX object management using DirectoryService  ...
mount           - Manages mounted filesystems, including puttin ...
nagios_command  - The Nagios type command.This resource type i ...
nagios_contact  - The Nagios type contact.This resource type i ...
nagios_contactgroup - The Nagios type contactgroup.This resource t ...
nagios_host     - The Nagios type host.This resource type is a ...
nagios_hostdependency - The Nagios type hostdependency.This resource ...
nagios_hostescalation - The Nagios type hostescalation.This resource ...
nagios_hostextinfo - The Nagios type hostextinfo.This resource ty ...
nagios_hostgroup - The Nagios type hostgroup.This resource type ...
nagios_service  - The Nagios type service.This resource type i ...
nagios_servicedependency - The Nagios type servicedependency.This resou ...
nagios_serviceescalation - The Nagios type serviceescalation.This resou ...
nagios_serviceextinfo - The Nagios type serviceextinfo.This resource ...
nagios_servicegroup - The Nagios type servicegroup.This resource t ...
nagios_timeperiod - The Nagios type timeperiod.This resource typ ...
nis             - Manage the configuration of the NIS client fo ...
notify          - Sends an arbitrary message to the agent run-t ...
nsswitch        - Name service switch configuration data
package         - Manage packages.There is a basic dichotomy i ...
pkg_facet       - Manage Oracle Solaris package facets
pkg_mediator    - Manage Oracle Solaris package mediators
pkg_publisher   - Manage Oracle Solaris package publishers
pkg_variant     - Manage Oracle Solaris package variants
protocol_properties - Manage Oracle Solaris protocol properties
resources       - This is a metatype that can manage other reso ...
router          - Manages connected router.
schedule        - Define schedules for Puppet.Resources can be ...
scheduled_task  - Installs and manages Windows Scheduled Tasks....
selboolean      - Manages SELinux booleans on systems with SELi ...
selmodule       - Manages loading and unloading of SELinux poli ...
service         - Manage running services.Service support unfo ...
solaris_vlan    - Manage the configuration of Oracle Solaris VL ...
ssh_authorized_key - Manages SSH authorized keys.Currently only t ...
sshkey          - Installs and manages ssh host keys.At this p ...
stage           - A resource type for specifying run stages.Th ...
svccfg          - Manage SMF service properties with svccfg(1M) ...
tidy            - Remove unwanted files based on specific crite ...
user            - Manage users.This type is mostly built to ma ...
vlan            - Manages a VLAN on a router or switch.
vni_interface   - Manage the configuration of Solaris VNI inter ...
vnic            - Manage the configuration of Oracle Solaris Vi ...
whit            - Whits are internal artifacts of Puppet's curr ...
yumrepo         - The client-side description of a yum reposito ...
zfs             - Manage zfs.Create destroy and set properties ...
zone            - Manages Solaris zones.

リスト12

リソース・タイプを用いたシステム情報の問合せ

システムの構成作業に進む前に、Puppetを用いて、リスト11とリスト12で確認したリソース・タイプを基にシステム情報を問い合わせてみましょう。puppet resourceコマンドを、適切なリソース・タイプを指定して実行します。puppet resourceコマンドは、現在のシステムの状態をPuppetの宣言型言語に変換します。この宣言型言語は、他のシステムで構成を適用するために利用できます。例として、serviceリソース・タイプを指定して、システムのサービスの状態を問い合わせてみましょう。

root@master:~# puppet resource service
service { 'svc:/application/cups/scheduler:default':
  ensure => 'running',
  enable => 'true',
}
...
service { 'svc:/system/zones-install:default':
  ensure => 'running',
  enable => 'true',
}
service { 'svc:/system/zones-monitoring:default':
  ensure => 'running',
  enable => 'true',
}
service { 'svc:/system/zones:default':
  ensure => 'running',
  enable => 'true',
}

リスト13

リスト13では、サービス名で識別された個別リソースの一覧が表示されています。各リソース内には、ensureとenableという2つの属性があり、それぞれの属性に値が関連付けられています。これがPuppetの宣言型言語の核心です。リソースは、リスト14のように記述できます。

resource_type { 'title':
  attribute1 => 'value1',
  attribute2 => 'value2',
}

リスト14

それぞれのresource_typeには、Puppetが利用する識別文字列であるtitleがあり、この文字列はリソース・タイプごとに一意である必要があります。属性には、リソースに対して希望する状態を記述します。ほとんどのリソースには必須の属性セットがありますが、オプションの属性セットも含まれます。また、それぞれのリソース・タイプにはnamevarという特殊な属性もあります。この属性は、ターゲット・システムが利用するもので、一意である必要があります。namevarが指定されていない場合は、通常はデフォルトでtitleが設定されます。この属性は、複数のプラットフォームを管理する予定の場合に重要です。たとえば、Oracle Solaris 11とRed Hat Enterprise Linuxの両方でNTPサービスが確実にインストールされた状態にする場合に、リソースのタイトルにはどちらもntpと記述しますが、Oracle Solaris 11のnamevarにはservice/network/ntpを利用し、Red Hat Enterprise Linuxのnamevarにはntpdを利用できます。

それでは、zoneリソース・タイプを利用して、マスター上の構成/インストール済みの大域ゾーンとすべての非大域ゾーンについて、現在の状態を問い合わせてみましょう。

root@master:~# puppet resource zone
zone { 'global':
  ensure   => 'running',
  brand    => 'solaris',
  iptype   => 'shared',
  zonepath => '/',
}

リスト15

リスト15では、このシステムに非大域ゾーンは存在せず、大域ゾーンのみが存在することが分かります。

最後に、構成済みのImage Packaging Systemパブリッシャの種類を確認します。リスト16のように、pkg_publisherリソース・タイプの情報を取得します。

root@master:~# puppet resource pkg_publisher
pkg_publisher { 'solaris':
  ensure      => 'present',
  enable      => 'true',
  origin      => ['http://pkg.oracle.com/solaris/beta'],
  searchfirst => 'true',
  sticky      => 'true',
}

リスト16

Puppetによる簡単な構成作業の実行

これまでに、Puppetマスターとエージェントをセットアップし、リソース・タイプの概要とリソースの宣言方法について少し確認しました。これで、エージェントに対する構成の適用に移ることができます。

Puppetは、/etc/puppet/manifests/site.ppにあるメインのサイト・マニフェストを利用します。管理者はこのファイルで、すべてのエージェント・システムに適用すべきリソースの定義を一元管理できます。Puppetの扱いに慣れた後、次のアプローチを採用することをお勧めします。

  • site.ppは、すべてのエージェントに影響を及ぼす構成だけに利用する。
  • 各エージェントを個別のPuppetクラスへと分類する。

この記事では、Puppetクラスの利用については取り上げず、site.ppを用いてリソースを定義します。

簡単に理解するために、fileリソース・タイプについて見てみましょう。/etc/puppet/manifests/site.ppを変更して、次のリソース宣言を追加します。

file { '/custom-file.txt':
  ensure => 'present',
  content => "Hello World",
}

リスト17

リスト17の宣言では、fileリソース・タイプを利用し、さらにensureとcontentという2つの属性によって、custom-file.txtファイルが確実にエージェント・ノードのルート・ディレクトリに存在し、そのファイルに"Hello World"という内容が含まれるようにしています。

この/etc/puppet/manifests/site.ppファイルを保存したら、puppet applyコマンドを実行して有効性をテストできます。ここではリスト18のように、-vオプションを付けて出力の詳細度を上げ、--noopオプションにより、変更を行わない（つまりドライランを実行する）ようにしています。

root@master:~# puppet apply -v --noop /etc/puppet/manifests/site.pp
Notice:Compiled catalog for master in environment production in 0.16 seconds
Info:Applying configuration version '1400794990'
Notice:/Stage[main]/Main/File[/custom-file.txt]/ensure: current_value absent, should be present (noop)
Notice:Class[Main]:Would have triggered 'refresh' from 1 events
Notice:Stage[Main]:Would have triggered 'refresh' from 1 events
Notice:Finished catalog run in 0.27 seconds

リスト18

このリソースをマスター自体に適用することも可能です。そのためには、リスト19のように、--vオプションと--noopオプションを取り除いてpuppet applyを再実行し、custom-file.txtファイルの有無と内容を確認します。

root@master:~# puppet apply /etc/puppet/manifests/site.pp
Notice:Compiled catalog for master in environment production in 0.16 seconds
Notice:/Stage[main]/Main/File[/custom-file.txt]/ensure: created
Notice:Finished catalog run in 0.28 seconds
root@master:~# ls -la /custom-file.txt
-rw-------   1 root     root          15 May 22 21:45 /custom-file.txt
root@master:~# cat /custom-file.txt
Hello World

リスト19

デフォルトでは、エージェントは30分間隔でマスター・サーバーに接続します（この間隔は、構成ファイルで必要に応じて変更できます）。エージェントでcustom-file.txtファイルが作成されているかを確認し、/var/log/puppet/puppet-agent.logにあるPuppetエージェントのログを調査することで、Puppetがこの構成をエージェントに適用したかを確認できます。

root@agent:~# ls -la /custom-file.txt
-rw-------   1 root     root          15 May 22 21:50 /custom-file.txt
root@agent:~# cat /custom-file.txt
Hello World
root@agent:~# tail /var/log/puppet/puppet-agent.log
....
2014-05-22 21:50:17 +0000 /Stage[main]/Main/File[/custom-file.txt]/ensure (notice): created
2014-05-22 21:50:17 +0000 Puppet (notice):Finished catalog run in 0.21 seconds

リスト20

リスト20から分かるように、構成の適用は正常に行われ、ファイルがエージェント・システム上に作成されました。

Facterユーティリティの利用

Puppetは、Facterというユーティリティによって、特定のノードに関する情報を収集し、Puppetマスターに送信します。この情報は、ノードに適用すべきシステム構成を判断するために利用されます。ノードに関する"ファクト"（実際の状態）を確認するために、リスト21のようにfacterコマンドを利用できます。

root@master:~# facter osfamily
Solaris
root@master:~# facter operatingsystem
Solaris
root@master:~# facter ipaddress
10.0.2.15
root@master:~# facter hostname
solaris

リスト21

あるノードについて、すべてのファクトを一覧で示すには、-pオプションを付けます。

root@master:~# facter -p
architecture => i86pc
facterversion => 1.6.18
hardwareisa => i386
hardwaremodel => i86pc
hostname => solaris
id => root
interfaces => lo0,net0
ipaddress => 10.0.2.15
ipaddress6 => ::
ipaddress_lo0 => 127.0.0.1
ipaddress_net0 => 10.0.2.15
ipaddress_net1 => 10.1.1.5
...
uptime => 0:22 hours
uptime_days => 0
uptime_hours => 0
uptime_seconds => 1320
virtual => virtualbox

リスト22

リスト22のように、特定のシステムに対して幅広いファクトを問い合わせることができます。これらのファクトは、リソース内でグローバル変数として公開することで、適用すべき構成をプログラムで判定するのに役立ちます。

一例として、プラットフォームごとに異なる内容をファイルに書き込むためのfileリソースの宣言方法について見ていきましょう。プラットフォームの検出には、osfamilyファクトを利用します。

$file_contents = $osfamily ?{
  'redhat' => "Hello RHEL",
  'solaris' => "Hello Oracle Solaris",
}

file { '/custom-file.txt':
  ensure => 'present',
  content => $file_contents,
}

リスト23

リスト23では、$file_contentsという新しい変数を作成し、osfamilyファクトを用いて条件付きチェックを行っています。その後、プラットフォームのタイプに応じて、ファイルに異なる内容を割り当てています。

特定ノードへの構成の対応付け

さまざまなシステムにわたって構成を管理する場合、条件付きロジックによって、ノードをどのように該当する構成に対応付けるかを制御したいことがあります。この作業のために、nodeキーワードをマニフェスト内で利用できます。たとえば、agent1.oracle.comという特定ホストに構成を対応付ける場合、リスト24のように記述できます。

node agent1.oracle.com {
  # ここにリソースを挿入
}

リスト24

また、agent1.oracle.comおよびagent2.oracle.comとagent3.oracle.comで、別々のリソース定義を指定する場合は、リスト25のように記述できます。

node agent1.oracle.com, agent2.oracle.com {
  # ここにリソースを挿入
}
node agent3.oracle.com {
  # ここに別のリソースを挿入
}

リスト25

defaultは特殊なノード名として利用でき、他のノード定義に一致しないノードについてのフォールバック構成を記述できます。フォールバックは、リスト26のように定義できます。

node default {
  # ここに別のリソースを挿入
}

リスト26

PuppetによるOracle Solaris 11システムの構成

これまではPuppetの基本について説明しました。次に、Oracle Solaris 11.2システムの管理用に追加された固有のリソース・タイプとプロバイダについて確認しましょう。これらのリソース・タイプにより、管理者はパッケージ、サービス、ZFS、Oracle Solaris Zones、多様なネットワーク構成を含む幅広いOracle Solarisテクノロジーを管理できるようになります。

Oracle Solaris Zonesの管理

まずは、zoneリソース・タイプについて確認します。設定可能な属性に関する理解を深めるため、先ほどと同様にpuppet describeコマンドを実行して出力内容を確認します。

root@master:~# puppet describe zone
zone
====
Manages Solaris zones.


Parameters
----------

- **archive**
    The archive file containing an archived zone.

- **archived_zonename**
    The archived zone to configure and install

- **brand**
    The zone's brand type

- **clone**
    Instead of installing the zone, clone it from another zone.
    If the zone root resides on a zfs file system, a snapshot will be
    used to create the clone; if it resides on a ufs filesystem, a copy of
    the
    zone will be used.The zone from which you clone must not be running.

- **config_profile**
    Path to the config_profile to use to configure a solaris zone.
    This is set when providing a sysconfig profile instead of running the
    sysconfig SCI tool on first boot of the zone.


- **ensure**
    The running state of the zone.The valid states directly reflect
    the states that `zoneadm` provides.The states are linear,
    in that a zone must be `configured`, then `installed`, and
    only then can be `running`.Note also that `halt` is currently
    used to stop zones.
    Valid values are `absent`, `configured`, `installed`, `running`. 

- **id**
    The numerical ID of the zone.This number is autogenerated
    and cannot be changed.

- **install_args**
    Arguments to the `zoneadm` install command.This can be used to create
    branded zones.

- **iptype**
    Displays exclusive or shared instance of IP.

- **name**
    The name of the zone.

- **sysidcfg**
    The text to go into the `sysidcfg` file when the zone is first
    booted.The best way is to use a template:
    # $confdir/modules/site/templates/sysidcfg.erb
        system_locale=en_US
        timezone=GMT
        terminal=xterms
        security_policy=NONE
        root_password=<%= password %>
        timeserver=localhost
        name_service=DNS {domain_name=<%= domain %> name_server=<%= nameserver %>}
        network_interface=primary {hostname=<%= realhostname %>
          ip_address=<%= ip %>
          netmask=<%= netmask %>
          protocol_ipv6=no
          default_route=<%= defaultroute %>}
        nfs4_domain=dynamic
    
    And then call that:
    zone { myzone:
          ip           => "bge0:192.168.0.23",
          sysidcfg     => template("site/sysidcfg.erb"),
          path         => "/opt/zones/myzone",
          realhostname => "fully.qualified.domain.name"
        }
    
    The `sysidcfg` only matters on the first booting of the zone,
    so Puppet only checks for it at that time.


- **zonecfg_export**
    Contains the zone configuration information.This can be passed in
    in the form of a file generated by the zonecfg command, in the form
    of a template, or a string.

- **zonepath**
    The path to zone's file system.

Providers
---------
    solaris

リスト27

リスト27では、属性の1つにzonecfg_exportというものがあります。この属性によって、ゾーン構成ファイルを指定できます。リスト28のように、zonecfgコマンドを用いてゾーン構成ファイルを簡単に作成しましょう。リスト28では、ゾーンにtestzoneという名前を付けていますが、後でzoneリソース・タイプを利用する際にこの名前を構成できます。

root@master:~# zonecfg -z testzone
Use 'create' to begin configuring a new zone.
zonecfg:testzone> create
create:Using system default template 'SYSdefault'
zonecfg:testzone> export -f /tmp/zone.cfg
zonecfg:testzone> exit
root@master:~# cat /tmp/zone.cfg
create -b
set zonepath=/system/zones/%{zonename}
set autoboot=false
set autoshutdown=shutdown
set ip-type=exclusive
add anet
set linkname=net0
set lower-link=auto
set configure-allowed-address=true
set link-protection=mac-nospoof
set mac-address=auto
end

リスト28

マニフェスト内で次のようにゾーンを定義できます。

zone { 'myzone':
  zonecfg_export => '/tmp/zone.cfg',
  ensure => 'installed',
}

リスト29

リスト29では、ゾーン構成ファイルとして/tmp/zone.cfgという値を指定し、ensure属性にinstalledを設定しています。ensureの値は、ゾーンの状態を表すconfigured、installed、runningのいずれかになります。この例では、エージェント・ノード上にmyzoneというゾーンを作成します。この構成を適用した後にしばらく待って、エージェント・ノード上での処理結果を確認します。

root@agent:~# zoneadm list -cv
  ID NAME             STATUS       PATH                       BRAND       IP
   0 global           running      /                          solaris     shared
   - myzone           installed    /system/zones/myzone       solaris     excl

リスト30

リスト30から分かるように、ゾーンは構成済み、インストール済みで、起動の準備ができた状態です。

ソフトウェア・パッケージの追加

今度は、packageリソース・タイプを用いて、Image Packaging Systemによって新しいソフトウェア・パッケージを追加します。

まずは、リスト31のように、特定のパッケージがまだエージェント・ノードにインストールされていないことを確認します。

root@agent:~# pkg info nmap
pkg: info: no packages matching the following patterns you specified are
installed on the system.Try specifying -r to query remotely:

        nmap
root@agent:~# pkg info -r nmap
          Name: diagnostic/nmap
       Summary:Network exploration tool and security / port scanner.
   Description:Nmap is useful for inventorying the network, managing service
                upgrade schedules, and monitoring host or service uptime.
      Category:System/Administration and Configuration
         State:Not installed
     Publisher: solaris
       Version:6.25
 Build Release:5.11
        Branch:0.175.2.0.0.37.1
Packaging Date:April 14, 2014 06:21:31 PM 
          Size:18.47 MB
          FMRI: pkg://solaris/diagnostic/nmap@6.25,5.11-0.175.2.0.0.37.1:20140414T182131Z

リスト31

ソフトウェア・パッケージの追加に関するリソース定義は簡単です。リスト32のように、タイトルにnmapを設定し、パッケージが確実に存在するようにするだけです。

package { 'nmap':
  ensure => 'present',
}

リスト32

しばらく経った後、リスト33のように、エージェント・ノードでこのパッケージが正常にインストールされていることを確認できます。

root@agent:~# pkg info nmap
          Name: diagnostic/nmap
       Summary:Network exploration tool and security / port scanner.
   Description:Nmap is useful for inventorying the network, managing service
                upgrade schedules, and monitoring host or service uptime.
      Category:System/Administration and Configuration
         State:Installed
     Publisher: solaris
       Version:6.25
 Build Release:5.11
        Branch:0.175.2.0.0.37.1
Packaging Date:April 14, 2014 06:21:31 PM 
          Size:18.47 MB
          FMRI: pkg://solaris/diagnostic/nmap@6.25,5.11-0.175.2.0.0.37.1:20140414T182131Z

リスト33

ここまでに、Puppetはノードに構成を適用すると説明しました。試しにエージェント・ノードからこのパッケージを削除してみましょう。

root@agent:~# pkg uninstall nmap
            Packages to remove:   1
            Services to change:   1
       Create boot environment:No
Create backup boot environment:No

Planning linked:0/1 done; 1 working: zone:myzone
Planning linked:1/1 done
Downloading linked:0/1 done; 1 working: zone:myzone
Downloading linked:1/1 done
PHASE                                          ITEMS
Removing old actions                         913/913
Updating package state databasea                Done
Updating package cache                           1/1
Updating image state                            Done
Creating fast lookup database                   Done
Executing linked:0/1 done; 1 working: zone:myzone
Executing linked:1/1 done
Updating package cache                           1/1
root@agent:~# which nmap
no nmap in /usr/bin /usr/sbin

リスト34

リスト34のように、パッケージはインストール済みの状態ではなくなりました。しかし、少し時間が経った後、エージェント・ノードがマスターに接続して、リスト35のようにパッケージが再インストールされます。

root@agent:~# pkg info nmap
          Name: diagnostic/nmap
       Summary:Network exploration tool and security / port scanner.
   Description:Nmap is useful for inventorying the network, managing service
                upgrade schedules, and monitoring host or service uptime.
      Category:System/Administration and Configuration
         State:Installed
     Publisher: solaris
       Version:6.25
 Build Release:5.11
        Branch:0.175.2.0.0.37.1
Packaging Date:April 14, 2014 06:21:31 PM 
          Size:18.47 MB
          FMRI: pkg://solaris/diagnostic/nmap@6.25,5.11-0.175.2.0.0.37.1:20140414T182131Z

リスト35

ZFSデータセットの作成

ZFSデータセットが存在するということを適用する、ごく単純な例を示します。そのために、リスト36のように、zfsリソース・タイプを用いたリソース定義を記述します。また、readonlyという追加属性にonを設定します。

zfs { 'rpool/test':
  ensure => 'present',
  readonly => 'on',
}

リスト36

リスト37のように、新しいZFSデータセットが作成され、readonlyデータセット・プロパティが設定されていることを簡単に確認できます。

root@agent:~# zfs list rpool/test
NAME        USED  AVAIL   REFER   MOUNTPOINT
rpool/test   31K  31.8G     31K   /rpool/test
root@agent:~# zfs get readonly rpool/test
NAME        PROPERTY  VALUE  SOURCE
rpool/test  readonly  on     local

リスト37

ステンシルによるその他の構成作業

前述のとおり、Puppetの構成はすべて、Service Management Facilityステンシルによって管理されます。/etc/puppet/puppet.confは直接編集しないようにしてください。Puppet Service Management Facilityサービスを再起動すると、直接編集した内容が失われるからです。代わりに、リスト38のように、svccfgと、puppet.conf(5)に定義された構成プロパティを用いて構成作業を実行できます。

root@master:~# svccfg -s puppet:master setprop config/<option> = "<value>"
root@master:~# svccfg -s puppet:master refresh

リスト38

Service Management FacilityによってPuppet構成を保存することで、Puppet環境の構成も非常に容易になります。これは、データセンターを任意の数の環境に分割する便利な方法です。

たとえば、Puppetマスターに、開発環境用の構成と本番環境用の構成を管理させることができます。リスト39のように、Puppetサービスの新しいService Management Facilityインスタンスを作成することで容易に実現できます。

root@master:~# svccfg -s puppet
svc:/application/puppet> add production
svc:/application/puppet> add dev
svc:/application/puppet> exit
root@master:~# svccfg -s puppet:production setprop config/modulepath = \
"$confdir/environments/$environment/modules:$confdir/modules"
root@master:~# svccfg -s puppet:dev setprop config/manifest = "$confdir/manifests/site-dev.pp"

リスト39

まとめ

Puppetは、データセンター内の幅広いプラットフォームにわたって構成管理を適用することを必要としている管理者に適したツールです。この記事では、Puppetの機能のごく一部について簡単に説明しました。パッケージ、サービス構成、ネットワーク、仮想化、データ管理など、Oracle Solaris 11ベースの一連のリソース・タイプが新たにサポートされたことで、管理者はLinuxベースのプラットフォームで以前に実施していたような自動化を実行できます。

参考資料

Puppet関連の参考資料：

Oracle Solaris 11のその他の参考資料：

著者について

Glynn Fosterは、Oracle SolarisのPrincipal Product Managerです。OpenStack、Oracle Solaris Image Packaging System、インストール、構成管理などの多数のテクノロジー分野に従事しています。

リビジョン1.0、2014/05/30

オラクルの最新情報をフォロー：
ブログ | Facebook | Twitter | YouTube

false ,,,,,,,,,,,,,,,,