自动化运维工具puppet详解(一)

一、puppet 介绍

1、puppet是什么

  puppet是一个IT基础设施自动化管理工具,它能够帮助系统管理员管理基础设施的整个生命周期: 供应(provisioning)、配置(configuration)、联动(orchestration)及报告(reporting)。
  基于puppet ,可实现自动化重复任务、快速部署关键性应用以及在本地或云端完成主动管理变更和快速扩展架构规模等。
  遵循GPL 协议(2.7.0-), 基于ruby语言开发。
  2.7.0 以后使用(Apache 2.0 license)
  对于系统管理员是抽象的,只依赖于rubyfacter
  能管理多达40 多种资源,例如:fileusergrouphostpackageservicecronexecyum repo等。

2、puppet的工作机制

1)工作模型

  puppet 通过声明性、基于模型的方法进行IT自动化管理。
  定义:通过puppet 的声明性配置语言定义基础设置配置的目标状态;
  模拟:强制应用改变的配置之前先进行模拟性应用;
  强制:自动、强制部署达成目标状态,纠正任何偏离的配置;
  报告:报告当下状态及目标状态的不同,以及达成目标状态所进行的任何强制性改变;
puppet三层模型
  puppet三层模型如下:

2)工作流程

3)使用模型

  puppet的使用模型分为单机使用模型master/agent模型,下面我们来看看这两个模型的原理图。
单机使用模型
  实现定义多个manifests --> complier --> catalog --> apply

master/agent模型
  master/agent模型实现的是集中式管理,即 agent 端周期性向 master 端发起请求,请求自己需要的数据。然后在自己的机器上运行,并将结果返回给 master 端。
  架构和工作原理如下:

架构

                          master/agent模式架构

工作原理

              master/agent模式工作原理

3、puppet 名词解释

  • 资源:是puppet的核心,通过资源申报,定义在资源清单中。相当于ansible中的模块,只是抽象的更加彻底。
  • 类:一组资源清单。
  • 模块:包含多个类。相当于ansible中的角色
  • 站点清单:以主机为核心,应用哪些模块。

二、puppet 资源详解

  接下来,我们就以单机模式来具体介绍一下puppet的各个部分。

1、程序安装及环境

  首先,我们还是来安装一下puppetpuppet的安装可以使用源码安装,也可以使用rpm(官方提供)、epel源、官方提供的yum仓库来安装(通过下载官方提供的rpm包可以指定官方的yum仓库)。
  在这里,我们就是用 yum 安装的方式。

[[email protected] ~]# yum install -y puppet

安装完成过后,我们可以通过rpm -ql puppet | less来查看一下包中都有一些什么文件。
  其中主配置文件为/etc/puppet/puppet.conf,使用的主程序为/usr/bin/puppet

