m
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
Puppet is a configuration management tool that is used to configure and ensure your machines are in a consistent state.
 
Puppet is a configuration management tool that is used to configure and ensure your machines are in a consistent state.
  
== Installation ==
+
==Installation==
 
Installing puppet can be done through your distro's package manager.
 
Installing puppet can be done through your distro's package manager.
  
== Quick Start ==
+
===CentOS 8===
 +
On CentOS 8, install the puppet repository and then the puppet agent. After installation, running <code>puppet</code> may result in a <code>bash: puppet: command not found</code> error message. This is because the puppet agent isn't installed to a standard path, but rather in <code>/opt/puppetlabs</code>. Relaunch your shell to have the new path applied or update your <code>PATH</code> variable if t his happens.
 +
{{Highlight
 +
| code = # yum install http://yum.puppetlabs.com/puppet-release-el-8.noarch.rpm
 +
# yum -y install puppet
 +
# puppet --version
 +
6.16.0
 +
| lang = terminal
 +
}}
 +
 
 +
===Post Installation Checks===
 +
Ensure that your host has the proper hostname and FQDN set. This is important especially if the host is to use a central puppet server as the hostname distinguishes the host and specifies what manifests will be executed.
 +
 
 +
{{Highlight
 +
| code = # facter {{!}} grep hostname
 +
centos8
 +
# facter {{!}} grep fqdn
 +
centos8.steamr.com
 +
| lang = terminal
 +
}}
 +
 
 +
If the hostname is incorrect, set the proper hostname by editing /etc/hostname.
 +
 
 +
==Quick Start==
 
Puppet can be used as a standalone tool to apply manifests (.pp files defining a particular configuration state) on a machine or it can be used in conjunction with a puppet master to retrieve manifests from a remote server.
 
Puppet can be used as a standalone tool to apply manifests (.pp files defining a particular configuration state) on a machine or it can be used in conjunction with a puppet master to retrieve manifests from a remote server.
  
Manifests are written in DSL, Puppet's Domain Specific Language and looks something like:
+
===Manifests ===
 +
Manifests are written in Puppet's Domain Specific Language (DSL). An example manifest:
 
{{highlight|lang=terminal|code=
 
{{highlight|lang=terminal|code=
 
# cat hosts.pp
 
# cat hosts.pp
Line 15: Line 39:
 
mode => '0644',
 
mode => '0644',
 
}
 
}
 +
}}Complex manifests should be grouped together into a class. Classes are logical groupings of manifests and resources. The environment that the puppet manifests run in can be seen by running <code>facter</code>. This command lists all the known facts of the host, any of which can be used within a manifest.
 +
 +
To apply the manifest, run:
 +
{{highlight|lang=terminal|code=
 
## Apply a manifest by running:
 
## Apply a manifest by running:
 
# puppet apply hosts.pp
 
# puppet apply hosts.pp
}}.
+
}}
 +
 
 +
===Modules===
 +
Modules groups puppet manifests, classes, and related resources such as templates into a neat package.  Using a module is done by invoking a specific interface that accepts certain arguments and parameters. As a result, modules are normally used like software packages; it is distributed for easy sharing and reuse.
 +
 
 +
==== Searching and Installing Modules ====
 +
Like software packages, modules can be searched for and installed. Searching for published modules can be done with {{code|puppet module search}}. Modules can be installed with  {{code|puppet module install}}. By default, when searching and installing like this, data is pulled from the puppet-labs forge server. Modules are installed in the default location at <code>/etc/puppetlabs/code/environments/production/modules</code>.  
  
Complex manifests should be grouped together into a class. Classes are logical groupings of manifests and resources.
+
For example, to install a specific version of the NTP module by puppetlabs, run {{code|puppet module install  puppetlabs-ntp --version 7.1.1}}. This package will be placed in the <code>/etc/puppetlabs/code/environments/production/modules/ntp</code> directory.
 +
 
 +
Alternatively, you can install modules from a custom repository or from a tarball. In fact, you can even put everything inside the modules directory into a git repository which allows you to git clone a set of modules for stand-alone puppet instances.
 +
 
 +
For more information on installing modules, see the documentation at: https://puppet.com/docs/puppet/latest/modules_installing.html
 +
 
 +
==== Creating custom Puppet modules ====
 +
Traditionally, you could use <code>puppet module generate</code>, but since around 2019, you need to install and use the <code>pdk</code> package.  Create a new module with <code>pdk new module author-modulename</code>.  
  
Modules contains code and resources in a specific directory structure. It provides puppet manifests/classes with a well defined interface (such as what parameters/types it accepts). Modules makes it easy to share and reuse puppet code.
 
