github.com/amanya/packer@v0.12.1-0.20161117214323-902ac5ab2eb6/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  -   `puppet_bin_dir` (string) - The path to the binary for running `puppet apply`.
    90      Usually, this would be found via the `$PATH` or `%PATH%` environment variable,
    91      but some builders (notably, the Docker one) do not run profile-setup scripts,
    92      therefore the Path is usually empty.
    93  
    94  -   `module_paths` (array of strings) - This is an array of paths to module
    95      directories on your local filesystem. These will be uploaded to the
    96      remote machine. By default, this is empty.
    97  
    98  -   `prevent_sudo` (boolean) - By default, the configured commands that are
    99      executed to run Puppet are executed with `sudo`. If this is true, then the
   100      sudo will be omitted.
   101  
   102  -   `staging_directory` (string) - This is the directory where all the
   103      configuration of Puppet by Packer will be placed. By default this
   104      is "/tmp/packer-puppet-masterless". This directory doesn't need to exist but
   105      must have proper permissions so that the SSH user that Packer uses is able
   106      to create directories and write into this folder. If the permissions are not
   107      correct, use a shell provisioner prior to this to configure it properly.
   108  
   109  -   `working_directory` (string) - This is the directory from which the puppet
   110      command will be run. When using hiera with a relative path, this option
   111      allows to ensure that the paths are working properly. If not specified,
   112      defaults to the value of specified `staging_directory` (or its default value
   113      if not specified either).
   114  
   115  ## Execute Command
   116  
   117  By default, Packer uses the following command (broken across multiple lines for
   118  readability) to execute Puppet:
   119  
   120  ``` {.liquid}
   121  cd {{.WorkingDir}} && \
   122  {{.FacterVars}}{{if .Sudo}} sudo -E {{end}} \
   123  {{if ne .PuppetBinDir \"\"}}{{.PuppetBinDir}}{{end}}puppet apply \
   124    --verbose \
   125    --modulepath='{{.ModulePath}}' \
   126    {{if ne .HieraConfigPath ""}}--hiera_config='{{.HieraConfigPath}}' {{end}} \
   127    {{if ne .ManifestDir ""}}--manifestdir='{{.ManifestDir}}' {{end}} \
   128    --detailed-exitcodes \
   129    {{.ManifestFile}}
   130  ```
   131  
   132  This command can be customized using the `execute_command` configuration. As you
   133  can see from the default value above, the value of this configuration can
   134  contain various template variables, defined below:
   135  
   136  -   `WorkingDir` - The path from which Puppet will be executed.
   137  -   `FacterVars` - Shell-friendly string of environmental variables used to set
   138      custom facts configured for this provisioner.
   139  -   `HieraConfigPath` - The path to a hiera configuration file.
   140  -   `ManifestFile` - The path on the remote machine to the manifest file for
   141      Puppet to use.
   142  -   `ModulePath` - The paths to the module directories.
   143  -   `Sudo` - A boolean of whether to `sudo` the command or not, depending on the
   144      value of the `prevent_sudo` configuration.
   145  
   146  ## Default Facts
   147  
   148  In addition to being able to specify custom Facter facts using the `facter`
   149  configuration, the provisioner automatically defines certain commonly useful
   150  facts:
   151  
   152  -   `packer_build_name` is set to the name of the build that Packer is running.
   153      This is most useful when Packer is making multiple builds and you want to
   154      distinguish them in your Hiera hierarchy.
   155  
   156  -   `packer_builder_type` is the type of the builder that was used to create the
   157      machine that Puppet is running on. This is useful if you want to run only
   158      certain parts of your Puppet code on systems built with certain builders.