Puppet - Revision history

Leo: /* Quick Start */

2020-06-24T22:24:04Z

Quick Start

← Older revision		Revision as of 22:24, 24 June 2020
Line 30:		Line 30:
	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 ===
	Manifests are written in Puppet's Domain Specific Language (DSL). An example manifest:		Manifests are written in Puppet's Domain Specific Language (DSL). An example manifest:
	{{highlight\|lang=terminal\|code=		{{highlight\|lang=terminal\|code=
Line 44:		Line 45:
	## Apply a manifest by running:		## Apply a manifest by running:
	# puppet apply hosts.pp		# puppet apply hosts.pp
	}}~~<br />~~		}}

	===Modules===		===Modules===

Leo: /* Terminology */

2020-06-24T22:21:40Z

Terminology

← Older revision		Revision as of 22:21, 24 June 2020
Line 129:		Line 129:
	==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
	*Nodes - The machines receiving configurations. (eg. Salt Minions)		:The machines receiving configurations. (eg. Salt Minions)
	*Facts - Facts about the nodes, such as hardware and software versions installed. (eg. Salt grains)		;Facts
	*Puppet Master - The server that nodes receive configuration information from. (eg. Salt Master)		:Facts about the nodes, such as hardware and software versions installed. (eg. Salt grains)
	*Puppet DB - Acts as a puppet data warehouse for information about nodes.		;Puppet Master
	*Master of Masters - Multi-levels of puppet masters for larger installations, where a puppet master is controlled by another puppet master.		:The server that nodes receive configuration information from. (eg. Salt Master)
	*DSL - The Domain Specific Language used by puppet configs. (eg. Yaml)		;Puppet DB
	*Manifest - A file containing specific configuration states a node should be in. (eg. Salt states)		:Acts as a puppet data warehouse for information about nodes.
	*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.		;Master of Masters
	*Class - A class is a grouping of manifests.		:Multi-levels of puppet masters for larger installations, where a puppet master is controlled by another puppet master.
	*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}}.		;DSL
	*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).		: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).

	==See Also==		==See Also==

Leo: /* Quick Start */

2020-06-24T22:18:48Z

Quick Start

← Older revision		Revision as of 22:18, 24 June 2020
Line 4:		Line 4:
	Installing puppet can be done through your distro's package manager.		Installing puppet can be done through your distro's package manager.

	=== CentOS 8 ===		===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.		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		{{Highlight
Line 14:		Line 14:
	}}		}}

	=== Post Installation Checks ===		===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.		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.

Line 38:		Line 38:
	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
	}}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.		}}<br />
	<br />

	=== Modules ===		===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.		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.

	Like software packages, modules can be searched for and installed. Searching for published modules can be done with {{code\|puppet module ~~list~~}}. Modules can be installed with {{code\|puppet module install}}. Eg. {{code\|puppet module install puppetlabs-ntp --version 7.1.1}}.		==== 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>.

			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

	~~To create your own~~ modules, ~~a boilerplate template can be generated with {{~~code\|puppet module generate ~~module-name}}. Modules should start with the organization~~, ~~a dash~~, ~~followed by~~ the module ~~name (eg. cpsc~~-~~hosts)~~.		==== 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>.

	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:
Line 77:		Line 88:
	}		}
	<nowiki>}</nowiki>		<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=

Leo: wip new content on installation

2020-06-24T20:35:58Z

wip new content on installation

← Older revision		Revision as of 20:35, 24 June 2020
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 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 17:		Line 40:
	## Apply a manifest by running:		## Apply a manifest by running:
	# puppet apply hosts.pp		# puppet apply hosts.pp
	}}.		}}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.
			<br />

	~~Complex~~ manifests ~~should be grouped together~~ into a ~~class~~. ~~Classes~~ are ~~logical groupings of manifests~~ and ~~resources~~.		=== 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.

			Like software packages, modules can be searched for and installed. Searching for published modules can be done with {{code\|puppet module list}}. Modules can be installed with {{code\|puppet module install}}. Eg. {{code\|puppet module install puppetlabs-ntp --version 7.1.1}}.

			To create your own modules, a boilerplate template can be generated with {{code\|puppet module generate module-name}}. Modules should start with the organization, a dash, followed by the module name (eg. cpsc-hosts).

	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 76:
	mode => '0644',		mode => '0644',
	}		}
	}		<nowiki>}</nowiki>
	}}		}}

