标签：name liuhaoran 详解 puppet user 资源 属性

这篇文章将会介绍puppet资源的结构，以及怎样查看puppet资源的属性。

我们已经运行过了一个puppet清单，清单中的资源定义如下：

root@liuhaoran:~# cat test.pp 
user{'liuhaoran':
  name => liuhaoran,
  ensure => present,
}

那么，我们来总结一下资源在清单中的定义格式。

定义资源的语法如下：

type{‘title’:
attribute1 => value1,
attribute2 => value2,
attribute3 => value3,
…
attributeN => valueN,
}

从上述语法格式中可以看到，在定义一个资源的时候，需要先指定其类型(type)，还记的我们总结的常用资源类型吗，常用的有package，service，user，file，exec等，指明资源类型以后，type后面要使用”{ }”括起，表示管理员可以在”{ }”中定义资源的属性值，我们先放下属性值不说，先说”title” , 在”{ }”的开始处，我们需要设置资源的标题,也就是资源的”title”，我们可以把资源的title理解成用来标识资源的ID，同一类型的资源中，资源的”title”不能重复，如果两个相同类型的资源的title重复了，当我们执行对应的清单时，则会报错，不同类型的资源的title可以相同，同时还需要注意，’title’最好使用小写字母定义，’title’后面不要忘记冒号”:”,这是固定语法，没什么好解释的，定义完”title”以后，则需要定义当前资源的属性信息了，还拿我们user资源为例，linux中的用户往往会有属主属组、附属组、家目录等概念，这些概念在puppet中都被称为user资源的属性，当然，不同的资源类型所包含的属性可能不同，但是有些属性是比较通用的，比如，名称属性，不管是user、service、package这些资源都有名称属性，在我们使用的第一个puppet清单中，user资源的第一个属性就是名称属性，如你所见，name关键字就表示名称属性，如果我们想要设置user的名称为liuhaoran， 则可以写为 “name => liuhaoran” ,这样就表示设置name属性的值为liuhaoran了，没错，为属性赋值时要使用” => ” 符号，从语法示例中可以看出，一个资源可能有多个属性，当我们为资源赋值时，每个属性之间需要用逗号”,”隔开。

再次强调，同一类型的资源中，’title’不能重复，而且尽量使用小写字母定义。

我们可以使用puppet describe -l命令，查看puppet中支持的所有资源。

可以看到，puppet支持不少资源，换句话说，我们能够通过puppet操作不少东西，那么，如果我想要查看某个资源都支持哪些属性，这些属性都有什么作用，该怎么查看呢，我们可以使用puppet describe type命令进行查看，注意，type要替换成对应的资源类型，比如，我们想要查看user资源的详细信息，可以使用puppet describe user命令查看，示例如下

可以看到，命令返回的信息中介绍了当前资源的作用，说明了user资源的作用就是用来管理系统用户的。

而且，返回信息列出了user资源中所有的属性信息，从Parameters向下看，全是user资源支持的属性信息，以及其他详细信息，信息较多，所以不一一解释，我们会在后面的总结中，对常用资源的常用属性进行总结。

使用puppet describe user命令查看资源时，返回的帮助信息太多，如果我们只是想要了解某个资源的大概信息，以及其支持的属性，可以使用puppet describe -s user命令查看user资源的属性，”-s”选项表示short，意思是输出简短格式的帮助信息。

可以从上图看出，简短格式的返回信息中，主要返回了3个部分的信息。

• 第一部分描述了user资源的主要作用。

• 第二部分描述了user资源包含的所有属性。

• 第三部分列出了user资源所能够支持的providers， 还记得我们曾经提到的”资源抽象层”的概念吗，管理员不用关心被管理服务器上的操作系统版本，puppet会通过”资源抽象层”自动判断底层的操作系统以及系统发行版，然后选择对应的默认的providers对资源进行操作，而配置管理员只需要写好清单即可，我们举个例子，仍然拿我们的user资源为例，当我们执行清单的时候，如果被管理服务器上面部署的是redhat/centos操纵系统，那么puppet会自动调用useradd去添加liuhaoran用户，如果被管理服务器上面安装的是HPUX操作系统，puppet会自动调用hpuxuseradd去添加用户， 刚才提到的hpuxuseradd和useradd都属于providers，它们是user资源在不同操作系统平台中的提供者，它们是为了简化管理员操作而存在的，大部分情况下，我们不用过分关心它们，我们只要明白它们会为我们服务即可。

我们还能够使用puppet describe -s -m type命令查看资源的元属性，比如，使用puppet describe -s -m user命令查看user资源的元属性，我们后面会对元属性的使用进行示例并解释它们，此处，我们只要知道怎样查看即可，示例如下：

好了，说了这么多，我们再动动手，丰富一下user资源中的属性，把user常用的属性做成一个示例，示例如下。

从上述示例中，我们定义了一个user资源，它的title是”liuhaoran”，我们要确保他处于present状态，我们指定liuhaoran用户的uid为700，同时指定他所使用的shell为bash，而且，指定了这个用户的家目录为”/home/liuhaoran”，但是细心的你一定发现，我们并没有指定name属性，这样会不会出问题呢，不会的，因为name属性是一种特殊属性，我们待会再细说name属性，当我们不写name属性时，user资源的名称会以title的值为准，也就是说，name属性可省略，而且，你一定也发现了，home属性的最后面没有逗号，我们说过，每个属性之间需要用逗号隔开，但是最后一个属性的逗号是可省的。

