github.com/ratanraj/packer@v1.3.2/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
     5      manifests can be uploaded from your local machine to the remote machine or can
     6      simply use remote paths. Puppet is run in masterless mode, meaning it never
     7      communicates to a Puppet master.
     8  layout: docs
     9  page_title: 'Puppet Masterless - Provisioners'
    10  sidebar_current: 'docs-provisioners-puppet-masterless'
    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  ``` json
    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-line to execute Puppet. This also has
    58      various [configuration template variables](/docs/templates/engine.html) available.
    59  
    60  -   `extra_arguments` (array of strings) - Additional options to
    61      pass to the Puppet command. This allows for customization of  
    62      `execute_command` without having to completely replace
    63      or subsume its contents, making forward-compatible customizations much
    64      easier to maintain.
    65      
    66      This string is lazy-evaluated so one can incorporate logic driven by template variables as 
    67      well as private elements of ExecuteTemplate (see source: provisioner/puppet-masterless/provisioner.go).
    68  ```
    69  [
    70    {{if ne "{{user environment}}" ""}}--environment={{user environment}}{{end}},
    71    {{if ne ".ModulePath" ""}}--modulepath="{{.ModulePath}}{{.ModulePathJoiner}}$(puppet config print {{if ne "{{user `environment`}}" ""}}--environment={{user `environment`}}{{end}} modulepath)"{{end}}
    72  ]
    73  ```
    74  
    75  -   `facter` (object of key:value strings) - Additional
    76      [facts](https://puppetlabs.com/facter) to make
    77      available to the Puppet run.
    78  
    79  -   `guest_os_type` (string) - The remote host's OS type ('windows' or 'unix') to
    80      tailor command-line and path separators. (default: unix).
    81  
    82  -   `hiera_config_path` (string) - Local path to self-contained Hiera
    83      data to be uploaded. NOTE: If you need data directories
    84      they must be previously transferred with a File provisioner.
    85  
    86  -   `ignore_exit_codes` (boolean) - If true, Packer will ignore failures.
    87  
    88  -   `manifest_dir` (string) - Local directory with manifests to be
    89      uploaded. This is useful if your main manifest uses imports, but the
    90      directory might not contain the `manifest_file` itself.
    91  
    92  ~> `manifest_dir` is passed to Puppet as `--manifestdir` option.
    93  This option was deprecated in puppet 3.6, and removed in puppet 4.0. If you have
    94  multiple manifests you should use `manifest_file` instead.
    95  
    96  -   `module_paths` (array of strings) - Array of local module
    97      directories to be uploaded.
    98  
    99  -   `prevent_sudo` (boolean) - On Unix platforms Puppet is typically invoked with `sudo`. If true,
   100      it will be omitted. (default: false)
   101  
   102  -   `puppet_bin_dir` (string) - Path to the Puppet binary. Ideally the program
   103      should be on the system (unix: `$PATH`, windows: `%PATH%`), but some builders (eg. Docker) do
   104      not run profile-setup scripts and therefore PATH might be empty or minimal.
   105  
   106  -   `staging_directory` (string) - Directory to where uploaded files
   107      will be placed (unix: "/tmp/packer-puppet-masterless",
   108      windows: "%SYSTEMROOT%/Temp/packer-puppet-masterless").
   109      It doesn't need to pre-exist, but the parent must have permissions sufficient
   110      for the account Packer connects as to create directories and write files.
   111      Use a Shell provisioner to prepare the way if needed.
   112  
   113  -   `working_directory` (string) - Directory from which `execute_command` will be run.
   114      If using Hiera files with relative paths, this option can be helpful. (default: `staging_directory`)
   115  
   116  ## Execute Command
   117  
   118  By default, Packer uses the following command (broken across multiple lines for
   119  readability) to execute Puppet:
   120  
   121  ```
   122  cd {{.WorkingDir}} &&
   123  	{{if ne .FacterVars ""}}{{.FacterVars}} {{end}}
   124  	{{if .Sudo}}sudo -E {{end}}
   125  	{{if ne .PuppetBinDir ""}}{{.PuppetBinDir}}/{{end}}
   126    puppet apply --detailed-exitcodes
   127  	{{if .Debug}}--debug {{end}}
   128  	{{if ne .ModulePath ""}}--modulepath='{{.ModulePath}}' {{end}}
   129  	{{if ne .HieraConfigPath ""}}--hiera_config='{{.HieraConfigPath}}' {{end}}
   130  	{{if ne .ManifestDir ""}}--manifestdir='{{.ManifestDir}}' {{end}}
   131  	{{if ne .ExtraArguments ""}}{{.ExtraArguments}} {{end}}
   132  	{{.ManifestFile}}
   133  ```
   134  
   135  The following command is used if guest OS type is windows:
   136  
   137  ```
   138  cd {{.WorkingDir}} &&
   139  	{{if ne .FacterVars ""}}{{.FacterVars}} && {{end}}
   140  	{{if ne .PuppetBinDir ""}}{{.PuppetBinDir}}/{{end}}
   141    puppet apply --detailed-exitcodes
   142  	{{if .Debug}}--debug {{end}}
   143  	{{if ne .ModulePath ""}}--modulepath='{{.ModulePath}}' {{end}}
   144  	{{if ne .HieraConfigPath ""}}--hiera_config='{{.HieraConfigPath}}' {{end}}
   145  	{{if ne .ManifestDir ""}}--manifestdir='{{.ManifestDir}}' {{end}}
   146  	{{if ne .ExtraArguments ""}}{{.ExtraArguments}} {{end}}
   147  	{{.ManifestFile}}
   148  ```
   149  
   150  ## Default Facts
   151  
   152  In addition to being able to specify custom Facter facts using the `facter`
   153  configuration, the provisioner automatically defines certain commonly useful
   154  facts:
   155  
   156  -   `packer_build_name` is set to the name of the build that Packer is running.
   157      This is most useful when Packer is making multiple builds and you want to
   158      distinguish them in your Hiera hierarchy.
   159  
   160  -   `packer_builder_type` is the type of the builder that was used to create the
   161      machine that Puppet is running on. This is useful if you want to run only
   162      certain parts of your Puppet code on systems built with certain builders.