自动化运维平台puppet的高级应用

自动化运维平台puppet的高级应用 2014-05-18 04:43:01
标签：自动化运维
puppet

class
template
原创作品，允许转载，转载时请务必以超链接形式标明文章
原始出处 、作者信息和本声明。否则将追究法律责任。http://wangfeng7399.blog.51cto.com/3518031/1413038

一、模板的应用

到目前为止，资源申报、定义类、声明类等所有功能都只能一个manifest文件中实现，但这却非有效的基于puppet管理IT资源架构的方式。实践中，一般需要把manifest文件分解成易于理解的结构，例如将类文件、配置文件甚至包括后面讲提到的模板文件等分类存放，并且通过某种机制在必要时将他们整合起来。这种机制即成为“模板”，它有助于结构化、层次化的方式使用puppet，而puppet则基于“模块自动装载器”完成模块装载

从另一个角度来说，模板实际上就是一个按约定的、预定义的机构存放了多个文件或子目录的目录，目录里的这些文件或子目录必须遵循其命名规范。puppet会按照这种规范在特定位置查找所需的模块文件，不过，这些特定目录页可以通过puppet的配置参数modulepath定义

只要在某模块中定于了一个类，就可以在任何manifest文件中使用它，puppet会自动去查找并装载包含了这个类的定义的manifest文件任意使用它们。于是，基于模块机制的puppet的主manifest文件就可以变得很小，也更易懂并能基于策略进行定制

模块目录的结构

在puppet中，模块本身用一个目录来表示，其需要存放于puppet的modulepath参数所定义的目录中，如/etc/puppet/modules。模块目录名称必须与模块名称相同，需要遵循特定的组织结构

MODULE NAME

manifests

init.pp

files

templates

lib

tests

spec

MODULE NAME：模块名称，也即模块目录名称：模块只能以小写字母开头，可以包含小写字母、数字和下划线，但不能使用“main”和“settings”作为模块名

manifests目录：包含当前模块的所有manifest文件：每个manifest文件包含了一个类或一个定义的类型，此文件访问路径格式为“Modulename::[SubDirectoryName::]ManifestFileName”。

init.pp:只能包含一个单独的类定义，且类的名称必须与模块名称相同

files目录：包含了一组静态的文件，这些文件可被站点下载使用：每个文件的访问路径都遵循puppet:///modules/MODELE_NAME/filename路径格式

lib目录：插件目录，常用于自定义fact及自定义资源类型等

templates目录：存储了manifest用到的模板文件，其访问路径遵循template（‘ModulesName/TemplateName’）格式，后缀名应该为.erb,关于模板文件详细信息，后文有介绍

tests目录：当前模板的使用帮助或使用范例文件，类似如何声明当前模板中的类及定义的类型等

spec目录：类似于tests目录的功能，只不过，其是为lib目录定义的各插件提供使用范例的

准备nginx配置文件，并有意修改nginx的配置文件

可以看到我们的配置执行成功

使用模板配置文件

语法：<%= Ruby Expression %>:替代为表达式的值，在使用表达式时应该使用@引用

<% ruby code %>:仅执行代码，不做任何替换，常用于条件判断或循环语句、设定变量以及在输出之前对数据进行处理

<%# commit %>:注释信息

<%%: 输出<%

%%>：输出%>

如上面的案例，在使用模板后

二、master/agent

应用场景：

统一资源管理软件

统一配置系统优化参数

定期检测服务器是否运行

主机上的软件配置合理的属性

1.安装

前提：配置实用epel的yum源，而后使用yum命令安装即可

环境规划

192.168.1.201 puppet-server端

192.168.1.202 puppet-agent端

安装部署puppet服务器端

安装部署puppet客户端

2.解析双方主机

解析双方主机，可以使用DNS和hosts文件，由于本处实验的缘故，故使用的为/etc/hosts文件来解析双方主机

建议的主机命名方式：

角色名-运营商-机房名-机器ip.域名

3.启动

1）启动puppet服务器端

收起启动puppet守护进程时，其会自动进行运行环境的初始化，例如创建一个本地CA及服务器端相关的证书和密钥等。初始化操作完成后，puppet就会监听指定的套接字并等待客户端的连接请求。默认情况下，其证书和密钥等文件位于/var/lib/puppet/ssl目录中

出于调试的目的，建议首次启动puppet服务进程可以以非守护进程方式进行，并让其输出详细信息以便于观察初始化过程，如下所示，其逐步展示了创建本地主叫向CA申请证书、获得证书以及CA移除证书签署请求的过程等，而后启动服务进程并准备接受各agent端的连接请求

使用puppet master --genconfig可以查看服务器端的配置信息，建议将其输出到/etc/puppet/puppet.conf中

注意：如果此前曾以其主机名或各种原因启动过puppet客户端过程并完成过初始化，其证书文件将无法符合本次启动的需要：此时，需要先情况/var/lib/puppet/ssl目录方可完成后续的初始化操作

如上述的测试启动没有问题，可终止当前的启动后将其以守护进程方式启动

2）启动puppet客户端

puppet agent在首次启动时，会想起指定的puppet server申请证书，并完成后续连接请求，同样的理由，处于测试的目的，接入当前puppet集群中的首个agent节点可以以非守护进程的方式运行，以观察其初始化过程

此时，在puppet服务器端使用puppet cert命令管理客户端的证书请求，其--list选项能够查看等待签署证书的客户端列表，而--sign选项可用于为指定节点签署证书，如果要一次性地多个节点证书申请进行签署可以使用--all选项

一旦agent节点收到签署过的证书，其将会显示如下信息

确保上述agent相关操作不存在问题后，便可以将--server选项指定的信息存储与agent的配置文件中，并以服务的方式启动puppet agent了。其配置文件为/etc/puppet/puppet.conf，配置完整既可以期待能够puppet

4.授权访问

在puppet服务器端的/etc/puppet/manifests/中创建site.pp,在master/agent时，所有节点清单文件入口文件为site.pp

建议：一类节点使用一个清单文件，所有清单文件都在site.pp中使用improt包含进来，清单文件修改后应重启文件

5.自动签发证书

可以设置master自动签发所有的证书，我们只需要在/etc/puppet目录下创建autosign.conf文件即可

这样就会对所有来自magedu.conf的机器的请求自动签署证书

6.puppet kick功能实现

puppet客户端默认每30分钟很服务器通讯一次，但是有时，我们希望服务器能够给客户端紧急推送一些人物，于是就有了puppet kick（puppet 2.6以前叫puppetrun）

1）编辑客户端配置文件/etc/puppet/puppet.conf在[agent]端中添加如下

2）在客户端编辑或创建新文件/etc/puppet/namespaceauth.conf，包含下面内容

3）在客户端编辑文件auth.conf,添加如下内容

4)推送方法，在服务器端运行命令

查看node2

错误信息，惨痛的教训，客户端一致在报这个错误

解决方法：

两台服务器需要时间同步

7.安装配置puppet-dashboard

1）安装

2）数据库授权

3）修改配置文件，dashboard的配置文件为/usr/share/puppet-dashboard/config/database.yml,修改如下参数

为dashboard导入依赖的数据表

启动服务

4）配置puppet服务器和客户端

服务器端配置

在puppetmaster的配置文件中添加如下内容

客户端配置

配置完成后重启puppet

5）测试


650)
this.width=650;" onsubmit onchange onunload onselect onreset>

还可以在页面中添加节点和类文件

终于完成了，一个时间不同步弄了2小时才找出错误。