github.com/kikitux/packer@v0.10.1-0.20160322154024-6237df566f9f/website/source/docs/provisioners/puppet-masterless.html.md (about) 1 --- 2 description: | 3 The masterless Puppet Packer provisioner configures Puppet to run on the 4 machines by Packer from local modules and manifest files. Modules and manifests 5 can be uploaded from your local machine to the remote machine or can simply use 6 remote paths (perhaps obtained using something like the shell provisioner). 7 Puppet is run in masterless mode, meaning it never communicates to a Puppet 8 master. 9 layout: docs 10 page_title: 'Puppet (Masterless) Provisioner' 11 ... 12 13 # Puppet (Masterless) Provisioner 14 15 Type: `puppet-masterless` 16 17 The masterless Puppet Packer provisioner configures Puppet to run on the 18 machines by Packer from local modules and manifest files. Modules and manifests 19 can be uploaded from your local machine to the remote machine or can simply use 20 remote paths (perhaps obtained using something like the shell provisioner). 21 Puppet is run in masterless mode, meaning it never communicates to a Puppet 22 master. 23 24 -> **Note:** Puppet will *not* be installed automatically by this 25 provisioner. This provisioner expects that Puppet is already installed on the 26 machine. It is common practice to use the [shell 27 provisioner](/docs/provisioners/shell.html) before the Puppet provisioner to do 28 this. 29 30 ## Basic Example 31 32 The example below is fully functional and expects the configured manifest file 33 to exist relative to your working directory: 34 35 ``` {.javascript} 36 { 37 "type": "puppet-masterless", 38 "manifest_file": "site.pp" 39 } 40 ``` 41 42 ## Configuration Reference 43 44 The reference of available configuration options is listed below. 45 46 Required parameters: 47 48 - `manifest_file` (string) - This is either a path to a puppet manifest 49 (`.pp` file) *or* a directory containing multiple manifests that puppet will 50 apply (the ["main 51 manifest"](https://docs.puppetlabs.com/puppet/latest/reference/dirs_manifest.html)). 52 These file(s) must exist on your local system and will be uploaded to the 53 remote machine. 54 55 Optional parameters: 56 57 - `execute_command` (string) - The command used to execute Puppet. This has 58 various [configuration template 59 variables](/docs/templates/configuration-templates.html) available. See 60 below for more information. 61 62 - `extra_arguments` (array of strings) - This is an array of additional options to 63 pass to the puppet command when executing puppet. This allows for 64 customization of the `execute_command` without having to completely replace 65 or include it's contents, making forward-compatible customizations much 66 easier. 67 68 - `facter` (object of key/value strings) - Additional 69 [facts](https://puppetlabs.com/facter) to make 70 available when Puppet is running. 71 72 - `hiera_config_path` (string) - The path to a local file with hiera 73 configuration to be uploaded to the remote machine. Hiera data directories 74 must be uploaded using the file provisioner separately. 75 76 - `ignore_exit_codes` (boolean) - If true, Packer will never consider the 77 provisioner a failure. 78 79 - `manifest_dir` (string) - The path to a local directory with manifests to be 80 uploaded to the remote machine. This is useful if your main manifest file 81 uses imports. This directory doesn't necessarily contain the 82 `manifest_file`. It is a separate directory that will be set as the 83 "manifestdir" setting on Puppet. 84 85 \~> `manifest_dir` is passed to `puppet apply` as the `--manifestdir` option. 86 This option was deprecated in puppet 3.6, and removed in puppet 4.0. If you have 87 multiple manifests you should use `manifest_file` instead. 88 89 - `module_paths` (array of strings) - This is an array of paths to module 90 directories on your local filesystem. These will be uploaded to the 91 remote machine. By default, this is empty. 92 93 - `prevent_sudo` (boolean) - By default, the configured commands that are 94 executed to run Puppet are executed with `sudo`. If this is true, then the 95 sudo will be omitted. 96 97 - `staging_directory` (string) - This is the directory where all the 98 configuration of Puppet by Packer will be placed. By default this 99 is "/tmp/packer-puppet-masterless". This directory doesn't need to exist but 100 must have proper permissions so that the SSH user that Packer uses is able 101 to create directories and write into this folder. If the permissions are not 102 correct, use a shell provisioner prior to this to configure it properly. 103 104 - `working_directory` (string) - This is the directory from which the puppet 105 command will be run. When using hiera with a relative path, this option 106 allows to ensure that the paths are working properly. If not specified, 107 defaults to the value of specified `staging_directory` (or its default value 108 if not specified either). 109 110 ## Execute Command 111 112 By default, Packer uses the following command (broken across multiple lines for 113 readability) to execute Puppet: 114 115 ``` {.liquid} 116 cd {{.WorkingDir}} && \ 117 {{.FacterVars}}{{if .Sudo}} sudo -E {{end}}puppet apply \ 118 --verbose \ 119 --modulepath='{{.ModulePath}}' \ 120 {{if ne .HieraConfigPath ""}}--hiera_config='{{.HieraConfigPath}}' {{end}} \ 121 {{if ne .ManifestDir ""}}--manifestdir='{{.ManifestDir}}' {{end}} \ 122 --detailed-exitcodes \ 123 {{.ManifestFile}} 124 ``` 125 126 This command can be customized using the `execute_command` configuration. As you 127 can see from the default value above, the value of this configuration can 128 contain various template variables, defined below: 129 130 - `WorkingDir` - The path from which Puppet will be executed. 131 - `FacterVars` - Shell-friendly string of environmental variables used to set 132 custom facts configured for this provisioner. 133 - `HieraConfigPath` - The path to a hiera configuration file. 134 - `ManifestFile` - The path on the remote machine to the manifest file for 135 Puppet to use. 136 - `ModulePath` - The paths to the module directories. 137 - `Sudo` - A boolean of whether to `sudo` the command or not, depending on the 138 value of the `prevent_sudo` configuration. 139 140 ## Default Facts 141 142 In addition to being able to specify custom Facter facts using the `facter` 143 configuration, the provisioner automatically defines certain commonly useful 144 facts: 145 146 - `packer_build_name` is set to the name of the build that Packer is running. 147 This is most useful when Packer is making multiple builds and you want to 148 distinguish them in your Hiera hierarchy. 149 150 - `packer_builder_type` is the type of the builder that was used to create the 151 machine that Puppet is running on. This is useful if you want to run only 152 certain parts of your Puppet code on systems built with certain builders.