---
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_title: 'Puppet Masterless'
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-line to execute Puppet. This is a
  [template engine](/docs/templates/engine.html). Therefore, you
  may use user variables and template functions in this field. In addition,
  you may use the following extra variables:
  - FacterVars: Additional facts to set when executing Puppet, joined for
    use in a command. This is internal and not settable by the user.
  - HieraConfigPath: Path to a hiera configuration file to upload and use;
    set in the template option hiera_config_path
  - ManifestDir: The directory of the manifest file on the remote machine.
  - ManifestFile: The manifest file on the remote machine.
  - ModulePath: The module_paths, combined into one path variable.
  - ModulePathJoiner: A colon `:` on posix systems and a semicolon `;` on
    Windows.
  - PuppetBinDir: The directory that the Puppet binary is in.
  - Sudo: Returns false when PreventSudo is set, and true when it is not.
  - WorkingDir: The value provided in the `working_directory` option.
    See below for `execute_command`'s default value.

* `extra_arguments` (array of strings) - Additional options to pass to the
  Puppet command. This allows for customization of
  `execute_command` without having to completely replace or subsume its
  contents, making forward-compatible customizations much easier to maintain.

  This string is lazy-evaluated so one can incorporate logic driven by
  template variables as well as private elements of ExecuteTemplate (see
  source: provisioner/puppet-masterless/provisioner.go).

  ```text
  [
    {{if ne "{{user environment}}" ""}}--environment={{user environment}}{{end}},
    {{if ne ".ModulePath" ""}}--modulepath="{{.ModulePath}}{{.ModulePathJoiner}}$(puppet config print {{if ne "{{user `environment`}}" ""}}--environment={{user `environment`}}{{end}} modulepath)"{{end}}
  ]
  ```

* `facter` (object of key:value strings) - Additional
  [facts](https://docs.puppet.com/facter/) to make available to the Puppet
  run.

* `guest_os_type` (string) - The remote host's OS type ('windows' or 'unix')
  to tailor command-line and path separators. (default: unix).

* `hiera_config_path` (string) - Local path to self-contained Hiera data to
  be uploaded. NOTE: If you need data directories they must be previously
  transferred with a File provisioner.

* `ignore_exit_codes` (boolean) - If true, Packer will ignore failures.

* `manifest_dir` (string) - Local directory with manifests to be uploaded.
  This is useful if your main manifest uses imports, but the directory might
  not contain the `manifest_file` itself.

~> `manifest_dir` is passed to Puppet as `--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) - Array of local module directories to be
  uploaded.

- `prevent_sudo` (boolean) - On Unix platforms Puppet is typically invoked
  with `sudo`. If true, it will be omitted. (default: false)

- `puppet_bin_dir` (string) - Path to the Puppet binary. Ideally the program
  should be on the system (unix: `$PATH`, windows: `%PATH%`), but some
  builders (eg. Docker) do not run profile-setup scripts and therefore PATH
  might be empty or minimal. On Windows, spaces should be `^`-escaped, i.e.
  `c:/program^ files/puppet^ labs/puppet/bin`.

- `staging_directory` (string) - Directory to where uploaded files will be
  placed (unix: "/tmp/packer-puppet-masterless", windows:
  "%SYSTEMROOT%/Temp/packer-puppet-masterless"). It doesn't need to
  pre-exist, but the parent must have permissions sufficient for the account
  Packer connects as to create directories and write files. Use a Shell
  provisioner to prepare the way if needed.

- `working_directory` (string) - Directory from which `execute_command` will
  be run. If using Hiera files with relative paths, this option can be
  helpful. (default: `staging_directory`)

- `elevated_user` and `elevated_password` (string) - If specified, Puppet
  will be run with elevated privileges using the given Windows user. See the
  [powershell](/docs/provisioners/powershell.html) provisioner for the full
  details. This is a [template engine](/docs/templates/engine.html).
  Therefore, you may use user variables and template functions in this
  field, including `` {{ build `Password`}} `` to use the password being used
  by the communicator to connect to your instance.

@include 'provisioners/common-config.mdx'

## Execute Command

By default, Packer uses the following command (broken across multiple lines for
readability) to execute Puppet:

```shell
cd {{.WorkingDir}} &&
    {{if ne .FacterVars ""}}{{.FacterVars}} {{end}}
    {{if .Sudo}}sudo -E {{end}}
    {{if ne .PuppetBinDir ""}}{{.PuppetBinDir}}/{{end}}
  puppet apply --detailed-exitcodes
    {{if .Debug}}--debug {{end}}
    {{if ne .ModulePath ""}}--modulepath='{{.ModulePath}}' {{end}}
    {{if ne .HieraConfigPath ""}}--hiera_config='{{.HieraConfigPath}}' {{end}}
    {{if ne .ManifestDir ""}}--manifestdir='{{.ManifestDir}}' {{end}}
    {{if ne .ExtraArguments ""}}{{.ExtraArguments}} {{end}}
    {{.ManifestFile}}
```

The following command is used if guest OS type is windows:

```shell
cd {{.WorkingDir}} &&
    {{if ne .FacterVars ""}}{{.FacterVars}} && {{end}}
    {{if ne .PuppetBinDir ""}}{{.PuppetBinDir}}/{{end}}
  puppet apply --detailed-exitcodes
    {{if .Debug}}--debug {{end}}
    {{if ne .ModulePath ""}}--modulepath='{{.ModulePath}}' {{end}}
    {{if ne .HieraConfigPath ""}}--hiera_config='{{.HieraConfigPath}}' {{end}}
    {{if ne .ManifestDir ""}}--manifestdir='{{.ManifestDir}}' {{end}}
    {{if ne .ExtraArguments ""}}{{.ExtraArguments}} {{end}}
    {{.ManifestFile}}
```

## 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.