[[email protected] ~]# rpm -ql puppet | less
/etc/NetworkManager
/etc/NetworkManager/dispatcher.d
/etc/NetworkManager/dispatcher.d/98-puppet
/etc/logrotate.d/puppet
/etc/puppet
/etc/puppet/auth.conf
/etc/puppet/modules
/etc/puppet/puppet.conf
/usr/bin/extlookup2hiera
/usr/bin/puppet
/usr/bin/start-puppet-agent
/usr/bin/start-puppet-ca
/usr/bin/start-puppet-master
/usr/lib/systemd/system/puppet.service
/usr/lib/systemd/system/puppetagent.service
/usr/share/doc/puppet-3.6.2
/usr/share/doc/puppet-3.6.2/LICENSE
/usr/share/doc/puppet-3.6.2/README.md
/usr/share/doc/puppet-3.6.2/examples
/usr/share/doc/puppet-3.6.2/examples/hiera
/usr/share/doc/puppet-3.6.2/examples/hiera/README.md
/usr/share/doc/puppet-3.6.2/examples/hiera/etc
/usr/share/doc/puppet-3.6.2/examples/hiera/etc/hiera.yaml
/usr/share/doc/puppet-3.6.2/examples/hiera/etc/hieradb
/usr/share/doc/puppet-3.6.2/examples/hiera/etc/hieradb/common.yaml
/usr/share/doc/puppet-3.6.2/examples/hiera/etc/hieradb/dc1.yaml
/usr/share/doc/puppet-3.6.2/examples/hiera/etc/hieradb/development.yaml
/usr/share/doc/puppet-3.6.2/examples/hiera/etc/puppet.conf
/usr/share/doc/puppet-3.6.2/examples/hiera/modules
/usr/share/doc/puppet-3.6.2/examples/hiera/modules/data
/usr/share/doc/puppet-3.6.2/examples/hiera/modules/data/manifests
/usr/share/doc/puppet-3.6.2/examples/hiera/modules/data/manifests/common.pp
/usr/share/doc/puppet-3.6.2/examples/hiera/modules/ntp
/usr/share/doc/puppet-3.6.2/examples/hiera/modules/ntp/manifests
/usr/share/doc/puppet-3.6.2/examples/hiera/modules/ntp/manifests/config.pp
/usr/share/doc/puppet-3.6.2/examples/hiera/modules/ntp/manifests/data.pp
/usr/share/doc/puppet-3.6.2/examples/hiera/modules/ntp/templates
/usr/share/doc/puppet-3.6.2/examples/hiera/modules/ntp/templates/ntp.conf.erb
/usr/share/doc/puppet-3.6.2/examples/hiera/modules/users
/usr/share/doc/puppet-3.6.2/examples/hiera/modules/users/manifests
/usr/share/doc/puppet-3.6.2/examples/hiera/modules/users/manifests/common.pp
/usr/share/doc/puppet-3.6.2/examples/hiera/modules/users/manifests/dc1.pp
/usr/share/doc/puppet-3.6.2/examples/hiera/modules/users/manifests/development.pp
[[email protected] ~]# 

2、puppet 资源简介

1)资源抽象

   puppet 从以下三个维度来对资源完成抽象:

  1. 相似的资源被抽象成同一种资源**“类型”** ,如程序包资源、用户资源及服务资源等;
  2. 将资源属性或状态的描述与其实现方式剥离开来,如仅说明安装一个程序包而不用关心其具体是通过yum、pkgadd、ports或是其它方式实现;
  3. 仅描述资源的目标状态,也即期望其实现的结果,而不是其具体过程,如“确定nginx 运行起来” 而不是具体描述为“运行nginx命令将其启动起来”;

  这三个也被称作puppet 的资源抽象层(RAL)
  RAL 由type( 类型) 和provider( 提供者,即不同OS 上的特定实现)组成。
 

2)资源定义

  资源定义通过向资源类型的属性赋值来实现,可称为资源类型实例化;
  定义了资源实例的文件即清单,manifest;
  定义资源的语法如下:

type {‘title‘:
    attribute1     => value1,
    atrribute2    => value2,
    ……
}

  注意:type必须使用小写字符;title是一个字符串,在同一类型中必须惟一;每一个属性之间需要用“,”隔开,最后一个“,”可省略。
  例如,可以同时有名为nginx 的“service”资源和“package”资源,但在“package” 类型的资源中只能有一个名为“nginx”的资源。

3)资源属性中的三个特殊属性:

Namevar:可简称为name;
ensure:资源的目标状态;
Provider:指明资源的管理接口;

3、常用资源总结

1)查看资源
  我们可以使用puppet describe来打印有关Puppet资源类型,提供者和元参数的帮助。使用语法如下:

puppet describe [-h|--help] [-s|--short] [-p|--providers] [-l|--list] [-m|--meta] [type]
    -l:列出所有资源类型;
    -s:显示指定类型的简要帮助信息;
    -m:显示指定类型的元参数,一般与-s一同使用;
 

2)group:管理系统上的用户组。
  查看使用帮助信息:

[[email protected] ~]# puppet describe group -s -m

group
=====
Manage groups. On most platforms this can only create groups.
Group membership must be managed on individual users.
On some platforms such as OS X, group membership is managed as an
attribute of the group, not the user record. Providers must have
the feature ‘manages_members‘ to manage the ‘members‘ property of
a group record.

Parameters
----------
    allowdupe, attribute_membership, attributes, auth_membership, ensure,
    forcelocal, gid, ia_load_module, members, name, system

Meta Parameters
---------------
    alias, audit, before, loglevel, noop, notify, require, schedule, stage,
    subscribe, tag

