87 lines
3.0 KiB
Markdown
87 lines
3.0 KiB
Markdown
|
---
|
||
|
|
layout: "docs"
|
||
|
|
---
|
||
|
|
|
||
|
|
# Templates: Provisioners
|
||
|
|
|
||
|
|
Within the template, the provisioners section contains an array of all the
|
||
|
|
provisioners that Packer should use to install and configure software within
|
||
|
|
running machines prior to turning them into machine images.
|
||
|
|
|
||
|
|
Provisioners are _optional_. If no provisioners are defined within a template,
|
||
|
|
then no software other than the defaults will be installed within the
|
||
|
|
resulting machine images. This is not typical, however, since much of the
|
||
|
|
value of Packer is to produce multiple identical images
|
||
|
|
of pre-configured software.
|
||
|
|
|
||
|
|
This documentation page will cover how to configure a provisioner in a template.
|
||
|
|
The specific configuration options available for each provisioner, however,
|
||
|
|
must be referenced from the documentation for that specific provisioner.
|
||
|
|
|
||
|
|
Within a template, a section of provisioner definitions looks like this:
|
||
|
|
|
||
|
|
<pre class="prettyprint">
|
||
|
|
{
|
||
|
|
"provisioners": [
|
||
|
|
... one or more provisioner definitions here ...
|
||
|
|
]
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
## Provisioner Definition
|
||
|
|
|
||
|
|
A provisioner definition is a JSON object that must contain at least
|
||
|
|
the `type` key. This key specifies the name of the provisioner to use.
|
||
|
|
Additional keys within the object are used to configure the provisioner,
|
||
|
|
with the exception of a handful of special keys, covered later.
|
||
|
|
|
||
|
|
As an example, the "shell" provisioner requires at least the `path` key,
|
||
|
|
which specifies a path to a shell script to execute within the machines
|
||
|
|
being created.
|
||
|
|
|
||
|
|
An example provisioner definition is shown below, configuring the shell
|
||
|
|
provisioner to run a local script within the machines:
|
||
|
|
|
||
|
|
<pre class="prettyprint">
|
||
|
|
{
|
||
|
|
"type": "shell",
|
||
|
|
"path": "script.sh"
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
## Build-Specific Overrides
|
||
|
|
|
||
|
|
While the goal of Packer is to produce identical machine images, it
|
||
|
|
sometimes requires periods of time where the machines are different before
|
||
|
|
they eventually converge to be identical. In these cases, different configurations
|
||
|
|
for provisioners may be necessary depending on the build. This can be done
|
||
|
|
using build-specific overrides.
|
||
|
|
|
||
|
|
An example of where this might be necessary is when building both an EC2 AMI
|
||
|
|
and a VMware machine. The source EC2 AMI may setup a user with administrative
|
||
|
|
privileges by default, whereas the VMware machine doesn't have these privileges.
|
||
|
|
In this case, the shell script may need to be executed differently. Of course,
|
||
|
|
the goal is that hopefully the shell script converges these two images to be
|
||
|
|
identical. However, they may initially need to be run differently.
|
||
|
|
|
||
|
|
This example is shown below:
|
||
|
|
|
||
|
|
<pre class="prettyprint">
|
||
|
|
{
|
||
|
|
"type": "shell",
|
||
|
|
"path": "script.sh",
|
||
|
|
|
||
|
|
"override": {
|
||
|
|
"vmware": {
|
||
|
|
"execute_command": "echo 'password' | sudo -S bash {{.Path}}"
|
||
|
|
}
|
||
|
|
}
|
||
|
|
}
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
As you can see, the `override` key is used. The value of this key is another
|
||
|
|
JSON object where the key is the name of a [builder definition](/docs/templates/builders.html).
|
||
|
|
The value of this is in turn another JSON object. This JSON object simply
|
||
|
|
contains the provisioner configuration as normal. This configuration is merged
|
||
|
|
into the default provisioner configuration.
|