那么，我们现在来运行一遍对应的清单，看看这个用户是否会被创建，在执行清单之前，我们先看看这个用户是否存在。

从上图可以看出，lihaoran用户一开始并不存在，执行对应清单以后，liuhaoran已经存在了，而且与我们指定的目标状态一致，那么，此时我们修改一下test.pp清单，把它改成如下模样。

user{'liuhaoran':
  uid => 700,
  name => liuhaoran,
  ensure => present,
  shell => '/bin/csh',
  home => '/home/liuhaoran'
}

可以看到，我们将liuhaoran用户的默认shell从”/bin/bash”改为了”/bin/csh”，其他的都没有改变，此刻我们再运行一遍test.pp，看看会发生什么。

从上图可以看出，在运行清单之前，我们先查看了一下liuhaoran用户的配置信息，然后执行了test.pp清单。

清单执行完毕后，从返回信息可以看出，shell 从 ‘/bin/bash’ 变成了 ‘/bin/csh’.

再次查看liuhaoran用户的信息，发现其默认shell已经改变，其他信息都没有发生改变。

这个例子又印证了我们之前所说的概念，puppet的作用就是确保被管理服务器处于管理员所要求的”目标状态”，管理员通过清单，告诉puppet，”目标状态”已经在清单中定义好了，你只要按照清单工作即可，上例中，我们通过test.pp清单，定义了我们所需要的”目标状态”，我们的目标是：被管理服务器上需要存在一个liuhaoran用户，而且这个用户的所有属性，必须符合我们的定义，在liuhaoran用户还不存在时，puppet会根据配置创建它，并且让其属性符合我们的定义，如果liuhaoran用户已经存在，那么puppet会判断，liuhaoran用户的各种属性是否符合我们定义的配置，如果符合，则不做处理，如果不符合我们的定义，puppet则会根据清单中的定义，做出对应操作，迫使被管理服务器达到我们所要求的目标状态，就像我们刚才改变清单中liuhaoran用户的默认shell一样，当我们修改了清单，再次执行清单时，puppet发现被管理服务器的”当前状态”与我们定义的”目标状态”不符，于是，puppet就会更改liuhaoran用户的默认shell，以确保目标状态符合我们的要求。如果配置符合要求则不做任何修改，这也体现了puppet操作的幂等性。

话说回来，我们说过，name属性是一种特殊属性，是可省的，当省略name属性时，资源的名称即为title的值，如下图，我们在定义user资源时，并没有给出name属性。

root@liuhaoran:~# cat test.pp 
user{'liuhaoran':
  uid => 700,
  ensure => present,
  shell => '/bin/csh',
  home => '/home/liuhaoran'
}

这是因为name属性是一种特殊的属性，而且它不是唯一的一种特殊属性，资源的特殊属性有如下三类。

• 第一种特殊属性：
  名称变量，英文原称为namevar，大多数资源的namevar为name属性（注意，name属性和namevar没有直接关系，只是碰巧他们都包含英文单词”name”而已），因为大多数资源的name属性是namevar，所以省略name属性时，资源的name与title中的值相同，但是并不是所有资源的namevar都是name属性，某些资源中，并没有name属性，而且它的namevar可能是其他属性，当省略namevar对应的属性时，其属性值与资源的title值相同，这样说不容易理解，等到实例演示时，自然会明白。

• 第二种特殊属性：
  ensure属性，此属性用于定义资源的目标状态，不同的资源，ensure对应的值不同，比如，user资源的ensure值可以设置为present，表示用户必须存在，也可以设置为absent表示用户不能存在（删除用户），而service资源也有ensure属性，但是在service资源中，ensure属性的值往往被设置为stopped或者running，当然，大部分资源的ensure的值，还是present或者absent。

• 第三种特殊属性：
  元参数，或者称为 “元属性”，英文为metaparameter，当我们为资源设置元属性时，目的往往是希望通过元属性影响puppet的行为，什么意思呢，我们想象一个场景，比如，我们想要安装一个nginx并且启动它，那么我们至少会用到两个资源，package资源与service资源，但是，service资源会依赖到package资源，因为如果nginx连安装都没有安装，就更别提启动服务了，所以，service资源是依赖于package资源的，这个时候，我们就可以在service资源中添加require属性，通过require属性指定service资源依赖的package资源，require属性就是元属性（元参数）的一种，我们也可以在package资源中添加before属性，表示package资源在service资源之前被处理，我们再在想一个场景，当配置文件发生改变时，我们往往有可能会重新同步配置文件，并且要重载配置文件，那么，就需要在配置文件发生改变时，通知服务重载配置，所以，有可能用会用到notify属性，反过来，我们也可以让service资源订阅某个资源，当被订阅的资源被操作时，service资源也会被操作，这个时候就需要用到subscribe属性，before、require、notify、subscribe这些属性都属于元属性，我们通过它们，可以影响puppet操作资源的顺序以及puppet的操作行为，当然，puppet还有其它的一些元属性，等我们用到的时候再进行总结，如果有兴趣，可以查看官网在线手册，puppet3.8版本文档中对metaparameter的解释地址如下。
  https://docs.puppet.com/puppet/3.8/metaparameter.html

标签：name,liuhaoran,详解,puppet,user,资源,属性
来源： https://www.cnblogs.com/even160941/p/14944307.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。