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.