github.com/phobos182/packer@v0.2.3-0.20130819023704-c84d2aeffc68/website/source/docs/extend/plugins.html.markdown (about)

     1  ---
     2  layout: "docs"
     3  page_title: "Packer Plugins - Extend Packer"
     4  ---
     5  
     6  # Packer Plugins
     7  
     8  Plugins allow new functionality to be added to Packer without
     9  modifying the core source code. Packer plugins are able to add new
    10  commands, builders, provisioners, hooks, and more. In fact, much of Packer
    11  itself is implemented by writing plugins that are simply distributed with
    12  Packer. For example, all the commands, builders, provisioners, and more
    13  that ship with Packer are implemented as Plugins that are simply hardcoded
    14  to load with Packer.
    15  
    16  This page will cover how to install and use plugins. If you're interested
    17  in developing plugins, the documentation for that is available the
    18  [developing plugins](/docs/extend/developing-plugins.html) page.
    19  
    20  Because Packer is so young, there is no official listing of available
    21  Packer plugins. Plugins are best found via Google. Typically, searching
    22  "packer plugin _x_" will find what you're looking for if it exists. As
    23  Packer gets older, an official plugin directory is planned.
    24  
    25  ## How Plugins Work
    26  
    27  Packer plugins are completely separate, standalone applications that the
    28  core of Packer starts and communicates with.
    29  
    30  These plugin applications aren't meant to be run manually. Instead, Packer core executes
    31  these plugin applications in a certain way and communicates with them.
    32  For example, the VMware builder is actually a standalone binary named
    33  `packer-builder-vmware`. The next time you run a Packer build, look at
    34  your process list and you should see a handful of `packer-` prefixed
    35  applications running.
    36  
    37  ## Installing Plugins
    38  
    39  Plugins are installed by modifying the [core Packer configuration](/docs/other/core-configuration.html). Within
    40  the core configuration, each component has a key/value mapping of the
    41  plugin name to the actual plugin binary.
    42  
    43  For example, if we're adding a new builder for CustomCloud, the core
    44  Packer configuration may look like this:
    45  
    46  <pre class="prettyprint">
    47  {
    48    "builders": {
    49      "custom-cloud": "packer-builder-custom-cloud"
    50    }
    51  }
    52  </pre>
    53  
    54  In this case, the "custom-cloud" type is the type that is actually used for the value
    55  of the "type" configuration key for the builder definition.
    56  
    57  The value, "packer-builder-custom-cloud", is the path to the plugin binary.
    58  It can be an absolute or relative path. If it is not an absolute path, then
    59  the binary is searched for on the PATH. In the example above, Packer will
    60  search for `packer-builder-custom-cloud` on the PATH.
    61  
    62  After adding the plugin to the core Packer configuration, it is immediately
    63  available on the next run of Packer. To uninstall a plugin, just remove it
    64  from the core Packer configuration.
    65  
    66  In addition to builders, other types of plugins can be installed. The full
    67  list is below:
    68  
    69  * `builders` - A key/value pair of builder type to the builder plugin
    70    application.
    71  
    72  * `commands` - A key/value pair of the command name to the command plugin
    73    application. The command name is what is executed on the command line, like
    74    `packer COMMAND`.
    75  
    76  * `provisioners` - A key/value pair of the provisioner type to the
    77    provisioner plugin application. The provisioner type is the value of the
    78    "type" configuration used within templates.