github.com/kimor79/packer@v0.8.7-0.20151221212622-d507b18eb4cf/website/source/docs/provisioners/puppet-masterless.html.markdown (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](http://puppetlabs.com/puppet/related-projects/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 - `manifest_dir` (string) - The path to a local directory with manifests to be 77 uploaded to the remote machine. This is useful if your main manifest file 78 uses imports. This directory doesn't necessarily contain the 79 `manifest_file`. It is a separate directory that will be set as the 80 "manifestdir" setting on Puppet. 81 82 \~> `manifest_dir` is passed to `puppet apply` as the `--manifestdir` option. 83 This option was deprecated in puppet 3.6, and removed in puppet 4.0. If you have 84 multiple manifests you should use `manifest_file` instead. 85 86 - `module_paths` (array of strings) - This is an array of paths to module 87 directories on your local filesystem. These will be uploaded to the 88 remote machine. By default, this is empty. 89 90 - `prevent_sudo` (boolean) - By default, the configured commands that are 91 executed to run Puppet are executed with `sudo`. If this is true, then the 92 sudo will be omitted. 93 94 - `staging_directory` (string) - This is the directory where all the 95 configuration of Puppet by Packer will be placed. By default this 96 is "/tmp/packer-puppet-masterless". This directory doesn't need to exist but 97 must have proper permissions so that the SSH user that Packer uses is able 98 to create directories and write into this folder. If the permissions are not 99 correct, use a shell provisioner prior to this to configure it properly. 100 101 - `working_directory` (string) - This is the directory from which the puppet 102 command will be run. When using hiera with a relative path, this option 103 allows to ensure that the paths are working properly. If not specified, 104 defaults to the value of specified `staging_directory` (or its default value 105 if not specified either). 106 107 ## Execute Command 108 109 By default, Packer uses the following command (broken across multiple lines for 110 readability) to execute Puppet: 111 112 ``` {.liquid} 113 cd {{.WorkingDir}} && \ 114 {{.FacterVars}}{{if .Sudo}} sudo -E {{end}}puppet apply \ 115 --verbose \ 116 --modulepath='{{.ModulePath}}' \ 117 {{if ne .HieraConfigPath ""}}--hiera_config='{{.HieraConfigPath}}' {{end}} \ 118 {{if ne .ManifestDir ""}}--manifestdir='{{.ManifestDir}}' {{end}} \ 119 --detailed-exitcodes \ 120 {{.ManifestFile}} 121 ``` 122 123 This command can be customized using the `execute_command` configuration. As you 124 can see from the default value above, the value of this configuration can 125 contain various template variables, defined below: 126 127 - `WorkingDir` - The path from which Puppet will be executed. 128 - `FacterVars` - Shell-friendly string of environmental variables used to set 129 custom facts configured for this provisioner. 130 - `HieraConfigPath` - The path to a hiera configuration file. 131 - `ManifestFile` - The path on the remote machine to the manifest file for 132 Puppet to use. 133 - `ModulePath` - The paths to the module directories. 134 - `Sudo` - A boolean of whether to `sudo` the command or not, depending on the 135 value of the `prevent_sudo` configuration. 136 137 ## Default Facts 138 139 In addition to being able to specify custom Facter facts using the `facter` 140 configuration, the provisioner automatically defines certain commonly useful 141 facts: 142 143 - `packer_build_name` is set to the name of the build that Packer is running. 144 This is most useful when Packer is making multiple builds and you want to 145 distinguish them in your Hiera hierarchy. 146 147 - `packer_builder_type` is the type of the builder that was used to create the 148 machine that Puppet is running on. This is useful if you want to run only 149 certain parts of your Puppet code on systems built with certain builders.