Providers
---------
    aix, directoryservice, groupadd, ldap, pw, windows_adsi
属性:
    name:组名,可以省略,如果省略,将继承title的值;
    gid:GID;
    system:是否为系统组,true OR false;
    ensure:目标状态,present/absent;
    members:成员用户;

简单举例如下:

[[email protected] puppet]# mkdir ppp
[[email protected] puppet]# cd ppp/
[[email protected] ppp]# vi test.pp

group{‘liujunjun‘:
        gid     => 2000,
        ensure  => present,
}
user{‘liujunjun‘:
        uid     => 2000,
        gid     => 2000,
        shell   => ‘/bin/bash‘,
        home    => ‘/home/liujunjun‘,
        ensure  => present,
}
[[email protected] ppp]# puppet apply -v --noop test.pp  试动行。[[email protected] ppp]# puppet apply -v test.pp
Notice: Compiled catalog for localhost in environment production in 0.27 seconds
Info: Applying configuration version ‘1579249129‘
Notice: /Stage[main]/Main/Group[liujunjun]/ensure: created
Notice: /Stage[main]/Main/User[liujunjun]/ensure: created
Info: Creating state file /var/lib/puppet/state/state.yaml
Notice: Finished catalog run in 0.13 seconds
[[email protected] ppp]# tail -1 /etc/group
liujunjun:x:2000:

3)user:管理系统上的用户。
  查看使用帮助信息:

[[email protected] ppp]# puppet describe user -m -s

user
====
Manage users.  This type is mostly built to manage system
users, so it is lacking some features useful for managing normal
users.
This resource type uses the prescribed native tools for creating
groups and generally uses POSIX APIs for retrieving information
about them.  It does not directly modify `/etc/passwd` or anything.
**Autorequires:** If Puppet is managing the user‘s primary group (as
provided in the `gid` attribute), the user resource will autorequire
that group. If Puppet is managing any role accounts corresponding to the
user‘s roles, the user resource will autorequire those role accounts.

Parameters
----------
    allowdupe, attribute_membership, attributes, auth_membership, auths,
    comment, ensure, expiry, forcelocal, gid, groups, home, ia_load_module,
    iterations, key_membership, keys, managehome, membership, name,
    password, password_max_age, password_min_age, profile_membership,
    profiles, project, purge_ssh_keys, role_membership, roles, salt, shell,
    system, uid

Meta Parameters
---------------
    alias, audit, before, loglevel, noop, notify, require, schedule, stage,
    subscribe, tag

Providers
---------
    aix, directoryservice, hpuxuseradd, ldap, pw, user_role_add, useradd,
    windows_adsi
属性:
    name:用户名,可以省略,如果省略,将继承title的值;
    uid: UID;
    gid:基本组ID;
    groups:附加组,不能包含基本组;
    comment:注释;
    expiry:过期时间 ;
    home:用户的家目录;
    shell:默认shell类型;
    system:是否为系统用户 ;
    ensure:present/absent;
    password:加密后的密码串; 
[[email protected] ppp]# cat test2.pp
user{‘keerr0‘:
        ensure => present,
        system => false,        #是否为系统用户。
        comment => ‘Test User‘,    #注释
        shell => ‘/bin/bash‘,      #默认shell类型
        home => ‘/home/keerr0‘,     #用户的家目录。
        managehome => true,
        groups => ‘liujunjun‘,
        uid => 3000,
        }
[[email protected] ppp]# puppet apply -v test2.pp
Notice: Compiled catalog for localhost in environment production in 0.17 seconds
Info: Applying configuration version ‘1579250211‘
Notice: /Stage[main]/Main/User[keerr0]/ensure: created
Notice: Finished catalog run in 0.12 seconds

4)package:puppet的管理软件包。
  查看使用帮助信息:

[[email protected] ppp]# puppet describe package -m -s

package
=======
Manage packages.  There is a basic dichotomy in package
support right now:  Some package types (e.g., yum and apt) can
retrieve their own package files, while others (e.g., rpm and sun)
cannot.  For those package formats that cannot retrieve their own files,
you can use the `source` parameter to point to the correct file.
Puppet will automatically guess the packaging format that you are
using based on the platform you are on, but you can override it
using the `provider` parameter; each provider defines what it
requires in order to function, and you must meet those requirements
to use a given provider.
**Autorequires:** If Puppet is managing the files specified as a
package‘s `adminfile`, `responsefile`, or `source`, the package
resource will autorequire those files.

