庖丁解puppet之高級篇（組織結構設計）

庖丁解puppet之高級篇
（組織結構設計）

 

前言：
    咱們通過puppet之初級入門和puppet之中級進階後，能夠說你也能夠用puppet管理上100臺linux服務器了，但管理服務器越多，在site.pp裏要設置的東西就越多，如真有上千臺服務器要管理，1千個節點的配置文檔都做到site.pp裏，勢必它將變得很複雜並很難去管理，所以puppet組織結構研究就出來了，咱們可把配置文件存儲在多個文件夾和文件中。咱們把Site.pp文件看做一個金字塔的頂點，其它全部文件及文件夾由它引用便可。

1、常見結構整理
   看了網上無數資料，經過億圖畫出瞭如下三種結構，紅色的表示根目錄，桔色的表示目錄，藍色的表示文件。由於我處於探索puppet中，因此很差說誰好誰壞，根據我目前我的的理解，我以爲圖二比較適合我公司用，linux服務器很少，只有70臺左右，其它幾百臺服務器都是windows，用不上puppet。圖一，太過於簡單，若是節點服務器一多，結構勢必會有點亂，圖三，過於精細化，對上千臺服務器的規模有用。

(1)、編寫base.pp
功能說明:安裝cron包並啓動服務

#vim base.pp
class cron::base {
package { cron:
name => $operatingsystem ?
{#facter 獲取客戶端操做系統肯定包的名稱
ubuntu => "cron",
debian => "cron",
redhat => "vixie-cron",
centos => "vixie-cron", },
ensure => present,
}
service { crond:
name => $operatingsystem ? { #肯定啓動cron的名稱
ubuntu => "cron",
debian => "cron",
redhat => "crond",
centos => "crond", },
ensure => running,
enable => true,
pattern => cron,
require => Package["cron"], #依賴關係
}
}
(2)、編寫crontabs.pp
功能說明：安裝crontabs包

#vim crontabs.pp
class cron::crontabs {
package { crontabs:
name => $operatingsystem ? {
redhat => "crontabs",
centos => "crontabs",
},
ensure => present,
}
}

(3)、編寫addcron.pp
功能說明：添加crontab定時任務（定時同步時間服務器每4個小時同步的第1分鐘同步）

#vim addcron.pp
class cron::addcron {
cron { ntpdate:
command => "/usr/sbin/ntpdate time-b.timefreq.bldrdoc.gov",
user => root,
hour => '*/4',
minute => '1'
}
}

(4)、編寫init.pp
功能說明:初始化文件

#vim init.php
class cron {
case $operatingsystem {
centos: {
include cron::base
include cron::crontabs
}
redhat: {
include cron::base
include cron::crontabs
include cron::addcron #這三行實現安裝添加cron功能
}
debian: { include cron::base }
ubuntu: { include cron::base }
freebsd: { }
}
}

(5)、編寫主manifests文件實現讓客戶端安裝cron和添加一條crontab做業。

#cd /etc/puppet/manifests
#vim modules.pp #加載cron模塊
import "cron"
#vim nodes.pp #客戶端節點管理文件
node 'client.puppet.com'{
include cron
}
#vim site.pp #加載modules.pp 和nodes.pp
import "modules.pp"
import "nodes.pp"

重啓服務端服務
# /etc/init.d/puppetmaster start

客戶端
執行同步
# puppetd --server server.puppet.com --test

manifests/
|– modules.pp #模塊導入接口，使用import systembase（模塊名）方式導入
|– node.pp #節點文件，在節文件裏面include 模塊
|– site.pp #puppet主要入口

modules/
|– systembase #模塊的名稱
|—templates #模板目錄
|– files #文件目錄
|– hosts
|– vimrc
|– manifests #模塊主入口
|– init.pp #這個文件是必須存在的

#cat modules.pp
Import 「systembase」
#cat node.pp
Node ‘node.xxxx.com’{ #node.xxxx.com 是客戶端的hostname
Include systembase #若是同時導入多個模塊用逗號隔開
}
#cat site.pp
Import 「node.pp」 #導入節點文件
Import 「modules.pp」 #導入模塊文件
Node default { #默認節點測試內容
File { 「/tmp/lightest.txt」:
Content => 「powerlgh is test puppet」,
}
}
#cat host
Ha ,ha
# cat init.pp
##systembase class modules
Class systembase {
#system files
File { 「/opt/host」: #一個語句的開始用冒號
Mode => 0644, #語句中間用逗號
Source => 「puppet://$fileserver/systembase/host」; #一個語句結束後使用分號
}
}

 

