puppet(5)-master/agent模式

master/agent模式的工作流程

1. agent每隔固定时长会向master端发送nodename(自己的节点名，节点名至关重要)和 facts ,并且向服务器端请求自己的catalog。

2. master端收到以后首先（classify）分类识别来请求的是哪一个客户端和这个客户端要哪些东西，于是master端就在本地根据定义的站点清单给这个agent端声明哪些类。

   Ps:每一个agent端必须向master端明确的发送自己的nodename。

master端依靠nodename识别agent端，为什么要靠nodename识别agent端呢？

1. 因为二者之间是基于ssl互相认证通讯的，puppet中master与agent是基于https协议通讯的。

2. https通讯的构建过程：客户端发请求服务端把证书扔给客户端，客户端验证这个这个证书。而在puppet中 是双向认证的，master要验证agent端的证书，agent还要验证master端的证书。也就意味着agent端发请求会把自己的证书扔给master端的，master要根据agent自己声明的名字和agent自己发过来的证书来验证二者之间是否一致的，如果能保持一致，那么我们就认为这是通过的，更重要的是master端还保存着ca证书，因此它还要使用ca去验证此证书各个方面的有效性，这一切都通过了，双方才可以建立基于ssl通信会话的。这里面的通信过程agent要发送自己的节点名，而agent向master请求时尽量使用master的节点名称而不要使用ip地址。因此在我们的puppet工作环境中，DNS服务至关重要。每一个节点都必须要有一个尽可能唯一的名字。通过dns服务能够解析，而且能彼此之间通过解析后能够互相通信才可以.

   ssl xmlrpc, https
   8140/tcp
   master : puppet , puppet-server, facter
   agent : puppet facter
   服务端启动puppet-server ，监听端口8140
   agent端启动puppet， 不监听端口，每隔固定时间向master端请求自己相关的catelog

构建master/agent的应用

• master端安装：

    sudo yum install puppet-server puppet facter
  

  安装master必备的两个包，puppet 和puppet-server，如果本机也需要请求catelog那就需要安装facter，这里我们想让master同时也做agent端，所以上面yum安装了 这三个包。

  查看puppet-server安装包

    $ rpm -ql puppet-server-3.6.2-3.el7.noarch
    /etc/puppet/fileserver.conf
    /etc/puppet/manifests
    /usr/lib/systemd/system/puppetmaster.service
    /usr/share/man/man8/puppet-kick.8.gz
    /usr/share/man/man8/puppet-master.8.gz
    /usr/share/man/man8/puppet-queue.8.gz
  

  从安装路可以看出：puppet-server并没有什么可执行文件，只有几个目录、文件以及使用手册。这就说明master的执行程序也是puppet提供的子命令。
  这里简单说明下：

    fileserver.conf是提供fileserver功能的配置文件
    /etc/puppet/manifests 目录是存放站点清单的目录
  

  安装puppet-server之后，就可以使用puppet-server的功能了。

• puppet的配置文件
  查看配置文件目录：

    $ ls /etc/puppet/
    auth.conf  fileserver.conf  manifests  modules  puppet.conf
  

  主配置文件 puppet.conf ，是init的配置文件类型，像mysql服务的配置文件，一个配置文件同时有mysqlclient和mysqld的配置项,我们来看看默认配置文件内容：

    $ cat /etc/puppet/puppet.conf
    [main]
        # The Puppet log directory.
        # The default value is '$vardir/log'.
        logdir = /var/log/puppet
  
        # Where Puppet PID files are kept.
        # The default value is '$vardir/run'.
        rundir = /var/run/puppet
  
        # Where SSL certificates are kept.
        # The default value is '$confdir/ssl'.
        ssldir = $vardir/ssl
  
    [agent]
        # The file in which puppetd stores a list of the classes
        # associated with the retrieved configuratiion.  Can be loaded in
        # the separate ``puppet`` executable using the ``--loadclasses``
        # option.
        # The default value is '$confdir/classes.txt'.
        classfile = $vardir/classes.txt
  
        # Where puppetd caches the local configuration.  An
        # extension indicating the cache format is added automatically.
        # The default value is '$confdir/localconfig'.
        localconfig = $vardir/localconfig
  

  我们看配置文件中并没有puppet-server的配置内容，可以用puppet config命令对配置文件进行操作
  [main] 表示agent和master都可以使用的配置
  [agent] agent进程的配置