Parameters
----------
    adminfile, allow_virtual, allowcdrom, category, configfiles,
    description, ensure, flavor, install_options, instance, name,
    package_settings, platform, responsefile, root, source, status,
    uninstall_options, vendor

Meta Parameters
---------------
    alias, audit, before, loglevel, noop, notify, require, schedule, stage,
    subscribe, tag

Providers
---------
    aix, appdmg, apple, apt, aptitude, aptrpm, blastwave, dpkg, fink,
    freebsd, gem, hpux, macports, msi, nim, openbsd, opkg, pacman, pip, pkg,
    pkgdmg, pkgin, pkgutil, portage, ports, portupgrade, rpm, rug, sun,
    sunfreeware, up2date, urpmi, windows, yum, zypper
属性:
    ensure:installed, present, latest, absent, any version string (implies present)
    name:包名,可以省略,如果省略,将继承title的值;
    source:程序包来源,仅对不会自动下载相关程序包的provider有用,例如rpm或dpkg;
    provider:指明安装方式;

简单举例如下:

[[email protected] ppp]# vi package.pp

package{ ‘zip‘:
                ensure  => installed,
        provider    =>  yum
        }
~
[[email protected] ppp]# puppet apply -v package.pp
Notice: Compiled catalog for localhost in environment production in 0.76 seconds
Warning: The package type‘s allow_virtual parameter will be changing its default value from false to true in a future release. If you do not want to allow virtual packages, please explicitly set allow_virtual to false.
   (at /usr/share/ruby/vendor_ruby/puppet/type.rb:816:in `set_default‘)
Info: Applying configuration version ‘1579250994‘
Notice: Finished catalog run in 0.21 seconds

5)service:定义服务的状态
  查看使用帮助信息:

[[email protected] ppp]# puppet describe service -s -m

service
=======
Manage running services.  Service support unfortunately varies
widely by platform --- some platforms have very little if any concept of a
running service, and some have a very codified and powerful concept.
Puppet‘s service support is usually capable of doing the right thing, but
the more information you can provide, the better behaviour you will get.
Puppet 2.7 and newer expect init scripts to have a working status command.
If this isn‘t the case for any of your services‘ init scripts, you will
need to set `hasstatus` to false and possibly specify a custom status
command in the `status` attribute. As a last resort, Puppet will attempt to
search the process table by calling whatever command is listed in the `ps`
fact. The default search pattern is the name of the service, but you can
specify it with the `pattern` attribute.
**Refresh:** `service` resources can respond to refresh events (via
`notify`, `subscribe`, or the `~>` arrow). If a `service` receives an
event from another resource, Puppet will restart the service it manages.
The actual command used to restart the service depends on the platform and
can be configured:
* If you set `hasrestart` to true, Puppet will use the init script‘s restart
command.
* You can provide an explicit command for restarting with the `restart`
attribute.
* If you do neither, the service‘s stop and start commands will be used.

Parameters
----------
    binary, control, enable, ensure, flags, hasrestart, hasstatus, manifest,
    name, path, pattern, restart, start, status, stop

Meta Parameters
---------------
    alias, audit, before, loglevel, noop, notify, require, schedule, stage,
    subscribe, tag

Providers
---------
    base, bsd, daemontools, debian, freebsd, gentoo, init, launchd, openbsd,
    openrc, openwrt, redhat, runit, service, smf, src, systemd, upstart,
    windows
属性:
    ensure:服务的目标状态,值有true(running)和false(stopped)
    enable:是否开机自动启动,值有true和false
    name:服务名称,可以省略,如果省略,将继承title的值
    path:服务脚本路径,默认为/etc/init.d/下
    start:定制启动命令
    stop:定制关闭命令
    restart:定制重启命令
    status:定制状态
[[email protected] ppp]# cat service1.pp
service{‘nginx‘:
        ensure  => true,
        enable  => false
}CentOS7下的启动不了。

6)file:管理文件、目录、软链接
  查看使用帮助信息:

[[email protected] ppp]# puppet describe file -s -m

file
====
Manages files, including their content, ownership, and permissions.
The `file` type can manage normal files, directories, and symlinks; the
type should be specified in the `ensure` attribute. Note that symlinks
cannot
be managed on Windows systems.
File contents can be managed directly with the `content` attribute, or
downloaded from a remote source using the `source` attribute; the latter
can also be used to recursively serve directories (when the `recurse`
attribute is set to `true` or `local`). On Windows, note that file
contents are managed in binary mode; Puppet never automatically translates
line endings.
**Autorequires:** If Puppet is managing the user or group that owns a
file, the file resource will autorequire them. If Puppet is managing any
parent directories of a file, the file resource will autorequire them.

Parameters
----------
    backup, checksum, content, ctime, ensure, force, group, ignore, links,
    mode, mtime, owner, path, purge, recurse, recurselimit, replace,
    selinux_ignore_defaults, selrange, selrole, seltype, seluser, show_diff,
    source, source_permissions, sourceselect, target, type, validate_cmd,
    validate_replacement

Meta Parameters
---------------
    alias, audit, before, loglevel, noop, notify, require, schedule, stage,
    subscribe, tag

Providers
---------
    posix, windows
[[email protected] ppp]# 
属性:
    ensure:目标状态,值有absent,present,file,directory和link
        file:类型为普通文件,其内容由content属性生成或复制由source属性指向的文件路径来创建;
        link:类型为符号链接文件,必须由target属性指明其链接的目标文件;
        directory:类型为目录,可通过source指向的路径复制生成,recurse属性指明是否递归复制;
    path:文件路径;
    source:源文件;
    content:文件内容;
    target:符号链接的目标文件;
    owner:定义文件的属主;
    group:定义文件的属组;
    mode:定义文件的权限;
    atime/ctime/mtime:时间戳;
[[email protected] ppp]# vim file1.pp

file{‘aaa‘:
        path    => ‘/data/aaa‘,
        source  => ‘/etc/aaa‘,
        owner   => ‘keerr0‘,
        mode    => ‘611‘,
        }
[[email protected] ppp]# puppet apply -v file1.pp
Notice: Compiled catalog for localhost in environment production in 0.15 seconds
Info: Applying configuration version ‘1579252230‘
Notice: /Stage[main]/Main/File[aaa]/ensure: defined content as ‘{md5}d41d8cd98f00b204e9800998ecf8427e‘
Notice: Finished catalog run in 0.08 seconds
[[email protected] ppp]# ls /data/aaa
/data/aaa

7)exec:执行命令,慎用。通常用来执行外部命令
  查看使用帮助信息:

[[email protected] ppp]# puppet describe exec -s -m

exec
====
Executes external commands.
Any command in an `exec` resource **must** be able to run multiple times
without causing harm --- that is, it must be *idempotent*. There are three
main ways for an exec to be idempotent:
* The command itself is already idempotent. (For example, `apt-get update`.)
* The exec has an `onlyif`, `unless`, or `creates` attribute, which prevents
  Puppet from running the command unless some condition is met.
* The exec has `refreshonly => true`, which only allows Puppet to run the
  command when some other resource is changed. (See the notes on refreshing
  below.)
A caution: There‘s a widespread tendency to use collections of execs to
manage resources that aren‘t covered by an existing resource type. This
works fine for simple tasks, but once your exec pile gets complex enough
that you really have to think to understand what‘s happening, you should
consider developing a custom resource type instead, as it will be much
more predictable and maintainable.
**Refresh:** `exec` resources can respond to refresh events (via
`notify`, `subscribe`, or the `~>` arrow). The refresh behavior of execs
is non-standard, and can be affected by the `refresh` and
`refreshonly` attributes:
* If `refreshonly` is set to true, the exec will _only_ run when it receives
an
  event. This is the most reliable way to use refresh with execs.
* If the exec already would have run and receives an event, it will run its
  command **up to two times.** (If an `onlyif`, `unless`, or `creates`
condition
  is no longer met after the first run, the second run will not occur.)
* If the exec already would have run, has a `refresh` command, and receives
an
  event, it will run its normal command, then run its `refresh` command
  (as long as any `onlyif`, `unless`, or `creates` conditions are still met
  after the normal command finishes).
* If the exec would **not** have run (due to an `onlyif`, `unless`, or
`creates`
  attribute) and receives an event, it still will not run.
* If the exec has `noop => true`, would otherwise have run, and receives
  an event from a non-noop resource, it will run once (or run its `refresh`
  command instead, if it has one).
In short: If there‘s a possibility of your exec receiving refresh events,
it becomes doubly important to make sure the run conditions are restricted.
**Autorequires:** If Puppet is managing an exec‘s cwd or the executable
file used in an exec‘s command, the exec resource will autorequire those
files. If Puppet is managing the user that an exec should run as, the
exec resource will autorequire that user.

Parameters
----------
    command, creates, cwd, environment, group, logoutput, onlyif, path,
    refresh, refreshonly, returns, timeout, tries, try_sleep, umask, unless,
    user

Meta Parameters
---------------
    alias, audit, before, loglevel, noop, notify, require, schedule, stage,
    subscribe, tag

Providers
---------
    posix, shell, windows
属性:
    command(namevar):要运行的命令;
    cwd:指定运行该命令的目录;
    creates:文件路径,仅此路径表示的文件不存在时,command方才执行;
    user/group:运行命令的用户身份;
    path:指定命令执行的搜索路径;
    onlyif:此属性指定一个命令,此命令正常(退出码为0)运行时,当前command才会运行;
    unless:此属性指定一个命令,此命令非正常(退出码为非0)运行时,当前command才会运行;
    refresh:重新执行当前command的替代命令;
    refreshonly:仅接收到订阅的资源的通知时方才运行;
[[email protected] ppp]# vim exec1.pp

exec{‘cmd‘:
        command => ‘mkdir /data/testdir‘,
        path => [‘/bin‘,‘/sbin‘,‘/usr/bin‘,‘/usr/sbin‘],
        #   path => ‘/bin:/sbin:/usr/bin:/usr/sbin‘,
        }
[[email protected] ppp]# puppet apply -v exec1.pp
Notice: Compiled catalog for localhost in environment production in 0.05 seconds
Info: Applying configuration version ‘1579252384‘
Notice: /Stage[main]/Main/Exec[cmd]/returns: executed successfully
Notice: Finished catalog run in 0.05 seconds
[[email protected] ppp]# ls /data/testdir/

8)cron:定义周期性任务
  查看使用帮助信息:

[[email protected] ppp]# puppet describe cron -s -m

cron
====
Installs and manages cron jobs.  Every cron resource created by Puppet
requires a command and at least one periodic attribute (hour, minute,
month, monthday, weekday, or special).  While the name of the cron job is
not part of the actual job, the name is stored in a comment beginning with
`# Puppet Name: `. These comments are used to match crontab entries created
by Puppet with cron resources.
If an existing crontab entry happens to match the scheduling and command of
a
cron resource that has never been synched, Puppet will defer to the existing
crontab entry and will not create a new entry tagged with the `# Puppet
Name: `
comment.
Example:
    cron { logrotate:
      command => "/usr/sbin/logrotate",
      user    => root,
      hour    => 2,
      minute  => 0
    }
Note that all periodic attributes can be specified as an array of values:
    cron { logrotate:
      command => "/usr/sbin/logrotate",
      user    => root,
      hour    => [2, 4]
    }
...or using ranges or the step syntax `*/2` (although there‘s no guarantee
that your `cron` daemon supports these):
    cron { logrotate:
      command => "/usr/sbin/logrotate",
      user    => root,
      hour    => [‘2-4‘],
      minute  => ‘*/10‘
    }
An important note: _the Cron type will not reset parameters that are
removed from a manifest_. For example, removing a `minute => 10` parameter
will not reset the minute component of the associated cronjob to `*`.
These changes must be expressed by setting the parameter to
`minute => absent` because Puppet only manages parameters that are out of
sync with manifest entries.
**Autorequires:** If Puppet is managing the user account specified by the
`user` property of a cron resource, then the cron resource will autorequire
that user.

Parameters
----------
    command, ensure, environment, hour, minute, month, monthday, name,
    special, target, user, weekday

Meta Parameters
---------------
    alias, audit, before, loglevel, noop, notify, require, schedule, stage,
    subscribe, tag

Providers
---------
    crontab
属性:
    command:要执行的任务(命令或脚本);
    ensure:目标状态,present/absent;
    hour:时;
    minute:分;
    monthday:日;
    month:月;
    weekday:周;
    user:以哪个用户的身份运行命令(默认为root);
    target:添加为哪个用户的任务;
    name:cron job的名称;
[[email protected] ppp]# vim cron1.pp

cron{‘timesync‘:
        command => ‘/usr/sbin/ntpdata 127.0.0.1‘,
        ensure  => present,
        minute  => ‘*/3‘,
        user    => ‘root‘,
        }
[[email protected] ppp]# puppet apply -v cron1.pp
Notice: Compiled catalog for localhost in environment production in 0.06 seconds
Info: Applying configuration version ‘1579252608‘
Notice: /Stage[main]/Main/Cron[timesync]/ensure: created
Notice: Finished catalog run in 0.14 seconds
[[email protected] ppp]# crontab -l
# HEADER: This file was autogenerated at 2020-01-17 17:16:49 +0800 by puppet.
# HEADER: While it can still be managed manually, it is definitely not recommended.
# HEADER: Note particularly that the comments starting with ‘Puppet Name‘ should
# HEADER: not be deleted, as doing so could cause duplicate cron jobs.
# Puppet Name: timesync
*/3 * * * * /usr/sbin/ntpdata 127.0.0.1
[[email protected] ppp]# 

9)notify:调试输出
  查看使用帮助信息:

[[email protected] ppp]# puppet describe notify -s -m

notify
======
Sends an arbitrary message to the agent run-time log.

Parameters
----------
    message, name, withpath

Meta Parameters
---------------
    alias, audit, before, loglevel, noop, notify, require, schedule, stage,
    subscribe, tag
属性:
    message:记录的信息
    name:信息名称

该选项一般用于master/agent模式中,来记录一些操作的时间,比如重新安装了一个程序呀,或者重启了应用等等。会直接输出到代理机的运行日志中。

  以上,就是我们常见的8个资源。其余的资源我们可以使用puppet describe -l来列出,上文中也已经说过了~

4、资源的特殊属性

  puppet中也提供了beforerequirenotifysubscribe四个参数来定义资源之间的依赖关系和通知关系。

before:表示需要依赖于某个资源
require:表示应该先执行本资源,在执行别的资源
notify:A notify B:B依赖于A,且A发生改变后会通知B;
subscribe:B subscribe A:B依赖于A,且B监控A资源的变化产生的事件;

  同时,依赖关系还可以使用->~>来表示:

-> 表示后资源需要依赖前资源
~> 表示前资源变动通知后资源调用

属性:
command(namevar):要运行的命令;
cwd:指定运行该命令的目录;
creates:文件路径,仅此路径表示的文件不存在时,command方才执行;
user/group:运行命令的用户身份;
path:指定命令执行的搜索路径;
onlyif:此属性指定一个命令,此命令正常(退出码为0)运行时,当前command才会运行;
unless:此属性指定一个命令,此命令非正常(退出码为非0)运行时,当前command才会运行;
refresh:重新执行当前command的替代命令;
refreshonly:仅接收到订阅的资源的通知时方才运行;