1全部的配置文件最後都要被主site.pp引用。
主線是：1 class目錄下的類.pp=>服務的主配置文件init.pp=>引用模塊的mudule.pp
2 node文件夾下服務器分組node節點.pp（例如C.pp）=>node文件夾下site.pp
3主配置site.pp把1的mudule.pp 和2的node文件夾下site.pp 去「 import」。
2可是site.pp，不是惟一的，咱們能夠建無數的site.pp，須要在/etc/puppet/manifests目錄下
3 維護方法：
3.1增長服務爲模塊，在/etc/puppet/module目錄下新建文件夾。
3.2只須要維護此模塊下的class下的文件，配置文件所有引用變量，在對應的node裏面「 include」類，而且申明變量值。

其中重要文件配置（我這裏主要是ice的升級和回滾）：
#cat manifests/node/site.pp
import 「java.pp」
import 「c.pp」
#cat modules/revfsserver/manifests/init.pp
import 「class/*.pp」

#cat manifests/node/c.pp
node ‘client.dongwm.com’ {
$group=」dongwm」
$owner=」dongwm」
$tar=」X.tar.gz」
$homedir=」/opt/newfs/bin」
$tardir=」/opt/src」
$path=」/usr/bin:/usr/sbin:/bin」
include ice::base
include ice::update
include ice::rollback

}

# cat manifests/site.pp
import 「node/site.pp」
import 「node/module.pp 」

#cat manifests/module.pp
import 「ice」

2、實例操做
目的：
經過模塊化編寫，實現兩臺web客戶機更新web站點

2.1搭建結構

2.2結構解說：
    全部的PP，最後都是site.pp裏進行引用，modules下面根據業務創建文件夾，每一個文件夾就是一個模塊。這裏的案例是更新java和puppet的兩個web服務器，因此取名爲java-web，puppet-web。全部的模塊，都在node.pp和modules.pp裏引用，注意node.pp裏引用，用的關鍵詞是include，不是import。每一個模塊下，必須有個init.pp。
[root@testsns manifests]# more site.pp

import "node.pp"
import "modules.pp"
node default {
file {
"/tmp/lghtest.txt":
content => "powerlgh is test puppet",
}
}
[root@testsns manifests]# more node.pp

node 'nfstest' {
include java-web
}
node 'kaifa' {
include puppet-web
}

[root@testsns manifests]# more modules.pp

import "java-web"
import "puppet-web"
[root@testsns manifests]# more init.pp
##java-web class modules

class java-web {
file
{ "/opt/java-web-update-file/java.war":
source => "puppet://$puppetserver/java-web/java.war",
notify => Exec["exec-java-web-update"],
}
exec
{ "exec-java-web-update":
cwd => "/root/scripts",
command => "sh /root/scripts/update_java_web.sh",
user => "root",
path => "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin",
}

}

init.pp
[root@testsns manifests]# more init.pp
##puppet-web class modules

class puppet-web {
file
{ "/opt/puppet-web-update-file/puppet.war":
source => "puppet://$puppetserver/puppet-web/puppet.war",
notify => Exec["exec-puppet-web-update"],
}
exec
{ "exec-puppet-web-update":
cwd => "/root/scripts",
command => "sh /root/scripts/update_Puppet_web.sh",
user => "root",
path => "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin",
}

}

2.3服務器端執行：
[root@testsns manifests]# puppetrun nfstest kaifa

2.4客戶端查看日誌：
[root@nfstest opt]# tail -f /var/log/messages

[root@kaifa puppet]# tail -f /var/log/messages

2.5打開網站，再次驗證：

嗯，達到效果了。
3、總結：
   把開發部送過來的包，丟到modules目錄下的files文件裏，而後執行puppetrun host1 host2 host… 就好了，不過實驗中發現，客戶端默認是每半小時去鏈接一次puppet服務器端，無論有沒有更新，sh更新腳本仍是執行了，這是個嚴重問題，解決辦法有兩個，一是把客戶端的間隔時間延長，但能延多長，網上的資料沒說，二是不起puppet客戶端，登陸到客戶端手工執行，這種方式，在我公司很少的服務器上仍是可取的，自己每次更新的程序，誰都沒法保證能正常更新在生產環境中，即時經過測試環境經過了，因此每次我在更新程序時，先看catalila.out日誌，有沒有報錯，有錯，程序必定有問題，沒錯，再打開頁面訪問一下，是否正常。
本博文參考瞭如下博文：
http://www.issacy.com/archives/587.html
http://dongwm.blog.51cto.com/2621371/471163
http://my.oschina.net/duxuefeng/blog/36201

4、後記：    因我的精力有限，加上我公司的linux服務器不到100臺，因此用puppet來做統一管理，真是浪費了puppet，我會在網站war更新中應用它，也就是應用它的file傳輸及shell命令執行兩個功能，至於更深刻的erb文件編寫，就不去研究了，經過初級篇，中級進階篇，到本文的高級篇，管理1000臺如下的服務器，是可行的了。