|
目录
1、puppet的master/agent部署
2、puppet的kick功能实现
3、master/agent工作案例
4、总结
在前一博文(http://www.iyunv.com/thread-77455-1-1.html)中介绍了puppet的一些基础知识,并且所有的测试代码都是直接运行manifest的方式来运行,这是puppet的standalone的工作方式,但在生产环境下往往是让puppet工作在master/agent的工作模式,所以此博文以实现部署一个master/agent的测试环境来对puppet的使用做进一步的说明。
1、puppet的master/agent部署
在puppet的master与agent之间的通信建立是需要解析主机名,所以需要DNS来解析,在实际生产环境下也应该为每一个加入puppet环境的主机规划好主机名,每个公司都应有自己的命名规范,强烈建议主机名中能体现出主机的角色、所处地址位置、主机IP、所属运营商等信息,即主机的命名规范一般为:“ 角色-运营商-机房名-IP.管理域名”,当然,这个要根据自己的实际需要而定。
这次不再用epel源来安装puppet,而是手动安装puppet第3版的,主机名的解析通过hosts文件来完成。先来介绍一下我这里的环境,系统都是CentOS 6.4_x86_64,主机名及IP规划如下:
Master:
nod1.test.com 192.168.0.201
Agent:
nod2.test.com 192.168.0.202
1.1、域名解析配置
确保两主机的“/etc/hosts”文件中有以下配置:
1
2
3
| [iyunv@nod1 ~]# cat /etc/hosts
192.168.0.200 nod0.test.comnod0
192.168.0.201 nod1.test.comnod1
|
注:在puppet的环境中一旦安装好puppet后,如果修改了主机名,那agent与master间的通信会有问题,因为它们之间的通信是需要证书,而证书又包含了主机的信息。
1.2、master与agent端安装
master端安装
1
2
| [iyunv@nod1 puppet3.3]# ls
facter-1.7.3-1.el6.x86_64.rpm puppet-server-3.3.1-1.el6.noarch.rpm puppet-3.3.1-1.el6.noarch.rpm ruby-rgen-0.6.5-1.el6.noarch.rpm
|
#ruby-rgen是可能的依赖包(这里下载http://www.filewatcher.com/m/ruby-rgen-0.6.5-1.el6.noarch.rpm.89036-0.html)
#facter-1.7是puppet所依赖的
#安装puppet-server时,它会依赖puppet
所以这些包在master端都需要安装上
1
2
3
4
5
6
7
| [iyunv@nod1 puppet3.3]# yum -y install puppet-server-3.3.1-1.el6.noarch.rpm puppet-3.3.1-1.el6.noarch.rpm facter-1.7.3-1.el6.x86_64.rpm
[iyunv@nod1 puppet3.3]# rpm -q puppet-server
puppet-server-3.3.1-1.el6.noarch
[iyunv@nod1 puppet3.3]# rpm -q puppet
puppet-3.3.1-1.el6.noarch
[iyunv@nod1 puppet3.3]# puppet -V
3.3.1
|
服务端安装好后,先在前台启动puppet来观察一下,puppet服务端在首次的启动时会发生什么,所用到的命令是puppet,此命令的使用格式为“puppet <subcommand> [options] <action> [options]”,因这是master,所以子命令就是master,用“puppet help master”就可以查看master子命令的使用方法。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| [iyunv@nod1 puppet3.3]# puppet master -v --no-daemonize #以在前台的方式启动puppet master,“-v”表示显示详细信息
Info: Creating a new SSL key for ca
Info: Creating a new SSL certificate request for ca
Info: Certificate Request fingerprint (SHA256): B5:09:73:02:41:FD:08:8A:9D:76:97:ED:CC:F0:29:1D:AB:05:E8:87:F4:1A:85:57:D6:BA:CD:93:47:15:00:7A
Notice: Signed certificate request for ca
Notice: Rebuilding inventory file
Info: Creating a new certificate revocation list
Info: Creating a new SSL key for nod1.test.com
Info: Creating a new SSL certificate request for nod1.test.com
Info: Certificate Request fingerprint (SHA256): 77:E8:8A:1C:6B:A5:67:76:9E:7B:99:14:89:03:6F:7E:D7:DC:EB:95:7B:2B:97:95:DD:BA:E1:90:3C:38:35:9E
Notice: nod1.test.com has a waiting certificate request
Notice: Signed certificate request for nod1.test.com
Notice: Removing file Puppet::SSL::CertificateRequest nod1.test.com at '/var/lib/puppet/ssl/ca/requests/nod1.test.com.pem'
Notice: Removing file Puppet::SSL::CertificateRequest nod1.test.com at '/var/lib/puppet/ssl/certificate_requests/nod1.test.com.pem'
Notice: Starting Puppet master version 3.3.1
|
仔细观察上边的输出,在服务端启动时,puppet会自己创建一个ca,并为自己颁发一个证书,接下来它就可以接受agent端面的证书签署请求了,一旦服务端给agent签署证书签署请求,那agent就可以到master来请求catalog了。
puppet的证书管理的目录是在"/var/lib/puppet/ssl/":
1
2
3
4
| [iyunv@nod1 ~]# ls /var/lib/puppet/ssl/
ca certificate_requests certs crl.pem private private_keys public_keys
[iyunv@nod1 ~]# ls /var/lib/puppet/ssl/certs/
ca.pem nod1.test.com.pem
|
检测服务端能正常启动后,结束掉前台运行的模式,用服务脚本的方式启动puppet master。
1
2
3
4
5
| [iyunv@nod1 puppet3.3]# service puppetmaster start
Starting puppetmaster: [ OK ]
[iyunv@nod1 puppet3.3]# ss -tnlp
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 5 *:8140 *:* users:(("puppet",2001,5))
|
#服务端面监听到tcp的8140端口上。
1
2
3
| [iyunv@nod1 puppet3.3]# puppet cert list --all
+ "nod1.test.com" (SHA256) C6:51:F9:72:15:7A:36:13:D1:12:AD:4D:0F:87:DE:8A:36:06:33:D8:5B:ED:77:76:35:DE:3D:78:57:0A:90:85 (alt names: "DNS:nod1.test.com", "DNS:puppet", "DNS:puppet.test.com")
#puppet master自己给自己颁发了一个证书,每行前的“+”号表示已签发。
|
agent端安装及与master通信的建立过程
1
2
3
4
5
6
7
| [iyunv@nod2 puppet3.3]# pwd
/root/software/puppet3.3
[iyunv@nod2 puppet3.3]# ls
facter-1.7.3-1.el6.x86_64.rpm puppet-3.3.1-1.el6.noarch.rpm ruby-rgen-0.6.5-1.el6.noarch.rpm
[iyunv@nod2 puppet3.3]# yum -y install ruby-rgen-0.6.5-1.el6.noarch.rpm puppet-3.3.1-1.el6.noarch.rpm facter-1.7.3-1.el6.x86_64.rpm
[iyunv@nod2 puppet3.3]# puppet -V
3.3.1
|
安装好后也在前台的方式启动agent来观察:
1
2
3
4
5
| [iyunv@nod2 puppet3.3]# puppet agent -v --no-daemonize --server nod1.test.com
Info: Creating a new SSL key for nod2.test.com
Info: Caching certificate for ca
Info: Creating a new SSL certificate request for nod2.test.com
Info: Certificate Request fingerprint (SHA256): 47:BA:C0:DA:39:51:37:19:11:E0:FB:1E:EE:80:46:7B:E3:B0:AC:2E:BA:04:23:E4:B0:C7:84:D7:A2:D2:85:1F
|
agent端在启动时会生成一个证书签署请求,存放的路径在“/var/lib/puppet/ssl/certificate_requests/ ”,如下:
1
2
| [iyunv@nod2 puppet3.3]# ls /var/lib/puppet/ssl/certificate_requests/
nod2.test.com.pem
|
因指定了“--server nod1.test.com”,这个证书签署请求发送到了master端,回到master端进行查看:
1
2
3
| [iyunv@nod1 puppet3.3]# puppet cert list --all
"nod2.test.com" (SHA256) 8B:3E:6A:6B:8A:38:D9:C5:89:8D:9A:F0:FB:B7:99:E2:AF:89:C5:9D:E8:1D:FA:2C:BD:31:CF:B9:60:15:C9:F5
+ "nod1.test.com" (SHA256) C6:51:F9:72:15:7A:36:13:D1:12:AD:4D:0F:87:DE:8A:36:06:33:D8:5B:ED:77:76:35:DE:3D:78:57:0A:90:85 (alt names: "DNS:nod1.test.com", "DNS:puppet", "DNS:puppet.test.com")
|
agent端发过来的证书签署请求被暂时存放在了“/var/lib/puppet/ssl/ca/requests/”目录下,当被master签署后此签署请求将被删除:
1
2
| [iyunv@nod1 puppet3.3]# ls /var/lib/puppet/ssl/ca/requests/
nod2.test.com.pem
|
接下来由管理员来对此证书签署请求决定是否签署,如果不签署,则用以下命令:
1
2
3
| [iyunv@nod1 puppet3.3]# puppet ca destroy nod2.test.com
Notice: Removing file Puppet::SSL::CertificateRequest nod2.test.com at '/var/lib/puppet/ssl/ca/requests/nod2.test.com.pem'
Deleted for nod2.test.com: Puppet::SSL::CertificateRequest
|
#对不签署证书的操作很容易搞错,因为签署时所用的命令是“puppet cert sign nod2.test.com”,在cert的帮助信息中也有"revoke"和"clean"这样的选项,给人造成了混淆。这里有个链接解答此问题:http://superuser.com/questions/784471/how-to-reject-certificate-request-on-puppet-master
如果master因某种原因拒绝了agent的证书签署请求,当agent的故障排除后需要再次向master端发起证书签署请求,这时你再次运行“puppet agent -v --no-daemonize --server nod1.test.com”命令后agent不会有任何反应,因为之前已发送了证书签署请求,这时应该把生成的证书签署请求删除后再运行命令重新向master连接,规范的做法如下:
1
2
| [iyunv@nod2 puppet3.3]# puppet certificate_request destroy nod2.test.com
Notice: Removing file Puppet::SSL::CertificateRequest nod2.test.com at '/var/lib/puppet/ssl/certificate_requests/nod2.test.com.pem'
|
也可以直接去删除“/var/lib/puppet/ssl/certificate_requests/nod2.test.com.pem”这个证书签署请求文件。
如果master端接收agent的证书签署请求,那运行如下命令:
1
2
3
4
| [iyunv@nod1 puppet3.3]# puppet cert sign nod2.test.com
Notice: Signed certificate request for nod2.test.com
Notice: Removing file Puppet::SSL::CertificateRequest nod2.test.com at '/var/lib/puppet/ssl/ca/requests/nod2.test.com.pem'
#一旦签署后,在master端的agent的证书签署请求文件被删除
|
证书签署请求被master签署后,回到agent再次运行“ puppet agent -v --no-daemonize --server nod1.test.com “命令观察:
1
2
3
4
5
6
7
8
9
10
| [iyunv@nod2 puppet3.3]# puppet agent -v --no-daemonize --server nod1.test.com
Info: Caching certificate for nod2.test.com
Notice: Starting Puppet client version 3.3.1
Info: Caching certificate_revocation_list for ca
Info: Retrieving plugin
Info: Caching catalog for nod2.test.com
Info: Applying configuration version '1434162185'
Info: Creating state file /var/lib/puppet/state/state.yaml
Notice: Finished catalog run in 0.03 seconds
#从输出内容可知,agent正在向master请求catalog(伪代码)。
|
最后agent端也需要以服务脚本的方式运行,所以需要在其配置文件中指向master:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| [iyunv@nod2 puppet3.3]# vim /etc/puppet/puppet.conf
.....
[agent]
....
#在agent配置段加入下边的代码指向master
server = nod1.test.com
[iyunv@nod2 puppet3.3]# service puppet start
Starting puppet agent: [ OK ]
[iyunv@nod2 puppet3.3]# ps aux | grep puppet
root 2370 1.4 8.4 129400 42404 ? Ss 10:31 0:00 /usr/bin/ruby /usr/bin/puppet agent
root 2482 0.0 0.1 103236 860 pts/0 S+ 10:31 0:00 grep puppet
[iyunv@nod2 puppet3.3]# ss -tnl
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 :::22 :::*
LISTEN 0 128 *:22 *:*
LISTEN 0 100 ::1:25 :::*
LISTEN 0 100 127.0.0.1:25 *:*
#agent端启动后不会监听在任何的端口上,只是在后台运行着。
|
小结:至此,puppet的master/agent模型部署完毕,要注意的细节:部署之前各服务器主机名的规划,一旦部署完成,最好不要更改服务器的主机名;证书的管理要记得那几个常用的命令,特别是拒绝证书签署请求时。
2、puppet的kick功能实现
默认时,agent端会每隔30分钟去联系master下载catalog到本地执行,但有些紧急情况下管理员希望手动强制把让agent来下载catalog进行执行,例如当一个高危险的漏洞报出后,你需要第一时间进行修补,这时kick功能就有其用武之地了。
编译agent端的配置文件:
1
2
3
4
5
6
| [iyunv@nod2 puppet3.3]# vim /etc/puppet/puppet.conf
.....
[agent]
....
#增加下边的代码,让agent监听在tcp的8139的端口上。
server = true
|
接着创建namespaceauth.conf文件:
1
2
3
| [iyunv@nod2 puppet3.3]# vim /etc/puppet/namespaceauth.conf
[puppetrunner]
allow *.test.com
|
#允许test.com这个域
再编辑auth.conf文件:
1
2
3
4
5
6
| [iyunv@nod2 puppet3.3]# vim /etc/puppet/auth.conf
......
#加入下边的代码
path /run
method save
allow nod1.test.com
|
注意:上边的代码不要加在最后边,应该加在”path / \n auth any“之前。
当想使用kick功能时直接在master端执行如下命令:
1
2
3
4
5
6
7
8
| [iyunv@nod1 puppet3.3]# puppet kick -p 10 --host nod2.test.com
Warning: Puppet kick is deprecated. See http://links.puppetlabs.com/puppet-kick-deprecation
Warning: Failed to load ruby LDAP library. LDAP functionality will not be available
Triggering nod2.test.com
Getting status
status is success
nod2.test.com finished with exit code 0
Finished
|
选项解释:
-p --ping:帮助文档中的说明为“Do an ICMP echo against the target host. Skip hosts that don't respond to ping”,我理解为在发出kick操作时对那些无法联系的主机进行ICMP探测,这里就是指定探测的次数
--host:指定主机,可以有多个,用空格隔开。
3、master/agent工作案例
puppet自动化运维环境部署好后,就要自己根据工作需要去编写manifest文件了,我这里以一个小案例来验证我们上边部署的puppet环境是否可用,在http://www.iyunv.com/thread-74049-1-1.html这一博文中我把tengine已打包成了一个rpm包,这里我就以安装tengine为例。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
| [iyunv@nod1 modules]# pwd
/etc/puppet/modules
[iyunv@nod1 modules]# mkdir -pv tengine/{manifests,files,templates,lib,spec,tests}
[iyunv@nod1 modules]# tree tengine/
tengine/
├── files
├── lib
├── manifests
├── spec
├── templates
└── tests
[iyunv@nod1 puppet]# vim modules/tengine/manifests/init.pp
class tengine {
package {'tengine':
ensure => present,
source => '/tmp/tengine-2.1.0-1.el6.x86_64.rpm', #这个包在agent上的/tmp目录下
provider => rpm,
before => File['nginx.conf'],
}
file {'nginx.conf':
ensure => file,
path => '/etc/tengine/nginx.conf',
source => 'puppet:///modules/tengine/nginx.conf',
owner => root,
group => root,
mode => 0644,
notify => Service['nginx'],
}
service {'nginx':
ensure => running,
enable => true,
path => '/etc/rc.d/init.d/nginx',
require => Package['tengine'],
}
}
#注意:init.pp中类的名称一定要与模块的名称相同。
[iyunv@nod1 puppet]# ls modules/tengine/files/
#此目录下提供了tengine的配置文件
nginx.conf
[iyunv@nod1 puppet]# vim /etc/puppet/manifests/site.pp
node "nod2.test.com" {
include tengine
}
[iyunv@nod1 puppet]# puppet kick -p 3 --host nod2.test.com
Warning: Puppet kick is deprecated. See http://links.puppetlabs.com/puppet-kick-deprecation
Warning: Failed to load ruby LDAP library. LDAP functionality will not be available
Triggering nod2.test.com
Getting status
status is success
nod2.test.com finished with exit code 0
Finished
|
#看输出报告是成功了
到agent端进行验证:
1
2
| [iyunv@nod2 ~]# ss -tnlp | grep nginx
LISTEN 0 128 *:80 *:* users:(("nginx",14798,6),("nginx",14799,6))
|
4、总结
master/agent的环境现在已搭建完毕,并能正常的运行,接下的学习就是不断的编写一些模块,让自己形成一种编写代码的风格。在puppet的世界需要学习的知识还有许多,我们一起前行!
|
|