原文地址:https://www.cnblogs.com/liujunjun/p/12206777.html

时间: 2024-12-11 17:38:45

自动化运维工具puppet详解(一)的相关文章

自动化运维工具——ansible详解案例分享

自动化运维工具--ansible详解案例分享(一)目录ansible 简介ansible 是什么?ansible 特点ansible 架构图ansible 任务执行ansible 任务执行模式ansible 执行流程ansible 命令执行过程ansible 配置详解ansible 安装方式使用 pip(python的包管理模块)安装使用 yum 安装ansible 程序结构ansible配置文件查找顺序ansible配置文件ansuble主机清单ansible 常用命令ansible 命令集a

自动化运维工具——ansible详解(一)

ansible 简介 ansible 是什么? ansible是新出现的自动化运维工具,基于Python开发,集合了众多运维工具(puppet.chef.func.fabric)的优点,实现了批量系统配置.批量程序部署.批量运行命令等功能. ansible是基于 paramiko 开发的,并且基于模块化工作,本身没有批量部署的能力.真正具有批量部署的是ansible所运行的模块,ansible只是提供一种框架.ansible不需要在远程主机上安装client/agents,因为它们是基于ssh来

自动化运维工具ansible详解

 ll  本文导航    · ansible的基础介绍   · ansible的安装与配置   · ansible的简单应用   · YAML介绍及语法   · ansible-playbooks(剧本)  ll  要求  掌握ansible基本应用与playbooks. 1.ansible介绍 ansible是一款基于python开发的自动化运维工具,它结合了puppet.cfengine.func.chef.fabric等工具的优点,实现了批量系统配置.批量部署应用程序及批量部署命令   a

