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