运维学习笔记-看看别人家的Puppet代码

这篇博客的目的是通过分析Forge上的Puppet模块来加深一些概念的理解,同时了解一些常用用法。

今天的例子是jfryman-nginx模块,它是原puppetlabs-nginx模块的升级版本,依赖3个Puppet公共模块:puppetlabs-aptpuppetlabs-stdlibpuppetlabs-concat。安装非常方便,puppet module install会自动为你安装所依赖的模块。

> puppet module install jfryman-nginx
/etc/puppet/modules
└─┬ jfryman-nginx (v0.3.0)
     ├── puppetlabs-apt (v2.2.2)                        #Puppet公共模块,提供Debain/Ubuntu下安装包管理功能
     ├── puppetlabs-stdlib (v4.12.0)                   #Puppet公共模块,提供对各种数据类型的操作函数,比如检查,转换之类
     └── puppetlabs-concat (v2.1.0)                  #Puppet公共模块,可以将分散在不同文件中的内容组合到一个目标文件中

模块的目录结构就不在这里累述了,tree /etc/puppet/modules/nginx命令可以显示详细的结构,需要注意的是模块的manifests目录中有以下5个文件:

├── manifests
│   ├── init.pp                             #模块自装载起始文件
│   ├── params.pp                      #参数类定义文件,用于给其他各类的参数变量提供默认值
│   ├── config.pp                        #配置类的定义文件
│   ├── package.pp                    #软件包安装类的定义文件
│   ├── service.pp                      #服务类的定义文件
│   └── ...

任何Forge中的模块,基本都会包含上面这几个文件。这已经成为了一种标准。其好处之一是可以清晰划分从软件包安装,配置到服务启动的各阶段功能;另一方面代码中可以利用类来定义各阶段的依赖关系,因为每个阶段通常都包含多个资源,所以用类定义依赖关系比用资源更加灵活实用。


下面我们看看模块的init.pp

代码片段1:类定义