ansible自动化运维工具使用详解

一.ansible简介 1.ansible ansible是新出现的自动化运维工具,基于Python研发.糅合了众多老牌运维工具的优点实现了批量操作系统配置.批量程序的部署.批量运行命令等功能.仅需在管理工作站上安装ansible程序配置被管控主机的IP信息,被管控的主机无客户端.ansible应用程序存在于epel(第三方社区)源,依赖于很多python组件 参考站点:http://www.ansible.com.cn 2.ansible特性 模块化设计,调用特定的模块来完成特定任务,本身是核

自动化运维工具Ansible-playbook详解和案例实战(四)

1.playbook-剧本介绍 playbooks是 一个不同于使用Ansible命令行执行方式的模式,其功能更强大灵活.简单来说,playbook是一个非常简单的配置管理和多主机部署系统,不同于任何已经存在的模式,可作为一个适合部署复杂应用程序的基础.Playbook可以定制配置,可以按照指定的操作步骤有序执行,支持同步和异步方式.值得注意的是playbook是通过YAML格式来进行描述定义的. 1.1.核心元素 hosts:执行的远程主机列表 tasks:任务,由模板定义的操作列表 vari

自动化运维工具puppet的部署与应用

作为一名运维工程师,维护服务器的正常运行是最基本的职责,随着服务器的增多,任务量也随之增大,就需要寻找一款能够降低工作量的工具.那么今天就给大家介绍一批工具,这批工具是"可编程"的,只需要为这批工具写上几行代码,它便会自动完成所有的工作,这批工具就是运维自动化puppet(为什么说是一批工具,因为软件不止一个).Puppet可以针对多台服务器进行统一的操作,例如:软件分发,统一执行脚本,在服务器上写好脚本分发给客户机,客户机就会自动执行,减少了人力及误操作风险. 1. puppet工作