Modules can be installed by running {{code|puppet module install}}. Eg. {{code|puppet module install  puppetlabs-ntp --version 7.1.1}}.
 
Modules that puppet can see can be found by running {{code|puppet module list}}.
 
Modules can be created using a boilerplate that is generated with {{code|puppet module generate module-name}}. Modules should start with the organization, a dash, followed by the module name (eg. cpsc-hosts).
 
 
When a module is loaded, the first file that is read is the {{code|init.pp}} file. The init.pp file should contain a class with the module name. For example:
 
When a module is loaded, the first file that is read is the {{code|init.pp}} file. The init.pp file should contain a class with the module name. For example:
 
{{highlight|lang=terminal|code=
 
{{highlight|lang=terminal|code=
Line 51: Line 88:
 
                 mode => '0644',
 
                 mode => '0644',
 
         }
 
         }
 +
<nowiki>}</nowiki>
 +
}}Modules can be built into a tarball with the <code>pdk build</code> command.
 +
 +
==== Using a module ====
 +
A manifest can make use of an installed module by just referencing it in the manifest. For example, if the <code>ntp</code> module is installed, your manifest just needs to reference the class and provide any required or optional parameters:
 +
{{Highlight
 +
| code = class {'::ntp':
 +
        server  => ['136.159.2.1', '136.159.2.4'],
 
}
 
}
 +
| lang = puppet
 +
}}
 +
The 3 lines above will set up the NTP service to use the two NTP servers. Apply the manifest using <code>puppet apply manifest.pp</code>, messages should indicate that the chrony.conf configuration file has been changed and the service is started.
 +
{{Highlight
 +
| code = # puppet module list
 +
/etc/puppetlabs/code/environments/production/modules
 +
└── thias-ntp (v1.1.9)
 +
 +
# puppet apply manifest.pp
 +
Notice: /Stage[main]/Ntp/File[/etc/chrony.conf]/content: content changed '{md5}97078948a9e2c1b99ab3e38d26a3311d' to '{md5}469a5cf69adf4a68097a63bd72e8a07'
 +
Notice: /Stage[main]/Ntp/Service[chronyd]/ensure: ensure changed 'stopped' to 'running'
 +
Notice: Applied catalog in 41.08 seconds
 +
| lang = terminal
 
}}
 
}}
  
 +
== Working with puppet master ==
 
Nodes can talk to a puppet master only after the master has signed the node's certificate. Certificates can be manually accepted by signing it using {{code|puppet cert sign node-name}}. Certificates on the puppet master can be shown by running:
 
Nodes can talk to a puppet master only after the master has signed the node's certificate. Certificates can be manually accepted by signing it using {{code|puppet cert sign node-name}}. Certificates on the puppet master can be shown by running:
 
{{highlight|lang=terminal|code=
 
{{highlight|lang=terminal|code=
Line 69: Line 128:
 
}}
 
}}
  
== Terminology ==
+
==Terminology==
 
There are a few differences in the terminology between puppet and other configuration management tools such as SaltStack.
 
There are a few differences in the terminology between puppet and other configuration management tools such as SaltStack.
 +
;Nodes
 +
:The machines receiving configurations. (eg. Salt Minions)
 +
;Facts
 +
:Facts about the nodes, such as hardware and software versions installed. (eg. Salt grains)
 +
;Puppet Master
 +
:The server that nodes receive configuration information from. (eg. Salt Master)
 +
;Puppet DB
 +
:Acts as a puppet data warehouse for information about nodes.
 +
;Master of Masters
 +
:Multi-levels of puppet masters for larger installations, where a puppet master is controlled by another puppet master.
 +
;DSL
 +
:The Domain Specific Language used by puppet configs. (eg. Yaml)
 +
;Manifest
 +
:A file containing specific configuration states a node should be in. (eg. Salt states)
 +
;Catalog
 +
:A manifest is into a catalog which is used by puppet to apply the desired state. Compilation is triggered by a {{code|puppet apply}}, or when a puppet master needs to update a node. Catalogs help by simplifying/limiting state changes for a particular node.
 +
;Class
 +
:A class is a grouping of manifests.
 +
;Module
 +
:A module contains a class as well as supporting files such as templates, files, etc. One can be created by running {{code|puppet module generate module-name}}.
 +
;Environment
 +
:An environment contains a set of modules/classes/manifests which are isolated from each other and are applied to a set of nodes. These can be promoted to other environments after testing. (eg. Dev, QA, Production environments).
  
* Nodes - The machines receiving configurations. (eg. Salt Minions)
+
==See Also==
* Facts - Facts about the nodes, such as hardware and software versions installed. (eg. Salt grains)
+
Augeas - Treats config files as tree values
* Puppet Master - The server that nodes receive configuration information from. (eg. Salt Master)
 
