Learning Puppet — Manifests

hotnet

Begin
　　In a text editor — vim, emacs, or nano — create a file with the following contents and filename: written and applied your first Puppet manifest.
　　[iyunv@yum01 ~]# useradd testuser
[iyunv@yum01 ~]# cat /etc/passwd |grep test
testuser:x:536:536::/home/testuser:/bin/bash
[iyunv@yum01 ~]# pwd
/root
[iyunv@yum01 ~]# vim user-absent.pp
[iyunv@yum01 ~]# cat user-absent.pp
user {'testuser':
      ensure => absent,
    }
[iyunv@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
[iyunv@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
[iyunv@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:
　　[iyunv@yum01 ~]# ls -l /tmp/ |grep test
[iyunv@yum01 ~]# vim file-1.pp
[iyunv@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 (})
  

　　[iyunv@yum01 ~]# pwd
/root
[iyunv@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
[iyunv@yum01 ~]# ls -l /tmp/ |grep test
-rw-r----- 1 root   root         16 Nov  6 06:50 testfile
[iyunv@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:
　　[iyunv@yum01 ~]# chmod 666 /tmp/testfile
[iyunv@yum01 ~]# ls -l /tmp/ |grep test
-rw-rw-rw- 1 root   root         16 Nov  6 06:50 testfile
[iyunv@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
[iyunv@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
  

　　[iyunv@yum01 ~]# vim file-2.pp
[iyunv@yum01 ~]# cat file-2.pp
file {'/tmp/test1':
ensure => file,
content => "hi.\n",
}
　　file {'/tmp/test2':
ensure => directory,
mode => 0644,
}
　　file {'/tmp/test3':
ensure => link,
target => '/tmp/test1',
}
　　notify {" iam nofitying you":}
notify {"so am i" :}
　　[iyunv@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 (user, group, package…), 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:
　　[iyunv@centos manifests]# pwd
/etc/puppet/manifests
[iyunv@centos manifests]# vim file.pp
[iyunv@centos manifests]# cat file.pp
file {'/tmp/test11111111':
        ensure => file,
        content => "hi. this is a test 111111 file \n",
}
[iyunv@centos manifests]# vim site.pp
[iyunv@centos manifests]# cat site.pp
import 'file.pp'
　　[iyunv@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
[iyunv@yum01 ~]# cat /tmp/test11111111
hi. this is a test 111111 file
　　
　　refer: https://docs.puppetlabs.com/learning/manifests.html