自动化运维工具puppet(二)

一.Puppet作域与变量 1.作用域 作域的作就是指定特定的代码与其他的代码进隔离. 变量与默认资源将接受这些限制, 资 源标题. 资源引将不接受这样的限制. 接受范围限制的有: 变量 默认资源 不接受范围限制的有: 资源标题 资源引 在任何给定作域内, 可访问在本域中定义的变量或资源默认值, 同时继承作域中的内容, 依 此类推. 因此, 任何局部作域都可访问顶级作域中的内容. 使的范围是从该节点作域内直到 全局作域, 如下图所. 从上图可以看到: 在全局作域内只能访问作域的变量及默认值. 节

自动化运维工具puppet的基础使用

一.puppet的简介 puppet是一种开源的.新一代的集中化的配置管理工具.可管理的平台有windows,Linux,Unix等.有自己的配置语言(资源申报语言),可管理文件.软件包.系统服务.用户等.这些统称为puppet的资源.puppet是采用ruby语言研发的. 工作流程 如下图: 工作模型: 单机模型:实现定义多个manifests --> complier --> catalog --> apply master/agent模型:集中式管理 架构: 工作原理: puppe

自动化运维之ansible详解

1.ansible安装以及配置认证 ansible也是有Python开发的. ansible特点: 不需要安装客户端,通过sshd去通信 基于模块工作,模块可以由任何语言开发 不仅支持命令行使用模块,也支持编写yaml格式的playbook 支持sudo 又提供UI(浏览器图形化)www.ansible.com/tower 10台主机以内免费 开源UI http://github.com/alaxli/ansible_ui 文档http://download.csdn.net/detail/li