github.com/phobos182/packer@v0.2.3-0.20130819023704-c84d2aeffc68/website/source/docs/templates/provisioners.html.markdown (about) 1 --- 2 layout: "docs" 3 --- 4 5 # Templates: Provisioners 6 7 Within the template, the provisioners section contains an array of all the 8 provisioners that Packer should use to install and configure software within 9 running machines prior to turning them into machine images. 10 11 Provisioners are _optional_. If no provisioners are defined within a template, 12 then no software other than the defaults will be installed within the 13 resulting machine images. This is not typical, however, since much of the 14 value of Packer is to produce multiple identical images 15 of pre-configured software. 16 17 This documentation page will cover how to configure a provisioner in a template. 18 The specific configuration options available for each provisioner, however, 19 must be referenced from the documentation for that specific provisioner. 20 21 Within a template, a section of provisioner definitions looks like this: 22 23 <pre class="prettyprint"> 24 { 25 "provisioners": [ 26 ... one or more provisioner definitions here ... 27 ] 28 } 29 </pre> 30 31 For each of the definitions, Packer will run the provisioner for each 32 of the configured builds. The provisioners will be run in the order 33 they are defined within the template. 34 35 ## Provisioner Definition 36 37 A provisioner definition is a JSON object that must contain at least 38 the `type` key. This key specifies the name of the provisioner to use. 39 Additional keys within the object are used to configure the provisioner, 40 with the exception of a handful of special keys, covered later. 41 42 As an example, the "shell" provisioner requires a key such as `script` 43 which specifies a path to a shell script to execute within the machines 44 being created. 45 46 An example provisioner definition is shown below, configuring the shell 47 provisioner to run a local script within the machines: 48 49 <pre class="prettyprint"> 50 { 51 "type": "shell", 52 "script": "script.sh" 53 } 54 </pre> 55 56 ## Build-Specific Overrides 57 58 While the goal of Packer is to produce identical machine images, it 59 sometimes requires periods of time where the machines are different before 60 they eventually converge to be identical. In these cases, different configurations 61 for provisioners may be necessary depending on the build. This can be done 62 using build-specific overrides. 63 64 An example of where this might be necessary is when building both an EC2 AMI 65 and a VMware machine. The source EC2 AMI may setup a user with administrative 66 privileges by default, whereas the VMware machine doesn't have these privileges. 67 In this case, the shell script may need to be executed differently. Of course, 68 the goal is that hopefully the shell script converges these two images to be 69 identical. However, they may initially need to be run differently. 70 71 This example is shown below: 72 73 <pre class="prettyprint"> 74 { 75 "type": "shell", 76 "script": "script.sh", 77 78 "override": { 79 "vmware": { 80 "execute_command": "echo 'password' | sudo -S bash {{.Path}}" 81 } 82 } 83 } 84 </pre> 85 86 As you can see, the `override` key is used. The value of this key is another 87 JSON object where the key is the name of a [builder definition](/docs/templates/builders.html). 88 The value of this is in turn another JSON object. This JSON object simply 89 contains the provisioner configuration as normal. This configuration is merged 90 into the default provisioner configuration.