* Puppet DB - Acts as a puppet data warehouse for information about nodes.
 
* Master of Masters - Multi-levels of puppet masters for larger installations, where a puppet master is controlled by another puppet master.
 
* DSL - The Domain Specific Language used by puppet configs. (eg. Yaml)
 
* Manifest - A file containing specific configuration states a node should be in. (eg. Salt states)
 
* Catalog - A manifest is into a catalog which is used by puppet to apply the desired state. Compilation is triggered by a {{code|puppet apply}}, or when a puppet master needs to update a node. Catalogs help by simplifying/limiting state changes for a particular node.
 
* Class - A class is a grouping of manifests.
 
* Module - A module contains a class as well as supporting files such as templates, files, etc. One can be created by running {{code|puppet module generate module-name}}.
 
* Environment - An environment contains a set of modules/classes/manifests which are isolated from each other and are applied to a set of nodes. These can be promoted to other environments after testing. (eg. Dev, QA, Production environments).
 
  
 +
*https://puppet.com/docs/puppet/5.3/resources_augeas.html
  
== See Also ==
+
*https://puppet.com/docs/puppet/5.5/file_serving.html
Augeas - Treats config files as tree values
+
*https://puppet.com/docs/puppet/5.3/modules_fundamentals.html
* https://puppet.com/docs/puppet/5.3/resources_augeas.html
+
*https://puppet.com/docs/puppet/5.3/environments_about.html
 
 
* https://puppet.com/docs/puppet/5.5/file_serving.html
 
* https://puppet.com/docs/puppet/5.3/modules_fundamentals.html
 
* https://puppet.com/docs/puppet/5.3/environments_about.html
 
  
{{Navbox Linux}}[[Category:Linux]]
+
{{Navbox Linux}}
 +
[[Category:Linux]]
 
[[Category:LinuxUtilities]]
 
[[Category:LinuxUtilities]]

Latest revision as of 16:24, 24 June 2020

Puppet is a configuration management tool that is used to configure and ensure your machines are in a consistent state.

Installation[edit | edit source]

Installing puppet can be done through your distro's package manager.

CentOS 8[edit | edit source]

On CentOS 8, install the puppet repository and then the puppet agent. After installation, running puppet may result in a bash: puppet: command not found error message. This is because the puppet agent isn't installed to a standard path, but rather in /opt/puppetlabs. Relaunch your shell to have the new path applied or update your PATH variable if t his happens.

# yum install http://yum.puppetlabs.com/puppet-release-el-8.noarch.rpm
# yum -y install puppet
# puppet --version
6.16.0

Post Installation Checks[edit | edit source]

Ensure that your host has the proper hostname and FQDN set. This is important especially if the host is to use a central puppet server as the hostname distinguishes the host and specifies what manifests will be executed.

# facter | grep hostname
centos8
# facter | grep fqdn
centos8.steamr.com

If the hostname is incorrect, set the proper hostname by editing /etc/hostname.

Quick Start[edit | edit source]

Puppet can be used as a standalone tool to apply manifests (.pp files defining a particular configuration state) on a machine or it can be used in conjunction with a puppet master to retrieve manifests from a remote server.

Manifests[edit | edit source]

Manifests are written in Puppet's Domain Specific Language (DSL). An example manifest:

# cat hosts.pp
file { "/etc/hosts":
	path => "/etc/hosts",
	source => puppet:///linux/hosts,
	mode => '0644',
}

Complex manifests should be grouped together into a class. Classes are logical groupings of manifests and resources. The environment that the puppet manifests run in can be seen by running facter. This command lists all the known facts of the host, any of which can be used within a manifest.

To apply the manifest, run:

## Apply a manifest by running:
# puppet apply hosts.pp

Modules[edit | edit source]

Modules groups puppet manifests, classes, and related resources such as templates into a neat package. Using a module is done by invoking a specific interface that accepts certain arguments and parameters. As a result, modules are normally used like software packages; it is distributed for easy sharing and reuse.

Searching and Installing Modules[edit | edit source]

Like software packages, modules can be searched for and installed. Searching for published modules can be done with puppet module search. Modules can be installed with puppet module install. By default, when searching and installing like this, data is pulled from the puppet-labs forge server. Modules are installed in the default location at /etc/puppetlabs/code/environments/production/modules.

For example, to install a specific version of the NTP module by puppetlabs, run puppet module install puppetlabs-ntp --version 7.1.1. This package will be placed in the /etc/puppetlabs/code/environments/production/modules/ntp directory.

Alternatively, you can install modules from a custom repository or from a tarball. In fact, you can even put everything inside the modules directory into a git repository which allows you to git clone a set of modules for stand-alone puppet instances.

