目錄
1、puppet的master/agent部署
2、puppet的kick功能實現
3、master/agent工作案例
4、總結
在前一博文(http://zhaochj.blog.51cto.com/368705/1661360)中介紹了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”文件中有以下配置:
[root@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端安裝
[root@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端都需要安裝上
[root@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 [root@nod1 puppet3.3]# rpm -q puppet-server puppet-server-3.3.1-1.el6.noarch [root@nod1 puppet3.3]# rpm -q puppet puppet-3.3.1-1.el6.noarch [root@nod1 puppet3.3]# puppet -V 3.3.1
服務端安裝好後,先在前臺啓動puppet來觀察一下,puppet服務端在首次的啓動時會發生什麼,所用到的命令是puppet,此命令的使用格式爲“puppet <subcommand> [options] <action> [options]”,因這是master,所以子命令就是master,用“puppet help master”就可以查看master子命令的使用方法。
[root@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/":
[root@nod1 ~]# ls /var/lib/puppet/ssl/ ca certificate_requests certs crl.pem private private_keys public_keys [root@nod1 ~]# ls /var/lib/puppet/ssl/certs/ ca.pem nod1.test.com.pem
檢測服務端能正常啓動後,結束掉前臺運行的模式,用服務腳本的方式啓動puppet master。
[root@nod1 puppet3.3]# service puppetmaster start Starting puppetmaster: [ OK ] [root@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端口上。
[root@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通信的建立過程
[root@nod2 puppet3.3]# pwd /root/software/puppet3.3 [root@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 [root@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 [root@nod2 puppet3.3]# puppet -V 3.3.1
安裝好後也在前臺的方式啓動agent來觀察:
[root@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/ ”,如下:
[root@nod2 puppet3.3]# ls /var/lib/puppet/ssl/certificate_requests/ nod2.test.com.pem
因指定了“--server nod1.test.com”,這個證書籤署請求發送到了master端,回到master端進行查看:
[root@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簽署後此簽署請求將被刪除:
[root@nod1 puppet3.3]# ls /var/lib/puppet/ssl/ca/requests/ nod2.test.com.pem
接下來由管理員來對此證書籤署請求決定是否簽署,如果不簽署,則用以下命令:
[root@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連接,規範的做法如下:
[root@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的證書籤署請求,那運行如下命令:
[root@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 “命令觀察:
[root@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:
[root@nod2 puppet3.3]# vim /etc/puppet/puppet.conf ..... [agent] .... #在agent配置段加入下邊的代碼指向master server = nod1.test.com [root@nod2 puppet3.3]# service puppet start Starting puppet agent: [ OK ] [root@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 [root@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端的配置文件:
[root@nod2 puppet3.3]# vim /etc/puppet/puppet.conf ..... [agent] .... #增加下邊的代碼,讓agent監聽在tcp的8139的端口上。 server = true
接着創建namespaceauth.conf文件:
[root@nod2 puppet3.3]# vim /etc/puppet/namespaceauth.conf [puppetrunner] allow *.test.com
#允許test.com這個域
再編輯auth.conf文件:
[root@nod2 puppet3.3]# vim /etc/puppet/auth.conf ...... #加入下邊的代碼 path /run method save allow nod1.test.com
注意:上邊的代碼不要加在最後邊,應該加在”path / \n auth any“之前。
當想使用kick功能時直接在master端執行如下命令:
[root@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://zhaochj.blog.51cto.com/368705/1658496這一博文中我把tengine已打包成了一個rpm包,這裏我就以安裝tengine爲例。
[root@nod1 modules]# pwd /etc/puppet/modules [root@nod1 modules]# mkdir -pv tengine/{manifests,files,templates,lib,spec,tests} [root@nod1 modules]# tree tengine/ tengine/ ├── files ├── lib ├── manifests ├── spec ├── templates └── tests [root@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中類的名稱一定要與模塊的名稱相同。 [root@nod1 puppet]# ls modules/tengine/files/ #此目錄下提供了tengine的配置文件 nginx.conf [root@nod1 puppet]# vim /etc/puppet/manifests/site.pp node "nod2.test.com" { include tengine } [root@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端進行驗證:
[root@nod2 ~]# ss -tnlp | grep nginx LISTEN 0 128 *:80 *:* users:(("nginx",14798,6),("nginx",14799,6))
4、總結
master/agent的環境現在已搭建完畢,並能正常的運行,接下的學習就是不斷的編寫一些模塊,讓自己形成一種編寫代碼的風格。在puppet的世界需要學習的知識還有許多,我們一起前行!