7.5 KiB
description | layout | page_title | sidebar_current |
---|---|---|---|
The masterless Puppet Packer provisioner configures Puppet to run on the machines by Packer from local modules and manifest files. Modules and manifests can be uploaded from your local machine to the remote machine or can simply use remote paths. Puppet is run in masterless mode, meaning it never communicates to a Puppet master. | docs | Puppet Masterless - Provisioners | docs-provisioners-puppet-masterless |
Puppet (Masterless) Provisioner
Type: puppet-masterless
The masterless Puppet Packer provisioner configures Puppet to run on the machines by Packer from local modules and manifest files. Modules and manifests can be uploaded from your local machine to the remote machine or can simply use remote paths (perhaps obtained using something like the shell provisioner). Puppet is run in masterless mode, meaning it never communicates to a Puppet master.
-> Note: Puppet will not be installed automatically by this provisioner. This provisioner expects that Puppet is already installed on the machine. It is common practice to use the shell provisioner before the Puppet provisioner to do this.
Basic Example
The example below is fully functional and expects the configured manifest file to exist relative to your working directory.
{
"type": "puppet-masterless",
"manifest_file": "site.pp"
}
Configuration Reference
The reference of available configuration options is listed below.
Required parameters:
manifest_file
(string) - This is either a path to a puppet manifest (.pp
file) or a directory containing multiple manifests that puppet will apply (the "main manifest"). These file(s) must exist on your local system and will be uploaded to the remote machine.
Optional parameters:
-
execute_command
(string) - The command used to execute Puppet. This has various configuration template variables available. See below for more information. -
extra_arguments
(array of strings) - This is an array of additional options to pass to the puppet command when executing puppet. This allows for customization of theexecute_command
without having to completely replace or include it's contents, making forward-compatible customizations much easier. -
facter
(object of key/value strings) - Additional facts to make available when Puppet is running. -
guest_os_type
(string) - The target guest OS type, either "unix" or "windows". Setting this to "windows" will cause the provisioner to use Windows friendly paths and commands. By default, this is "unix". -
hiera_config_path
(string) - The path to a local file with hiera configuration to be uploaded to the remote machine. Hiera data directories must be uploaded using the file provisioner separately. -
ignore_exit_codes
(boolean) - If true, Packer will never consider the provisioner a failure. -
manifest_dir
(string) - The path to a local directory with manifests to be uploaded to the remote machine. This is useful if your main manifest file uses imports. This directory doesn't necessarily contain themanifest_file
. It is a separate directory that will be set as the "manifestdir" setting on Puppet.
~> manifest_dir
is passed to puppet apply
as the --manifestdir
option.
This option was deprecated in puppet 3.6, and removed in puppet 4.0. If you have
multiple manifests you should use manifest_file
instead.
-
module_paths
(array of strings) - This is an array of paths to module directories on your local filesystem. These will be uploaded to the remote machine. By default, this is empty. -
prevent_sudo
(boolean) - By default, the configured commands that are executed to run Puppet are executed withsudo
. If this is true, then the sudo will be omitted. -
puppet_bin_dir
(string) - The path to the directory that contains the puppet binary for runningpuppet apply
. Usually, this would be found via the$PATH
or%PATH%
environment variable, but some builders (notably, the Docker one) do not run profile-setup scripts, therefore the path is usually empty. -
staging_directory
(string) - This is the directory where all the configuration of Puppet by Packer will be placed. By default this is "/tmp/packer-puppet-masterless" when guest OS type is unix and "C:/Windows/Temp/packer-puppet-masterless" when windows. This directory doesn't need to exist but must have proper permissions so that the SSH user that Packer uses is able to create directories and write into this folder. If the permissions are not correct, use a shell provisioner prior to this to configure it properly. -
working_directory
(string) - This is the directory from which the puppet command will be run. When using hiera with a relative path, this option allows to ensure that the paths are working properly. If not specified, defaults to the value of specifiedstaging_directory
(or its default value if not specified either).
Execute Command
By default, Packer uses the following command (broken across multiple lines for readability) to execute Puppet:
cd {{.WorkingDir}} &&
{{if ne .FacterVars ""}}{{.FacterVars}} {{end}}
{{if .Sudo}}sudo -E {{end}}
{{if ne .PuppetBinDir ""}}{{.PuppetBinDir}}/{{end}}
puppet apply --verbose --modulepath='{{.ModulePath}}'
{{if ne .HieraConfigPath ""}}--hiera_config='{{.HieraConfigPath}}' {{end}}
{{if ne .ManifestDir ""}}--manifestdir='{{.ManifestDir}}' {{end}}
--detailed-exitcodes
{{if ne .ExtraArguments ""}}{{.ExtraArguments}} {{end}}
{{.ManifestFile}}
The following command is used if guest OS type is windows:
cd {{.WorkingDir}} &&
{{.FacterVars}} &&
{{if ne .PuppetBinDir ""}}{{.PuppetBinDir}}/{{end}}
puppet apply --verbose --modulepath='{{.ModulePath}}'
{{if ne .HieraConfigPath ""}}--hiera_config='{{.HieraConfigPath}}' {{end}}
{{if ne .ManifestDir ""}}--manifestdir='{{.ManifestDir}}' {{end}}
--detailed-exitcodes
{{if ne .ExtraArguments ""}}{{.ExtraArguments}} {{end}}
{{.ManifestFile}}
This command can be customized using the execute_command
configuration. As you
can see from the default value above, the value of this configuration can
contain various template variables, defined below:
WorkingDir
- The path from which Puppet will be executed.FacterVars
- Shell-friendly string of environmental variables used to set custom facts configured for this provisioner.HieraConfigPath
- The path to a hiera configuration file.ManifestFile
- The path on the remote machine to the manifest file for Puppet to use.ModulePath
- The paths to the module directories.Sudo
- A boolean of whether tosudo
the command or not, depending on the value of theprevent_sudo
configuration.
Default Facts
In addition to being able to specify custom Facter facts using the facter
configuration, the provisioner automatically defines certain commonly useful
facts:
-
packer_build_name
is set to the name of the build that Packer is running. This is most useful when Packer is making multiple builds and you want to distinguish them in your Hiera hierarchy. -
packer_builder_type
is the type of the builder that was used to create the machine that Puppet is running on. This is useful if you want to run only certain parts of your Puppet code on systems built with certain builders.