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.
[[email protected] ~]# useradd testuser
[[email protected] ~]# cat /etc/passwd |grep test
testuser:x:536:536::/home/testuser:/bin/bash
[[email protected] ~]# pwd
/root
[[email protected] ~]# vim user-absent.pp
[[email protected] ~]# cat user-absent.pp
user {‘testuser‘:
ensure => absent,
}
[[email protected] ~]# 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
[[email protected] ~]# 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
[[email protected] ~]# 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:
[[email protected] ~]# ls -l /tmp/ |grep test
[[email protected] ~]# vim file-1.pp
[[email protected] ~]# 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.)
- The title (
- A closing curly brace (
})
[[email protected] ~]# pwd
/root
[[email protected] ~]# 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
[[email protected] ~]# ls -l /tmp/ |grep test
-rw-r----- 1 root root 16 Nov 6 06:50 testfile
[[email protected] ~]# 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:
[[email protected] ~]# chmod 666 /tmp/testfile
[[email protected] ~]# ls -l /tmp/ |grep test
-rw-rw-rw- 1 root root 16 Nov 6 06:50 testfile
[[email protected] ~]# 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
[[email protected] ~]# 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
ensureattribute - 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
[[email protected] ~]# vim file-2.pp
[[email protected] ~]# 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" :}
[[email protected] ~]# 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:
[[email protected] manifests]# pwd
/etc/puppet/manifests
[[email protected] manifests]# vim file.pp
[[email protected] manifests]# cat file.pp
file {‘/tmp/test11111111‘:
ensure => file,
content => "hi. this is a test 111111 file \n",
}
[[email protected] manifests]# vim site.pp
[[email protected] manifests]# cat site.pp
import ‘file.pp‘
[[email protected] ~]# 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
[[email protected] ~]# cat /tmp/test11111111
hi. this is a test 111111 file
refer: https://docs.puppetlabs.com/learning/manifests.html