Line 69:		Line 94:
	}}		}}

	== 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)		*Nodes - The machines receiving configurations. (eg. Salt Minions)
	* Facts - Facts about the nodes, such as hardware and software versions installed. (eg. Salt grains)		*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 Master - The server that nodes receive configuration information from. (eg. Salt Master)
	* Puppet DB - Acts as a puppet data warehouse for information about nodes.		*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.		*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)		*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)		*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.		*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.		*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}}.		*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).		*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 ==		==See Also==
	Augeas - Treats config files as tree values		Augeas - Treats config files as tree values
	* https://puppet.com/docs/puppet/5.3/resources_augeas.html

	* https://puppet.com/docs/puppet/5.5/file_serving.html		*https://puppet.com/docs/puppet/5.3/resources_augeas.html
	* https://puppet.com/docs/puppet/5.3/modules_fundamentals.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]]

Leo at 22:02, 14 June 2020

2020-06-14T22:02:41Z

← Older revision		Revision as of 22:02, 14 June 2020
Line 94:		Line 94:

	{{Navbox Linux}}[[Category:Linux]]		{{Navbox Linux}}[[Category:Linux]]
			[[Category:LinuxUtilities]]

Leo: Text replacement - "Category:Linux{{Navbox Linux}}" to "{{Navbox Linux}}Category:Linux"

2019-09-01T06:20:39Z

Text replacement - "Category:Linux{{Navbox Linux}}" to "{{Navbox Linux}}Category:Linux"

← Older revision		Revision as of 06:20, 1 September 2019
Line 93:		Line 93:
	* https://puppet.com/docs/puppet/5.3/environments_about.html		* https://puppet.com/docs/puppet/5.3/environments_about.html

	[[Category:Linux]]~~{{Navbox Linux}}~~		{{Navbox Linux}}[[Category:Linux]]

Leo: Text replacement - "{{Navbox Linux}}{{Navbox Linux}}" to "{{Navbox Linux}}"

2019-09-01T05:10:22Z

Text replacement - "{{Navbox Linux}}{{Navbox Linux}}" to "{{Navbox Linux}}"

← Older revision		Revision as of 05:10, 1 September 2019
Line 93:		Line 93:
	* https://puppet.com/docs/puppet/5.3/environments_about.html		* https://puppet.com/docs/puppet/5.3/environments_about.html

	[[Category:Linux]]~~{{Navbox Linux}}~~{{Navbox Linux}}		[[Category:Linux]]{{Navbox Linux}}

Leo: Text replacement - "Category:Linux" to "Category:Linux{{Navbox Linux}}"

2019-09-01T05:09:15Z

Text replacement - "Category:Linux" to "Category:Linux{{Navbox Linux}}"

← Older revision		Revision as of 05:09, 1 September 2019
Line 93:		Line 93:
	* https://puppet.com/docs/puppet/5.3/environments_about.html		* https://puppet.com/docs/puppet/5.3/environments_about.html

	[[Category:Linux]]{{Navbox Linux}}		[[Category:Linux]]{{Navbox Linux}}{{Navbox Linux}}

Leo: /* See Also */

2019-09-01T02:13:38Z

Leo at 17:50, 15 June 2018

2018-06-15T17:50:27Z

← Older revision		Revision as of 17:50, 15 June 2018
Line 63:		Line 63:

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

			Once a node has been accepted, configs can be pulled by the node by running:
			{{highlight\|lang=terminal\|code=
			# puppet agent -t
			}}

	== Terminology ==		== Terminology ==

← Older revision		Revision as of 02:13, 1 September 2019
Line 92:		Line 92:
	* https://puppet.com/docs/puppet/5.3/modules_fundamentals.html		* https://puppet.com/docs/puppet/5.3/modules_fundamentals.html
	* https://puppet.com/docs/puppet/5.3/environments_about.html		* https://puppet.com/docs/puppet/5.3/environments_about.html

			[[Category:Linux]]{{Navbox Linux}}