zoukankan      html  css  js  c++  java
  • Learning Puppet — Manifests

    Begin

    In a text editor — vimemacs, or nano — create a file with the following contents and filename: written and applied your first Puppet manifest.

    [root@yum01 ~]# useradd testuser
    [root@yum01 ~]# cat /etc/passwd |grep test
    testuser:x:536:536::/home/testuser:/bin/bash
    [root@yum01 ~]# pwd
    /root
    [root@yum01 ~]# vim user-absent.pp
    [root@yum01 ~]# cat user-absent.pp
    user {'testuser':
    ensure => absent,
    }
    [root@yum01 ~]# puppet apply /root/user-absent.pp
    Notice: Compiled catalog for yum01.test.com in environment production in 7.99 seconds
    Notice: /Stage[main]/Main/User[testuser]/ensure: removed
    Notice: Finished catalog run in 4.34 seconds
    [root@yum01 ~]# puppet apply /root/user-absent.pp
    Notice: Compiled catalog for yum01.test.com in environment production in 0.27 seconds
    Notice: Finished catalog run in 0.03 seconds
    [root@yum01 ~]# cat /etc/passwd |grep test

    Manifests

    Puppet programs are called “manifests,” and they use the .pp file extension.

    The core of the Puppet language is the resource declaration. A resource declaration describes a desired state for one resource.

    Puppet Apply

    Like resource in the last chapter, apply is a Puppet subcommand. It takes the name of a manifest file as its argument, and enforces the desired state described in the manifest.

    We’ll use it below to test small manifests, but it can be used for larger jobs too. In fact, it can do nearly everything an agent/master Puppet environment can do.

    Resource Declarations

    Let’s start by looking at a single resource:

    [root@yum01 ~]# ls -l /tmp/ |grep test
    [root@yum01 ~]# vim file-1.pp
    [root@yum01 ~]# cat file-1.pp
    file {'testfile':
    path => '/tmp/testfile',
    ensure => present,
    mode => 0640,
    content => "i am a test file",
    }

    • The type (file, in this case)
    • An opening curly brace ({)
      • The title (testfile)
      • A colon (:)
      • A set of attribute => value pairs, with a comma after each pair (path => '/tmp/testfile', etc.)
    • A closing curly brace (})

    [root@yum01 ~]# pwd
    /root
    [root@yum01 ~]# puppet apply /root/file-1.pp
    Notice: Compiled catalog for yum01.test.com in environment production in 0.18 seconds
    Notice: /Stage[main]/Main/File[testfile]/ensure: created
    Notice: Finished catalog run in 0.32 seconds
    [root@yum01 ~]# ls -l /tmp/ |grep test
    -rw-r----- 1 root root 16 Nov 6 06:50 testfile
    [root@yum01 ~]# cat /tmp/testfile
    i am a test file

    Puppet noticed that the file didn’t exist, and created it. It set the desired content and mode at the same time.

    If we try changing the mode and applying the manifest again, Puppet will fix it:

    [root@yum01 ~]# chmod 666 /tmp/testfile
    [root@yum01 ~]# ls -l /tmp/ |grep test
    -rw-rw-rw- 1 root root 16 Nov 6 06:50 testfile
    [root@yum01 ~]# puppet apply /root/file-1.pp
    Notice: Compiled catalog for yum01.test.com in environment production in 0.22 seconds
    Notice: /Stage[main]/Main/File[testfile]/mode: mode changed '0666' to '0640'
    Notice: Finished catalog run in 0.27 seconds
    [root@yum01 ~]# ls -l /tmp/ |grep test
    -rw-r----- 1 root root 16 Nov 6 06:50 testfile

    Once More, With Feeling!

    Now that you know resource declarations, let’s play with the file type some more. We’ll:

    • Put multiple resources of different types in the same manifest
    • Use new values for the ensure attribute
    • Find an attribute with a special relationship to the resource title
    • See what happens when we leave off certain attributes
    • See some automatic permission adjustments on directories

    [root@yum01 ~]# vim file-2.pp
    [root@yum01 ~]# cat file-2.pp
    file {'/tmp/test1':
    ensure => file,
    content => "hi. ",
    }

    file {'/tmp/test2':
    ensure => directory,
    mode => 0644,
    }

    file {'/tmp/test3':
    ensure => link,
    target => '/tmp/test1',
    }

    notify {" iam nofitying you":}
    notify {"so am i" :}

    [root@yum01 ~]# puppet apply /root/file-2.pp
    Notice: Compiled catalog for yum01.test.com in environment production in 0.18 seconds
    Notice: /Stage[main]/Main/File[/tmp/test1]/ensure: defined content as '{md5}4e9141e3aa25c784aa6bc0b2892c12d9'
    Notice: /Stage[main]/Main/File[/tmp/test3]/ensure: created
    Notice: /Stage[main]/Main/File[/tmp/test2]/ensure: created
    Notice: iam nofitying you
    Notice: /Stage[main]/Main/Notify[ iam nofitying you]/message: defined 'message' as ' iam nofitying you'
    Notice: so am i
    Notice: /Stage[main]/Main/Notify[so am i]/message: defined 'message' as 'so am i'
    Notice: Finished catalog run in 0.14 seconds

    New Ensure Values, Different States

    The ensure attribute is somewhat special. It’s available on most (but not all) resource types, and it controls whether the resource exists, with the definition of “exists” being somewhat local.

    With files, there are several ways to exist:

    • As a normal file (ensure => file)
    • As a directory (ensure => directory)
    • As a symlink (ensure => link)
    • As any of the above (ensure => present)
    • As nothing (ensure => absent).

    Titles and Namevars

    Notice how our original file resource had a path attribute, but our next three left it out?

    Almost every resource type has one attribute whose value defaults to the resource’s title. For the file resource, that’s path. Most of the time (usergrouppackage…), it’sname.

    The Site Manifest and Puppet Agen

    We’ve seen how to use puppet apply to directly apply manifests on one system. The puppet master/agent services work very similarly, but with a few key differences:

    Puppet apply:

    • A user executes a command, triggering a Puppet run.
    • Puppet apply reads the manifest passed to it, compiles it into a catalog, and applies the catalog.

    Puppet agent/master:

    • Puppet agent runs as a service, and triggers a Puppet run about every half hour (configurable).
    • Puppet agent does not have access to any manifests; instead, it requests a pre-compiled catalog from a puppet master server.
    • The puppet master always reads one special manifest, called the “site manifest” or site.pp. It uses this to compile a catalog, which it sends back to the agent. ----site.pp
    • After getting the catalog, the agent applies it.

     This way, you can have many machines being configured by Puppet, while only maintaining your manifests on one (or a few) servers. This also gives some extra security, as described above under “Compilation.”

    Exercise: Use Puppet Agent/Master to Apply the Same Configuration

    To see how the same manifest code works in puppet agent:

    [root@centos manifests]# pwd
    /etc/puppet/manifests
    [root@centos manifests]# vim file.pp
    [root@centos manifests]# cat file.pp
    file {'/tmp/test11111111':
    ensure => file,
    content => "hi. this is a test 111111 file ",
    }
    [root@centos manifests]# vim site.pp
    [root@centos manifests]# cat site.pp
    import 'file.pp'

    [root@yum01 ~]# puppet agent --test
    Info: Retrieving pluginfacts
    Info: Retrieving plugin
    Info: Caching catalog for yum01.test.com
    Info: Applying configuration version '1415262208'
    Notice: /Stage[main]/Main/File[/tmp/test11111111]/ensure: defined content as '{md5}cb94281a2c8ccc1c3a64aa2c0e04721e'
    Notice: Finished catalog run in 0.14 seconds
    [root@yum01 ~]# cat /tmp/test11111111
    hi. this is a test 111111 file

    refer: https://docs.puppetlabs.com/learning/manifests.html

  • 相关阅读:
    linux进程cpu使用率过高分析与排查
    重启服务器后keepalived,vip找不到
    linux五种IO模型
    redis为什么单线程这么快?
    nginx为什么比apache快?
    redis高可用,主从,哨兵,集群
    git合并远端commit
    查看cpu和内存
    CommitLog文件和ConsumeQueue在文件系统中的映射
    hadoop集群启动
  • 原文地址:https://www.cnblogs.com/oskb/p/4078968.html
Copyright © 2011-2022 走看看