github.com/raghuse92/packer@v1.3.2/website/source/docs/templates/provisioners.html.md (about) 1 --- 2 description: | 3 Within the template, the provisioners section contains an array of all the 4 provisioners that Packer should use to install and configure software within 5 running machines prior to turning them into machine images. 6 layout: docs 7 page_title: 'Provisioners - Templates' 8 sidebar_current: 'docs-templates-provisioners' 9 --- 10 11 # Template Provisioners 12 13 Within the template, the provisioners section contains an array of all the 14 provisioners that Packer should use to install and configure software within 15 running machines prior to turning them into machine images. 16 17 Provisioners are *optional*. If no provisioners are defined within a template, 18 then no software other than the defaults will be installed within the resulting 19 machine images. This is not typical, however, since much of the value of Packer 20 is to produce multiple identical images of pre-configured software. 21 22 This documentation page will cover how to configure a provisioner in a template. 23 The specific configuration options available for each provisioner, however, must 24 be referenced from the documentation for that specific provisioner. 25 26 Within a template, a section of provisioner definitions looks like this: 27 28 ``` json 29 { 30 "provisioners": [ 31 // ... one or more provisioner definitions here 32 ] 33 } 34 ``` 35 36 For each of the definitions, Packer will run the provisioner for each of the 37 configured builds. The provisioners will be run in the order they are defined 38 within the template. 39 40 ## Provisioner Definition 41 42 A provisioner definition is a JSON object that must contain at least the `type` 43 key. This key specifies the name of the provisioner to use. Additional keys 44 within the object are used to configure the provisioner, with the exception of a 45 handful of special keys, covered later. 46 47 As an example, the "shell" provisioner requires a key such as `script` which 48 specifies a path to a shell script to execute within the machines being created. 49 50 An example provisioner definition is shown below, configuring the shell 51 provisioner to run a local script within the machines: 52 53 ``` json 54 { 55 "type": "shell", 56 "script": "script.sh" 57 } 58 ``` 59 60 ## Run on Specific Builds 61 62 You can use the `only` or `except` configurations to run a provisioner only with 63 specific builds. These two configurations do what you expect: `only` will only 64 run the provisioner on the specified builds and `except` will run the 65 provisioner on anything other than the specified builds. 66 67 An example of `only` being used is shown below, but the usage of `except` is 68 effectively the same: 69 70 ``` json 71 { 72 "type": "shell", 73 "script": "script.sh", 74 "only": ["virtualbox-iso"] 75 } 76 ``` 77 78 The values within `only` or `except` are *build names*, not builder types. If 79 you recall, build names by default are just their builder type, but if you 80 specify a custom `name` parameter, then you should use that as the value instead 81 of the type. 82 83 ## Build-Specific Overrides 84 85 While the goal of Packer is to produce identical machine images, it sometimes 86 requires periods of time where the machines are different before they eventually 87 converge to be identical. In these cases, different configurations for 88 provisioners may be necessary depending on the build. This can be done using 89 build-specific overrides. 90 91 An example of where this might be necessary is when building both an EC2 AMI and 92 a VMware machine. The source EC2 AMI may setup a user with administrative 93 privileges by default, whereas the VMware machine doesn't have these privileges. 94 In this case, the shell script may need to be executed differently. Of course, 95 the goal is that hopefully the shell script converges these two images to be 96 identical. However, they may initially need to be run differently. 97 98 This example is shown below: 99 100 ``` json 101 { 102 "type": "shell", 103 "script": "script.sh", 104 "override": { 105 "vmware-iso": { 106 "execute_command": "echo 'password' | sudo -S bash {{.Path}}" 107 } 108 } 109 } 110 ``` 111 112 As you can see, the `override` key is used. The value of this key is another 113 JSON object where the key is the name of a [builder 114 definition](/docs/templates/builders.html). The value of this is in turn another 115 JSON object. This JSON object simply contains the provisioner configuration as 116 normal. This configuration is merged into the default provisioner configuration. 117 118 ## Pausing Before Running 119 120 With certain provisioners it is sometimes desirable to pause for some period of 121 time before running it. Specifically, in cases where a provisioner reboots the 122 machine, you may want to wait for some period of time before starting the next 123 provisioner. 124 125 Every provisioner definition in a Packer template can take a special 126 configuration `pause_before` that is the amount of time to pause before running 127 that provisioner. By default, there is no pause. An example is shown below: 128 129 ``` json 130 { 131 "type": "shell", 132 "script": "script.sh", 133 "pause_before": "10s" 134 } 135 ``` 136 137 For the above provisioner, Packer will wait 10 seconds before uploading and 138 executing the shell script.