class nginx (                                                      #nginx类定义
...
  $package_name      = $::nginx::params::package_name,    #用nginx::params类中的变量$package_name给nginx类的$package_name赋默认值
  $package_source    = 'nginx',                           #设置$package_source默认值为'nginx'
  $package_flavor    = undef,                             #设置$package_source默认值undef
...
) inherits ::nginx::params {                                  #nginx类继承nginx::params类

以上是nginx的类定义。不禁要问几个问题

nginx类为什么要定义参数

主要是为了使nginx类更加灵活的适应各种不同的应用场景。调用者可以通过nginx类的参数变量来传递不同的值,从而影响nginx中资源的属性和行为。

nginx为什么要继承nginx::params类

在Puppet中,类继承一般只用于2个目的

    * 重用基类中大部分代码和逻辑,只重写一小部分代码以实现新的功能

    * 利用基类中的预定义变量值给子类的类参数赋值。

这里是第2种情况。nginx会用到的大多数默认值都预定义在nginx::params类中。nginx继承nginx::params类来为自己的参数赋默认值。这也是最常用的赋默认值的方式。

这里专门定义了nginx::params类是因为某些默认值很可能会随目标主机的OS或其他Facts有所差异,所以将相关逻辑隔离在nginx::params类中可以更容易管理代码。比如下面的代码片段是nginx::params类中根据Facts $::osfamily设置hash变量$_module_os_overrides

  case $::osfamily {
    'ArchLinux': {
      $_module_os_overrides = {
        'pid'         => false,
        'daemon_user' => 'http',
      }
    }
    'FreeBSD': {
      $_module_os_overrides = {
        'conf_dir'    => '/usr/local/etc/nginx',
        'daemon_user' => 'www',
        'root_group'  => 'wheel',
      }
    }
...
}

很容易联想到的另一个场景是为类的参数赋初值(注意不是赋默认值),它需要在声明类的时候(注意不是定义类的时候使用resource-like声明方式声明类。比如

  class { '::nginx::service':
    configtest_enable => $configtest_enable,            #用变量$configtest_enable为类参数赋初值
....
  }

类的名字和继承有什么关系?

答案是没有关系。确定继承关系的唯一标准是看类定义时是否使用了inherits关键字。类的名字只和其manifest文件在模块目录结构中的位置有关。比如: 详情请看模块的目录结构

/etc/puppet/modules/nginx/manifests
├── init.pp                                                #nginx类
├── package.pp                                       #nginx::package类
├── package
│   ├── debian.pp                                     #nginx::package::debian类
│   └── redhat.pp                                     #nginx::package::redhat类
...

什么时候应该使用变量的长名字,什么时候使用短名字?

使用短名字访问变量受scope(作用域)的限制。

scope-euler-diagram.png

这张图中有4层作用域

    a. 顶层作用域是top scope,包含Facts和Agent/Master内置变量,以及所有site.pp中节点定义以外的所有变量,表达式,资源类型等等内容

    b. 下面一层是node scope, 也就是site.pp中节点定义所包含的所有内容

    c. 再下面是各种类的定义,在图中包括example:parent,example:four和exmaple:other.这3个类在同一层,但每个类自己是一个单独的作用域。

    d. 最下面一层是example:child,它是example:parent的子类,自己是一个作用域。

底层作用域中的代码可以用变量的短名字访问上层作用域的变量。比如,top scope 有个变量$var, example:child可以直接在自己的代码中用短名字$var使用它,同样方法也可以用来访问node scope和它的父类example:parent中的变量。

注意:这么做的前提条件是本地作用域没有同名的变量。在上面的代码段中,虽然nginx是nginx:params的子类,但因为都定义了同名的变量$package_nam,需要用长名字$::nginx:params::package_name指代nginx:params类中的$package_name变量。

除此之外,只要是访问其他作用域里的变量,都必须用长名字。比如访问同一个模块中的其他类的变量,或者另外一个模块里的的类变量。来看几个例子:   

    a. example::four和example:child在一个模块中,但它既不是example:child的父类,也不是node scope或者top scope, 如果想访问其中的变量,需要这样写

include ::exmaple::four
$myvar=$::example::four::var1。

  b. 我想访问apache模块中的apache::php类里的变量$var1。需要这样写

include ::apache::php
$myvar=$::apache::ph::var1。

在实际的编码中,为了清晰,一般都会在名字左边加::,表示从顶层作用域开始唯一标识一个类或者变量。这就就如同文件路径中的绝对路径,不会造成任何混淆。

代码片段2:依赖关系定义


Class['::nginx::package'] -> Class['::nginx::config'] ~> Class['::nginx::service']

这段代码的意思是nginx::package类必须在nginx::config类之前执行,而nginx::service类必须在nginx::config类之后执行。而且nginx::config类中任何资源的状态发生变化,比如文件内容,nginx::service类中的所有资源都会收到refresh事件。

值得注意的几点是

为什么需要描述依赖关系?

Puppet语言是声明性语言,不描述流程,所以Puppet代码执行的顺序和代码写的顺序经常是不一致的,这就是Puppet中经常提到的 independent of evaluation-order 。当资源或者类有执行的先后顺序时,就需要显性的描述依赖关系。

还有什么方式可以描述依赖关系?

类和资源都可以使用->和~>描述依赖关系(资源与资源,类与类,资源与类之间)。

另一种方法是用元参数require/before/notify/subscribe。这种方法可以在资源声明时说明依赖关系,既可以用于资源,也适用于resource-like声明的类。

还有一种方法是使用require函数(注意不是元参数require)描述类之间的依赖关系。详情请见在线文档

为什么Class首字母大写?

因为是引用(reference),也就是在定义和声明之外的任何场景使用类或者资源时,Class和资源类型关键字的首字母都要大写。

常见的引用场景包括

    a. 类或资源声明时,使用require/before/notify/subscribe来描述依赖关系,比如

file { '/etc/nginx.conf'
require=> Package['nginx']                                #Package首字母大写
}

    b. 资源声明时,引用另外一个资源的属性,这个例子中引用另外一个文件资源的mode属性

file { "/etc/second.conf":
ensure => file,
mode   => File["/etc/first.conf"]["mode"]                #File首字母大写
}

    c. 资源声明后,需要设置或者修改资源的某个属性,比如

File['/etc/nginx.conf'] {                                 #File首字母大写
content => template('nginx/sample.conf'),
}

在引用资源时,如果被引用的资源类型是长名字时(一般是自定义资源类型),所有::分隔的命名空间的首字母都要大写,比如。

Nginx::Resource::Location["${name}-default"] {           #Nginx::Resource::Location各段首字母大写
    location_cfg_prepend => $location_cfg_prepend
}

引用的对象是谁?

类,资源及属性可以被引用。变量不适用。

可以在类或者资源声明前引用他们吗?

答案是可以,可以在类或者资源声明前引用他们。此外,由于在同一个catalog范围的所有资源(标题)和类(名字)必须是唯一的,所以可以在代码的任何部分引用任何类和资源,不受作用域影响。

哪些资源可以处理refresh事件

service, mount和exec资源可以处理refresh事件

service的默认行为是使用init脚本(redhat linux上,脚本在/etc/rc.d/init.d/中)重新启动服务,如果你想避免重启服务, 可以设置restart属性

service {"sshd":
restart=>"service reload sshd"                #收到refresh时,运行reload而不是restart
}

mount的默认行为是重新挂载(umount再mount)

exec的默认行为是重新运行命令。它有两个相关的属性

exec { "/bin/ls ":
refresh   => "ls -l"                             #refresh发生时,运行refresh属性指定的另外一个命令
refreshonly => true,                          #exec只在refresh事件发生时才运行命令
}

代码片段3:调用所需的类


class { '::nginx::service':
    configtest_enable => $configtest_enable,
    service_ensure    => $service_ensure,
    service_restart   => $service_restart,
    service_name      => $service_name,
    service_flags     => $service_flags,
}

这段代码是用resource-like方式声明类。

Puppet支持两种类的声明方式

  include-like方式:使用include, require, contain或者hiera_include关键字,后面跟类的名字来声明类

  resource-like方式:像声明资源一样声明类。

定义和声明有什么区别?

以类举例,定义一般是说明类看起来是什么样子,含有那些资源,声明是设定类参数从而确定类中资源的属性和行为,说明类的依赖关系,然后告诉Puppet在catalog中加入这个类的一个实例。

除了类,自定义的资源类型,函数,Facts,Provider等等也需要先定义,然后声明。

注意:变量不需要定义或者声明,直接赋值就可以了

inlcude-like和resource-like声明类有什么区别?

相比inlcude-like,resource-like最大优势是可以为类赋值,这也是在类声明时为类传递参数的唯一方法。在上面的例子中,=>左边是类参数,右边是参数值。

同时,resource-like也有一个缺点,就是只能声明一次。相比之下,include-like可以声明任意多次。在一个catalog范围内,允许把个resource-like(一次)和include-like(多次)混合使用。

为什么resource-like声明只允许使用一次呢?

OOP中的类的通常有下面4个特性。Puppet中的类不一样,只有前3个特性,且只支持从一个父类继承,不支持从多个父类继承。

            抽象

            封装

            继承

            多态性

原因是Puppet中的类只是一般OOP中的的单实例类(singleton)。

当用include-like方式声明类时,虽然声明了多次,但是在catalog中只会有一个类的实例,Puppet也只会执行这个实例一次。这就是所谓的“可以多次声明,但只应用一次”。因为include-like不传入任何参数,所以这个单实例可满足所有调用者的要求。

resource-like声明可以传入参数,理论上讲,传入不同的参数也就创建出不同的实例。 所以为了保证一个实例,resource-like声明只允许使用一次,只生成一个实例。

在include-like声明方式中,include, require, contain和hiera_include有什么区别吗?

include关键是最简单的声明方式,就是告诉Puppet在catalog中生成一个类的实例。

require关键字除了include的功能,还表明的类的依赖关系

hiera_include关键字是在当Master和Hirea集成时使用,它可以通过Hirea获取类的信息并声明。

contain用在比较特殊的场合。我们会在下面和anchor一起解释。

代码片段4:使用anchor


anchor{ 'nginx::begin':
    before => Class['::nginx::package'],
    notify => Class['::nginx::service'],
}
anchor { 'nginx::end':
    require => Class['::nginx::service'],
}

anchor是Puppet的内置资源类型。上面的代码声明了两个anchor资源,分别是nginx::begin和nginx::end,他们将类nginx::package,nginx::config和nginx::service夹在中间(这3个类在上面已经用->/~>设好了依赖关系),作用是强制这3个类在nginx类开始后执行,并且必须在nginx类退出前全部执行完。

上面的代码等价于

anchor{ 'nginx::begin': }
anchor{ 'nginx::end': }
Anchor['nginx::begin']->Class['::nginx::package']->Class['::nginx::config']->Class['::nginx::service']->Anchor['nginx::end']

为什么需要用anchor呢?

如果代码中只有2层类,比如类A包含类A1和类A2,A1和A2都直接包含资源,且A2依赖A1,那么执行A时Puppet会按照定义好的顺序先执行A1内的资源,再执行A2里的资源。

当类的层次增加时,情况就不同了。比如这个例子

# /etc/puppetlabs/puppet/modules/profiles/manifests/dbserver.pp
class profiles::dbserver {
 include mysql
}
# /etc/puppetlabs/puppet/modules/profiles/manifests/webserver.pp
class profiles::webserver {
 include apache
}
# /etc/puppetlabs/puppet/modules/roles/webstack.pp
class roles::ecommerce_app {
 include profiles::dbserver
 include profiles::webserver
 Class['profiles::dbserver'] -> Class['profiles::webserver']
}
#/etc/puppetpabs/puppet/manifests/site.pp
node 'webapp01.puppetlabs.com' {
 include roles::ecommerce_app
}

大多数人的第一感觉上是Puppet会先运行mysql类,然后是apache类,实际结果却不一定,经常会看到相反的顺序,这是因为默认情况下,下层的类(mysql类和apache类)之间不会继承上层类(profiles::dbserver类和profiles::webserver类)之间的依赖关系。

为了使下层的类也能够遵循上层类的顺序执行,需要使用contain或者anchor

a. 使用contain

# /etc/puppetlabs/puppet/modules/profiles/manifests/dbserver.pp
class profiles::dbserver {
  contain mysql                                 #把include换成contain
}
# /etc/puppetlabs/puppet/modules/profiles/manifests/webserver.pp
class profiles::webserver {
  contain apache                                #把include换成contain
}

b.使用anchor

# /etc/puppetlabs/puppet/modules/profiles/manifests/dbserver.pp
class profiles::dbserver {
  anchor{'before_mysql:'} -> class{'mysql':} -> anchor{'after_mysql':}   #声明anchor并把mysql夹在中间
}
# /etc/puppetlabs/puppet/modules/profiles/manifests/webserver.pp
class profiles::webserver {
  anchor{'before_apache:'} -> class{'apache':} -> anchor{'after_apache':}#声明anchor并把apache夹在中间
}

anchor和contain有什么区别呢?

contain和anchor的效果完全相同。Puppet也同时支持这两种方法。

区别是contian是在Puppet Enterprise 3.2.0 (Puppet 3.4.0)之后才出现的,在此之前只能用anchor. 而且contain后面只能直接跟类的名字,不能跟resource-like类声明。

除此之外,还可以看到一些常用的用法

代码片段5:调用stdlib函数


  validate_string($multi_accept)                        #检查输入字符串是否合法
...
  validate_array($proxy_set_header)                #检查输入数组是否合法
...
  validate_bool($confd_purge)                         #检查输入bool是否合法
...

上面的代码是调用puppetlabs-stdlib模块中携带的函数做各种检查。

puppetlabs-stdlib是Forge上的一个公共模块,提供了很多自定义资源类型,函数,Facts,极大的方便了编程。在编程中也非常常用到。

在使用时,需要先确认puppetlabs-stdlib已经安装在你的系统中(可以用puppet module list检查),如果没有安装,运行puppet module install puppetlabs-stdlib进行安装。

一般情况下,无需显性声明stdlib(include stdlib),可以直接调用其中功能,和使用内置的资源类型,函数,Facts没有区别。

代码片段6:调用concat函数


concat { $config_file:                                    #声明concat资源,指定目标文件,这里是$config_file指代的文件
    owner  => $owner,
    group  => $group,
    mode   => $mode,
    notify => Class['::nginx::service'],
}

concat::fragment { "${name_sanitized}-header":           #声明concat::fragment资源,然后将所需内容写入目标文件。
    target  => $config_file,                             #目标文件是$config_file指代的文件
    content => template('nginx/vhost/vhost_header.erb'), #写入的内容来自于模板'nginx/vhost/vhost_header.erb'
    order   => '001',                                    #说明当前内容在目标文件中的位置。这个数字越小,写入的内容越排在前面
}

concat::fragment { "${name_sanitized}-footer":            #声明另外一个concat::fragment资源,然后将所需内容写入目标文件。  
    target  => $config_file,                              #目标文件是$config_file指代的文件
    content => template('nginx/vhost/vhost_footer.erb'),  #写入的内容来自于模板'nginx/vhost/vhost_footer.erb'
    order   => '699',                                     #说明当前内容在目标文件中的位置。699大于001,所以写在vhost_header.erb写在vhost_header.erb
}

以上代码是将使用puppetlabs-concat模块将vhost_header.erb和vhost_footer.erb的结果输出的$config_file指定的文件中。

puppetlabs-concat也是一个很常用的公共模块,它的作用是将不同的文件的内容排序后输出到一个新的目标文件中。使用puppetlabs-concat与puppetlabs-stdlib方法一致,不再累述。

代码片段7:日志信息函数


warning('$worker_processes must be an integer or have value "auto".')                #输出一条警告信息

除了notify资源,Puppet还有很多内置的函数可以输出不同级别的日志信息,非常方便。

        emerg             #emergency level

        crit                  #critical level

        alert                #alert level

        err                  #error level

        warning          #warning level

        info                #information level

        debug            # debug level

        notice            # notice level

代码片段8:模板


<%- if @listen_ip.is_a?(Array) then -%>                                 #判断listen_ip是不是一个列表(array),listen_ip是外部的变量,所以有@
   <%- @listen_ip.each do |ip| -%>                                         #遍历listen_ip列表。ip代表列表中的当前项,是内部变量,所以他没有@
 listen       <%= ip %>:<%= @listen_port %><% if @listen_options %> <%= @listen_options %><% end %>;    #将内部变量ip, 外部变量listen_port 和listen_options组成一行,写入文件。
   <%- end -%>
 <%- else -%>                                                                        #如果listen_ip只有一个值,不是列表,就不再遍历
 listen       <%= @listen_ip %>:<%= @listen_port %><% if @listen_options %> <%= @listen_options %><% end %>; ##将外部变量listen_ip,listen_port 和listen_options组成一行,写入文件。
   <%- end -%>
<%- end -%>

上面是模板中的一段代码,由ERB(embedded ruby )写成,基本覆盖了比较典型的逻辑和语法。详情请参照在线文档

原创文章,作者:MVP,如若转载,请注明出处:http://www.178linux.com/18103

(0)
MVPMVP
上一篇 2016-06-23
下一篇 2016-06-23

相关推荐

  • 搭建博客程序wordpress

    根据需求安装相关软件,搭建实验环境: #CentOS 6:Httpd,PHP,mysql-server,php-mysql #CentOS 7:Httpd,php,php-mysql mariadb-server 下载wordpress程序,并解压至/var/www/html/目录下 [root@centos077 html]# pwd /var/www/h…

    2017-04-28
  • 高效运维最佳实践(03):Redis集群技术及Codis实践

    前言 诚如开篇文章所言,高效运维包括管理的专业化和技术的专业化。前两篇我们主要在说些管理相关的内容,本篇说一下技术专业化。希望读者朋友们能适应这个转换,谢谢。 互联网早在几年前就已进入Web 2.0时代,对后台支撑能力的要求,提高了几十倍甚至几百倍。在这个演化过程中,缓存系统扮演了举足轻重的角色。 运维进化到今天,已经不是重复造轮子的时代。所以,我们在架构优…

    Linux干货 2015-04-03
  • 权限管理

    1、创建组sales,gid 3000,passwd:centos,sales admins:user2 将用户user1,user2,user3加入到sales辅助组 希望user1 创建新文件 默认的所属组为sales user2将用户user3从sales组移除 # groupadd -g 3000 sales  # gpasswd sale…

    Linux干货 2016-08-03
  • 救援模式安装grub

    如果之前mbr没有备份,而后grub损坏进不了系统,只能用系统光盘或U盘开机进入救援模式安装grub,操作如下 1.光盘启动,进入救援模式 2.切换根目录 # chroot /mnt/sysimage 3.安装 grub # grub-install /dev/sda 4.重新启动        &…

    Linux干货 2017-01-13
  • N22-妙手-第五周博客作业

    1、显示/boot/grub/grub.conf中以至少一个空白字符开头的行; [root@localhost grub]# grep "^[[:space:]]\+" /boot/grub/grub.conf 2、显示/etc/rc.d/rc.sysinit文件中以#开头,后面跟至少一个空白字符,…

    Linux干货 2016-09-19
  • 鸟哥?马哥?靠边站!今天猫哥带你玩千万PV级别运维架构实战

    1.哼,从今天开始马哥linux,就是我猫哥的天下了!,马哥你奏凯! 我猫哥在此宣誓,从今以后马哥教育正式更名猫哥教育! 哼,信猫哥,得永生! 2.妹的,都好好给我学习,猫哥我盯着呢 3.猫哥我第一次出镜,给咱来个特写啊小伙,拍的好看了,猫哥就免费给你讲讲Linux运维之道。 4.哎哟,拍的还不赖,猫哥我算是45°角仰望星空了,来来,猫哥给你讲讲互联网运维架…

    Linux干货 2016-04-01