1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
|
---
description: |
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.
layout: docs
page_title: 'Puppet Masterless - Provisioners'
sidebar_current: '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](/docs/provisioners/shell.html) 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.
``` json
{
"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"](https://docs.puppetlabs.com/puppet/latest/reference/dirs_manifest.html)).
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](/docs/templates/engine.html) available. See
below for more information.
- `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".
- `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 the `execute_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](https://puppetlabs.com/facter) to make
available when Puppet is running.
- `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 the
`manifest_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.
- `puppet_bin_dir` (string) - The path to the directory that contains the puppet
binary for running `puppet 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.
- `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 with `sudo`. If this is true, then the
sudo will be omitted.
- `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 specified `staging_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}} &&
{{.FacterVars}} {{if .Sudo}} sudo -E {{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}} &&
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 to `sudo` the command or not, depending on the
value of the `prevent_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.
|