Tech Sketch Bucket of Technical Chips by TIS Inc.

Puppet 3.8.7でpuppet kickを使ってみた

Pocket


puppet logo


ITmedita @ITに、サーバ構築自動化ツール(Chef/Ansible/Puppet/Itamae)の比較記事を執筆させて頂いた。

Puppetの検証の際にあわせて検証を行ったが、記事には記載しなかったpuppet Ver 3.8.7環境およびpuppet kickの実行環境の構築手順と実際の動作検証の結果をまとめたものである。

記事中の評価には2016年5月現在の最新のstable版のVer 4.4.2を使用したが、当初想定で検証を予定していた、push型のpuppet kickコマンドがVer 4.xからは廃止されてることが判明した。

puppet kickコマンドは他の3製品と同様にserver側からnode(agent)側に構築の指示を実行するpush型の機能である。puppetはnode側からserver側にmanifestの取得を要求するpull型のpuppet agentコマンドがメインの操作方法となっており、この点が他製品との差異となっている。

ただ、3.x系は2016年4月26日にVer3.8.7がリリースされ、サポートも継続されており、puppet kickを使いたい場合は、3.x系を選択することもあり得ると考え、本編では記載しなかったが検証を実施することとした。

構築手順および検証結果は以下となる。

Puppet環境の構築

検証に使用した環境は以下となる。


Server : puppetmasterのサービスを実行するサーバ。manifest/moduleを配置する。
Node : puppet agentのサービスを実行するサーバ。Serverからmanifest/moduleをダウンロードして環境を構築する。

Server : puppet-serverのインストールと設定

1.epelリポジトリの登録
$ sudo yum install -y epel-release.noarch

2.ruby-ldapモジュールのインストール
$ sudo yum install -y ruby-ldap

3.puppetリポジトリの登録
$ sudo rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-7.noarch.rpm

4.puppet-serverのインストール
$ sudo yum install -y puppet-server

5.manifests/site.ppを空ファイルで作成
nodeがmanifestを実行する際、最初にアクセスするファイルがmanifests/site.ppとなる。
$ sudo touch /etc/puppet/manifests/site.pp

6.manifests/site.ppをpuppet-serverに登録
$ sudo puppet apply /etc/puppet/manifests/site.pp
Notice: Compiled catalog for tissvv097 in environment production in 0.02 seconds
Notice: Finished catalog run in 0.01 seconds

7.puppetmasterサービスの起動と自動起動の設定
$ sudo systemctl start puppetmaster
$ sudo systemctl enable puppetmaster

8.puppetmasterサービスのポートの解放
$ sudo firewall-cmd --add-port=8140/tcp --zone=public --permanent
$ sudo firewall-cmd --reload

9.Serverのcert list登録を確認
$ sudo puppet cert list --all
+ "tissvv097" (SHA256) 05:DE:F1:22:D2:D4:76:5F:99:BE:6A:E2:80:7E:45:BC:7C:9C:94:A0:55:D1:42:AA:3E:11:8D:8A:AA:39:42:24

Node : puppet agentのインストール

1.puppetリポジトリの登録
$ sudo rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-7.noarch.rpm

2.puppetのインストール
$ sudo yum install -y puppet

3.NodeからServerに接続して、Nodeのcertを登録
$ sudo puppet agent --test --server tissvv097
Info: Creating a new SSL key for tissvv096
Info: Caching certificate for ca
Info: csr_attributes file loading from /etc/puppet/csr_attributes.yaml
Info: Creating a new SSL certificate request for tissvv096
Info: Certificate Request fingerprint (SHA256): 38:0A:7F:5E:A5:75:83:CA:32:2F:23:1A:1B:E8:CC:CB:CB:D3:1A:B4:C0:82:7C:34:14:C4:65:F6:5F:BF:CA:56
Info: Caching certificate for ca
Exiting; no certificate found and waitforcert is disabled

Server側でNodeのcertを認証

1.Nodeのcertが登録されていることを確認
$ sudo puppet cert list --all
"tissvv096" (SHA256) 38:0A:7F:5E:A5:75:83:CA:32:2F:23:1A:1B:E8:CC:CB:CB:D3:1A:B4:C0:82:7C:34:14:C4:65:F6:5F:BF:CA:56
+ "tissvv097" (SHA256) 05:DE:F1:22:D2:D4:76:5F:99:BE:6A:E2:80:7E:45:BC:7C:9C:94:A0:55:D1:42:AA:3E:11:8D:8A:AA:39:42:24