• puppet config 命令使用
  查看命令帮助

    $ puppet help config
    ...
    ACTIONS:
      print    Examine Puppet's current settings.
      set      Set Puppet's settings.
  
    See 'puppet man config' or 'man puppet-config' for full help.
  

  可以使用print查看当前puppet的配置（包括master, agent, main）

    $ puppet config print
    confdir = /home/ops-manager/.puppet
    vardir = /home/ops-manager/.puppet/var
    name = config
    logdir = /home/ops-manager/.puppet/var/log
    log_level = notice
    disable_warnings = []
    priority =
    trace = false
    profile = false
    autoflush = true
    ...
    下面有很多配置项，就不贴出来了
  

  可以使用set 来单独设置某一个配置项
  通过 puppet print列出的配置项都是默认的配置项。但展示出来的并没有说明某一个配置项的含义。而且也不知道哪些配置是master端的，哪些是agent端的。这个print也只能用于管理员确认某一个配置项时使用。那么我们想看配置文件说明怎么办？ -- 用puppet doc 子命令，doc自命令分段、分类介绍。可以使用puppet doc --list查看分为哪几个段，如：

    $ puppet doc --list
    configuration - A reference for all settings
    function - All functions available in the parser
    indirection - Indirection types and their terminus classes
    metaparameter - All Puppet metaparameters and all their details
    providers - Which providers are valid for this machine
    report - All available transaction reports
    type - All Puppet resource types and all their details
  

• 使用puppet doc --reference configuration 可以查看配置文件相关的文档

    # Configuration Reference
  
    **This page is autogenerated; any changes will get overwritten** *(last generated on 2018-03-27 05:38:24 +0000)*
  
    ## Configuration Settings
  
    * Each of these settings can be specified in `puppet.conf` or on the
      command line.
    * When using boolean settings on the command line, use `--setting` and
      `--no-setting` instead of `--setting (true|false)`.
    * Settings can be interpolated as `$variables` in other settings; `$environment`
      is special, in that puppet master will interpolate each agent node's
      environment instead of its own.
    * Multiple values should be specified as comma-separated lists; multiple
      directories should be separated with the system path separator (usually
      a colon).
    ...
    同样是一堆内容，可以作为日后查找手册
  

  puppet config print命令 和puppet doc --reference configuration命令内容都不太适合刚入手查看。
  有更适合新手的查看方法：

    puppet master --genconfig 显示master的相关配置
    puppet agent  --genconfig 显示agent的相关配置
  

  使用上面两个命令可以帮助我们了解master、agent端的默认配置项。如果我想改这些默认配置项，可以把内容放到puppet.conf文件中，但要注意的是，puppet master --genconfig 和 puppet agent --genconfig命令都是通过调用puppet.conf文件进行显示的，所以你千万不能直接就把puppet.conf文件给覆盖了，这样会有很大问题的。正确的做法都是先将显示的内容输出到一个新建的文件中，然后在不puppet.conf 重命名为puppet.conf_default，在把那个新文件命名为puppet.conf。

    puppet master --genconfig > puppet_new.conf
    puppet agent --genconfig >> puppet_new.conf
  

  注意：
  (1) 生产新的配置之前不能删除或移动原有的puppet.conf;
  (2) 生成的配置中，有的参数已经被废弃，与现有puppet版本不兼容，因此还需进行手动排查。
  (3) 有的参数的默认值与现在的版本所支持值可能不相兼容。
  因此如果我们自己不想麻烦的话，最好不要自己手动生成配置文件，只要修改部分想修改的相关项即可。

• puppet配置文件的组成部分：

    [main]
    [master]
    [agent]
  