For more information on installing modules, see the documentation at: https://puppet.com/docs/puppet/latest/modules_installing.html

Creating custom Puppet modules[edit | edit source]

Traditionally, you could use puppet module generate, but since around 2019, you need to install and use the pdk package. Create a new module with pdk new module author-modulename.

When a module is loaded, the first file that is read is the init.pp file. The init.pp file should contain a class with the module name. For example:

# find
.
./Gemfile
./Rakefile
./examples
./examples/init.pp
./manifests
./manifests/init.pp
./spec
./spec/classes
./spec/classes/init_spec.rb
./spec/spec_helper.rb
./metadata.json
./files
./files/linux
./files/linux/hosts

# cat manifests/init.pp
class hosts {
        file { "/etc/hosts":
                path => "/etc/hosts",
                source => "puppet:///modules/hosts/linux/hosts",
                mode => '0644',
        }
}

Modules can be built into a tarball with the pdk build command.

Using a module[edit | edit source]

A manifest can make use of an installed module by just referencing it in the manifest. For example, if the ntp module is installed, your manifest just needs to reference the class and provide any required or optional parameters:

class {'::ntp':
        server   => ['136.159.2.1', '136.159.2.4'],
}

The 3 lines above will set up the NTP service to use the two NTP servers. Apply the manifest using puppet apply manifest.pp, messages should indicate that the chrony.conf configuration file has been changed and the service is started.

# puppet module list
/etc/puppetlabs/code/environments/production/modules
└── thias-ntp (v1.1.9)

# puppet apply manifest.pp
Notice: /Stage[main]/Ntp/File[/etc/chrony.conf]/content: content changed '{md5}97078948a9e2c1b99ab3e38d26a3311d' to '{md5}469a5cf69adf4a68097a63bd72e8a07'
Notice: /Stage[main]/Ntp/Service[chronyd]/ensure: ensure changed 'stopped' to 'running'
Notice: Applied catalog in 41.08 seconds

Working with puppet master[edit | edit source]

Nodes can talk to a puppet master only after the master has signed the node's certificate. Certificates can be manually accepted by signing it using puppet cert sign node-name. Certificates on the puppet master can be shown by running:

# puppet cert list --all
+ "foreman-test.lab.cs.ucalgary.ca" (SHA256) E9:C0:89:31:96:61:9C:2E:F7:48:24:D5:DD:DF:4D:DC:22:50:1B:1E:91:D4:BE:9F:37:9D:CB:12:9B:C1:80:67
+ "foreman.lab.cs.ucalgary.ca"      (SHA256) 71:8D:78:2B:A6:D2:E4:4D:16:DF:65:AD:DC:16:0F:7A:59:8A:67:AF:D5:FB:63:C7:17:3B:DE:59:EB:D6:FA:C1 (alt names: "DNS:foreman.lab.cs.ucalgary.ca", "DNS:puppet", "DNS:puppet.lab.cs.ucalgary.ca")
+ "leo-linux.lab.cs.ucalgary.ca"    (SHA256) EC:27:E8:AC:FF:2B:4C:E6:6F:36:96:E0:A4:87:41:32:6A:08:05:6A:C0:23:30:0E:4F:DF:98:DD:33:A0:D9:68

"+" sign means the cert has been signed and accepted by the puppet master. Signed certificates are also placed in /etc/puppetlabs/puppet/ssl/ca/signed.

Once a node has been accepted, configs can be pulled by the node by running:

# puppet agent -t

Terminology[edit | edit source]

There are a few differences in the terminology between puppet and other configuration management tools such as SaltStack.

Nodes
The machines receiving configurations. (eg. Salt Minions)
Facts
Facts about the nodes, such as hardware and software versions installed. (eg. Salt grains)
Puppet Master
The server that nodes receive configuration information from. (eg. Salt Master)
Puppet DB
Acts as a puppet data warehouse for information about nodes.
Master of Masters
Multi-levels of puppet masters for larger installations, where a puppet master is controlled by another puppet master.
DSL
The Domain Specific Language used by puppet configs. (eg. Yaml)
Manifest
A file containing specific configuration states a node should be in. (eg. Salt states)
Catalog
A manifest is into a catalog which is used by puppet to apply the desired state. Compilation is triggered by a puppet apply, or when a puppet master needs to update a node. Catalogs help by simplifying/limiting state changes for a particular node.
Class
A class is a grouping of manifests.
Module
A module contains a class as well as supporting files such as templates, files, etc. One can be created by running puppet module generate module-name.
Environment
An environment contains a set of modules/classes/manifests which are isolated from each other and are applied to a set of nodes. These can be promoted to other environments after testing. (eg. Dev, QA, Production environments).

See Also[edit | edit source]

Augeas - Treats config files as tree values