2.Nodeのcertを承認
$ sudo puppet cert sign tissvv096
Notice: Signed certificate request for tissvv096
Notice: Removing file Puppet::SSL::CertificateRequest tissvv096 at '/var/lib/puppet/ssl/ca/requests/tissvv096.pem'

3.Nodeのcertが認証されていることを確認
認証が完了するとホスト名の前に "+" が付与される。
$ sudo puppet cert list --all
+ "tissvv096" (SHA256) 55:7D:F8:5C:BF:80:41:30:E0:EA:48:45:9B:38:F5:67:C7:68:4D:5C:00:BA:DF:46:EB:06:9C:A5:41:06:9D:B2
+ "tissvv097" (SHA256) 05:DE:F1:22:D2:D4:76:5F:99:BE:6A:E2:80:7E:45:BC:7C:9C:94:A0:55:D1:42:AA:3E:11:8D:8A:AA:39:42:24

Node : puppet kick用の設定

1./etc/puppet/namespaceauth.confを作成
$ sudo vi /etc/puppet/namespaceauth.conf

2./etc/puppet/auth.confにpuppet kickの許可設定を追加
$ sudo vi /etc/puppet/auth.conf

3.puppet(agent)用の設定ファイルを作成
$ sudo vi /etc/sysconfig/puppetagent

4.puppet(agent)のサービスの起動と自動起動の設定
$ sudo systemctl start puppet
$ sudo systemctl enable puppet

4.puppet(agent)のサービスのポートの解放
$ sudo firewall-cmd --add-port=8139/tcp --zone=public --permanent
$ sudo firewall-cmd --reload

manifest作成

WordPressを設定するmanifestを作成する。

1.hunner-wordpress moduleをインストール
$ sudo puppet module install hunner-wordpress

2.WordPressインストール用のmodule格納フォルダを作成
$ sudo mkdir -p /etc/puppet/modules/wordpress_server/{manifests,templates}

3.WordPressインストール用のmanifestを作成
$ sudo vi /etc/puppet/modules/wordpress_server/manifests/init.pp

4.wordpressのhttpd用のconfファイルのtemplateの作成
$ sudo vi /etc/puppet/modules/wordpress_server/templates/wordpress.conf.erb

5.site.ppファイルにNodeを登録
$ sudo vi /etc/puppet/manifests/site.pp

Server : puppet kickでのインストールの実行

1.Server側でpuppet kickコマンドでmanifestを実行
動作はするが、puppet kickは廃止された(Puppet kick is deprecated.)機能であることが警告として表示される。
$ sudo puppet kick --foreground tissvv096
Warning: Puppet kick is deprecated. See http://links.puppetlabs.com/puppet-kick-deprecation
Triggering tissvv096
Getting status
status is success
tissvv096 finished with exit code 0
Finished

2.Node側でログでmanifestの実行結果を確認
$ sudo less /var/log/puppet/puppet-agent.log

3.Nodeにブラウザで接続し、WordPressの初期設定画面が表示されることを確認


まとめ

 この方法でPuppetも他のサーバ構築自動化製品と同様にServer側からNodeへのmanifest実行指示が行える。
 ただ、実際にはpuppet kickがNode側のpuppet agentに実行の指示を出してだけなので、他製品と異なり、Node側のPuppet agentの実行ログをServer側で取得できるわけではない。その為、puppet kickで実行した場合のmanifestの実行結果はログファイルに出力しておく必要があることに注意が必要である。

 puppetは通常運用時はNode側でcron等で起動され、manifestに定義された状態にサーバを維持する製品だと考えている。そのため、即時に対応が必要な緊急メンテナンスなどには対応できない。puppet kickのようなpush型の実行は、かなり有効な手段であると考えられる。

 Puppet Ticketでもpuppet kickの存続を求める利用者の声(Undeprecate 'puppet kick' run mode)もあがっているが、残念ながら復活は無く、現状のStable版の4.x系を利用する場合はMarionette Collectiveの利用することが標準となっているようである。

 puppet kickは非常に便利だが、利用する場合は将来、廃止される機能であることを考慮することが必須となる。

 

エンジニア採用中!私たちと一緒に働いてみませんか?