• 运行puppet master puppet agent
  puppet master/agent各节点是强依赖主机名的，所以在启动meter/agent工作模式时，要确保各节点之间可以通过FQDN完全限定名能够互相解析。
  以服务方式启动命令 ： puppet master
  建议第一次启动，使用参数让master在前端运行：

    puppet master --no-daemonize -v
    -v 表示工作在详细模式
    --no-daemonize 不工作在守护模式下
    -d 调试信息模式，可能会有一些干扰信息，我们这里就不使用它。
  

  以下是运行结果
  

  如果我们看到上面的信息，没有什么错误信息的话，其实我们就可以直接把puppet master服务启动了，不用进行更改配置了。即使用它的默认配置就可以工作起来。同时我们可以看到默认证书存放的位置/var/lib/puppet/ssl。

  如果这次生成的内容不想要了，如何做的呢？
  只要删除刚刚生成的证书目录即可：

    rm -rf /var/lib/puppet/ssl/*
  

  然后再次运行puppet master --no-daemonize -v 从新生成一遍。如果没有问题就可以启动在后台。在centos7上有专门的unit file，如：

    # ls /usr/lib/systemd/system/puppet
    puppetagent.service   puppetmaster.service  puppet.service
  

  这里puppetagent.service 是连接到 puppet.service 都是启动puppet agent的
  puppetmaster.service 是启动 puppet master的

    [root@ops ssl]# systemctl start puppetmaster.service
    使用ss -tnl查看端口
  

  接着我们就要安装 、 配置agent端
  安装就简单了

    sudo yum install epel-realese
    sudo yum install agent facter
  

  配置文件是 /etc/puppet/puppet.conf 中的 [agent] 段
  默认配置文件中内容不多，我们想首先 配置的应该是指明master端的 FQDN完全限定名
  如果我们不在配置文件中指定，也可以使用puppet agent命令指定

    puppet agent --server puppet-master.my.com
  

  注意如果命令执行了，agent端会自动生成一个ssl私钥，并生成一个证书签署请求而后发送给master端，并等待master端给它做签署，在签署完成之前双方是不可以进行通信的。因此我们第一次做的时候，对于agent端而言 还是一样 我们先做测试，看能不能正常通过。命令如下：

    puppet agent --server ops-zabbix.blockshine.com --noop --test -v --no-daemonize
    -v 显示
    --noop 表示dry run ,预演的意思
    --test 表示测试
  

  输出结果如图：
  

  接下来把--noop 和 --test 选项去掉
  执行后界面卡住如下：
  

  虽然没有显示，实际上它已经生成key和自签证书请求，并把请求发给master端，等待master端签发证书。

• 签署证书
  打开master端，使用puppet help cert命令查看帮助

    puppet cert <action> [-h|--help] [-V|--version] [-d|--debug] [-v|--verbose] [--digest <digest>] [<host>]
    Action
    	list 查看所有待签署证书
        sign 签署证书
    puppet  cert list		显示未签发的
    puppet  cert list --all 显示已经签发和未签发的
    puppet sign 节点		签发指定节点
    puppet sign --all	签发所有
  

  

  上面显示已经完成了为节点签署证书，客户端再次启动就显示如下：
  

  此时agent端的测试已完成就可以使用unit file启动了
  sudo systemctl start puppet.service

• 总结配置启动master/agent

  1. 配置master
     # puppet master --no-daemonize -v
     # systemctl start puppetmaster.service
     # systemctl enable puppetmaster.service
     8140/tcp

  2. 配置agent
     # puppet agent --server ops-zabbix.blockshine.com --noop --test -v --no-daemonize
     # puppet agent --server ops-zabbix.blockshine.com -v --no-daemonize
     发送证书请求给master

  3. 在master端为客户端签署证书
     # puppet cert list
     # puppet cert sign node_name
     # puppet cert sign --all

  4. 如果想把某一个节点的证书清楚掉
     服务端 # puppet cert clean node_name
     客户端 # rm /var/lib/puppet/ssl/* -rf
     然后在重新启动agent端

  5. 在master端：
     （1）安装所有要用到的模块：

      puppet module install
      自建
     

     （2）定义site manifest:

      /etc/puppet/manifests/site.pp
      	node 'NODE_NAME' {
          	... puppet code ...
          }
      例如：
      	node 'node3.my.com'{
          	include nginx::proxy
          }
          include直接跟类名，因为模块中的类可以全局进行直接调用的
     

  当完成以上配置，并且运行master/agent后，agent每隔30分钟会想master端索取catelog，但有时候要立刻执行，那么可以在master端进行推送，推送命令稍后说。
  其实到这一步骤，基本上就够我们使用了，接下来就是一些比较好的实例用法。

• 站点清单高级定义方式

  site.pp定义节点的方式：
  (1) 以主机名直接给出其相关定义:

    	node 'NODE_NAME' {
        	节点变量$web_port = 8088
        	... puppet code ...
        }
    (2) 把功能相近的主机事先按统一格式命名，按统一格式调用：
  
    	node /^webd+.my.com/ {
        	... puppet code ...
        }
    (3) 假如公司维护的节点有上千个，主机命名要依照 命名规范 进行命名
    假如现在所有节点都需要进行ntp 时间同步，那么有没有比较方便的定义方法？这就是定义基节点，而后每一个节点去继承基节点。
  
    node  basenode {
    	include ntp
    }
  
    node web.my.com inherits basenode {
    	include  nginx::proxy
    }
    当某一模块被多数主机所共用时，可以通过定义基节点的方式，让其他节点通过继承的方式获取这个公共配置。
  
  	（4）不管怎么讲，我们把上千个节点的配置放在site.pp文件中，也显得臃肿，不方便查找。可以通过对节点配置进行分段管理。
  
    	/etc/puppet/manifests/
        	site.pp
    			import "webservers/*.pp"
            webservers/
    			unicom.pp
                telecom.pp
            cacheservers/
  
            appservers/
    (5) 模块当中，如果manifest/init.pp 下要定义的类太多的话，也可以采用分段切割，放在多个文件中，但是在init.pp中要把他们给import 进来，道理和节点分段管理一样的。
  

依赖于主机名称互相通信

• DNS

• 主机名命令规范：

  • 角色-运营商-机房名-IP.管理域名
    web1-unicom-sh-1.1.1.1.magedu.com
    依赖于主机名称互相通信

    DNS

    主机名命令规范：
    角色-运营商-机房名-IP.管理域名
    web1-unicom-sh-1.1.1.1.magedu.com

  定义节点：

    node 'NODE_NAME' {
    	变量
    	声明类
    }
  
    定义在站点清单：/etc/puppet/manifests/site.pp
  

  节点名称定义亦可以继承：

    node basenode {
    	$dbport = 3306
    	include baseserver
    }
  
    node "node2.magedu.com" inherits basenode {
    	include nginx
    }
  
    node "node3.magedu.com" inherits basenode {
    	$dbport = 3307
    	include mysql
    }
  
    目的：为所有节点应用相同的全局变量，以及完成节点的初始化；
  
    节点定义方式：
    	1、每节点单独定义；
    	2、在节点名称中使用正则表达式；
    		node "/node[0-9]+.magedu.com/" {
  
    		}
  

  puppet进程的配置文件：puppet.conf
  生成配置：puppet master --genconfig > /etc/puppet/puppet.conf
  puppet agent --genconfig >> /etc/puppet/puppet.conf

    	[main], [master], [agent]
  
    了解配置文件路径：puppet doc --configprint confdir
  

  master端而言：/etc/puppet/manifests/site.pp
  站点清单

    认证配置文件：auth.conf
    	应用于puppet的restful风格的API的访问授权；
  
    名称空间访问认证配置文件：namespaceauth.conf
    	[puppetmaster]
    		allow *.magedu.com
  
    autosign.conf
  

  配置puppet master支持多种不同的环境：

    puppet.conf
    	[master]
    	environment = development, testing, production
  
    	[development]
    	manifests = /etc/puppet/manifests/development/site.pp
    	modulepath = /etc/puppet/modules/development/:/usr/share/modules/development
    	fileserverconfig = /etc/puppet/fileserver.conf.development
  
    	[testing]
    	manifests = /etc/puppet/manifests/testing/site.pp
    	modulepath = /etc/puppet/modules/testing/:/usr/share/modules/testing
    	fileserverconfig = /etc/puppet/fileserver.conf.testing
  
    	[production]
    	manifests = /etc/puppet/manifests/production/site.pp
    	modulepath = /etc/puppet/modules/production/:/usr/share/modules/production
    	fileserverconfig = /etc/puppet/fileserver.conf.production
  
    puppet agent:
    	[agent]
    	environment = development
  

  模块管理：
  Puppet Forge: puppet维护模块仓库，大部分由第三方作者提供

    puppet module
  
    	list
    	search
    	install
  

  Puppet kick机制：

    紧急推送配置时使用。
  

  puppet架构扩展：
  单台master节点可能会出现瓶颈之处：

    	认证功能
    	文件服务
    	网络
  
    解决思路：单机扩展
  
    	Nginx+Mongrel
    	Apache+Passenger
    	Nginx+Passenger
  
    解决思路：多机扩展
  

  mcollective

  Foreman