github.com/renier/terraform@v0.7.8-0.20161024133817-eb8a9ef5471a/website/source/docs/configuration/resources.html.md (about) 1 --- 2 layout: "docs" 3 page_title: "Configuring Resources" 4 sidebar_current: "docs-config-resources" 5 description: |- 6 The most important thing you'll configure with Terraform are resources. Resources are a component of your infrastructure. It might be some low level component such as a physical server, virtual machine, or container. Or it can be a higher level component such as an email provider, DNS record, or database provider. 7 --- 8 9 # Resource Configuration 10 11 The most important thing you'll configure with Terraform are 12 resources. Resources are a component of your infrastructure. 13 It might be some low level component such as a physical server, 14 virtual machine, or container. Or it can be a higher level 15 component such as an email provider, DNS record, or database 16 provider. 17 18 This page assumes you're familiar with the 19 [configuration syntax](/docs/configuration/syntax.html) 20 already. 21 22 ## Example 23 24 A resource configuration looks like the following: 25 26 ``` 27 resource "aws_instance" "web" { 28 ami = "ami-408c7f28" 29 instance_type = "t1.micro" 30 } 31 ``` 32 33 ## Description 34 35 The `resource` block creates a resource of the given `TYPE` (first 36 parameter) and `NAME` (second parameter). The combination of the type 37 and name must be unique. 38 39 Within the block (the `{ }`) is configuration for the resource. The 40 configuration is dependent on the type, and is documented for each 41 resource type in the 42 [providers section](/docs/providers/index.html). 43 44 ### Meta-parameters 45 46 There are **meta-parameters** available to all resources: 47 48 * `count` (int) - The number of identical resources to create. 49 This doesn't apply to all resources. For details on using variables in 50 conjunction with count, see [Using Variables with 51 `count`](#using-variables-with-count) below. 52 53 * `depends_on` (list of strings) - Explicit dependencies that this 54 resource has. These dependencies will be created before this 55 resource. The dependencies are in the format of `TYPE.NAME`, 56 for example `aws_instance.web`. 57 58 * `lifecycle` (configuration block) - Customizes the lifecycle 59 behavior of the resource. The specific options are documented 60 below. 61 62 The `lifecycle` block allows the following keys to be set: 63 64 * `create_before_destroy` (bool) - This flag is used to ensure 65 the replacement of a resource is created before the original 66 instance is destroyed. As an example, this can be used to 67 create an new DNS record before removing an old record. 68 69 * `prevent_destroy` (bool) - This flag provides extra protection against the 70 destruction of a given resource. When this is set to `true`, any plan 71 that includes a destroy of this resource will return an error message. 72 73 <a id="ignore-changes"></a> 74 75 * `ignore_changes` (list of strings) - Customizes how diffs are evaluated for 76 resources, allowing individual attributes to be ignored through changes. 77 As an example, this can be used to ignore dynamic changes to the 78 resource from external resources. Other meta-parameters cannot be ignored. 79 80 ~> **NOTE on create\_before\_destroy and dependencies:** Resources that utilize 81 the `create_before_destroy` key can only depend on other resources that also 82 include `create_before_destroy`. Referencing a resource that does not include 83 `create_before_destroy` will result in a dependency graph cycle. 84 85 ~> **NOTE on ignore\_changes:** Ignored attribute names can be matched by their 86 name, not state ID. For example, if an `aws_route_table` has two routes defined 87 and the `ignore_changes` list contains "route", both routes will be ignored. 88 Additionally you can also use a single entry with a wildcard (e.g. `"*"`) 89 which will match all attribute names. Using a partial string together with a 90 wildcard (e.g. `"rout*"`) is **not** supported. 91 92 93 ### Connection block 94 95 Within a resource, you can optionally have a **connection block**. 96 Connection blocks describe to Terraform how to connect to the 97 resource for 98 [provisioning](/docs/provisioners/index.html). This block doesn't 99 need to be present if you're using only local provisioners, or 100 if you're not provisioning at all. 101 102 Resources provide some data on their own, such as an IP address, 103 but other data must be specified by the user. 104 105 The full list of settings that can be specified are listed on 106 the [provisioner connection page](/docs/provisioners/connection.html). 107 108 ### Provisioners 109 110 Within a resource, you can specify zero or more **provisioner 111 blocks**. Provisioner blocks configure 112 [provisioners](/docs/provisioners/index.html). 113 114 Within the provisioner block is provisioner-specific configuration, 115 much like resource-specific configuration. 116 117 Provisioner blocks can also contain a connection block 118 (documented above). This connection block can be used to 119 provide more specific connection info for a specific provisioner. 120 An example use case might be to use a different user to log in 121 for a single provisioner. 122 123 <a id="using-variables-with-count"></a> 124 125 ## Using Variables With `count` 126 127 When declaring multiple instances of a resource using [`count`](#count), it is 128 common to want each instance to have a different value for a given attribute. 129 130 You can use the `${count.index}` 131 [interpolation](/docs/configuration/interpolation.html) along with a map 132 [variable](/docs/configuration/variables.html) to accomplish this. 133 134 For example, here's how you could create three [AWS 135 Instances](/docs/providers/aws/r/instance.html) each with their own 136 static IP address: 137 138 ``` 139 variable "instance_ips" { 140 default = { 141 "0" = "10.11.12.100" 142 "1" = "10.11.12.101" 143 "2" = "10.11.12.102" 144 } 145 } 146 147 resource "aws_instance" "app" { 148 count = "3" 149 private_ip = "${lookup(var.instance_ips, count.index)}" 150 # ... 151 } 152 ``` 153 154 ## Multiple Provider Instances 155 156 By default, a resource targets the provider based on its type. For example 157 an `aws_instance` resource will target the "aws" provider. As of Terraform 158 0.5.0, a resource can target any provider by name. 159 160 The primary use case for this is to target a specific configuration of 161 a provider that is configured multiple times to support multiple regions, etc. 162 163 To target another provider, set the `provider` field: 164 165 ``` 166 resource "aws_instance" "foo" { 167 provider = "aws.west" 168 169 # ... 170 } 171 ``` 172 173 The value of the field should be `TYPE` or `TYPE.ALIAS`. The `ALIAS` value 174 comes from the `alias` field value when configuring the 175 [provider](/docs/configuration/providers.html). 176 177 ``` 178 provider "aws" { 179 alias = "west" 180 181 # ... 182 } 183 ``` 184 185 If no `provider` field is specified, the default provider is used. 186 187 ## Syntax 188 189 The full syntax is: 190 191 ``` 192 resource TYPE NAME { 193 CONFIG ... 194 [count = COUNT] 195 [depends_on = [RESOURCE NAME, ...]] 196 [provider = PROVIDER] 197 198 [LIFECYCLE] 199 200 [CONNECTION] 201 [PROVISIONER ...] 202 } 203 ``` 204 205 where `CONFIG` is: 206 207 ``` 208 KEY = VALUE 209 210 KEY { 211 CONFIG 212 } 213 ``` 214 215 where `LIFECYCLE` is: 216 217 ``` 218 lifecycle { 219 [create_before_destroy = true|false] 220 [prevent_destroy = true|false] 221 [ignore_changes = [ATTRIBUTE NAME, ...]] 222 } 223 ``` 224 225 where `CONNECTION` is: 226 227 ``` 228 connection { 229 KEY = VALUE 230 ... 231 } 232 ``` 233 234 where `PROVISIONER` is: 235 236 ``` 237 provisioner NAME { 238 CONFIG ... 239 240 [CONNECTION] 241 } 242 ```