From d28e5a16389f241b6509369357925a437512811a Mon Sep 17 00:00:00 2001 From: Mitchell Hashimoto Date: Mon, 28 Jul 2014 10:43:00 -0700 Subject: [PATCH] dos2unix --- .gitignore | 34 +- .../apply-config-invalid/main.tf | 6 +- command/test-fixtures/apply-error/main.tf | 14 +- command/test-fixtures/apply-shutdown/main.tf | 14 +- command/test-fixtures/apply-vars/main.tf | 10 +- command/test-fixtures/apply/main.tf | 6 +- command/test-fixtures/graph/main.tf | 6 +- command/test-fixtures/plan-vars/main.tf | 10 +- command/test-fixtures/plan/main.tf | 18 +- command/test-fixtures/refresh-var/main.tf | 14 +- command/test-fixtures/refresh/main.tf | 6 +- config/test-fixtures/bad_type.tf.nope | 2 +- config/test-fixtures/basic.tf.json | 106 ++--- config/test-fixtures/connection.tf | 46 +- config/test-fixtures/dir-basic/README.md | 4 +- .../test-fixtures/dir-basic/nested/nested.tf | 6 +- config/test-fixtures/dir-basic/one.tf | 34 +- config/test-fixtures/dir-basic/two.tf | 40 +- config/test-fixtures/dir-merge/one.tf | 16 +- config/test-fixtures/dir-merge/two.tf | 4 +- .../dir-override/foo_override.tf.json | 18 +- config/test-fixtures/dir-override/one.tf | 34 +- .../dir-override/override.tf.json | 20 +- config/test-fixtures/dir-override/two.tf | 40 +- config/test-fixtures/import/one.tf | 14 +- config/test-fixtures/provisioners.tf | 22 +- .../validate-bad-depends-on/main.tf | 6 +- .../validate-bad-multi-resource/main.tf | 14 +- .../validate-count-below-zero/main.tf | 6 +- .../test-fixtures/validate-count-zero/main.tf | 6 +- .../validate-dup-resource/main.tf | 14 +- config/test-fixtures/validate-good/main.tf | 74 +-- .../validate-output-bad-field/main.tf | 14 +- .../main.tf | 12 +- .../validate-unknown-resource-var/main.tf | 12 +- .../validate-unknownthing/main.tf | 2 +- .../test-fixtures/validate-unknownvar/main.tf | 16 +- .../validate-var-default-bad-type/main.tf | 6 +- .../validate-var-default/main.tf | 18 +- config/test-fixtures/variables.tf | 14 +- helper/README.md | 14 +- terraform/test-fixtures/apply-cancel/main.tf | 14 +- .../apply-destroy-outputs/main.tf | 28 +- terraform/test-fixtures/apply-destroy/main.tf | 20 +- terraform/test-fixtures/apply-error/main.tf | 14 +- terraform/test-fixtures/apply-good/main.tf | 14 +- terraform/test-fixtures/apply-idattr/main.tf | 4 +- .../apply-output-multi-index/main.tf | 24 +- .../test-fixtures/apply-output-multi/main.tf | 24 +- terraform/test-fixtures/apply-output/main.tf | 22 +- .../apply-provisioner-fail/main.tf | 14 +- .../apply-provisioner-resource-ref/main.tf | 14 +- terraform/test-fixtures/apply-taint/main.tf | 8 +- terraform/test-fixtures/apply-unknown/main.tf | 8 +- terraform/test-fixtures/apply-vars/main.tf | 46 +- terraform/test-fixtures/graph-basic/main.tf | 48 +- terraform/test-fixtures/graph-count/main.tf | 14 +- terraform/test-fixtures/graph-cycle/main.tf | 36 +- .../test-fixtures/graph-depends-on/main.tf | 10 +- .../test-fixtures/graph-diff-destroy/main.tf | 16 +- terraform/test-fixtures/graph-diff/main.tf | 4 +- .../test-fixtures/graph-provisioners/main.tf | 64 +-- terraform/test-fixtures/new-good/main.tf | 12 +- .../test-fixtures/new-graph-cycle/main.tf | 14 +- terraform/test-fixtures/new-pc-cache/main.tf | 24 +- .../new-provider-validate/main.tf | 10 +- terraform/test-fixtures/new-variables/main.tf | 8 +- terraform/test-fixtures/plan-computed/main.tf | 16 +- .../test-fixtures/plan-count-dec/main.tf | 14 +- .../test-fixtures/plan-count-inc/main.tf | 16 +- terraform/test-fixtures/plan-count/main.tf | 16 +- terraform/test-fixtures/plan-destroy/main.tf | 14 +- terraform/test-fixtures/plan-diffvar/main.tf | 14 +- terraform/test-fixtures/plan-empty/main.tf | 10 +- terraform/test-fixtures/plan-good/main.tf | 14 +- terraform/test-fixtures/plan-nil/main.tf | 6 +- terraform/test-fixtures/plan-orphan/main.tf | 6 +- .../test-fixtures/plan-provider-init/main.tf | 18 +- terraform/test-fixtures/plan-taint/main.tf | 14 +- terraform/test-fixtures/refresh-basic/main.tf | 2 +- terraform/test-fixtures/refresh-vars/main.tf | 10 +- terraform/test-fixtures/smc-uservars/main.tf | 30 +- .../test-fixtures/validate-bad-pc/main.tf | 10 +- .../validate-bad-prov-conf/main.tf | 14 +- .../test-fixtures/validate-bad-rc/main.tf | 6 +- .../test-fixtures/validate-bad-var/main.tf | 14 +- terraform/test-fixtures/validate-good/main.tf | 16 +- .../validate-required-var/main.tf | 10 +- .../validate-self-ref-multi-all/main.tf | 8 +- .../validate-self-ref-multi/main.tf | 8 +- .../test-fixtures/validate-self-ref/main.tf | 6 +- test-fixtures/config | 8 +- .../source/docs/configuration/index.html.md | 46 +- .../docs/configuration/interpolation.html.md | 84 ++-- .../source/docs/configuration/load.html.md | 68 +-- .../source/docs/configuration/outputs.html.md | 114 ++--- .../docs/configuration/override.html.md | 104 ++--- .../docs/configuration/providers.html.md | 152 +++--- .../docs/configuration/resources.html.md | 248 +++++----- .../source/docs/configuration/syntax.html.md | 254 +++++----- .../docs/configuration/variables.html.md | 222 ++++----- website/source/docs/internals/graph.html.md | 196 ++++---- website/source/docs/internals/index.html.md | 38 +- .../source/docs/internals/lifecycle.html.md | 116 ++--- website/source/docs/plugins/index.html.md | 48 +- website/source/docs/plugins/provider.html.md | 82 ++-- .../source/intro/examples/aws.html.markdown | 300 ++++++------ .../intro/examples/consul.html.markdown | 260 +++++------ website/source/intro/examples/count.markdown | 156 +++---- .../intro/examples/cross-provider.markdown | 156 +++---- .../intro/getting-started/build.html.md | 432 +++++++++--------- .../intro/getting-started/change.html.md | 190 ++++---- .../getting-started/dependencies.html.md | 330 ++++++------- .../intro/getting-started/destroy.html.md | 146 +++--- .../intro/getting-started/outputs.html.md | 160 +++---- .../intro/getting-started/provision.html.md | 220 ++++----- .../intro/getting-started/variables.html.md | 282 ++++++------ 117 files changed, 2995 insertions(+), 2995 deletions(-) diff --git a/.gitignore b/.gitignore index 5ae6f83f5..352c7e9fe 100644 --- a/.gitignore +++ b/.gitignore @@ -1,17 +1,17 @@ -*.dll -*.exe -example.tf -terraform.tfplan -terraform.tfstate -bin/ -config/y.go -config/y.output -vendor/ -website/.vagrant -website/build -website/node_modules -.vagrant/ -*.backup -*.tfstate -*.log -*.bak +*.dll +*.exe +example.tf +terraform.tfplan +terraform.tfstate +bin/ +config/y.go +config/y.output +vendor/ +website/.vagrant +website/build +website/node_modules +.vagrant/ +*.backup +*.tfstate +*.log +*.bak diff --git a/command/test-fixtures/apply-config-invalid/main.tf b/command/test-fixtures/apply-config-invalid/main.tf index ea4d9df6e..81ea8d185 100644 --- a/command/test-fixtures/apply-config-invalid/main.tf +++ b/command/test-fixtures/apply-config-invalid/main.tf @@ -1,3 +1,3 @@ -resource "test_instance" "foo" { - ami = "${var.nope}" -} +resource "test_instance" "foo" { + ami = "${var.nope}" +} diff --git a/command/test-fixtures/apply-error/main.tf b/command/test-fixtures/apply-error/main.tf index 9b4b65a8f..a6d6cc0df 100644 --- a/command/test-fixtures/apply-error/main.tf +++ b/command/test-fixtures/apply-error/main.tf @@ -1,7 +1,7 @@ -resource "test_instance" "foo" { - ami = "bar" -} - -resource "test_instance" "bar" { - error = "true" -} +resource "test_instance" "foo" { + ami = "bar" +} + +resource "test_instance" "bar" { + error = "true" +} diff --git a/command/test-fixtures/apply-shutdown/main.tf b/command/test-fixtures/apply-shutdown/main.tf index 1238f273a..5fc966034 100644 --- a/command/test-fixtures/apply-shutdown/main.tf +++ b/command/test-fixtures/apply-shutdown/main.tf @@ -1,7 +1,7 @@ -resource "test_instance" "foo" { - ami = "bar" -} - -resource "test_instance" "bar" { - ami = "${test_instance.foo.ami}" -} +resource "test_instance" "foo" { + ami = "bar" +} + +resource "test_instance" "bar" { + ami = "${test_instance.foo.ami}" +} diff --git a/command/test-fixtures/apply-vars/main.tf b/command/test-fixtures/apply-vars/main.tf index 6c1541d3a..005abad09 100644 --- a/command/test-fixtures/apply-vars/main.tf +++ b/command/test-fixtures/apply-vars/main.tf @@ -1,5 +1,5 @@ -variable "foo" {} - -resource "test_instance" "foo" { - value = "${var.foo}" -} +variable "foo" {} + +resource "test_instance" "foo" { + value = "${var.foo}" +} diff --git a/command/test-fixtures/apply/main.tf b/command/test-fixtures/apply/main.tf index 5794f94d9..1b1012991 100644 --- a/command/test-fixtures/apply/main.tf +++ b/command/test-fixtures/apply/main.tf @@ -1,3 +1,3 @@ -resource "test_instance" "foo" { - ami = "bar" -} +resource "test_instance" "foo" { + ami = "bar" +} diff --git a/command/test-fixtures/graph/main.tf b/command/test-fixtures/graph/main.tf index 5794f94d9..1b1012991 100644 --- a/command/test-fixtures/graph/main.tf +++ b/command/test-fixtures/graph/main.tf @@ -1,3 +1,3 @@ -resource "test_instance" "foo" { - ami = "bar" -} +resource "test_instance" "foo" { + ami = "bar" +} diff --git a/command/test-fixtures/plan-vars/main.tf b/command/test-fixtures/plan-vars/main.tf index 6c1541d3a..005abad09 100644 --- a/command/test-fixtures/plan-vars/main.tf +++ b/command/test-fixtures/plan-vars/main.tf @@ -1,5 +1,5 @@ -variable "foo" {} - -resource "test_instance" "foo" { - value = "${var.foo}" -} +variable "foo" {} + +resource "test_instance" "foo" { + value = "${var.foo}" +} diff --git a/command/test-fixtures/plan/main.tf b/command/test-fixtures/plan/main.tf index 93c28b253..fd9da13e0 100644 --- a/command/test-fixtures/plan/main.tf +++ b/command/test-fixtures/plan/main.tf @@ -1,9 +1,9 @@ -resource "test_instance" "foo" { - ami = "bar" - - # This is here because at some point it caused a test failure - network_interface { - device_index = 0 - description = "Main network interface" - } -} +resource "test_instance" "foo" { + ami = "bar" + + # This is here because at some point it caused a test failure + network_interface { + device_index = 0 + description = "Main network interface" + } +} diff --git a/command/test-fixtures/refresh-var/main.tf b/command/test-fixtures/refresh-var/main.tf index daabae5cc..af73b1c1b 100644 --- a/command/test-fixtures/refresh-var/main.tf +++ b/command/test-fixtures/refresh-var/main.tf @@ -1,7 +1,7 @@ -variable "foo" {} - -provider "test" { - value = "${var.foo}" -} - -resource "test_instance" "foo" {} +variable "foo" {} + +provider "test" { + value = "${var.foo}" +} + +resource "test_instance" "foo" {} diff --git a/command/test-fixtures/refresh/main.tf b/command/test-fixtures/refresh/main.tf index 5794f94d9..1b1012991 100644 --- a/command/test-fixtures/refresh/main.tf +++ b/command/test-fixtures/refresh/main.tf @@ -1,3 +1,3 @@ -resource "test_instance" "foo" { - ami = "bar" -} +resource "test_instance" "foo" { + ami = "bar" +} diff --git a/config/test-fixtures/bad_type.tf.nope b/config/test-fixtures/bad_type.tf.nope index 289e728ba..91084f7a1 100644 --- a/config/test-fixtures/bad_type.tf.nope +++ b/config/test-fixtures/bad_type.tf.nope @@ -1 +1 @@ -variable "foo" {} +variable "foo" {} diff --git a/config/test-fixtures/basic.tf.json b/config/test-fixtures/basic.tf.json index 6c6ff00bd..506e2a7b8 100644 --- a/config/test-fixtures/basic.tf.json +++ b/config/test-fixtures/basic.tf.json @@ -1,53 +1,53 @@ -{ - "variable": { - "foo": { - "default": "bar", - "description": "bar" - } - }, - - "provider": { - "aws": { - "access_key": "foo", - "secret_key": "bar" - }, - - "do": { - "api_key": "${var.foo}" - } - }, - - "resource": { - "aws_instance": { - "db": { - "security_groups": ["${aws_security_group.firewall.*.id}"], - "VPC": "foo", - "depends_on": ["aws_instance.web"] - }, - - "web": { - "ami": "${var.foo}", - "security_groups": [ - "foo", - "${aws_security_group.firewall.foo}" - ], - "network_interface": { - "device_index": 0, - "description": "Main network interface" - } - } - }, - - "aws_security_group": { - "firewall": { - "count": 5 - } - } - }, - - "output": { - "web_ip": { - "value": "${aws_instance.web.private_ip}" - } - } -} +{ + "variable": { + "foo": { + "default": "bar", + "description": "bar" + } + }, + + "provider": { + "aws": { + "access_key": "foo", + "secret_key": "bar" + }, + + "do": { + "api_key": "${var.foo}" + } + }, + + "resource": { + "aws_instance": { + "db": { + "security_groups": ["${aws_security_group.firewall.*.id}"], + "VPC": "foo", + "depends_on": ["aws_instance.web"] + }, + + "web": { + "ami": "${var.foo}", + "security_groups": [ + "foo", + "${aws_security_group.firewall.foo}" + ], + "network_interface": { + "device_index": 0, + "description": "Main network interface" + } + } + }, + + "aws_security_group": { + "firewall": { + "count": 5 + } + } + }, + + "output": { + "web_ip": { + "value": "${aws_instance.web.private_ip}" + } + } +} diff --git a/config/test-fixtures/connection.tf b/config/test-fixtures/connection.tf index 7f808f2cb..25d47624b 100644 --- a/config/test-fixtures/connection.tf +++ b/config/test-fixtures/connection.tf @@ -1,23 +1,23 @@ -resource "aws_instance" "web" { - ami = "${var.foo}" - security_groups = [ - "foo", - "${aws_security_group.firewall.foo}" - ] - - connection { - type = "ssh" - user = "root" - } - - provisioner "shell" { - path = "foo" - connection { - user = "nobody" - } - } - - provisioner "shell" { - path = "bar" - } -} +resource "aws_instance" "web" { + ami = "${var.foo}" + security_groups = [ + "foo", + "${aws_security_group.firewall.foo}" + ] + + connection { + type = "ssh" + user = "root" + } + + provisioner "shell" { + path = "foo" + connection { + user = "nobody" + } + } + + provisioner "shell" { + path = "bar" + } +} diff --git a/config/test-fixtures/dir-basic/README.md b/config/test-fixtures/dir-basic/README.md index 0e528aca0..f33f7e9c0 100644 --- a/config/test-fixtures/dir-basic/README.md +++ b/config/test-fixtures/dir-basic/README.md @@ -1,2 +1,2 @@ -This file just exists to test that LoadDir doesn't load non-Terraform -files. +This file just exists to test that LoadDir doesn't load non-Terraform +files. diff --git a/config/test-fixtures/dir-basic/nested/nested.tf b/config/test-fixtures/dir-basic/nested/nested.tf index 11a40a1d1..189c48dc0 100644 --- a/config/test-fixtures/dir-basic/nested/nested.tf +++ b/config/test-fixtures/dir-basic/nested/nested.tf @@ -1,3 +1,3 @@ -output "i-am-nested" { - value = "what" -} +output "i-am-nested" { + value = "what" +} diff --git a/config/test-fixtures/dir-basic/one.tf b/config/test-fixtures/dir-basic/one.tf index a4b59f1ae..51829234f 100644 --- a/config/test-fixtures/dir-basic/one.tf +++ b/config/test-fixtures/dir-basic/one.tf @@ -1,17 +1,17 @@ -variable "foo" { - default = "bar"; - description = "bar"; -} - -provider "aws" { - access_key = "foo"; - secret_key = "bar"; -} - -resource "aws_instance" "db" { - security_groups = "${aws_security_group.firewall.*.id}" -} - -output "web_ip" { - value = "${aws_instance.web.private_ip}" -} +variable "foo" { + default = "bar"; + description = "bar"; +} + +provider "aws" { + access_key = "foo"; + secret_key = "bar"; +} + +resource "aws_instance" "db" { + security_groups = "${aws_security_group.firewall.*.id}" +} + +output "web_ip" { + value = "${aws_instance.web.private_ip}" +} diff --git a/config/test-fixtures/dir-basic/two.tf b/config/test-fixtures/dir-basic/two.tf index c87c5059a..ecdf95c4c 100644 --- a/config/test-fixtures/dir-basic/two.tf +++ b/config/test-fixtures/dir-basic/two.tf @@ -1,20 +1,20 @@ -provider "do" { - api_key = "${var.foo}"; -} - -resource "aws_security_group" "firewall" { - count = 5 -} - -resource aws_instance "web" { - ami = "${var.foo}" - security_groups = [ - "foo", - "${aws_security_group.firewall.foo}" - ] - - network_interface { - device_index = 0 - description = "Main network interface" - } -} +provider "do" { + api_key = "${var.foo}"; +} + +resource "aws_security_group" "firewall" { + count = 5 +} + +resource aws_instance "web" { + ami = "${var.foo}" + security_groups = [ + "foo", + "${aws_security_group.firewall.foo}" + ] + + network_interface { + device_index = 0 + description = "Main network interface" + } +} diff --git a/config/test-fixtures/dir-merge/one.tf b/config/test-fixtures/dir-merge/one.tf index c62dc93e6..471efce36 100644 --- a/config/test-fixtures/dir-merge/one.tf +++ b/config/test-fixtures/dir-merge/one.tf @@ -1,8 +1,8 @@ -variable "foo" { - default = "bar"; - description = "bar"; -} - -resource "aws_instance" "db" { - security_groups = "${aws_security_group.firewall.*.id}" -} +variable "foo" { + default = "bar"; + description = "bar"; +} + +resource "aws_instance" "db" { + security_groups = "${aws_security_group.firewall.*.id}" +} diff --git a/config/test-fixtures/dir-merge/two.tf b/config/test-fixtures/dir-merge/two.tf index 39f6d7e63..c0936f493 100644 --- a/config/test-fixtures/dir-merge/two.tf +++ b/config/test-fixtures/dir-merge/two.tf @@ -1,2 +1,2 @@ -resource "aws_instance" "db" { -} +resource "aws_instance" "db" { +} diff --git a/config/test-fixtures/dir-override/foo_override.tf.json b/config/test-fixtures/dir-override/foo_override.tf.json index a2f07c173..1e9194d5f 100644 --- a/config/test-fixtures/dir-override/foo_override.tf.json +++ b/config/test-fixtures/dir-override/foo_override.tf.json @@ -1,9 +1,9 @@ -{ - "resource": { - "aws_instance": { - "web": { - "foo": "bar", - } - } - } -} +{ + "resource": { + "aws_instance": { + "web": { + "foo": "bar", + } + } + } +} diff --git a/config/test-fixtures/dir-override/one.tf b/config/test-fixtures/dir-override/one.tf index a4b59f1ae..51829234f 100644 --- a/config/test-fixtures/dir-override/one.tf +++ b/config/test-fixtures/dir-override/one.tf @@ -1,17 +1,17 @@ -variable "foo" { - default = "bar"; - description = "bar"; -} - -provider "aws" { - access_key = "foo"; - secret_key = "bar"; -} - -resource "aws_instance" "db" { - security_groups = "${aws_security_group.firewall.*.id}" -} - -output "web_ip" { - value = "${aws_instance.web.private_ip}" -} +variable "foo" { + default = "bar"; + description = "bar"; +} + +provider "aws" { + access_key = "foo"; + secret_key = "bar"; +} + +resource "aws_instance" "db" { + security_groups = "${aws_security_group.firewall.*.id}" +} + +output "web_ip" { + value = "${aws_instance.web.private_ip}" +} diff --git a/config/test-fixtures/dir-override/override.tf.json b/config/test-fixtures/dir-override/override.tf.json index a9dcf875e..36d04846d 100644 --- a/config/test-fixtures/dir-override/override.tf.json +++ b/config/test-fixtures/dir-override/override.tf.json @@ -1,10 +1,10 @@ -{ - "resource": { - "aws_instance": { - "db": { - "ami": "foo", - "security_groups": "" - } - } - } -} +{ + "resource": { + "aws_instance": { + "db": { + "ami": "foo", + "security_groups": "" + } + } + } +} diff --git a/config/test-fixtures/dir-override/two.tf b/config/test-fixtures/dir-override/two.tf index c87c5059a..ecdf95c4c 100644 --- a/config/test-fixtures/dir-override/two.tf +++ b/config/test-fixtures/dir-override/two.tf @@ -1,20 +1,20 @@ -provider "do" { - api_key = "${var.foo}"; -} - -resource "aws_security_group" "firewall" { - count = 5 -} - -resource aws_instance "web" { - ami = "${var.foo}" - security_groups = [ - "foo", - "${aws_security_group.firewall.foo}" - ] - - network_interface { - device_index = 0 - description = "Main network interface" - } -} +provider "do" { + api_key = "${var.foo}"; +} + +resource "aws_security_group" "firewall" { + count = 5 +} + +resource aws_instance "web" { + ami = "${var.foo}" + security_groups = [ + "foo", + "${aws_security_group.firewall.foo}" + ] + + network_interface { + device_index = 0 + description = "Main network interface" + } +} diff --git a/config/test-fixtures/import/one.tf b/config/test-fixtures/import/one.tf index 6b79a4c8c..074af3430 100644 --- a/config/test-fixtures/import/one.tf +++ b/config/test-fixtures/import/one.tf @@ -1,7 +1,7 @@ -variable "bar" {} - -provider "aws" { - bar = "baz"; -} - -resource "aws_security_group" "db" {} +variable "bar" {} + +provider "aws" { + bar = "baz"; +} + +resource "aws_security_group" "db" {} diff --git a/config/test-fixtures/provisioners.tf b/config/test-fixtures/provisioners.tf index 16578134c..e20d95f4f 100644 --- a/config/test-fixtures/provisioners.tf +++ b/config/test-fixtures/provisioners.tf @@ -1,11 +1,11 @@ -resource "aws_instance" "web" { - ami = "${var.foo}" - security_groups = [ - "foo", - "${aws_security_group.firewall.foo}" - ] - - provisioner "shell" { - path = "foo" - } -} +resource "aws_instance" "web" { + ami = "${var.foo}" + security_groups = [ + "foo", + "${aws_security_group.firewall.foo}" + ] + + provisioner "shell" { + path = "foo" + } +} diff --git a/config/test-fixtures/validate-bad-depends-on/main.tf b/config/test-fixtures/validate-bad-depends-on/main.tf index 60ca18c7e..32a71bf24 100644 --- a/config/test-fixtures/validate-bad-depends-on/main.tf +++ b/config/test-fixtures/validate-bad-depends-on/main.tf @@ -1,3 +1,3 @@ -resource "aws_instance" "web" { - depends_on = ["aws_instance.db"] -} +resource "aws_instance" "web" { + depends_on = ["aws_instance.db"] +} diff --git a/config/test-fixtures/validate-bad-multi-resource/main.tf b/config/test-fixtures/validate-bad-multi-resource/main.tf index c92ada968..938b685fa 100644 --- a/config/test-fixtures/validate-bad-multi-resource/main.tf +++ b/config/test-fixtures/validate-bad-multi-resource/main.tf @@ -1,7 +1,7 @@ -resource "aws_instance" "web" { - count = 5 -} - -output "ip" { - value = "${aws_instance.web.id}" -} +resource "aws_instance" "web" { + count = 5 +} + +output "ip" { + value = "${aws_instance.web.id}" +} diff --git a/config/test-fixtures/validate-count-below-zero/main.tf b/config/test-fixtures/validate-count-below-zero/main.tf index ffe7f1466..5c92e28fb 100644 --- a/config/test-fixtures/validate-count-below-zero/main.tf +++ b/config/test-fixtures/validate-count-below-zero/main.tf @@ -1,3 +1,3 @@ -resource "aws_instance" "web" { - count = -1 -} +resource "aws_instance" "web" { + count = -1 +} diff --git a/config/test-fixtures/validate-count-zero/main.tf b/config/test-fixtures/validate-count-zero/main.tf index 4e1010491..96f05099a 100644 --- a/config/test-fixtures/validate-count-zero/main.tf +++ b/config/test-fixtures/validate-count-zero/main.tf @@ -1,3 +1,3 @@ -resource "aws_instance" "web" { - count = 0 -} +resource "aws_instance" "web" { + count = 0 +} diff --git a/config/test-fixtures/validate-dup-resource/main.tf b/config/test-fixtures/validate-dup-resource/main.tf index 23a66aa31..477e91e9e 100644 --- a/config/test-fixtures/validate-dup-resource/main.tf +++ b/config/test-fixtures/validate-dup-resource/main.tf @@ -1,7 +1,7 @@ -resource "aws_instance" "web" { - count = 5 -} - -resource "aws_instance" "web" { - count = 10 -} +resource "aws_instance" "web" { + count = 5 +} + +resource "aws_instance" "web" { + count = 10 +} diff --git a/config/test-fixtures/validate-good/main.tf b/config/test-fixtures/validate-good/main.tf index 5a4f87159..4c46a8313 100644 --- a/config/test-fixtures/validate-good/main.tf +++ b/config/test-fixtures/validate-good/main.tf @@ -1,37 +1,37 @@ -variable "foo" { - default = "bar"; - description = "bar"; -} - -variable "amis" { - default = { - "east": "foo", - } -} - -provider "aws" { - access_key = "foo"; - secret_key = "bar"; -} - -provider "do" { - api_key = "${var.foo}"; -} - -resource "aws_security_group" "firewall" { -} - -resource aws_instance "web" { - ami = "${var.amis.east}" - security_groups = [ - "foo", - "${aws_security_group.firewall.foo}" - ] - - network_interface { - device_index = 0 - description = "Main network interface" - } - - depends_on = ["aws_security_group.firewall"] -} +variable "foo" { + default = "bar"; + description = "bar"; +} + +variable "amis" { + default = { + "east": "foo", + } +} + +provider "aws" { + access_key = "foo"; + secret_key = "bar"; +} + +provider "do" { + api_key = "${var.foo}"; +} + +resource "aws_security_group" "firewall" { +} + +resource aws_instance "web" { + ami = "${var.amis.east}" + security_groups = [ + "foo", + "${aws_security_group.firewall.foo}" + ] + + network_interface { + device_index = 0 + description = "Main network interface" + } + + depends_on = ["aws_security_group.firewall"] +} diff --git a/config/test-fixtures/validate-output-bad-field/main.tf b/config/test-fixtures/validate-output-bad-field/main.tf index dae3781a4..71895ebb3 100644 --- a/config/test-fixtures/validate-output-bad-field/main.tf +++ b/config/test-fixtures/validate-output-bad-field/main.tf @@ -1,7 +1,7 @@ -resource "aws_instance" "web" { -} - -output "ip" { - value = "foo" - another = "nope" -} +resource "aws_instance" "web" { +} + +output "ip" { + value = "foo" + another = "nope" +} diff --git a/config/test-fixtures/validate-unknown-resource-var-output/main.tf b/config/test-fixtures/validate-unknown-resource-var-output/main.tf index d79c65712..0d93b72a8 100644 --- a/config/test-fixtures/validate-unknown-resource-var-output/main.tf +++ b/config/test-fixtures/validate-unknown-resource-var-output/main.tf @@ -1,6 +1,6 @@ -resource "aws_instance" "web" { -} - -output "ip" { - value = "${aws_instance.loadbalancer.foo}" -} +resource "aws_instance" "web" { +} + +output "ip" { + value = "${aws_instance.loadbalancer.foo}" +} diff --git a/config/test-fixtures/validate-unknown-resource-var/main.tf b/config/test-fixtures/validate-unknown-resource-var/main.tf index 3c89cc013..2fcc7bdff 100644 --- a/config/test-fixtures/validate-unknown-resource-var/main.tf +++ b/config/test-fixtures/validate-unknown-resource-var/main.tf @@ -1,6 +1,6 @@ -resource "aws_instance" "web" { -} - -resource "aws_instance" "db" { - ami = "${aws_instance.loadbalancer.foo}" -} +resource "aws_instance" "web" { +} + +resource "aws_instance" "db" { + ami = "${aws_instance.loadbalancer.foo}" +} diff --git a/config/test-fixtures/validate-unknownthing/main.tf b/config/test-fixtures/validate-unknownthing/main.tf index fcfdf7274..e273ef33c 100644 --- a/config/test-fixtures/validate-unknownthing/main.tf +++ b/config/test-fixtures/validate-unknownthing/main.tf @@ -1 +1 @@ -what "is this" +what "is this" diff --git a/config/test-fixtures/validate-unknownvar/main.tf b/config/test-fixtures/validate-unknownvar/main.tf index 7d1a77bfb..ddbc363f5 100644 --- a/config/test-fixtures/validate-unknownvar/main.tf +++ b/config/test-fixtures/validate-unknownvar/main.tf @@ -1,8 +1,8 @@ -variable "foo" { - default = "bar"; - description = "bar"; -} - -provider "do" { - api_key = "${var.bar}"; -} +variable "foo" { + default = "bar"; + description = "bar"; +} + +provider "do" { + api_key = "${var.bar}"; +} diff --git a/config/test-fixtures/validate-var-default-bad-type/main.tf b/config/test-fixtures/validate-var-default-bad-type/main.tf index c7975db38..7edf7f2ed 100644 --- a/config/test-fixtures/validate-var-default-bad-type/main.tf +++ b/config/test-fixtures/validate-var-default-bad-type/main.tf @@ -1,3 +1,3 @@ -variable "foo" { - default = ["foo", "bar"] -} +variable "foo" { + default = ["foo", "bar"] +} diff --git a/config/test-fixtures/validate-var-default/main.tf b/config/test-fixtures/validate-var-default/main.tf index 75a6bc9e0..89d5e9968 100644 --- a/config/test-fixtures/validate-var-default/main.tf +++ b/config/test-fixtures/validate-var-default/main.tf @@ -1,9 +1,9 @@ -variable "foo" { - default = "bar" -} - -variable "foo" { - default = { - "foo" = "bar" - } -} +variable "foo" { + default = "bar" +} + +variable "foo" { + default = { + "foo" = "bar" + } +} diff --git a/config/test-fixtures/variables.tf b/config/test-fixtures/variables.tf index 2fc0c6489..77d43a040 100644 --- a/config/test-fixtures/variables.tf +++ b/config/test-fixtures/variables.tf @@ -1,7 +1,7 @@ -variable "foo" {} -variable "bar" { - default = "" -} -variable "baz" { - default = "foo" -} +variable "foo" {} +variable "bar" { + default = "" +} +variable "baz" { + default = "foo" +} diff --git a/helper/README.md b/helper/README.md index 5451aba8a..d0fee0686 100644 --- a/helper/README.md +++ b/helper/README.md @@ -1,7 +1,7 @@ -# Helper Libraries - -This folder contains helper libraries for Terraform plugins. A running -joke is that this is "Terraform standard library" for plugins. The goal -of the packages in this directory are to provide high-level helpers to -make it easier to implement the various aspects of writing a plugin for -Terraform. +# Helper Libraries + +This folder contains helper libraries for Terraform plugins. A running +joke is that this is "Terraform standard library" for plugins. The goal +of the packages in this directory are to provide high-level helpers to +make it easier to implement the various aspects of writing a plugin for +Terraform. diff --git a/terraform/test-fixtures/apply-cancel/main.tf b/terraform/test-fixtures/apply-cancel/main.tf index 94ed55478..1b6cdae67 100644 --- a/terraform/test-fixtures/apply-cancel/main.tf +++ b/terraform/test-fixtures/apply-cancel/main.tf @@ -1,7 +1,7 @@ -resource "aws_instance" "foo" { - num = "2" -} - -resource "aws_instance" "bar" { - foo = "${aws_instance.foo.num}" -} +resource "aws_instance" "foo" { + num = "2" +} + +resource "aws_instance" "bar" { + foo = "${aws_instance.foo.num}" +} diff --git a/terraform/test-fixtures/apply-destroy-outputs/main.tf b/terraform/test-fixtures/apply-destroy-outputs/main.tf index 98c3476ef..c893161d1 100644 --- a/terraform/test-fixtures/apply-destroy-outputs/main.tf +++ b/terraform/test-fixtures/apply-destroy-outputs/main.tf @@ -1,14 +1,14 @@ -resource "aws_instance" "foo" { - id = "foo" - num = "2" -} - -resource "aws_instance" "bar" { - id = "bar" - foo = "{aws_instance.foo.num}" - dep = "foo" -} - -output "foo" { - value = "${aws_instance.foo.id}" -} +resource "aws_instance" "foo" { + id = "foo" + num = "2" +} + +resource "aws_instance" "bar" { + id = "bar" + foo = "{aws_instance.foo.num}" + dep = "foo" +} + +output "foo" { + value = "${aws_instance.foo.id}" +} diff --git a/terraform/test-fixtures/apply-destroy/main.tf b/terraform/test-fixtures/apply-destroy/main.tf index 63c561692..cd1a686f6 100644 --- a/terraform/test-fixtures/apply-destroy/main.tf +++ b/terraform/test-fixtures/apply-destroy/main.tf @@ -1,10 +1,10 @@ -resource "aws_instance" "foo" { - id = "foo" - num = "2" -} - -resource "aws_instance" "bar" { - id = "bar" - foo = "{aws_instance.foo.num}" - dep = "foo" -} +resource "aws_instance" "foo" { + id = "foo" + num = "2" +} + +resource "aws_instance" "bar" { + id = "bar" + foo = "{aws_instance.foo.num}" + dep = "foo" +} diff --git a/terraform/test-fixtures/apply-error/main.tf b/terraform/test-fixtures/apply-error/main.tf index 94ed55478..1b6cdae67 100644 --- a/terraform/test-fixtures/apply-error/main.tf +++ b/terraform/test-fixtures/apply-error/main.tf @@ -1,7 +1,7 @@ -resource "aws_instance" "foo" { - num = "2" -} - -resource "aws_instance" "bar" { - foo = "${aws_instance.foo.num}" -} +resource "aws_instance" "foo" { + num = "2" +} + +resource "aws_instance" "bar" { + foo = "${aws_instance.foo.num}" +} diff --git a/terraform/test-fixtures/apply-good/main.tf b/terraform/test-fixtures/apply-good/main.tf index ce5654441..b07fc97f4 100644 --- a/terraform/test-fixtures/apply-good/main.tf +++ b/terraform/test-fixtures/apply-good/main.tf @@ -1,7 +1,7 @@ -resource "aws_instance" "foo" { - num = "2" -} - -resource "aws_instance" "bar" { - foo = "bar" -} +resource "aws_instance" "foo" { + num = "2" +} + +resource "aws_instance" "bar" { + foo = "bar" +} diff --git a/terraform/test-fixtures/apply-idattr/main.tf b/terraform/test-fixtures/apply-idattr/main.tf index ca956330c..b626e60c8 100644 --- a/terraform/test-fixtures/apply-idattr/main.tf +++ b/terraform/test-fixtures/apply-idattr/main.tf @@ -1,2 +1,2 @@ -resource "aws_instance" "foo" { -} +resource "aws_instance" "foo" { +} diff --git a/terraform/test-fixtures/apply-output-multi-index/main.tf b/terraform/test-fixtures/apply-output-multi-index/main.tf index 7db99d62b..c7ede94d5 100644 --- a/terraform/test-fixtures/apply-output-multi-index/main.tf +++ b/terraform/test-fixtures/apply-output-multi-index/main.tf @@ -1,12 +1,12 @@ -resource "aws_instance" "foo" { - num = "2" -} - -resource "aws_instance" "bar" { - foo = "bar" - count = 3 -} - -output "foo_num" { - value = "${aws_instance.bar.0.foo}" -} +resource "aws_instance" "foo" { + num = "2" +} + +resource "aws_instance" "bar" { + foo = "bar" + count = 3 +} + +output "foo_num" { + value = "${aws_instance.bar.0.foo}" +} diff --git a/terraform/test-fixtures/apply-output-multi/main.tf b/terraform/test-fixtures/apply-output-multi/main.tf index 40003342e..ba9aa7e64 100644 --- a/terraform/test-fixtures/apply-output-multi/main.tf +++ b/terraform/test-fixtures/apply-output-multi/main.tf @@ -1,12 +1,12 @@ -resource "aws_instance" "foo" { - num = "2" -} - -resource "aws_instance" "bar" { - foo = "bar" - count = 3 -} - -output "foo_num" { - value = "${aws_instance.bar.*.foo}" -} +resource "aws_instance" "foo" { + num = "2" +} + +resource "aws_instance" "bar" { + foo = "bar" + count = 3 +} + +output "foo_num" { + value = "${aws_instance.bar.*.foo}" +} diff --git a/terraform/test-fixtures/apply-output/main.tf b/terraform/test-fixtures/apply-output/main.tf index 4d8b0c4f0..1f91a40f1 100644 --- a/terraform/test-fixtures/apply-output/main.tf +++ b/terraform/test-fixtures/apply-output/main.tf @@ -1,11 +1,11 @@ -resource "aws_instance" "foo" { - num = "2" -} - -resource "aws_instance" "bar" { - foo = "bar" -} - -output "foo_num" { - value = "${aws_instance.foo.num}" -} +resource "aws_instance" "foo" { + num = "2" +} + +resource "aws_instance" "bar" { + foo = "bar" +} + +output "foo_num" { + value = "${aws_instance.foo.num}" +} diff --git a/terraform/test-fixtures/apply-provisioner-fail/main.tf b/terraform/test-fixtures/apply-provisioner-fail/main.tf index d27208d4f..4aacf4b5b 100644 --- a/terraform/test-fixtures/apply-provisioner-fail/main.tf +++ b/terraform/test-fixtures/apply-provisioner-fail/main.tf @@ -1,7 +1,7 @@ -resource "aws_instance" "foo" { - num = "2" -} - -resource "aws_instance" "bar" { - provisioner "shell" {} -} +resource "aws_instance" "foo" { + num = "2" +} + +resource "aws_instance" "bar" { + provisioner "shell" {} +} diff --git a/terraform/test-fixtures/apply-provisioner-resource-ref/main.tf b/terraform/test-fixtures/apply-provisioner-resource-ref/main.tf index 056a6304a..6b750ff60 100644 --- a/terraform/test-fixtures/apply-provisioner-resource-ref/main.tf +++ b/terraform/test-fixtures/apply-provisioner-resource-ref/main.tf @@ -1,7 +1,7 @@ -resource "aws_instance" "bar" { - num = "2" - - provisioner "shell" { - foo = "${aws_instance.bar.num}" - } -} +resource "aws_instance" "bar" { + num = "2" + + provisioner "shell" { + foo = "${aws_instance.bar.num}" + } +} diff --git a/terraform/test-fixtures/apply-taint/main.tf b/terraform/test-fixtures/apply-taint/main.tf index fb8e23f34..efa28f8ba 100644 --- a/terraform/test-fixtures/apply-taint/main.tf +++ b/terraform/test-fixtures/apply-taint/main.tf @@ -1,4 +1,4 @@ -resource "aws_instance" "bar" { - id = "foo" - num = "2" -} +resource "aws_instance" "bar" { + id = "foo" + num = "2" +} diff --git a/terraform/test-fixtures/apply-unknown/main.tf b/terraform/test-fixtures/apply-unknown/main.tf index ee1564b7a..36f5074ae 100644 --- a/terraform/test-fixtures/apply-unknown/main.tf +++ b/terraform/test-fixtures/apply-unknown/main.tf @@ -1,4 +1,4 @@ -resource "aws_instance" "foo" { - num = "2" - compute = "foo" -} +resource "aws_instance" "foo" { + num = "2" + compute = "foo" +} diff --git a/terraform/test-fixtures/apply-vars/main.tf b/terraform/test-fixtures/apply-vars/main.tf index 6645e532d..a73b9092b 100644 --- a/terraform/test-fixtures/apply-vars/main.tf +++ b/terraform/test-fixtures/apply-vars/main.tf @@ -1,23 +1,23 @@ -variable "amis" { - default = { - "us-east-1": "foo", - "us-west-2": "foo", - } -} - -variable "bar" { - default = "baz" -} - -variable "foo" {} - -resource "aws_instance" "foo" { - num = "2" - bar = "${var.bar}" -} - -resource "aws_instance" "bar" { - foo = "${var.foo}" - bar = "${lookup(var.amis, var.foo)}" - baz = "${var.amis.us-east-1}" -} +variable "amis" { + default = { + "us-east-1": "foo", + "us-west-2": "foo", + } +} + +variable "bar" { + default = "baz" +} + +variable "foo" {} + +resource "aws_instance" "foo" { + num = "2" + bar = "${var.bar}" +} + +resource "aws_instance" "bar" { + foo = "${var.foo}" + bar = "${lookup(var.amis, var.foo)}" + baz = "${var.amis.us-east-1}" +} diff --git a/terraform/test-fixtures/graph-basic/main.tf b/terraform/test-fixtures/graph-basic/main.tf index cd84eb51a..846805a24 100644 --- a/terraform/test-fixtures/graph-basic/main.tf +++ b/terraform/test-fixtures/graph-basic/main.tf @@ -1,24 +1,24 @@ -variable "foo" { - default = "bar"; - description = "bar"; -} - -provider "aws" { - foo = "${openstack_floating_ip.random.value}" -} - -resource "openstack_floating_ip" "random" {} - -resource "aws_security_group" "firewall" {} - -resource "aws_instance" "web" { - ami = "${var.foo}" - security_groups = [ - "foo", - "${aws_security_group.firewall.foo}" - ] -} - -resource "aws_load_balancer" "weblb" { - members = "${aws_instance.web.id_list}" -} +variable "foo" { + default = "bar"; + description = "bar"; +} + +provider "aws" { + foo = "${openstack_floating_ip.random.value}" +} + +resource "openstack_floating_ip" "random" {} + +resource "aws_security_group" "firewall" {} + +resource "aws_instance" "web" { + ami = "${var.foo}" + security_groups = [ + "foo", + "${aws_security_group.firewall.foo}" + ] +} + +resource "aws_load_balancer" "weblb" { + members = "${aws_instance.web.id_list}" +} diff --git a/terraform/test-fixtures/graph-count/main.tf b/terraform/test-fixtures/graph-count/main.tf index b35995faa..c6fdf97e4 100644 --- a/terraform/test-fixtures/graph-count/main.tf +++ b/terraform/test-fixtures/graph-count/main.tf @@ -1,7 +1,7 @@ -resource "aws_instance" "web" { - count = 3 -} - -resource "aws_load_balancer" "weblb" { - members = "${aws_instance.web.*.id}" -} +resource "aws_instance" "web" { + count = 3 +} + +resource "aws_load_balancer" "weblb" { + members = "${aws_instance.web.*.id}" +} diff --git a/terraform/test-fixtures/graph-cycle/main.tf b/terraform/test-fixtures/graph-cycle/main.tf index 135a35af8..c7373f97f 100644 --- a/terraform/test-fixtures/graph-cycle/main.tf +++ b/terraform/test-fixtures/graph-cycle/main.tf @@ -1,18 +1,18 @@ -variable "foo" { - default = "bar"; - description = "bar"; -} - -provider "aws" { - foo = "${aws_security_group.firewall.value}" -} - -resource "aws_security_group" "firewall" {} - -resource "aws_instance" "web" { - ami = "${var.foo}" - security_groups = [ - "foo", - "${aws_security_group.firewall.foo}" - ] -} +variable "foo" { + default = "bar"; + description = "bar"; +} + +provider "aws" { + foo = "${aws_security_group.firewall.value}" +} + +resource "aws_security_group" "firewall" {} + +resource "aws_instance" "web" { + ami = "${var.foo}" + security_groups = [ + "foo", + "${aws_security_group.firewall.foo}" + ] +} diff --git a/terraform/test-fixtures/graph-depends-on/main.tf b/terraform/test-fixtures/graph-depends-on/main.tf index 2a2d904dc..5a5430917 100644 --- a/terraform/test-fixtures/graph-depends-on/main.tf +++ b/terraform/test-fixtures/graph-depends-on/main.tf @@ -1,5 +1,5 @@ -resource "aws_instance" "web" {} - -resource "aws_instance" "db" { - depends_on = ["aws_instance.web"] -} +resource "aws_instance" "web" {} + +resource "aws_instance" "db" { + depends_on = ["aws_instance.web"] +} diff --git a/terraform/test-fixtures/graph-diff-destroy/main.tf b/terraform/test-fixtures/graph-diff-destroy/main.tf index acbc6dd33..1df2421fc 100644 --- a/terraform/test-fixtures/graph-diff-destroy/main.tf +++ b/terraform/test-fixtures/graph-diff-destroy/main.tf @@ -1,8 +1,8 @@ -provider "aws" {} - -resource "aws_instance" "foo" { -} - -resource "aws_instance" "bar" { - foo = "${aws_instance.foo.id}" -} +provider "aws" {} + +resource "aws_instance" "foo" { +} + +resource "aws_instance" "bar" { + foo = "${aws_instance.foo.id}" +} diff --git a/terraform/test-fixtures/graph-diff/main.tf b/terraform/test-fixtures/graph-diff/main.tf index ca956330c..b626e60c8 100644 --- a/terraform/test-fixtures/graph-diff/main.tf +++ b/terraform/test-fixtures/graph-diff/main.tf @@ -1,2 +1,2 @@ -resource "aws_instance" "foo" { -} +resource "aws_instance" "foo" { +} diff --git a/terraform/test-fixtures/graph-provisioners/main.tf b/terraform/test-fixtures/graph-provisioners/main.tf index 7222c3f98..db177cc00 100644 --- a/terraform/test-fixtures/graph-provisioners/main.tf +++ b/terraform/test-fixtures/graph-provisioners/main.tf @@ -1,32 +1,32 @@ -variable "foo" { - default = "bar"; - description = "bar"; -} - -provider "aws" {} - -resource "aws_security_group" "firewall" {} - -resource "aws_instance" "web" { - ami = "${var.foo}" - security_groups = [ - "foo", - "${aws_security_group.firewall.foo}" - ] - provisioner "winrm" { - cmd = "echo foo" - } - provisioner "winrm" { - cmd = "echo bar" - } -} - -resource "aws_load_balancer" "weblb" { - provisioner "shell" { - cmd = "add ${aws_instance.web.id}" - connection { - type = "magic" - user = "${aws_security_group.firewall.id}" - } - } -} +variable "foo" { + default = "bar"; + description = "bar"; +} + +provider "aws" {} + +resource "aws_security_group" "firewall" {} + +resource "aws_instance" "web" { + ami = "${var.foo}" + security_groups = [ + "foo", + "${aws_security_group.firewall.foo}" + ] + provisioner "winrm" { + cmd = "echo foo" + } + provisioner "winrm" { + cmd = "echo bar" + } +} + +resource "aws_load_balancer" "weblb" { + provisioner "shell" { + cmd = "add ${aws_instance.web.id}" + connection { + type = "magic" + user = "${aws_security_group.firewall.id}" + } + } +} diff --git a/terraform/test-fixtures/new-good/main.tf b/terraform/test-fixtures/new-good/main.tf index b8bb628e1..40ed1a89c 100644 --- a/terraform/test-fixtures/new-good/main.tf +++ b/terraform/test-fixtures/new-good/main.tf @@ -1,6 +1,6 @@ -provider "aws" { - foo = "bar" -} - -resource "aws_instance" "foo" {} -resource "do_droplet" "bar" {} +provider "aws" { + foo = "bar" +} + +resource "aws_instance" "foo" {} +resource "do_droplet" "bar" {} diff --git a/terraform/test-fixtures/new-graph-cycle/main.tf b/terraform/test-fixtures/new-graph-cycle/main.tf index a292b8706..b4285424f 100644 --- a/terraform/test-fixtures/new-graph-cycle/main.tf +++ b/terraform/test-fixtures/new-graph-cycle/main.tf @@ -1,7 +1,7 @@ -resource "aws_instance" "foo" { - ami = "${aws_instance.bar.id}" -} - -resource "aws_instance" "bar" { - ami = "${aws_instance.foo.id}" -} +resource "aws_instance" "foo" { + ami = "${aws_instance.bar.id}" +} + +resource "aws_instance" "bar" { + ami = "${aws_instance.foo.id}" +} diff --git a/terraform/test-fixtures/new-pc-cache/main.tf b/terraform/test-fixtures/new-pc-cache/main.tf index 9e1c92cf2..617fd43bf 100644 --- a/terraform/test-fixtures/new-pc-cache/main.tf +++ b/terraform/test-fixtures/new-pc-cache/main.tf @@ -1,12 +1,12 @@ -provider "aws" { - foo = "bar" -} - -provider "aws_elb" { - foo = "baz" -} - -resource "aws_instance" "foo" {} -resource "aws_instance" "bar" {} -resource "aws_elb" "lb" {} -resource "do_droplet" "bar" {} +provider "aws" { + foo = "bar" +} + +provider "aws_elb" { + foo = "baz" +} + +resource "aws_instance" "foo" {} +resource "aws_instance" "bar" {} +resource "aws_elb" "lb" {} +resource "do_droplet" "bar" {} diff --git a/terraform/test-fixtures/new-provider-validate/main.tf b/terraform/test-fixtures/new-provider-validate/main.tf index 1a3bc66e1..9ba300bad 100644 --- a/terraform/test-fixtures/new-provider-validate/main.tf +++ b/terraform/test-fixtures/new-provider-validate/main.tf @@ -1,5 +1,5 @@ -provider "aws" { - foo = "bar" -} - -resource "aws_instance" "foo" {} +provider "aws" { + foo = "bar" +} + +resource "aws_instance" "foo" {} diff --git a/terraform/test-fixtures/new-variables/main.tf b/terraform/test-fixtures/new-variables/main.tf index 8f6471e36..8a42d5cda 100644 --- a/terraform/test-fixtures/new-variables/main.tf +++ b/terraform/test-fixtures/new-variables/main.tf @@ -1,4 +1,4 @@ -variable "foo" {} -variable "bar" { - default = "baz" -} +variable "foo" {} +variable "bar" { + default = "baz" +} diff --git a/terraform/test-fixtures/plan-computed/main.tf b/terraform/test-fixtures/plan-computed/main.tf index a9dfe01ee..71809138b 100644 --- a/terraform/test-fixtures/plan-computed/main.tf +++ b/terraform/test-fixtures/plan-computed/main.tf @@ -1,8 +1,8 @@ -resource "aws_instance" "foo" { - num = "2" - compute = "foo" -} - -resource "aws_instance" "bar" { - foo = "${aws_instance.foo.foo}" -} +resource "aws_instance" "foo" { + num = "2" + compute = "foo" +} + +resource "aws_instance" "bar" { + foo = "${aws_instance.foo.foo}" +} diff --git a/terraform/test-fixtures/plan-count-dec/main.tf b/terraform/test-fixtures/plan-count-dec/main.tf index e4cba316c..7837f5865 100644 --- a/terraform/test-fixtures/plan-count-dec/main.tf +++ b/terraform/test-fixtures/plan-count-dec/main.tf @@ -1,7 +1,7 @@ -resource "aws_instance" "foo" { - foo = "foo" -} - -resource "aws_instance" "bar" { - foo = "bar" -} +resource "aws_instance" "foo" { + foo = "foo" +} + +resource "aws_instance" "bar" { + foo = "bar" +} diff --git a/terraform/test-fixtures/plan-count-inc/main.tf b/terraform/test-fixtures/plan-count-inc/main.tf index d5a3d8434..3c7fdb9ff 100644 --- a/terraform/test-fixtures/plan-count-inc/main.tf +++ b/terraform/test-fixtures/plan-count-inc/main.tf @@ -1,8 +1,8 @@ -resource "aws_instance" "foo" { - foo = "foo" - count = 3 -} - -resource "aws_instance" "bar" { - foo = "bar" -} +resource "aws_instance" "foo" { + foo = "foo" + count = 3 +} + +resource "aws_instance" "bar" { + foo = "bar" +} diff --git a/terraform/test-fixtures/plan-count/main.tf b/terraform/test-fixtures/plan-count/main.tf index 32e61dc28..7cf29a208 100644 --- a/terraform/test-fixtures/plan-count/main.tf +++ b/terraform/test-fixtures/plan-count/main.tf @@ -1,8 +1,8 @@ -resource "aws_instance" "foo" { - count = 5 - foo = "foo" -} - -resource "aws_instance" "bar" { - foo = "${aws_instance.foo.*.foo}" -} +resource "aws_instance" "foo" { + count = 5 + foo = "foo" +} + +resource "aws_instance" "bar" { + foo = "${aws_instance.foo.*.foo}" +} diff --git a/terraform/test-fixtures/plan-destroy/main.tf b/terraform/test-fixtures/plan-destroy/main.tf index 94ed55478..1b6cdae67 100644 --- a/terraform/test-fixtures/plan-destroy/main.tf +++ b/terraform/test-fixtures/plan-destroy/main.tf @@ -1,7 +1,7 @@ -resource "aws_instance" "foo" { - num = "2" -} - -resource "aws_instance" "bar" { - foo = "${aws_instance.foo.num}" -} +resource "aws_instance" "foo" { + num = "2" +} + +resource "aws_instance" "bar" { + foo = "${aws_instance.foo.num}" +} diff --git a/terraform/test-fixtures/plan-diffvar/main.tf b/terraform/test-fixtures/plan-diffvar/main.tf index 1dbc7c981..eadc5b71b 100644 --- a/terraform/test-fixtures/plan-diffvar/main.tf +++ b/terraform/test-fixtures/plan-diffvar/main.tf @@ -1,7 +1,7 @@ -resource "aws_instance" "foo" { - num = "2" -} - -resource "aws_instance" "bar" { - num = "${aws_instance.foo.num}" -} +resource "aws_instance" "foo" { + num = "2" +} + +resource "aws_instance" "bar" { + num = "${aws_instance.foo.num}" +} diff --git a/terraform/test-fixtures/plan-empty/main.tf b/terraform/test-fixtures/plan-empty/main.tf index 51e84d936..88002d078 100644 --- a/terraform/test-fixtures/plan-empty/main.tf +++ b/terraform/test-fixtures/plan-empty/main.tf @@ -1,5 +1,5 @@ -resource "aws_instance" "foo" { -} - -resource "aws_instance" "bar" { -} +resource "aws_instance" "foo" { +} + +resource "aws_instance" "bar" { +} diff --git a/terraform/test-fixtures/plan-good/main.tf b/terraform/test-fixtures/plan-good/main.tf index 94ed55478..1b6cdae67 100644 --- a/terraform/test-fixtures/plan-good/main.tf +++ b/terraform/test-fixtures/plan-good/main.tf @@ -1,7 +1,7 @@ -resource "aws_instance" "foo" { - num = "2" -} - -resource "aws_instance" "bar" { - foo = "${aws_instance.foo.num}" -} +resource "aws_instance" "foo" { + num = "2" +} + +resource "aws_instance" "bar" { + foo = "${aws_instance.foo.num}" +} diff --git a/terraform/test-fixtures/plan-nil/main.tf b/terraform/test-fixtures/plan-nil/main.tf index 4adbc1aca..4e1b1885c 100644 --- a/terraform/test-fixtures/plan-nil/main.tf +++ b/terraform/test-fixtures/plan-nil/main.tf @@ -1,3 +1,3 @@ -resource "aws_instance" "foo" { - nil = "1" -} +resource "aws_instance" "foo" { + nil = "1" +} diff --git a/terraform/test-fixtures/plan-orphan/main.tf b/terraform/test-fixtures/plan-orphan/main.tf index cccf922e8..98f5ee87e 100644 --- a/terraform/test-fixtures/plan-orphan/main.tf +++ b/terraform/test-fixtures/plan-orphan/main.tf @@ -1,3 +1,3 @@ -resource "aws_instance" "foo" { - num = "2" -} +resource "aws_instance" "foo" { + num = "2" +} diff --git a/terraform/test-fixtures/plan-provider-init/main.tf b/terraform/test-fixtures/plan-provider-init/main.tf index baa619eb7..ca800ad7b 100644 --- a/terraform/test-fixtures/plan-provider-init/main.tf +++ b/terraform/test-fixtures/plan-provider-init/main.tf @@ -1,9 +1,9 @@ -provider "do" { - foo = "${aws_instance.foo.num}" -} - -resource "aws_instance" "foo" { - num = "2" -} - -resource "do_droplet" "bar" {} +provider "do" { + foo = "${aws_instance.foo.num}" +} + +resource "aws_instance" "foo" { + num = "2" +} + +resource "do_droplet" "bar" {} diff --git a/terraform/test-fixtures/plan-taint/main.tf b/terraform/test-fixtures/plan-taint/main.tf index 94ed55478..1b6cdae67 100644 --- a/terraform/test-fixtures/plan-taint/main.tf +++ b/terraform/test-fixtures/plan-taint/main.tf @@ -1,7 +1,7 @@ -resource "aws_instance" "foo" { - num = "2" -} - -resource "aws_instance" "bar" { - foo = "${aws_instance.foo.num}" -} +resource "aws_instance" "foo" { + num = "2" +} + +resource "aws_instance" "bar" { + foo = "${aws_instance.foo.num}" +} diff --git a/terraform/test-fixtures/refresh-basic/main.tf b/terraform/test-fixtures/refresh-basic/main.tf index e76190a70..64cbf6236 100644 --- a/terraform/test-fixtures/refresh-basic/main.tf +++ b/terraform/test-fixtures/refresh-basic/main.tf @@ -1 +1 @@ -resource "aws_instance" "web" {} +resource "aws_instance" "web" {} diff --git a/terraform/test-fixtures/refresh-vars/main.tf b/terraform/test-fixtures/refresh-vars/main.tf index 009514f4f..86cd6ace3 100644 --- a/terraform/test-fixtures/refresh-vars/main.tf +++ b/terraform/test-fixtures/refresh-vars/main.tf @@ -1,5 +1,5 @@ -resource "aws_instance" "web" {} - -resource "aws_instance" "db" { - ami = "${aws_instance.web.id}" -} +resource "aws_instance" "web" {} + +resource "aws_instance" "db" { + ami = "${aws_instance.web.id}" +} diff --git a/terraform/test-fixtures/smc-uservars/main.tf b/terraform/test-fixtures/smc-uservars/main.tf index cfa329378..5ce22361c 100644 --- a/terraform/test-fixtures/smc-uservars/main.tf +++ b/terraform/test-fixtures/smc-uservars/main.tf @@ -1,15 +1,15 @@ -# Required -variable "foo" { -} - -# Optional -variable "bar" { - default = "baz" -} - -# Mapping -variable "map" { - default = { - "foo" = "bar"; - } -} +# Required +variable "foo" { +} + +# Optional +variable "bar" { + default = "baz" +} + +# Mapping +variable "map" { + default = { + "foo" = "bar"; + } +} diff --git a/terraform/test-fixtures/validate-bad-pc/main.tf b/terraform/test-fixtures/validate-bad-pc/main.tf index 2aada399b..70ad701e6 100644 --- a/terraform/test-fixtures/validate-bad-pc/main.tf +++ b/terraform/test-fixtures/validate-bad-pc/main.tf @@ -1,5 +1,5 @@ -provider "aws" { - foo = "bar" -} - -resource "aws_instance" "test" {} +provider "aws" { + foo = "bar" +} + +resource "aws_instance" "test" {} diff --git a/terraform/test-fixtures/validate-bad-prov-conf/main.tf b/terraform/test-fixtures/validate-bad-prov-conf/main.tf index bb239fad7..abca992de 100644 --- a/terraform/test-fixtures/validate-bad-prov-conf/main.tf +++ b/terraform/test-fixtures/validate-bad-prov-conf/main.tf @@ -1,7 +1,7 @@ -provider "aws" { - foo = "bar" -} - -resource "aws_instance" "test" { - provisioner "shell" {} -} +provider "aws" { + foo = "bar" +} + +resource "aws_instance" "test" { + provisioner "shell" {} +} diff --git a/terraform/test-fixtures/validate-bad-rc/main.tf b/terraform/test-fixtures/validate-bad-rc/main.tf index 292a1443e..152a23e0d 100644 --- a/terraform/test-fixtures/validate-bad-rc/main.tf +++ b/terraform/test-fixtures/validate-bad-rc/main.tf @@ -1,3 +1,3 @@ -resource "aws_instance" "test" { - foo = "bar" -} +resource "aws_instance" "test" { + foo = "bar" +} diff --git a/terraform/test-fixtures/validate-bad-var/main.tf b/terraform/test-fixtures/validate-bad-var/main.tf index f5c9c684f..50028453d 100644 --- a/terraform/test-fixtures/validate-bad-var/main.tf +++ b/terraform/test-fixtures/validate-bad-var/main.tf @@ -1,7 +1,7 @@ -resource "aws_instance" "foo" { - num = "2" -} - -resource "aws_instance" "bar" { - foo = "${var.foo}" -} +resource "aws_instance" "foo" { + num = "2" +} + +resource "aws_instance" "bar" { + foo = "${var.foo}" +} diff --git a/terraform/test-fixtures/validate-good/main.tf b/terraform/test-fixtures/validate-good/main.tf index f9aa393ca..fe44019b7 100644 --- a/terraform/test-fixtures/validate-good/main.tf +++ b/terraform/test-fixtures/validate-good/main.tf @@ -1,8 +1,8 @@ -resource "aws_instance" "foo" { - num = "2" - foo = "bar" -} - -resource "aws_instance" "bar" { - foo = "bar" -} +resource "aws_instance" "foo" { + num = "2" + foo = "bar" +} + +resource "aws_instance" "bar" { + foo = "bar" +} diff --git a/terraform/test-fixtures/validate-required-var/main.tf b/terraform/test-fixtures/validate-required-var/main.tf index a7907b654..bd55ea11b 100644 --- a/terraform/test-fixtures/validate-required-var/main.tf +++ b/terraform/test-fixtures/validate-required-var/main.tf @@ -1,5 +1,5 @@ -variable "foo" {} - -resource "aws_instance" "web" { - ami = "${var.foo}" -} +variable "foo" {} + +resource "aws_instance" "web" { + ami = "${var.foo}" +} diff --git a/terraform/test-fixtures/validate-self-ref-multi-all/main.tf b/terraform/test-fixtures/validate-self-ref-multi-all/main.tf index 3c5176139..d3a9857f7 100644 --- a/terraform/test-fixtures/validate-self-ref-multi-all/main.tf +++ b/terraform/test-fixtures/validate-self-ref-multi-all/main.tf @@ -1,4 +1,4 @@ -resource "aws_instance" "web" { - foo = "${aws_instance.web.*.foo}" - count = 4 -} +resource "aws_instance" "web" { + foo = "${aws_instance.web.*.foo}" + count = 4 +} diff --git a/terraform/test-fixtures/validate-self-ref-multi/main.tf b/terraform/test-fixtures/validate-self-ref-multi/main.tf index f45abb99a..5b27cac71 100644 --- a/terraform/test-fixtures/validate-self-ref-multi/main.tf +++ b/terraform/test-fixtures/validate-self-ref-multi/main.tf @@ -1,4 +1,4 @@ -resource "aws_instance" "web" { - foo = "${aws_instance.web.0.foo}" - count = 4 -} +resource "aws_instance" "web" { + foo = "${aws_instance.web.0.foo}" + count = 4 +} diff --git a/terraform/test-fixtures/validate-self-ref/main.tf b/terraform/test-fixtures/validate-self-ref/main.tf index d3b481d51..f2bf91d77 100644 --- a/terraform/test-fixtures/validate-self-ref/main.tf +++ b/terraform/test-fixtures/validate-self-ref/main.tf @@ -1,3 +1,3 @@ -resource "aws_instance" "web" { - foo = "${aws_instance.web.foo}" -} +resource "aws_instance" "web" { + foo = "${aws_instance.web.foo}" +} diff --git a/test-fixtures/config b/test-fixtures/config index bb597145d..065d20a12 100644 --- a/test-fixtures/config +++ b/test-fixtures/config @@ -1,4 +1,4 @@ -providers { - "aws" = "foo" - "do" = "bar" -} +providers { + "aws" = "foo" + "do" = "bar" +} diff --git a/website/source/docs/configuration/index.html.md b/website/source/docs/configuration/index.html.md index 6c015bfbd..422bf007b 100644 --- a/website/source/docs/configuration/index.html.md +++ b/website/source/docs/configuration/index.html.md @@ -1,23 +1,23 @@ ---- -layout: "docs" -page_title: "Configuration" -sidebar_current: "docs-config" ---- - -# Configuration - -Terraform uses text files to describe infrastructure and to set variables. -These text files are called Terraform _configurations_ and end in -`.tf`. This section talks about the format of these files as well as -how they're loaded. - -The format of the configuration files are able to be in two formats: -Terraform format and JSON. The Terraform format is more human-readable, -supports comments, and is the generally recommended format for most -Terraform files. The JSON format is meant for machines to create, -modify, and update, but can also be done by Terraform operators if -you prefer. Terraform format ends in `.tf` and JSON format ends in -`.tf.json`. - -Click a sub-section in the navigation to the left to learn more about -Terraform configuration. +--- +layout: "docs" +page_title: "Configuration" +sidebar_current: "docs-config" +--- + +# Configuration + +Terraform uses text files to describe infrastructure and to set variables. +These text files are called Terraform _configurations_ and end in +`.tf`. This section talks about the format of these files as well as +how they're loaded. + +The format of the configuration files are able to be in two formats: +Terraform format and JSON. The Terraform format is more human-readable, +supports comments, and is the generally recommended format for most +Terraform files. The JSON format is meant for machines to create, +modify, and update, but can also be done by Terraform operators if +you prefer. Terraform format ends in `.tf` and JSON format ends in +`.tf.json`. + +Click a sub-section in the navigation to the left to learn more about +Terraform configuration. diff --git a/website/source/docs/configuration/interpolation.html.md b/website/source/docs/configuration/interpolation.html.md index d2de8f35c..5399f4924 100644 --- a/website/source/docs/configuration/interpolation.html.md +++ b/website/source/docs/configuration/interpolation.html.md @@ -1,42 +1,42 @@ ---- -layout: "docs" -page_title: "Interpolation Syntax" -sidebar_current: "docs-config-interpolation" ---- - -# Interpolation Syntax - -Embedded within strings in Terraform, whether you're using the -Terraform syntax or JSON syntax, you can interpolate other values -into strings. These interpolations are wrapped in `${}`, such as -`${var.foo}`. - -The interpolation syntax is powerful and allows you to reference -variables, attributes of resources, call functions, etc. - -To reference variables, use the `var.` prefix followed by the -variable name. For example, `${var.foo}` will interpolate the -`foo` variable value. If the variable is a mapping, then you -can reference static keys in the map with the syntax -`var.MAP.KEY`. For example, `${var.amis.us-east-1}` would -get the value of the `us-east-1` key within the `amis` variable -that is a mapping. - -To reference attributes of other resources, the syntax is -`TYPE.NAME.ATTRIBUTE`. For example, `${aws_instance.web.id}` -will interpolate the ID attribute from the "aws\_instance" -resource named "web". - -Finally, Terraform ships with built-in functions. Functions -are called with the syntax `name(arg, arg2, ...)`. For example, -to read a file: `${file("path.txt")}`. The built-in functions -are documented below. - -## Built-in Functions - -The supported built-in functions are: - - * `file(path)` - Reads the contents of a file into the string. - - * `lookup(map, key)` - Performs a dynamic lookup into a mapping - variable. +--- +layout: "docs" +page_title: "Interpolation Syntax" +sidebar_current: "docs-config-interpolation" +--- + +# Interpolation Syntax + +Embedded within strings in Terraform, whether you're using the +Terraform syntax or JSON syntax, you can interpolate other values +into strings. These interpolations are wrapped in `${}`, such as +`${var.foo}`. + +The interpolation syntax is powerful and allows you to reference +variables, attributes of resources, call functions, etc. + +To reference variables, use the `var.` prefix followed by the +variable name. For example, `${var.foo}` will interpolate the +`foo` variable value. If the variable is a mapping, then you +can reference static keys in the map with the syntax +`var.MAP.KEY`. For example, `${var.amis.us-east-1}` would +get the value of the `us-east-1` key within the `amis` variable +that is a mapping. + +To reference attributes of other resources, the syntax is +`TYPE.NAME.ATTRIBUTE`. For example, `${aws_instance.web.id}` +will interpolate the ID attribute from the "aws\_instance" +resource named "web". + +Finally, Terraform ships with built-in functions. Functions +are called with the syntax `name(arg, arg2, ...)`. For example, +to read a file: `${file("path.txt")}`. The built-in functions +are documented below. + +## Built-in Functions + +The supported built-in functions are: + + * `file(path)` - Reads the contents of a file into the string. + + * `lookup(map, key)` - Performs a dynamic lookup into a mapping + variable. diff --git a/website/source/docs/configuration/load.html.md b/website/source/docs/configuration/load.html.md index 7966e89f7..e1b760894 100644 --- a/website/source/docs/configuration/load.html.md +++ b/website/source/docs/configuration/load.html.md @@ -1,34 +1,34 @@ ---- -layout: "docs" -page_title: "Load Order and Semantics" -sidebar_current: "docs-config-load" ---- - -# Load Order and Semantics - -When invoking any command that loads the Terraform configuration, -Terraform loads all configuration files within the directory -specified in alphabetical order. - -The files loaded must end in -either `.tf` or `.tf.json` to specify the format that is in use. -Otherwise, the files are ignored. Multiple file formats can -be present in the same directory; it is okay to have one Terraform -configuration file be Terraform syntax and another be JSON. - -[Override](/docs/configuration/override.html) -files are the exception, as they're loaded after all non-override -files, in alphabetical order. - -The configuration within the loaded files are appended to each -other. This is in contrast to being merged. This means that two -resources with the same name are not merged, and will instead -cause a validation error. This is in contrast to -[overrides](/docs/configuration/override.html), -which do merge. - -The order of variables, resources, etc. defined within the -configuration doesn't matter. Terraform configurations are -[declarative](http://en.wikipedia.org/wiki/Declarative_programming), -so references to other resources and variables do not depend -on the order they're defined. +--- +layout: "docs" +page_title: "Load Order and Semantics" +sidebar_current: "docs-config-load" +--- + +# Load Order and Semantics + +When invoking any command that loads the Terraform configuration, +Terraform loads all configuration files within the directory +specified in alphabetical order. + +The files loaded must end in +either `.tf` or `.tf.json` to specify the format that is in use. +Otherwise, the files are ignored. Multiple file formats can +be present in the same directory; it is okay to have one Terraform +configuration file be Terraform syntax and another be JSON. + +[Override](/docs/configuration/override.html) +files are the exception, as they're loaded after all non-override +files, in alphabetical order. + +The configuration within the loaded files are appended to each +other. This is in contrast to being merged. This means that two +resources with the same name are not merged, and will instead +cause a validation error. This is in contrast to +[overrides](/docs/configuration/override.html), +which do merge. + +The order of variables, resources, etc. defined within the +configuration doesn't matter. Terraform configurations are +[declarative](http://en.wikipedia.org/wiki/Declarative_programming), +so references to other resources and variables do not depend +on the order they're defined. diff --git a/website/source/docs/configuration/outputs.html.md b/website/source/docs/configuration/outputs.html.md index fc9ee7892..e5daae12c 100644 --- a/website/source/docs/configuration/outputs.html.md +++ b/website/source/docs/configuration/outputs.html.md @@ -1,57 +1,57 @@ ---- -layout: "docs" -page_title: "Configuring Outputs" -sidebar_current: "docs-config-outputs" ---- - -# Output Configuration - -Outputs define values that will be highlighted to the user -when Terraform applies, and can be queried easily using the -[output command](/docs/commands/output.html). Output usage -is covered in more detail in the -[getting started guide](/intro/getting-started/outputs.html). -This page covers configuration syntax for outputs. - -Terraform knows a lot about the infrastructure it manages. -Most resources have a handful or even a dozen or more attributes -associated with it. Outputs are a way to easily extract -information. - -This page assumes you're familiar with the -[configuration syntax](/docs/configuration/syntax.html) -already. - -## Example - -An output configuration looks like the following: - -``` -output "address" { - value = "${aws_instance.web.public_dns}" -} -``` - -## Decription - -The `output` block configures a single output variable. Multiple -output variables can be configured with multiple output blocks. -The `NAME` given to the output block is the name used to reference -the output variable. - -Within the block (the `{ }`) is configuration for the output. -These are the parameters that can be set: - - * `value` (required, string) - The value of the output. This must - be a string. This usually includes an interpolation since outputs - that are static aren't usually useful. - -## Syntax - -The full syntax is: - -``` -output NAME { - value = VALUE -} -``` +--- +layout: "docs" +page_title: "Configuring Outputs" +sidebar_current: "docs-config-outputs" +--- + +# Output Configuration + +Outputs define values that will be highlighted to the user +when Terraform applies, and can be queried easily using the +[output command](/docs/commands/output.html). Output usage +is covered in more detail in the +[getting started guide](/intro/getting-started/outputs.html). +This page covers configuration syntax for outputs. + +Terraform knows a lot about the infrastructure it manages. +Most resources have a handful or even a dozen or more attributes +associated with it. Outputs are a way to easily extract +information. + +This page assumes you're familiar with the +[configuration syntax](/docs/configuration/syntax.html) +already. + +## Example + +An output configuration looks like the following: + +``` +output "address" { + value = "${aws_instance.web.public_dns}" +} +``` + +## Decription + +The `output` block configures a single output variable. Multiple +output variables can be configured with multiple output blocks. +The `NAME` given to the output block is the name used to reference +the output variable. + +Within the block (the `{ }`) is configuration for the output. +These are the parameters that can be set: + + * `value` (required, string) - The value of the output. This must + be a string. This usually includes an interpolation since outputs + that are static aren't usually useful. + +## Syntax + +The full syntax is: + +``` +output NAME { + value = VALUE +} +``` diff --git a/website/source/docs/configuration/override.html.md b/website/source/docs/configuration/override.html.md index cb77da49d..e0b42c781 100644 --- a/website/source/docs/configuration/override.html.md +++ b/website/source/docs/configuration/override.html.md @@ -1,52 +1,52 @@ ---- -layout: "docs" -page_title: "Overrides" -sidebar_current: "docs-config-override" ---- - -# Overrides - -Terraform loads all configuration files within a directory and -appends them together. Terraform also has a concept of _overrides_, -a way to create files that are loaded last and _merged_ into your -configuration, rather than appended. - -Overrides have a few use cases: - - * Machines (tools) can create overrides to modify Terraform - behavior without having to edit the Terraform configuration - tailored to human readability. - - * Temporary modifications can be made to Terraform configurations - without having to modify the configuration itself. - -Overrides names must be `override` or end in `_override`, excluding -the extension. Examples of valid override files are `override.tf`, -`override.tf.json`, `temp_override.tf`. - -Override files are loaded last in alphabetical order. - -Override files can be in Terraform syntax or JSON, just like non-override -Terraform configurations. - -## Example - -If you have a Terraform configuration `example.tf` with the contents: - -``` -resource "aws_instance" "web" { - ami = "ami-1234567" -} -``` - -And you created a file `override.tf` with the contents: - -``` -resource "aws_instance" "web" { - ami = "foo" -} -``` - -Then the AMI for the one resource will be replaced with "foo". Note -that the override syntax can be Terraform syntax or JSON. You can -mix and match syntaxes without issue. +--- +layout: "docs" +page_title: "Overrides" +sidebar_current: "docs-config-override" +--- + +# Overrides + +Terraform loads all configuration files within a directory and +appends them together. Terraform also has a concept of _overrides_, +a way to create files that are loaded last and _merged_ into your +configuration, rather than appended. + +Overrides have a few use cases: + + * Machines (tools) can create overrides to modify Terraform + behavior without having to edit the Terraform configuration + tailored to human readability. + + * Temporary modifications can be made to Terraform configurations + without having to modify the configuration itself. + +Overrides names must be `override` or end in `_override`, excluding +the extension. Examples of valid override files are `override.tf`, +`override.tf.json`, `temp_override.tf`. + +Override files are loaded last in alphabetical order. + +Override files can be in Terraform syntax or JSON, just like non-override +Terraform configurations. + +## Example + +If you have a Terraform configuration `example.tf` with the contents: + +``` +resource "aws_instance" "web" { + ami = "ami-1234567" +} +``` + +And you created a file `override.tf` with the contents: + +``` +resource "aws_instance" "web" { + ami = "foo" +} +``` + +Then the AMI for the one resource will be replaced with "foo". Note +that the override syntax can be Terraform syntax or JSON. You can +mix and match syntaxes without issue. diff --git a/website/source/docs/configuration/providers.html.md b/website/source/docs/configuration/providers.html.md index d1c9b8d63..f2f4204ee 100644 --- a/website/source/docs/configuration/providers.html.md +++ b/website/source/docs/configuration/providers.html.md @@ -1,76 +1,76 @@ ---- -layout: "docs" -page_title: "Configuring Providers" -sidebar_current: "docs-config-providers" ---- - -# Provider Configuration - -Providers are responsible in Terraform for managing the lifecycle -of a [resource](/docs/configuration/resource.html): create, -read, update, delete. - -Every resource in Terraform is mapped to a provider based -on longest-prefix matching. For example the `aws_instance` -resource type would map to the `aws` provider (if that exists). - -Most providers require some sort of configuration to provide -authentication information, endpoint URLs, etc. Provider configuration -blocks are a way to set this information globally for all -matching resources. - -This page assumes you're familiar with the -[configuration syntax](/docs/configuration/syntax.html) -already. - -## Example - -A provider configuration looks like the following: - -``` -provider "aws" { - access_key = "foo" - secret_key = "bar" - region = "us-east-1" -} -``` - -## Decription - -The `provider` block configures the provider of the given `NAME`. -Multiple provider blocks can be used to configure multiple providers. - -Terraform matches providers to resources by matching two criteria. -Both criteria must be matched for a provider to manage a resource: - - * They must share a common prefix. Longest matching prefixes are - tried first. For example, `aws_instance` would choose the - `aws` provider. - - * The provider must report that it supports the given resource - type. Providers internally tell Terraform the list of resources - they support. - -Within the block (the `{ }`) is configuration for the resource. -The configuration is dependent on the type, and is documented -[for each provider](/docs/providers/index.html). - -## Syntax - -The full syntax is: - -``` -provider NAME { - CONFIG ... -} -``` - -where `CONFIG` is: - -``` -KEY = VALUE - -KEY { - CONFIG -} -``` +--- +layout: "docs" +page_title: "Configuring Providers" +sidebar_current: "docs-config-providers" +--- + +# Provider Configuration + +Providers are responsible in Terraform for managing the lifecycle +of a [resource](/docs/configuration/resource.html): create, +read, update, delete. + +Every resource in Terraform is mapped to a provider based +on longest-prefix matching. For example the `aws_instance` +resource type would map to the `aws` provider (if that exists). + +Most providers require some sort of configuration to provide +authentication information, endpoint URLs, etc. Provider configuration +blocks are a way to set this information globally for all +matching resources. + +This page assumes you're familiar with the +[configuration syntax](/docs/configuration/syntax.html) +already. + +## Example + +A provider configuration looks like the following: + +``` +provider "aws" { + access_key = "foo" + secret_key = "bar" + region = "us-east-1" +} +``` + +## Decription + +The `provider` block configures the provider of the given `NAME`. +Multiple provider blocks can be used to configure multiple providers. + +Terraform matches providers to resources by matching two criteria. +Both criteria must be matched for a provider to manage a resource: + + * They must share a common prefix. Longest matching prefixes are + tried first. For example, `aws_instance` would choose the + `aws` provider. + + * The provider must report that it supports the given resource + type. Providers internally tell Terraform the list of resources + they support. + +Within the block (the `{ }`) is configuration for the resource. +The configuration is dependent on the type, and is documented +[for each provider](/docs/providers/index.html). + +## Syntax + +The full syntax is: + +``` +provider NAME { + CONFIG ... +} +``` + +where `CONFIG` is: + +``` +KEY = VALUE + +KEY { + CONFIG +} +``` diff --git a/website/source/docs/configuration/resources.html.md b/website/source/docs/configuration/resources.html.md index 00b4a30cb..1e1d3d1c2 100644 --- a/website/source/docs/configuration/resources.html.md +++ b/website/source/docs/configuration/resources.html.md @@ -1,124 +1,124 @@ ---- -layout: "docs" -page_title: "Configuring Resources" -sidebar_current: "docs-config-resources" ---- - -# Resource Configuration - -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. - -This page assumes you're familiar with the -[configuration syntax](/docs/configuration/syntax.html) -already. - -## Example - -A resource configuration looks like the following: - -``` -resource "aws_instance" "web" { - ami = "ami-123456" - instance_type = "m1.small" -} -``` - -## Decription - -The `resource` block creates a resource of the given `TYPE` (first -parameter) and `NAME` (second parameter). The combination of the type -and name must be unique. - -Within the block (the `{ }`) is configuration for the resource. The -configuration is dependent on the type, and is documented for each -resource type in the -[providers section](/docs/providers/index.html). - -There are **meta-parameters** available to all resources: - - * `count` (int) - The number of identical resources to create. - This doesn't apply to all resources. - - * `depends_on` (list of strings) - Explicit dependencies that this - resource has. These dependencies will be created before this - resource. The dependencies are in the format of `TYPE.NAME`, - for example `aws_instance.web`. - -------------- - -Within a resource, you can optionally have a **connection block**. -Connection blocks describe to Terraform how to connect to the -resource for -[provisioning](/docs/provisioners/index.html). This block doesn't -need to be present if you're using only local provisioners, or -if you're not provisioning at all. - -Resources provide some data on their own, such as an IP address, -but other data must be specified by the user. - -The full list of settings that can be specified are listed on -the [provisioner connection page](/docs/provisioners/connection.html). - -------------- - -Within a resource, you can specify zero or more **provisioner -blocks**. Provisioner blocks configure -[provisioners](/docs/provisioners/index.html). - -Within the provisioner block is provisioner-specific configuration, -much like resource-specific configuration. - -Provisioner blocks can also contain a connection block -(documented above). This connection block can be used to -provide more specific connection info for a specific provisioner. -An example use case might be to use a different user to log in -for a single provisioner. - -## Syntax - -The full syntax is: - -``` -resource TYPE NAME { - CONFIG ... - [count = COUNT] - [depends_on = [RESOURCE NAME, ...]] - - [CONNECTION] - [PROVISIONER ...] -} -``` - -where `CONFIG` is: - -``` -KEY = VALUE - -KEY { - CONFIG -} -``` - -where `CONNECTION` is: - -``` -connection { - KEY = VALUE - ... -} -``` - -where `PROVISIONER` is: - -``` -provisioner NAME { - CONFIG ... - - [CONNECTION] -} -``` +--- +layout: "docs" +page_title: "Configuring Resources" +sidebar_current: "docs-config-resources" +--- + +# Resource Configuration + +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. + +This page assumes you're familiar with the +[configuration syntax](/docs/configuration/syntax.html) +already. + +## Example + +A resource configuration looks like the following: + +``` +resource "aws_instance" "web" { + ami = "ami-123456" + instance_type = "m1.small" +} +``` + +## Decription + +The `resource` block creates a resource of the given `TYPE` (first +parameter) and `NAME` (second parameter). The combination of the type +and name must be unique. + +Within the block (the `{ }`) is configuration for the resource. The +configuration is dependent on the type, and is documented for each +resource type in the +[providers section](/docs/providers/index.html). + +There are **meta-parameters** available to all resources: + + * `count` (int) - The number of identical resources to create. + This doesn't apply to all resources. + + * `depends_on` (list of strings) - Explicit dependencies that this + resource has. These dependencies will be created before this + resource. The dependencies are in the format of `TYPE.NAME`, + for example `aws_instance.web`. + +------------- + +Within a resource, you can optionally have a **connection block**. +Connection blocks describe to Terraform how to connect to the +resource for +[provisioning](/docs/provisioners/index.html). This block doesn't +need to be present if you're using only local provisioners, or +if you're not provisioning at all. + +Resources provide some data on their own, such as an IP address, +but other data must be specified by the user. + +The full list of settings that can be specified are listed on +the [provisioner connection page](/docs/provisioners/connection.html). + +------------- + +Within a resource, you can specify zero or more **provisioner +blocks**. Provisioner blocks configure +[provisioners](/docs/provisioners/index.html). + +Within the provisioner block is provisioner-specific configuration, +much like resource-specific configuration. + +Provisioner blocks can also contain a connection block +(documented above). This connection block can be used to +provide more specific connection info for a specific provisioner. +An example use case might be to use a different user to log in +for a single provisioner. + +## Syntax + +The full syntax is: + +``` +resource TYPE NAME { + CONFIG ... + [count = COUNT] + [depends_on = [RESOURCE NAME, ...]] + + [CONNECTION] + [PROVISIONER ...] +} +``` + +where `CONFIG` is: + +``` +KEY = VALUE + +KEY { + CONFIG +} +``` + +where `CONNECTION` is: + +``` +connection { + KEY = VALUE + ... +} +``` + +where `PROVISIONER` is: + +``` +provisioner NAME { + CONFIG ... + + [CONNECTION] +} +``` diff --git a/website/source/docs/configuration/syntax.html.md b/website/source/docs/configuration/syntax.html.md index c162d2ec6..7cb13fa1e 100644 --- a/website/source/docs/configuration/syntax.html.md +++ b/website/source/docs/configuration/syntax.html.md @@ -1,127 +1,127 @@ ---- -layout: "docs" -page_title: "Configuration Syntax" -sidebar_current: "docs-config-syntax" ---- - -# Configuration Syntax - -The syntax of Terraform configurations is custom. It is meant to -strike a balance between human readable and editable as well as being -machine-friendly. For machine-friendliness, Terraform can also -read JSON configurations. For general Terraform configurations, -however, we recommend using the Terraform syntax. - -## Terraform Syntax - -Here is an example of Terraform syntax: - -``` -# An AMI -variable "ami" { - description = "the AMI to use" -} - -/* A multi - line comment. */ -resource "aws_instance" "web" { - ami = "${var.ami}" - count = 2 - source_dest_check = false - - connection { - user = "root" - } -} -``` - -Basic bullet point reference: - - * Single line comments start with `#` - - * Multi-line comments are wrapped with `/*` and `*/` - - * Values are assigned with the syntax of `key = value` (whitespace - doesn't matter). The value can be any primitive: a string, - number, or boolean. - - * Strings are in double-quotes. - - * Strings can interpolate other values using syntax wrapped - in `${}`, such as `${var.foo}`. The full syntax for interpolation - is - [documented here](/docs/configuration/interpolation.html). - - * Numbers are assumed to be base 10. If you prefix a number with - `0x`, it is treated as a hexadecimal number. - - * Numbers can be suffxed with `kKmMgG` for some multiple of 10. - For example: `1k` is equal to `1000`. - - * Numbers can be suffxed with `[kKmMgG]b` for power of 2 multiples, - example: `1kb` is equal to `1024`. - - * Boolean values: `true`, `false`, `on`, `off`, `yes`, `no`. - - * Arrays of primitive types can be made by wrapping it in `[]`. - Example: `["foo", "bar", 42]`. - - * Maps can be made with the `{}` syntax: - `{ "foo": "bar", "bar": "baz" }`. - -In addition to the basics, the syntax supports hierarchies of sections, -such as the "resource" and "variable" in the example above. These -sections are similar to maps, but visually look better. For example, -these are nearly equivalent: - -``` -variable "ami" { - description = "the AMI to use" -} - -# is equal to: - -variable = [{ - "ami": { - "description": "the AMI to use", - } -}] -``` - -Notice that the top visually looks a lot better? By repeating multiple -`variable` sections, it adds the `variable` array. When possible, use -sections since they're visually clearer and more reasily readable. - -## JSON Syntax - -Terraform also supports reading JSON formatted configuration files. -The above example converted to JSON: - -```json -{ - "variable": { - "ami": { - "description": "the AMI to use" - } - }, - - "resource": { - "aws_instance": { - "web": { - "ami": "${var.ami}", - "count": 2, - "source_dest_check": false, - - "connection": { - "user": "root" - } - } - } - } -} -``` - -The conversion should be pretty straightforward and self-documented. - -The downsides of JSON are less human readability and the lack of -comments. Otherwise, the two are completely interoperable. +--- +layout: "docs" +page_title: "Configuration Syntax" +sidebar_current: "docs-config-syntax" +--- + +# Configuration Syntax + +The syntax of Terraform configurations is custom. It is meant to +strike a balance between human readable and editable as well as being +machine-friendly. For machine-friendliness, Terraform can also +read JSON configurations. For general Terraform configurations, +however, we recommend using the Terraform syntax. + +## Terraform Syntax + +Here is an example of Terraform syntax: + +``` +# An AMI +variable "ami" { + description = "the AMI to use" +} + +/* A multi + line comment. */ +resource "aws_instance" "web" { + ami = "${var.ami}" + count = 2 + source_dest_check = false + + connection { + user = "root" + } +} +``` + +Basic bullet point reference: + + * Single line comments start with `#` + + * Multi-line comments are wrapped with `/*` and `*/` + + * Values are assigned with the syntax of `key = value` (whitespace + doesn't matter). The value can be any primitive: a string, + number, or boolean. + + * Strings are in double-quotes. + + * Strings can interpolate other values using syntax wrapped + in `${}`, such as `${var.foo}`. The full syntax for interpolation + is + [documented here](/docs/configuration/interpolation.html). + + * Numbers are assumed to be base 10. If you prefix a number with + `0x`, it is treated as a hexadecimal number. + + * Numbers can be suffxed with `kKmMgG` for some multiple of 10. + For example: `1k` is equal to `1000`. + + * Numbers can be suffxed with `[kKmMgG]b` for power of 2 multiples, + example: `1kb` is equal to `1024`. + + * Boolean values: `true`, `false`, `on`, `off`, `yes`, `no`. + + * Arrays of primitive types can be made by wrapping it in `[]`. + Example: `["foo", "bar", 42]`. + + * Maps can be made with the `{}` syntax: + `{ "foo": "bar", "bar": "baz" }`. + +In addition to the basics, the syntax supports hierarchies of sections, +such as the "resource" and "variable" in the example above. These +sections are similar to maps, but visually look better. For example, +these are nearly equivalent: + +``` +variable "ami" { + description = "the AMI to use" +} + +# is equal to: + +variable = [{ + "ami": { + "description": "the AMI to use", + } +}] +``` + +Notice that the top visually looks a lot better? By repeating multiple +`variable` sections, it adds the `variable` array. When possible, use +sections since they're visually clearer and more reasily readable. + +## JSON Syntax + +Terraform also supports reading JSON formatted configuration files. +The above example converted to JSON: + +```json +{ + "variable": { + "ami": { + "description": "the AMI to use" + } + }, + + "resource": { + "aws_instance": { + "web": { + "ami": "${var.ami}", + "count": 2, + "source_dest_check": false, + + "connection": { + "user": "root" + } + } + } + } +} +``` + +The conversion should be pretty straightforward and self-documented. + +The downsides of JSON are less human readability and the lack of +comments. Otherwise, the two are completely interoperable. diff --git a/website/source/docs/configuration/variables.html.md b/website/source/docs/configuration/variables.html.md index 59b37fdc4..706dc81a0 100644 --- a/website/source/docs/configuration/variables.html.md +++ b/website/source/docs/configuration/variables.html.md @@ -1,111 +1,111 @@ ---- -layout: "docs" -page_title: "Configuring Variables" -sidebar_current: "docs-config-variables" ---- - -# Variable Configuration - -Variables define the parameterization of Terraform configurations. -Variables can be overridden via the CLI. Variable usage is -covered in more detail in the -[getting started guide](/intro/getting-started/variables.html). -This page covers configuration syntax for variables. - -This page assumes you're familiar with the -[configuration syntax](/docs/configuration/syntax.html) -already. - -## Example - -A variable configuration looks like the following: - -``` -variable "key" {} - -variable "images" { - default = { - "us-east-1": "image-1234", - "us-west-2": "image-4567", - } -} -``` - -## Decription - -The `variable` block configures a single input variable for -a Terraform configuration. Multiple variables blocks can be used to -add multiple variables. - -The `NAME` given to the variable block is the name used to -set the variable via the CLI as well as reference the variable -throughout the Terraform configuration. - -Within the block (the `{ }`) is configuration for the variable. -These are the parameters that can be set: - - * `default` (optional) - If set, this sets a default value - for the variable. If this isn't set, the variable is required - and Terraform will error if not set. The default value can be - a string or a mapping. This is covered in more detail below. - - * `description` (optional) - A human-friendly description for - the variable. This is primarily for documentation for users - using your Terraform configuration. A future version of Terraform - will expose these descriptions as part of some Terraform CLI - command. - ------- - -**Default values** can be either strings or maps. If a default -value is omitted and the variable is required, the value assigned -via the CLI must be a string. - -String values are simple and represent a basic key to value -mapping where the key is the variable name. An example is: - -``` -variable "key" { - default = "value" -} -``` - -A map allows a key to contain a lookup table. This is useful -for some values that change depending on some external pivot. -A common use case for this is mapping cloud images to regions. -An example: - -``` -variable "images" { - default = { - "us-east-1": "image-1234", - "us-west-2": "image-4567", - } -} -``` - -The usage of maps, strings, etc. is documented fully in the -[interpolation syntax](/docs/configuration/interpolation.html) -page. - -## Syntax - -The full syntax is: - -``` -variable NAME { - [default = DEFAULT] - [description = DESCRIPTION] -} -``` - -where `DEFAULT` is: - -``` -VALUE - -{ - KEY: VALUE, - ... -} -``` +--- +layout: "docs" +page_title: "Configuring Variables" +sidebar_current: "docs-config-variables" +--- + +# Variable Configuration + +Variables define the parameterization of Terraform configurations. +Variables can be overridden via the CLI. Variable usage is +covered in more detail in the +[getting started guide](/intro/getting-started/variables.html). +This page covers configuration syntax for variables. + +This page assumes you're familiar with the +[configuration syntax](/docs/configuration/syntax.html) +already. + +## Example + +A variable configuration looks like the following: + +``` +variable "key" {} + +variable "images" { + default = { + "us-east-1": "image-1234", + "us-west-2": "image-4567", + } +} +``` + +## Decription + +The `variable` block configures a single input variable for +a Terraform configuration. Multiple variables blocks can be used to +add multiple variables. + +The `NAME` given to the variable block is the name used to +set the variable via the CLI as well as reference the variable +throughout the Terraform configuration. + +Within the block (the `{ }`) is configuration for the variable. +These are the parameters that can be set: + + * `default` (optional) - If set, this sets a default value + for the variable. If this isn't set, the variable is required + and Terraform will error if not set. The default value can be + a string or a mapping. This is covered in more detail below. + + * `description` (optional) - A human-friendly description for + the variable. This is primarily for documentation for users + using your Terraform configuration. A future version of Terraform + will expose these descriptions as part of some Terraform CLI + command. + +------ + +**Default values** can be either strings or maps. If a default +value is omitted and the variable is required, the value assigned +via the CLI must be a string. + +String values are simple and represent a basic key to value +mapping where the key is the variable name. An example is: + +``` +variable "key" { + default = "value" +} +``` + +A map allows a key to contain a lookup table. This is useful +for some values that change depending on some external pivot. +A common use case for this is mapping cloud images to regions. +An example: + +``` +variable "images" { + default = { + "us-east-1": "image-1234", + "us-west-2": "image-4567", + } +} +``` + +The usage of maps, strings, etc. is documented fully in the +[interpolation syntax](/docs/configuration/interpolation.html) +page. + +## Syntax + +The full syntax is: + +``` +variable NAME { + [default = DEFAULT] + [description = DESCRIPTION] +} +``` + +where `DEFAULT` is: + +``` +VALUE + +{ + KEY: VALUE, + ... +} +``` diff --git a/website/source/docs/internals/graph.html.md b/website/source/docs/internals/graph.html.md index 70b49a45b..55f995332 100644 --- a/website/source/docs/internals/graph.html.md +++ b/website/source/docs/internals/graph.html.md @@ -1,98 +1,98 @@ ---- -layout: "docs" -page_title: "Resource Graph" -sidebar_current: "docs-internals-graph" ---- - -# Resource Graph - -Terraform builds a -[dependency graph](http://en.wikipedia.org/wiki/Dependency_graph) -from the Terraform configurations, and walks this graph to -generate plans, refresh state, and more. This page documents -the details of what are contained in this graph, what types -of nodes there are, and how the edges of the graph are determined. - -
-Advanced Topic! This page covers technical details -of Terraform. You don't need to understand these details to -effectively use Terraform. The details are documented here for -those who wish to learn about them without having to go -spelunking through the source code. -
- -## Graph Nodes - -There are only a handful of node types that can exist within the -graph. We'll cover these first before explaining how they're -determined and built: - - * **Resource Node** - Represents a single resource. If you have - the `count` metaparameter set, then there will be one resource - node for each count. The configuration, diff, state, etc. of - the resource under change is attached to this node. - - * **Provider Configuration Node** - Represents the time to fully - configure a provider. This is when the provider configuration - block is given to a provider, such as AWS security credentials. - - * **Resource Meta-Node** - Represents a group of resources, but - does not represent any action on its own. This is done for - convenience on dependencies and making a prettier graph. This - node is only present for resources that have a `count` - parameter greater than 1. - -When visualizing a configuration with `terraform graph`, you can -see all of these nodes present. - -## Building the Graph - -Building the graph is done in a series of sequential steps: - - 1. Resources nodes are added based on the configuration. If a - diff (plan) or state is present, that meta-data is attached - to each resource node. - - 1. Resources are mapped to provisioners if they have any - defined. This must be done after all resource nodes are - created so resources with the same provisioner type can - share the provisioner implementation. - - 1. Explicit dependencies from the `depends_on` meta-parameter - are used to create edges between resources. - - 1. If a state is present, any "orphan" resources are added to - the graph. Orphan resources are any resources that are no - longer present in the configuration but are present in the - state file. Orphans never have any configuration associated - with them, since the state file does not store configuration. - - 1. Resources are mapped to providers. Provider configuration - nodes are created for these providers, and edges are created - such that the resources depend on their respective provider - being configured. - - 1. Interpolations are parsed in resource and provider configurations - to determine dependencies. References to resource attributes - are turned into dependencies from the resource with the interpolation - to the resource being referenced. - - 1. Create a root node. The root node points to all resources and - is created so there is a single root to the dependency graph. When - traversing the graph, the root node is ignored. - - 1. If a diff is present, traverse all resource nodes and find resources - that are being destroyed. These resource nodes are split into two: - one node that destroys the resource and another that creates - the resource (if it is being recreated). The reason the nodes must - be split is because the destroy order is often different from the - create order, and so they can't be represented by a single graph - node. - - 1. Validate the graph has no cycles and has a single root. - -## Walking the Graph - -To walk the graph, a standard depth-first traversal is done. Graph -walking is done with as much parallelism as possible: a node is walked -as soon as all of its dependencies are walked. +--- +layout: "docs" +page_title: "Resource Graph" +sidebar_current: "docs-internals-graph" +--- + +# Resource Graph + +Terraform builds a +[dependency graph](http://en.wikipedia.org/wiki/Dependency_graph) +from the Terraform configurations, and walks this graph to +generate plans, refresh state, and more. This page documents +the details of what are contained in this graph, what types +of nodes there are, and how the edges of the graph are determined. + +
+Advanced Topic! This page covers technical details +of Terraform. You don't need to understand these details to +effectively use Terraform. The details are documented here for +those who wish to learn about them without having to go +spelunking through the source code. +
+ +## Graph Nodes + +There are only a handful of node types that can exist within the +graph. We'll cover these first before explaining how they're +determined and built: + + * **Resource Node** - Represents a single resource. If you have + the `count` metaparameter set, then there will be one resource + node for each count. The configuration, diff, state, etc. of + the resource under change is attached to this node. + + * **Provider Configuration Node** - Represents the time to fully + configure a provider. This is when the provider configuration + block is given to a provider, such as AWS security credentials. + + * **Resource Meta-Node** - Represents a group of resources, but + does not represent any action on its own. This is done for + convenience on dependencies and making a prettier graph. This + node is only present for resources that have a `count` + parameter greater than 1. + +When visualizing a configuration with `terraform graph`, you can +see all of these nodes present. + +## Building the Graph + +Building the graph is done in a series of sequential steps: + + 1. Resources nodes are added based on the configuration. If a + diff (plan) or state is present, that meta-data is attached + to each resource node. + + 1. Resources are mapped to provisioners if they have any + defined. This must be done after all resource nodes are + created so resources with the same provisioner type can + share the provisioner implementation. + + 1. Explicit dependencies from the `depends_on` meta-parameter + are used to create edges between resources. + + 1. If a state is present, any "orphan" resources are added to + the graph. Orphan resources are any resources that are no + longer present in the configuration but are present in the + state file. Orphans never have any configuration associated + with them, since the state file does not store configuration. + + 1. Resources are mapped to providers. Provider configuration + nodes are created for these providers, and edges are created + such that the resources depend on their respective provider + being configured. + + 1. Interpolations are parsed in resource and provider configurations + to determine dependencies. References to resource attributes + are turned into dependencies from the resource with the interpolation + to the resource being referenced. + + 1. Create a root node. The root node points to all resources and + is created so there is a single root to the dependency graph. When + traversing the graph, the root node is ignored. + + 1. If a diff is present, traverse all resource nodes and find resources + that are being destroyed. These resource nodes are split into two: + one node that destroys the resource and another that creates + the resource (if it is being recreated). The reason the nodes must + be split is because the destroy order is often different from the + create order, and so they can't be represented by a single graph + node. + + 1. Validate the graph has no cycles and has a single root. + +## Walking the Graph + +To walk the graph, a standard depth-first traversal is done. Graph +walking is done with as much parallelism as possible: a node is walked +as soon as all of its dependencies are walked. diff --git a/website/source/docs/internals/index.html.md b/website/source/docs/internals/index.html.md index ad2a08192..bde40ef03 100644 --- a/website/source/docs/internals/index.html.md +++ b/website/source/docs/internals/index.html.md @@ -1,19 +1,19 @@ ---- -layout: "docs" -page_title: "Internals" -sidebar_current: "docs-internals" ---- - -# Terraform Internals - -This section covers the internals of Terraform and explains how -plans are generated, the lifecycle of a provider, etc. The goal -of this section is to remove any notion of "magic" from Terraform. -We want you to be able to trust and understand what Terraform is -doing to function. - -
-Note: Knowledge of Terraform internals is not -required to use Terraform. If you aren't interested in the internals -of Terraform, you may safely skip this section. -
+--- +layout: "docs" +page_title: "Internals" +sidebar_current: "docs-internals" +--- + +# Terraform Internals + +This section covers the internals of Terraform and explains how +plans are generated, the lifecycle of a provider, etc. The goal +of this section is to remove any notion of "magic" from Terraform. +We want you to be able to trust and understand what Terraform is +doing to function. + +
+Note: Knowledge of Terraform internals is not +required to use Terraform. If you aren't interested in the internals +of Terraform, you may safely skip this section. +
diff --git a/website/source/docs/internals/lifecycle.html.md b/website/source/docs/internals/lifecycle.html.md index aa072dfd9..d39b6000b 100644 --- a/website/source/docs/internals/lifecycle.html.md +++ b/website/source/docs/internals/lifecycle.html.md @@ -1,58 +1,58 @@ ---- -layout: "docs" -page_title: "Resource Lifecycle" -sidebar_current: "docs-internals-lifecycle" ---- - -# Resource Lifecycle - -Resources have a strict lifecycle, and can be thought of as basic -state machines. Understanding this lifecycle can help better understand -how Terraform generates an execution plan, how it safely executes that -plan, and what the resource provider is doing throughout all of this. - -
-Advanced Topic! This page covers technical details -of Terraform. You don't need to understand these details to -effectively use Terraform. The details are documented here for -those who wish to learn about them without having to go -spelunking through the source code. -
- -## Lifecycle - -A resource roughly follows the steps below: - - 1. `ValidateResource` is called to do a high-level structural - validation of a resource's configuration. The configuration - at this point is raw and the interpolations have not been processed. - The value of any key is not guaranteed and is just meant to be - a quick structural check. - - 1. `Diff` is called with the current state and the configuration. - The resource provider inspects this and returns a diff, outlining - all the changes that need to occur to the resource. The diff includes - details such as whether or not the resource is being destroyed, what - attribute necessitates the destroy, old values and new values, whether - a value is computed, etc. It is up to the resource provider to - have this knowledge. - - 1. `Apply` is called with the current state and the diff. Apply does - not have access to the configuration. This is a safety mechanism - that limits the possibility that a provider changes a diff on the - fly. `Apply` must apply a diff as prescribed and do nothing else - to remain true to the Terraform execution plan. Apply returns the - new state of the resource (or nil if the resource was destroyed). - - 1. If a resource was just created and did not exist before, and the - apply succeeded without error, then the provisioners are executed - in sequence. If any provisioner errors, the resource is marked as - _tainted_, so that it will be destroyed on the next apply. - -## Partial State and Error Handling - -If an error happens at any stage in the lifecycle of a resource, -Terraform stores a partial state of the resource. This behavior is -critical for Terraform to ensure that you don't end up with any -_zombie_ resources: resources that were created by Terraform but -no longer managed by Terraform due to a loss of state. +--- +layout: "docs" +page_title: "Resource Lifecycle" +sidebar_current: "docs-internals-lifecycle" +--- + +# Resource Lifecycle + +Resources have a strict lifecycle, and can be thought of as basic +state machines. Understanding this lifecycle can help better understand +how Terraform generates an execution plan, how it safely executes that +plan, and what the resource provider is doing throughout all of this. + +
+Advanced Topic! This page covers technical details +of Terraform. You don't need to understand these details to +effectively use Terraform. The details are documented here for +those who wish to learn about them without having to go +spelunking through the source code. +
+ +## Lifecycle + +A resource roughly follows the steps below: + + 1. `ValidateResource` is called to do a high-level structural + validation of a resource's configuration. The configuration + at this point is raw and the interpolations have not been processed. + The value of any key is not guaranteed and is just meant to be + a quick structural check. + + 1. `Diff` is called with the current state and the configuration. + The resource provider inspects this and returns a diff, outlining + all the changes that need to occur to the resource. The diff includes + details such as whether or not the resource is being destroyed, what + attribute necessitates the destroy, old values and new values, whether + a value is computed, etc. It is up to the resource provider to + have this knowledge. + + 1. `Apply` is called with the current state and the diff. Apply does + not have access to the configuration. This is a safety mechanism + that limits the possibility that a provider changes a diff on the + fly. `Apply` must apply a diff as prescribed and do nothing else + to remain true to the Terraform execution plan. Apply returns the + new state of the resource (or nil if the resource was destroyed). + + 1. If a resource was just created and did not exist before, and the + apply succeeded without error, then the provisioners are executed + in sequence. If any provisioner errors, the resource is marked as + _tainted_, so that it will be destroyed on the next apply. + +## Partial State and Error Handling + +If an error happens at any stage in the lifecycle of a resource, +Terraform stores a partial state of the resource. This behavior is +critical for Terraform to ensure that you don't end up with any +_zombie_ resources: resources that were created by Terraform but +no longer managed by Terraform due to a loss of state. diff --git a/website/source/docs/plugins/index.html.md b/website/source/docs/plugins/index.html.md index 24091852e..cbc3bc4c0 100644 --- a/website/source/docs/plugins/index.html.md +++ b/website/source/docs/plugins/index.html.md @@ -1,24 +1,24 @@ ---- -layout: "docs" -page_title: "Plugins" -sidebar_current: "docs-plugins" ---- - -# Plugins - -Terraform is built on a plugin-based architecture. All providers and -provisioners that are used in Terraform configurations are plugins, even -the core types such as AWS and Heroku. Users of Terraform are able to -write new plugins in order to support new functionality in Terraform. - -This section of the documentation gives a high-level overview of how -to write plugins for Terraform. It does not hold your hand through the -process, however, and expects a relatively high level of understanding -of Go, provider semantics, Unix, etc. - -
-Advanced topic! Plugin development is a highly advanced -topic in Terraform, and is not required knowledge for day-to-day usage. -If you don't plan on writing any plugins, we recommend not reading -this section of the documentation. -
+--- +layout: "docs" +page_title: "Plugins" +sidebar_current: "docs-plugins" +--- + +# Plugins + +Terraform is built on a plugin-based architecture. All providers and +provisioners that are used in Terraform configurations are plugins, even +the core types such as AWS and Heroku. Users of Terraform are able to +write new plugins in order to support new functionality in Terraform. + +This section of the documentation gives a high-level overview of how +to write plugins for Terraform. It does not hold your hand through the +process, however, and expects a relatively high level of understanding +of Go, provider semantics, Unix, etc. + +
+Advanced topic! Plugin development is a highly advanced +topic in Terraform, and is not required knowledge for day-to-day usage. +If you don't plan on writing any plugins, we recommend not reading +this section of the documentation. +
diff --git a/website/source/docs/plugins/provider.html.md b/website/source/docs/plugins/provider.html.md index 6b724a289..f1389bfa3 100644 --- a/website/source/docs/plugins/provider.html.md +++ b/website/source/docs/plugins/provider.html.md @@ -1,41 +1,41 @@ ---- -layout: "docs" -page_title: "Provider Plugins" -sidebar_current: "docs-plugins-provider" ---- - -# Provider Plugins - -A provider in Terraform is responsible for the lifecycle of a resource: -create, read, update, delete. An example of a provider is AWS, which -can manage resources of type `aws_instance`, `aws_eip`, `aws_elb`, etc. - -The primary reasons to care about provider plugins are: - - * You want to add a new resource type to an existing provider. - - * You want to write a completely new provider for managing resource - types in a system not yet supported. - - * You want to write a completely new provider for custom, internal - systems such as a private inventory management system. - -
-Advanced topic! Plugin development is a highly advanced -topic in Terraform, and is not required knowledge for day-to-day usage. -If you don't plan on writing any plugins, we recommend not reading -this section of the documentation. -
- -## Coming Soon! - -The documentation for writing custom providers is coming soon. In the -mean time, you can look at how our -[built-in providers are written](https://github.com/hashicorp/terraform/tree/master/builtin). -We recommend copying as much as possible from our providers when working -on yours. - -We're also rapidly working on improving the high-level helpers for -writing providers. We expect that writing providers will become much -easier very shortly, and acknowledge that writing them now is not the -easiest thing to do. +--- +layout: "docs" +page_title: "Provider Plugins" +sidebar_current: "docs-plugins-provider" +--- + +# Provider Plugins + +A provider in Terraform is responsible for the lifecycle of a resource: +create, read, update, delete. An example of a provider is AWS, which +can manage resources of type `aws_instance`, `aws_eip`, `aws_elb`, etc. + +The primary reasons to care about provider plugins are: + + * You want to add a new resource type to an existing provider. + + * You want to write a completely new provider for managing resource + types in a system not yet supported. + + * You want to write a completely new provider for custom, internal + systems such as a private inventory management system. + +
+Advanced topic! Plugin development is a highly advanced +topic in Terraform, and is not required knowledge for day-to-day usage. +If you don't plan on writing any plugins, we recommend not reading +this section of the documentation. +
+ +## Coming Soon! + +The documentation for writing custom providers is coming soon. In the +mean time, you can look at how our +[built-in providers are written](https://github.com/hashicorp/terraform/tree/master/builtin). +We recommend copying as much as possible from our providers when working +on yours. + +We're also rapidly working on improving the high-level helpers for +writing providers. We expect that writing providers will become much +easier very shortly, and acknowledge that writing them now is not the +easiest thing to do. diff --git a/website/source/intro/examples/aws.html.markdown b/website/source/intro/examples/aws.html.markdown index 7a5ca0488..db1829b86 100644 --- a/website/source/intro/examples/aws.html.markdown +++ b/website/source/intro/examples/aws.html.markdown @@ -1,150 +1,150 @@ ---- -layout: "intro" -page_title: "Basic Two-Tier AWS Architecture" -sidebar_current: "examples-aws" ---- - -# Basic Two-Tier AWS Architecture - -This provides a template for running a simple two-tier architecture on Amazon -Web services. - -The basic premise is you have stateless app servers running behind -an ELB serving traffic. - -To simplify the example, this intentionally ignores deploying and -getting your application onto the servers. However, you could do so either via -[provisioners](/docs/provisioners/index.html) and a configuration -management tool, or by pre-baking configured AMIs with -[Packer](http://www.packer.io). - -After you run `terraform apply` on this configuration, it will -automatically output the DNS address of the ELB. After your instance -registers, this should respond with the default nginx web page. - -The configuration file contains comments describing each -resource. - -## Command - -``` - terraform apply \ - -var 'aws_access_key=YOUR_ACCESS_KEY' \ - -var 'aws_secret_key=YOUR_SECRET_KEY' \ - -var 'key_path=/path/to/key/pair.pem' \ - -var 'key_name=keypair-name' -``` - -## Configuration - -``` -variable "aws_access_key" {} -variable "aws_secret_key" {} -variable "key_path" {} -variable "key_name" {} -variable "aws_region" { - default = "us-west-2" -} - -# Ubuntu Precise 12.04 LTS (x64) -variable "aws_amis" { - default = { - "eu-west-1": "ami-b1cf19c6", - "us-east-1": "ami-de7ab6b6", - "us-west-1": "ami-3f75767a", - "us-west-2": "ami-21f78e11" - } -} - -# Specify the provider and access details -provider "aws" { - access_key = "${var.aws_access_key}" - secret_key = "${var.aws_secret_key}" - region = "${var.aws_region}" -} - -# Our default security group to access -# the instances over SSH and HTTP -resource "aws_security_group" "default" { - name = "terraform_example" - description = "Used in the terraform" - - # SSH access from anywhere - ingress { - from_port = 22 - to_port = 22 - protocol = "tcp" - cidr_blocks = ["0.0.0.0/0"] - } - - # HTTP access from anywhere - ingress { - from_port = 80 - to_port = 80 - protocol = "tcp" - cidr_blocks = ["0.0.0.0/0"] - } -} - - -resource "aws_elb" "web" { - name = "terraform-example-elb" - - # The same availability zone as our instance - availability_zones = ["${aws_instance.web.availability_zone}"] - - listener { - instance_port = 80 - instance_protocol = "http" - lb_port = 80 - lb_protocol = "http" - } - - # The instance is registered automatically - instances = ["${aws_instance.web.id}"] -} - - -resource "aws_instance" "web" { - # The connection block tells our provisioner how to - # communicate with the resource (instance) - connection { - # The default username for our AMI - user = "ubuntu" - - # The path to your keyfile - key_file = "${var.key_path}" - } - - instance_type = "m1.small" - - # Loookup the correct AMI based on the region - # we specified - ami = "${lookup(var.aws_amis, var.aws_region)}" - - # The name of our SSH keypair you've created and downloaded - # from the AWS console. - # - # https://console.aws.amazon.com/ec2/v2/home?region=us-west-2#KeyPairs: - # - key_name = "${var.key_name}" - - # Our Security group to allow HTTP and SSH access - security_groups = ["${aws_security_group.default.name}"] - - # We run a remote provisioner on the instance after creating it. - # In this case, we just install nginx and start it. By default, - # this should be on port 80 - provisioner "remote-exec" { - inline = [ - "sudo apt-get -y update", - "sudo apt-get -y install nginx", - "sudo service nginx start", - ] - } -} - -output "address" { - value = "${aws_elb.web.dns_name}" -} -``` +--- +layout: "intro" +page_title: "Basic Two-Tier AWS Architecture" +sidebar_current: "examples-aws" +--- + +# Basic Two-Tier AWS Architecture + +This provides a template for running a simple two-tier architecture on Amazon +Web services. + +The basic premise is you have stateless app servers running behind +an ELB serving traffic. + +To simplify the example, this intentionally ignores deploying and +getting your application onto the servers. However, you could do so either via +[provisioners](/docs/provisioners/index.html) and a configuration +management tool, or by pre-baking configured AMIs with +[Packer](http://www.packer.io). + +After you run `terraform apply` on this configuration, it will +automatically output the DNS address of the ELB. After your instance +registers, this should respond with the default nginx web page. + +The configuration file contains comments describing each +resource. + +## Command + +``` + terraform apply \ + -var 'aws_access_key=YOUR_ACCESS_KEY' \ + -var 'aws_secret_key=YOUR_SECRET_KEY' \ + -var 'key_path=/path/to/key/pair.pem' \ + -var 'key_name=keypair-name' +``` + +## Configuration + +``` +variable "aws_access_key" {} +variable "aws_secret_key" {} +variable "key_path" {} +variable "key_name" {} +variable "aws_region" { + default = "us-west-2" +} + +# Ubuntu Precise 12.04 LTS (x64) +variable "aws_amis" { + default = { + "eu-west-1": "ami-b1cf19c6", + "us-east-1": "ami-de7ab6b6", + "us-west-1": "ami-3f75767a", + "us-west-2": "ami-21f78e11" + } +} + +# Specify the provider and access details +provider "aws" { + access_key = "${var.aws_access_key}" + secret_key = "${var.aws_secret_key}" + region = "${var.aws_region}" +} + +# Our default security group to access +# the instances over SSH and HTTP +resource "aws_security_group" "default" { + name = "terraform_example" + description = "Used in the terraform" + + # SSH access from anywhere + ingress { + from_port = 22 + to_port = 22 + protocol = "tcp" + cidr_blocks = ["0.0.0.0/0"] + } + + # HTTP access from anywhere + ingress { + from_port = 80 + to_port = 80 + protocol = "tcp" + cidr_blocks = ["0.0.0.0/0"] + } +} + + +resource "aws_elb" "web" { + name = "terraform-example-elb" + + # The same availability zone as our instance + availability_zones = ["${aws_instance.web.availability_zone}"] + + listener { + instance_port = 80 + instance_protocol = "http" + lb_port = 80 + lb_protocol = "http" + } + + # The instance is registered automatically + instances = ["${aws_instance.web.id}"] +} + + +resource "aws_instance" "web" { + # The connection block tells our provisioner how to + # communicate with the resource (instance) + connection { + # The default username for our AMI + user = "ubuntu" + + # The path to your keyfile + key_file = "${var.key_path}" + } + + instance_type = "m1.small" + + # Loookup the correct AMI based on the region + # we specified + ami = "${lookup(var.aws_amis, var.aws_region)}" + + # The name of our SSH keypair you've created and downloaded + # from the AWS console. + # + # https://console.aws.amazon.com/ec2/v2/home?region=us-west-2#KeyPairs: + # + key_name = "${var.key_name}" + + # Our Security group to allow HTTP and SSH access + security_groups = ["${aws_security_group.default.name}"] + + # We run a remote provisioner on the instance after creating it. + # In this case, we just install nginx and start it. By default, + # this should be on port 80 + provisioner "remote-exec" { + inline = [ + "sudo apt-get -y update", + "sudo apt-get -y install nginx", + "sudo service nginx start", + ] + } +} + +output "address" { + value = "${aws_elb.web.dns_name}" +} +``` diff --git a/website/source/intro/examples/consul.html.markdown b/website/source/intro/examples/consul.html.markdown index 9e1fa6665..2e5358054 100644 --- a/website/source/intro/examples/consul.html.markdown +++ b/website/source/intro/examples/consul.html.markdown @@ -1,130 +1,130 @@ ---- -layout: "intro" -page_title: "Consul Example" -sidebar_current: "examples-consul" ---- - -# Consul Example - -[Consul](http://www.consul.io) is a tool for service discovery, configuration -and orchestration. The Key/Value store it provides is often used to store -application configuration and information about the infrastructure necessary -to process requests. - -Terraform provides a [Consul provider](/docs/providers/consul/index.html) which -can be used to interface with Consul from inside a Terraform configuration. - -For our example, we use the [Consul demo cluster](http://demo.consul.io) -to both read configuration and store information about a newly created EC2 instance. -The size of the EC2 instance will be determind by the "tf\_test/size" key in Consul, -and will default to "m1.small" if that key does not exist. Once the instance is created -the "tf\_test/id" and "tf\_test/public\_dns" keys will be set with the computed -values for the instance. - -Before we run the example, use the [Web UI](http://demo.consul.io/ui/#/nyc1/kv/) -to set the "tf\_test/size" key to "t1.micro". Once that is done, -copy the configuration into a configuration file ("consul.tf" works fine). -Either provide the AWS credentials as a default value in the configuration -or invoke `apply` with the appropriate variables set. - -Once the `apply` has completed, we can see the keys in Consul by -visiting the [Web UI](http://demo.consul.io/ui/#/nyc1/kv/). We can see -that the "tf\_test/id" and "tf\_test/public\_dns" values have been -set. - -We can now teardown the infrastructure following the -[instructions here](/intro/getting-started/destroy.html). Because -we set the 'delete' property of two of the Consul keys, Terraform -will cleanup those keys on destroy. We can verify this by using -the Web UI. - -The point of this example is to show that Consul can be used with -Terraform both to enable dynamic inputs, but to also store outputs. - -Inputs like AMI name, security groups, puppet roles, bootstrap scripts, -etc can all be loaded from Consul. This allows the specifics of an -infrastructure to be decoupled from it's overall architecture. This enables -details to be changed without updating the Terraform configuration. - -Outputs from Terraform can also be easily stored in Consul. One powerful -features this enables is using Consul for inventory management. If an -application relies on ELB for routing, Terraform can update the application's -configuration directly by setting the ELB address into Consul. Any resource -attribute can be stored in Consul, allowing an operator to capture anything -useful. - - -## Command - -``` -terraform apply \ - -var 'aws_access_key=YOUR_KEY' \ - -var 'aws_secret_key=YOUR_KEY' -``` - -## Configuration - -``` -# Declare our variables, require access and secret keys -variable "aws_access_key" {} -variable "aws_secret_key" {} -variable "aws_region" { - default = "us-east-1" -} - -# AMI's from http://cloud-images.ubuntu.com/locator/ec2/ -variable "aws_amis" { - default = { - "eu-west-1": "ami-b1cf19c6", - "us-east-1": "ami-de7ab6b6", - "us-west-1": "ami-3f75767a", - "us-west-2": "ami-21f78e11", - } -} - -# Setup the Consul provisioner to use the demo cluster -provider "consul" { - address = "demo.consul.io:80" - datacenter = "nyc1" -} - -# Setup an AWS provider -provider "aws" { - access_key = "${var.aws_access_key}" - secret_key = "${var.aws_secret_key}" - region = "${var.aws_region}" -} - -# Setup a key in Consul to provide inputs -resource "consul_keys" "input" { - key { - name = "size" - path = "tf_test/size" - default = "m1.small" - } -} - -# Setup a new AWS instance using a dynamic ami and -# instance type -resource "aws_instance" "test" { - ami = "${lookup(var.aws_amis, var.aws_region)}" - instance_type = "${consul_keys.input.var.size}" -} - -# Setup a key in Consul to store the instance id and -# the DNS name of the instance -resource "consul_keys" "test" { - key { - name = "id" - path = "tf_test/id" - value = "${aws_instance.test.id}" - delete = true - } - key { - name = "address" - path = "tf_test/public_dns" - value = "${aws_instance.test.public_dns}" - delete = true - } -} -``` +--- +layout: "intro" +page_title: "Consul Example" +sidebar_current: "examples-consul" +--- + +# Consul Example + +[Consul](http://www.consul.io) is a tool for service discovery, configuration +and orchestration. The Key/Value store it provides is often used to store +application configuration and information about the infrastructure necessary +to process requests. + +Terraform provides a [Consul provider](/docs/providers/consul/index.html) which +can be used to interface with Consul from inside a Terraform configuration. + +For our example, we use the [Consul demo cluster](http://demo.consul.io) +to both read configuration and store information about a newly created EC2 instance. +The size of the EC2 instance will be determind by the "tf\_test/size" key in Consul, +and will default to "m1.small" if that key does not exist. Once the instance is created +the "tf\_test/id" and "tf\_test/public\_dns" keys will be set with the computed +values for the instance. + +Before we run the example, use the [Web UI](http://demo.consul.io/ui/#/nyc1/kv/) +to set the "tf\_test/size" key to "t1.micro". Once that is done, +copy the configuration into a configuration file ("consul.tf" works fine). +Either provide the AWS credentials as a default value in the configuration +or invoke `apply` with the appropriate variables set. + +Once the `apply` has completed, we can see the keys in Consul by +visiting the [Web UI](http://demo.consul.io/ui/#/nyc1/kv/). We can see +that the "tf\_test/id" and "tf\_test/public\_dns" values have been +set. + +We can now teardown the infrastructure following the +[instructions here](/intro/getting-started/destroy.html). Because +we set the 'delete' property of two of the Consul keys, Terraform +will cleanup those keys on destroy. We can verify this by using +the Web UI. + +The point of this example is to show that Consul can be used with +Terraform both to enable dynamic inputs, but to also store outputs. + +Inputs like AMI name, security groups, puppet roles, bootstrap scripts, +etc can all be loaded from Consul. This allows the specifics of an +infrastructure to be decoupled from it's overall architecture. This enables +details to be changed without updating the Terraform configuration. + +Outputs from Terraform can also be easily stored in Consul. One powerful +features this enables is using Consul for inventory management. If an +application relies on ELB for routing, Terraform can update the application's +configuration directly by setting the ELB address into Consul. Any resource +attribute can be stored in Consul, allowing an operator to capture anything +useful. + + +## Command + +``` +terraform apply \ + -var 'aws_access_key=YOUR_KEY' \ + -var 'aws_secret_key=YOUR_KEY' +``` + +## Configuration + +``` +# Declare our variables, require access and secret keys +variable "aws_access_key" {} +variable "aws_secret_key" {} +variable "aws_region" { + default = "us-east-1" +} + +# AMI's from http://cloud-images.ubuntu.com/locator/ec2/ +variable "aws_amis" { + default = { + "eu-west-1": "ami-b1cf19c6", + "us-east-1": "ami-de7ab6b6", + "us-west-1": "ami-3f75767a", + "us-west-2": "ami-21f78e11", + } +} + +# Setup the Consul provisioner to use the demo cluster +provider "consul" { + address = "demo.consul.io:80" + datacenter = "nyc1" +} + +# Setup an AWS provider +provider "aws" { + access_key = "${var.aws_access_key}" + secret_key = "${var.aws_secret_key}" + region = "${var.aws_region}" +} + +# Setup a key in Consul to provide inputs +resource "consul_keys" "input" { + key { + name = "size" + path = "tf_test/size" + default = "m1.small" + } +} + +# Setup a new AWS instance using a dynamic ami and +# instance type +resource "aws_instance" "test" { + ami = "${lookup(var.aws_amis, var.aws_region)}" + instance_type = "${consul_keys.input.var.size}" +} + +# Setup a key in Consul to store the instance id and +# the DNS name of the instance +resource "consul_keys" "test" { + key { + name = "id" + path = "tf_test/id" + value = "${aws_instance.test.id}" + delete = true + } + key { + name = "address" + path = "tf_test/public_dns" + value = "${aws_instance.test.public_dns}" + delete = true + } +} +``` diff --git a/website/source/intro/examples/count.markdown b/website/source/intro/examples/count.markdown index c1a2b0a7c..f70dde558 100644 --- a/website/source/intro/examples/count.markdown +++ b/website/source/intro/examples/count.markdown @@ -1,78 +1,78 @@ ---- -layout: "intro" -page_title: "Count" -sidebar_current: "examples-count" ---- - -# Count Example - -The count parameter on resources can simplify configurations -and let you scale resources by simply incrementing a number. - -Additionally, variables can be used to expand a list of resources -for use elsewhere. - -## Command - -``` - terraform apply \ - -var 'aws_access_key=YOUR_ACCESS_KEY' \ - -var 'aws_secret_key=YOUR_SECRET_KEY' -``` - -## Configuration - -``` -variable "aws_access_key" {} -variable "aws_secret_key" {} -variable "aws_region" { - default = "us-west-2" -} - -# Ubuntu Precise 12.04 LTS (x64) -variable "aws_amis" { - default = { - "eu-west-1": "ami-b1cf19c6", - "us-east-1": "ami-de7ab6b6", - "us-west-1": "ami-3f75767a", - "us-west-2": "ami-21f78e11" - } -} - -# Specify the provider and access details -provider "aws" { - access_key = "${var.aws_access_key}" - secret_key = "${var.aws_secret_key}" - region = "${var.aws_region}" -} - -resource "aws_elb" "web" { - name = "terraform-example-elb" - - # The same availability zone as our instances - availability_zones = ["${aws_instance.web.*.availability_zone}"] - - listener { - instance_port = 80 - instance_protocol = "http" - lb_port = 80 - lb_protocol = "http" - } - - # The instances are registered automatically - instances = ["${aws_instance.web.*.id}"] -} - - -resource "aws_instance" "web" { - instance_type = "m1.small" - ami = "${lookup(var.aws_amis, var.aws_region)}" - - # This will create 4 instances - count = 4 -} - -output "address" { - value = "Instances: ${aws_instance.web.*.id}" -} -``` +--- +layout: "intro" +page_title: "Count" +sidebar_current: "examples-count" +--- + +# Count Example + +The count parameter on resources can simplify configurations +and let you scale resources by simply incrementing a number. + +Additionally, variables can be used to expand a list of resources +for use elsewhere. + +## Command + +``` + terraform apply \ + -var 'aws_access_key=YOUR_ACCESS_KEY' \ + -var 'aws_secret_key=YOUR_SECRET_KEY' +``` + +## Configuration + +``` +variable "aws_access_key" {} +variable "aws_secret_key" {} +variable "aws_region" { + default = "us-west-2" +} + +# Ubuntu Precise 12.04 LTS (x64) +variable "aws_amis" { + default = { + "eu-west-1": "ami-b1cf19c6", + "us-east-1": "ami-de7ab6b6", + "us-west-1": "ami-3f75767a", + "us-west-2": "ami-21f78e11" + } +} + +# Specify the provider and access details +provider "aws" { + access_key = "${var.aws_access_key}" + secret_key = "${var.aws_secret_key}" + region = "${var.aws_region}" +} + +resource "aws_elb" "web" { + name = "terraform-example-elb" + + # The same availability zone as our instances + availability_zones = ["${aws_instance.web.*.availability_zone}"] + + listener { + instance_port = 80 + instance_protocol = "http" + lb_port = 80 + lb_protocol = "http" + } + + # The instances are registered automatically + instances = ["${aws_instance.web.*.id}"] +} + + +resource "aws_instance" "web" { + instance_type = "m1.small" + ami = "${lookup(var.aws_amis, var.aws_region)}" + + # This will create 4 instances + count = 4 +} + +output "address" { + value = "Instances: ${aws_instance.web.*.id}" +} +``` diff --git a/website/source/intro/examples/cross-provider.markdown b/website/source/intro/examples/cross-provider.markdown index 6d85a54c9..5c496f3e9 100644 --- a/website/source/intro/examples/cross-provider.markdown +++ b/website/source/intro/examples/cross-provider.markdown @@ -1,78 +1,78 @@ ---- -layout: "intro" -page_title: "Cross Provider" -sidebar_current: "examples-cross-provider" ---- - -# Cross Provider Example - -This is a simple example of the cross-provider capabilities of -Terraform. - -Very simply, this creates a Heroku application and points a DNS -CNAME record at the result via DNSimple. A `host` query to the outputted -hostname should reveal the correct DNS configuration. - -## Command - -``` -terraform apply \ - -var 'heroku_email=YOUR_EMAIL' \ - -var 'heroku_api_key=YOUR_KEY' \ - -var 'dnsimple_domain=example.com' \ - -var 'dnsimple_email=YOUR_EMAIL' \ - -var 'dnsimple_token=YOUR_TOKEN' -``` - -## Configuration - -``` -variable "heroku_email" {} -variable "heroku_api_key" {} - -# The domain we are creating a record for -variable "dnsimple_domain" {} - -variable "dnsimple_token" {} -variable "dnsimple_email" {} - - -# Specify the provider and access details -provider "heroku" { - email = "${var.heroku_email}" - api_key = "${var.heroku_api_key}" -} - -# Create our Heroku application. Heroku will -# automatically assign a name. -resource "heroku_app" "web" { -} - -# Create our DNSimple record to point to the -# heroku application. -resource "dnsimple_record" "web" { - domain = "${var.dnsimple_domain}" - - name = "terraform" - - # heroku_hostname is a computed attribute on the heroku - # application we can use to determine the hostname - value = "${heroku_app.web.heroku_hostname}" - - type = "CNAME" - ttl = 3600 -} - -# The Heroku domain, which will be created and added -# to the heroku application after we have assigned the domain -# in DNSimple -resource "heroku_domain" "foobar" { - app = "${heroku_app.web.name}" - hostname = "${dnsimple_record.web.hostname}" -} - -# Output the hostname of the newly created record -output "address" { - value = "${dnsimple_record.web.hostname}" -} -``` +--- +layout: "intro" +page_title: "Cross Provider" +sidebar_current: "examples-cross-provider" +--- + +# Cross Provider Example + +This is a simple example of the cross-provider capabilities of +Terraform. + +Very simply, this creates a Heroku application and points a DNS +CNAME record at the result via DNSimple. A `host` query to the outputted +hostname should reveal the correct DNS configuration. + +## Command + +``` +terraform apply \ + -var 'heroku_email=YOUR_EMAIL' \ + -var 'heroku_api_key=YOUR_KEY' \ + -var 'dnsimple_domain=example.com' \ + -var 'dnsimple_email=YOUR_EMAIL' \ + -var 'dnsimple_token=YOUR_TOKEN' +``` + +## Configuration + +``` +variable "heroku_email" {} +variable "heroku_api_key" {} + +# The domain we are creating a record for +variable "dnsimple_domain" {} + +variable "dnsimple_token" {} +variable "dnsimple_email" {} + + +# Specify the provider and access details +provider "heroku" { + email = "${var.heroku_email}" + api_key = "${var.heroku_api_key}" +} + +# Create our Heroku application. Heroku will +# automatically assign a name. +resource "heroku_app" "web" { +} + +# Create our DNSimple record to point to the +# heroku application. +resource "dnsimple_record" "web" { + domain = "${var.dnsimple_domain}" + + name = "terraform" + + # heroku_hostname is a computed attribute on the heroku + # application we can use to determine the hostname + value = "${heroku_app.web.heroku_hostname}" + + type = "CNAME" + ttl = 3600 +} + +# The Heroku domain, which will be created and added +# to the heroku application after we have assigned the domain +# in DNSimple +resource "heroku_domain" "foobar" { + app = "${heroku_app.web.name}" + hostname = "${dnsimple_record.web.hostname}" +} + +# Output the hostname of the newly created record +output "address" { + value = "${dnsimple_record.web.hostname}" +} +``` diff --git a/website/source/intro/getting-started/build.html.md b/website/source/intro/getting-started/build.html.md index 6c26984f9..1135391fd 100644 --- a/website/source/intro/getting-started/build.html.md +++ b/website/source/intro/getting-started/build.html.md @@ -1,216 +1,216 @@ ---- -layout: "intro" -page_title: "Build Infrastructure" -sidebar_current: "gettingstarted-build" ---- - -# Build Infrastructure - -With Terraform installed, let's dive right into it and start creating -some infrastructure. - -We'll build infrastructure on -[AWS](http://aws.amazon.com) for the getting started guide -since it is popular and generally understood, but Terraform -can [manage many providers](/docs/providers/index.html), -including multiple providers in a single configuration. -Some examples of this are in the -[use cases section](/intro/use-cases.html). - -If you don't have an AWS account, -[create one now](http://aws.amazon.com/free/). -For the getting started guide, we'll only be using resources -which qualify under the AWS -[free-tier](http://aws.amazon.com/free/), -meaning it will be free. -If you already have an AWS account, you may be charged some -amount of money, but it shouldn't be more than a few dollars -at most. - -
-

-Note: If you're not using an account that qualifies -under the AWS -free-tier, -you may be charged to run these examples. The most you should -be charged should only be a few dollars, but we're not responsible -for any charges that may incur. -

-
- -## Configuration - -The set of files used to describe infrastructure in Terraform is simply -known as a Terraform _configuration_. We're going to write our first -configuration now to launch a single AWS EC2 instance. - -The format of the configuration files is -[documented here](/docs/configuration/index.html). -Configuration files can -[also be JSON](/docs/configuration/syntax.html), but we recommend only using JSON when the -configuration is generated by a machine. - -The entire configuration is shown below. We'll go over each part -after. Save the contents to a file named `example.tf`. Verify that -there are no other `*.tf` files in your directory, since Terraform -loads all of them. - -``` -provider "aws" { - access_key = "ACCESS_KEY_HERE" - secret_key = "SECRET_KEY_HERE" - region = "us-east-1" -} - -resource "aws_instance" "example" { - ami = "ami-408c7f28" - instance_type = "t1.micro" -} -``` - -Replace the `ACCESS_KEY_HERE` and `SECRET_KEY_HERE` with your -AWS access key and secret key, available from -[this page](https://console.aws.amazon.com/iam/home?#security_credential). -We're hardcoding them for now, but will extract these into -variables later in the getting started guide. - -This is a complete configuration that Terraform is ready to apply. -The general structure should be intuitive and straightforward. - -The `provider` block is used to configure the named provider, in -our case "aws." A provider is responsible for creating and -managing resources. Multiple provider blocks can exist if a -Terraform configuration is comprised of multiple providers, -which is a common situation. - -The `resource` block defines a resource that exists within -the infrastructure. A resource might be a physical component such -as an EC2 instance, or it can be a logical resource such as -a Heroku application. - -The resource block has two strings before opening the block: -the resource type and the resource name. In our example, the -resource type is "aws\_instance" and the name is "example." -The prefix of the type maps to the provider. In our case -"aws\_instance" automatically tells Terraform that it is -managed by the "aws" provider. - -Within the resource block itself is configuration for that -resource. This is dependent on each resource provider and -is fully documented within our -[providers reference](/docs/providers/index.html). For our EC2 instance, we specify -an AMI for Ubuntu, and request a "t1.micro" instance so we -qualify under the free tier. - -## Execution Plan - -Next, let's see what Terraform would do if we asked it to -apply this configuration. In the same directory as the -`example.tf` file you created, run `terraform plan`. You -should see output similar to what is copied below. We've -truncated some of the output to save space. - -``` -$ terraform plan -... - -+ aws_instance.example - ami: "" => "ami-408c7f28" - availability_zone: "" => "" - instance_type: "" => "t1.micro" - key_name: "" => "" - private_dns: "" => "" - private_ip: "" => "" - public_dns: "" => "" - public_ip: "" => "" - security_groups: "" => "" - subnet_id: "" => "" -``` - -`terraform plan` shows what changes Terraform will apply to -your infrastructure given the current state of your infrastructure -as well as the current contents of your configuration. - -If `terraform plan` failed with an error, read the error message -and fix the error that occurred. At this stage, it is probably a -syntax error in the configuration. - -The output format is similar to the diff format generated by tools -such as Git. The output has a "+" next to "aws\_instance.example", -meaning that Terraform will create this resource. Beneath that, -it shows the attributes that will be set. When the value it is -going to is ``, it means that the value won't be known -until the resource is created. - -## Apply - -The plan looks good, our configuration appears valid, so its time to -create real resources. Run `terraform apply` in the same directory -as your `example.tf`, and watch it go! It will take a few minutes -since Terraform waits for the EC2 instance to become available. - -``` -$ terraform apply -aws_instance.example: Creating... - ami: "" => "ami-408c7f28" - instance_type: "" => "t1.micro" - -Apply complete! Resources: 1 added, 0 changed, 0 destroyed. - -... -``` - -Done! You can go to the AWS console to prove to yourself that the -EC2 instance has been created. - -Terraform also put some state into the `terraform.tfstate` file -by default. This state file is extremely important; it maps various -resource metadata to actual resource IDs so that Terraform knows -what it is managing. This file must be saved and distributed -to anyone who might run Terraform. We recommend simply putting it -into version control, since it generally isn't too large. - -You can inspect the state using `terraform show`: - -``` -$ terraform show -aws_instance.example: - id = i-e60900cd - ami = ami-408c7f28 - availability_zone = us-east-1c - instance_type = t1.micro - key_name = - private_dns = domU-12-31-39-12-38-AB.compute-1.internal - private_ip = 10.200.59.89 - public_dns = ec2-54-81-21-192.compute-1.amazonaws.com - public_ip = 54.81.21.192 - security_groups.# = 1 - security_groups.0 = default - subnet_id = -``` - -You can see that by creating our resource, we've also gathered -a lot more metadata about it. This metadata can actually be referenced -for other resources or outputs, which will be covered later in -the getting started guide. - -## Provisioning - -The EC2 instance we launched at this point is based on the AMI -given, but has no additional software installed. If you're running -an image-based infrastructure (perhaps creating images with -[Packer](http://www.packer.io)), then this is all you need. - -However, many infrastructures still require some sort of initialization -or software provisioning step. Terraform supports -provisioners, -which we'll cover a little bit later in the getting started guide, -in order to do this. - -## Next - -Congratulations! You've built your first infrastructure with Terraform. -You've seen the configuration syntax, an example of a basic execution -plan, and understand the state file. - -Next, we're going to move on to [changing and destroying infrastructure](/intro/getting-started/change.html). +--- +layout: "intro" +page_title: "Build Infrastructure" +sidebar_current: "gettingstarted-build" +--- + +# Build Infrastructure + +With Terraform installed, let's dive right into it and start creating +some infrastructure. + +We'll build infrastructure on +[AWS](http://aws.amazon.com) for the getting started guide +since it is popular and generally understood, but Terraform +can [manage many providers](/docs/providers/index.html), +including multiple providers in a single configuration. +Some examples of this are in the +[use cases section](/intro/use-cases.html). + +If you don't have an AWS account, +[create one now](http://aws.amazon.com/free/). +For the getting started guide, we'll only be using resources +which qualify under the AWS +[free-tier](http://aws.amazon.com/free/), +meaning it will be free. +If you already have an AWS account, you may be charged some +amount of money, but it shouldn't be more than a few dollars +at most. + +
+

+Note: If you're not using an account that qualifies +under the AWS +free-tier, +you may be charged to run these examples. The most you should +be charged should only be a few dollars, but we're not responsible +for any charges that may incur. +

+
+ +## Configuration + +The set of files used to describe infrastructure in Terraform is simply +known as a Terraform _configuration_. We're going to write our first +configuration now to launch a single AWS EC2 instance. + +The format of the configuration files is +[documented here](/docs/configuration/index.html). +Configuration files can +[also be JSON](/docs/configuration/syntax.html), but we recommend only using JSON when the +configuration is generated by a machine. + +The entire configuration is shown below. We'll go over each part +after. Save the contents to a file named `example.tf`. Verify that +there are no other `*.tf` files in your directory, since Terraform +loads all of them. + +``` +provider "aws" { + access_key = "ACCESS_KEY_HERE" + secret_key = "SECRET_KEY_HERE" + region = "us-east-1" +} + +resource "aws_instance" "example" { + ami = "ami-408c7f28" + instance_type = "t1.micro" +} +``` + +Replace the `ACCESS_KEY_HERE` and `SECRET_KEY_HERE` with your +AWS access key and secret key, available from +[this page](https://console.aws.amazon.com/iam/home?#security_credential). +We're hardcoding them for now, but will extract these into +variables later in the getting started guide. + +This is a complete configuration that Terraform is ready to apply. +The general structure should be intuitive and straightforward. + +The `provider` block is used to configure the named provider, in +our case "aws." A provider is responsible for creating and +managing resources. Multiple provider blocks can exist if a +Terraform configuration is comprised of multiple providers, +which is a common situation. + +The `resource` block defines a resource that exists within +the infrastructure. A resource might be a physical component such +as an EC2 instance, or it can be a logical resource such as +a Heroku application. + +The resource block has two strings before opening the block: +the resource type and the resource name. In our example, the +resource type is "aws\_instance" and the name is "example." +The prefix of the type maps to the provider. In our case +"aws\_instance" automatically tells Terraform that it is +managed by the "aws" provider. + +Within the resource block itself is configuration for that +resource. This is dependent on each resource provider and +is fully documented within our +[providers reference](/docs/providers/index.html). For our EC2 instance, we specify +an AMI for Ubuntu, and request a "t1.micro" instance so we +qualify under the free tier. + +## Execution Plan + +Next, let's see what Terraform would do if we asked it to +apply this configuration. In the same directory as the +`example.tf` file you created, run `terraform plan`. You +should see output similar to what is copied below. We've +truncated some of the output to save space. + +``` +$ terraform plan +... + ++ aws_instance.example + ami: "" => "ami-408c7f28" + availability_zone: "" => "" + instance_type: "" => "t1.micro" + key_name: "" => "" + private_dns: "" => "" + private_ip: "" => "" + public_dns: "" => "" + public_ip: "" => "" + security_groups: "" => "" + subnet_id: "" => "" +``` + +`terraform plan` shows what changes Terraform will apply to +your infrastructure given the current state of your infrastructure +as well as the current contents of your configuration. + +If `terraform plan` failed with an error, read the error message +and fix the error that occurred. At this stage, it is probably a +syntax error in the configuration. + +The output format is similar to the diff format generated by tools +such as Git. The output has a "+" next to "aws\_instance.example", +meaning that Terraform will create this resource. Beneath that, +it shows the attributes that will be set. When the value it is +going to is ``, it means that the value won't be known +until the resource is created. + +## Apply + +The plan looks good, our configuration appears valid, so its time to +create real resources. Run `terraform apply` in the same directory +as your `example.tf`, and watch it go! It will take a few minutes +since Terraform waits for the EC2 instance to become available. + +``` +$ terraform apply +aws_instance.example: Creating... + ami: "" => "ami-408c7f28" + instance_type: "" => "t1.micro" + +Apply complete! Resources: 1 added, 0 changed, 0 destroyed. + +... +``` + +Done! You can go to the AWS console to prove to yourself that the +EC2 instance has been created. + +Terraform also put some state into the `terraform.tfstate` file +by default. This state file is extremely important; it maps various +resource metadata to actual resource IDs so that Terraform knows +what it is managing. This file must be saved and distributed +to anyone who might run Terraform. We recommend simply putting it +into version control, since it generally isn't too large. + +You can inspect the state using `terraform show`: + +``` +$ terraform show +aws_instance.example: + id = i-e60900cd + ami = ami-408c7f28 + availability_zone = us-east-1c + instance_type = t1.micro + key_name = + private_dns = domU-12-31-39-12-38-AB.compute-1.internal + private_ip = 10.200.59.89 + public_dns = ec2-54-81-21-192.compute-1.amazonaws.com + public_ip = 54.81.21.192 + security_groups.# = 1 + security_groups.0 = default + subnet_id = +``` + +You can see that by creating our resource, we've also gathered +a lot more metadata about it. This metadata can actually be referenced +for other resources or outputs, which will be covered later in +the getting started guide. + +## Provisioning + +The EC2 instance we launched at this point is based on the AMI +given, but has no additional software installed. If you're running +an image-based infrastructure (perhaps creating images with +[Packer](http://www.packer.io)), then this is all you need. + +However, many infrastructures still require some sort of initialization +or software provisioning step. Terraform supports +provisioners, +which we'll cover a little bit later in the getting started guide, +in order to do this. + +## Next + +Congratulations! You've built your first infrastructure with Terraform. +You've seen the configuration syntax, an example of a basic execution +plan, and understand the state file. + +Next, we're going to move on to [changing and destroying infrastructure](/intro/getting-started/change.html). diff --git a/website/source/intro/getting-started/change.html.md b/website/source/intro/getting-started/change.html.md index 8a59a9de1..21b3f102d 100644 --- a/website/source/intro/getting-started/change.html.md +++ b/website/source/intro/getting-started/change.html.md @@ -1,95 +1,95 @@ ---- -layout: "intro" -page_title: "Change Infrastructure" -sidebar_current: "gettingstarted-change" ---- - -# Change Infrastructure - -In the previous page, you created your first infrastructure with -Terraform: a single EC2 instance. In this page, we're going to -modify that resource, and see how Terraform handles change. - -Infrastructure is continuously evolving, and Terraform was built -to help manage and enact that change. As you change Terraform -configurations, Terraform builds an execution plan that only -modifies what is necessary to reach your desired state. - -By using Terraform to change infrastructure, you can version -control not only your configurations but also your state so you -can see how the infrastructure evolved over time. - -## Configuration - -Let's modify the `ami` of our instance. Edit the "aws\_instance.web" -resource in your configuration and change it to the following: - -``` -resource "aws_instance" "example" { - ami = "ami-aa7ab6c2" - instance_type = "t1.micro" -} -``` - -We've changed the AMI from being an Ubuntu 14.04 AMI to being -an Ubuntu 12.04 AMI. Terraform configurations are meant to be -changed like this. You can also completely remove resources -and Terraform will know to destroy the old one. - -## Execution Plan - -Let's see what Terraform will do with the change we made. - -``` -$ terraform plan -... - --/+ aws_instance.example - ami: "ami-408c7f28" => "ami-aa7ab6c2" (forces new resource) - availability_zone: "us-east-1c" => "" - key_name: "" => "" - private_dns: "domU-12-31-39-12-38-AB.compute-1.internal" => "" - private_ip: "10.200.59.89" => "" - public_dns: "ec2-54-81-21-192.compute-1.amazonaws.com" => "" - public_ip: "54.81.21.192" => "" - security_groups: "" => "" - subnet_id: "" => "" -``` - -The prefix "-/+" means that Terraform will destroy and recreate -the resource, versus purely updating it in-place. While some attributes -can do in-place updates (which are shown with a "~" prefix), AMI -changing on EC2 instance requires a new resource. Terraform handles -these details for you, and the execution plan makes it clear what -Terraform will do. - -Additionally, the plan output shows that the AMI change is what -necessitated the creation of a new resource. Using this information, -you can tweak your changes to possibly avoid destroy/create updates -if you didn't want to do them at this time. - -## Apply - -From the plan, we know what will happen. Let's apply and enact -the change. - -``` -$ terraform apply -aws_instance.example: Destroying... -aws_instance.example: Modifying... - ami: "ami-408c7f28" => "ami-aa7ab6c2" - -Apply complete! Resources: 0 added, 1 changed, 1 destroyed. - -... -``` - -As the plan predicted, Terraform started by destroying our old -instance, then creating the new one. You can use `terraform show` -again to see the new properties associated with this instance. - -## Next - -You've now seen how easy it is to modify infrastructure with -Terraform. Feel free to play around with this more before continuing. -In the next section we're going to [destroy our infrastructure](/intro/getting-started/destroy.html). +--- +layout: "intro" +page_title: "Change Infrastructure" +sidebar_current: "gettingstarted-change" +--- + +# Change Infrastructure + +In the previous page, you created your first infrastructure with +Terraform: a single EC2 instance. In this page, we're going to +modify that resource, and see how Terraform handles change. + +Infrastructure is continuously evolving, and Terraform was built +to help manage and enact that change. As you change Terraform +configurations, Terraform builds an execution plan that only +modifies what is necessary to reach your desired state. + +By using Terraform to change infrastructure, you can version +control not only your configurations but also your state so you +can see how the infrastructure evolved over time. + +## Configuration + +Let's modify the `ami` of our instance. Edit the "aws\_instance.web" +resource in your configuration and change it to the following: + +``` +resource "aws_instance" "example" { + ami = "ami-aa7ab6c2" + instance_type = "t1.micro" +} +``` + +We've changed the AMI from being an Ubuntu 14.04 AMI to being +an Ubuntu 12.04 AMI. Terraform configurations are meant to be +changed like this. You can also completely remove resources +and Terraform will know to destroy the old one. + +## Execution Plan + +Let's see what Terraform will do with the change we made. + +``` +$ terraform plan +... + +-/+ aws_instance.example + ami: "ami-408c7f28" => "ami-aa7ab6c2" (forces new resource) + availability_zone: "us-east-1c" => "" + key_name: "" => "" + private_dns: "domU-12-31-39-12-38-AB.compute-1.internal" => "" + private_ip: "10.200.59.89" => "" + public_dns: "ec2-54-81-21-192.compute-1.amazonaws.com" => "" + public_ip: "54.81.21.192" => "" + security_groups: "" => "" + subnet_id: "" => "" +``` + +The prefix "-/+" means that Terraform will destroy and recreate +the resource, versus purely updating it in-place. While some attributes +can do in-place updates (which are shown with a "~" prefix), AMI +changing on EC2 instance requires a new resource. Terraform handles +these details for you, and the execution plan makes it clear what +Terraform will do. + +Additionally, the plan output shows that the AMI change is what +necessitated the creation of a new resource. Using this information, +you can tweak your changes to possibly avoid destroy/create updates +if you didn't want to do them at this time. + +## Apply + +From the plan, we know what will happen. Let's apply and enact +the change. + +``` +$ terraform apply +aws_instance.example: Destroying... +aws_instance.example: Modifying... + ami: "ami-408c7f28" => "ami-aa7ab6c2" + +Apply complete! Resources: 0 added, 1 changed, 1 destroyed. + +... +``` + +As the plan predicted, Terraform started by destroying our old +instance, then creating the new one. You can use `terraform show` +again to see the new properties associated with this instance. + +## Next + +You've now seen how easy it is to modify infrastructure with +Terraform. Feel free to play around with this more before continuing. +In the next section we're going to [destroy our infrastructure](/intro/getting-started/destroy.html). diff --git a/website/source/intro/getting-started/dependencies.html.md b/website/source/intro/getting-started/dependencies.html.md index 9e50ed3f8..62535fd1f 100644 --- a/website/source/intro/getting-started/dependencies.html.md +++ b/website/source/intro/getting-started/dependencies.html.md @@ -1,165 +1,165 @@ ---- -layout: "intro" -page_title: "Resource Dependencies" -sidebar_current: "gettingstarted-deps" ---- - -# Resource Dependencies - -In this page, we're going to introduce resource dependencies, -where we'll not only see a configuration with multiple resources -for the first time, but also scenarios where resource parameters -use information from other resources. - -Up to this point, our example has only contained a single resource. -Real infrastructure has a diverse set of resources and resource -types. Terraform configurations can contain multiple resources, -multiple resource types, and these types can even span multiple -providers. - -On this page, we'll show a basic example of multiple resources -and how to reference the attributes of other resources to configure -subsequent resources. - -## Assigning an Elastic IP - -We'll improve our configuration by assigning an elastic IP to -the EC2 instance we're managing. Modify your `example.tf` and -add the following: - -``` -resource "aws_eip" "ip" { - instance = "${aws_instance.example.id}" -} -``` - -This should look familiar from the earlier example of adding -an EC2 instance resource, except this time we're building -an "aws\_eip" resource type. This resource type allocates -and associates an -[elastic IP](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html) -to an EC2 instance. - -The only parameter for -[aws\_eip](/docs/providers/aws/r/eip.html) is "instance" which -is the EC2 instance to assign the IP to. For this value, we -use an interpolation to use an attribute from the EC2 instance -we managed earlier. - -The syntax for this interpolation should be straightforward: -it requests the "id" attribute from the "aws\_instance.example" -resource. - -## Plan and Execute - -Run `terraform plan` to view the execution plan. The output -will look something like the following: - -``` -$ terraform plan -... - -+ aws_eip.ip - instance: "" => "${aws_instance.example.id}" - private_ip: "" => "" - public_ip: "" => "" - -+ aws_instance.example - ami: "" => "ami-aa7ab6c2" - availability_zone: "" => "" - instance_type: "" => "t1.micro" - key_name: "" => "" - private_dns: "" => "" - private_ip: "" => "" - public_dns: "" => "" - public_ip: "" => "" - security_groups: "" => "" - subnet_id: "" => "" -``` - -Terraform will create two resources: the instance and the elastic -IP. In the "instance" value for the "aws\_eip", you can see the -raw interpolation is still present. This is because this variable -won't be known until the "aws\_instance" is created. It will be -replaced at apply-time. - -Next, run `terraform apply`. The output will look similar to the -following: - -``` -aws_instance.example: Creating... - ami: "" => "ami-aa7ab6c2" - instance_type: "" => "t1.micro" -aws_eip.ip: Creating... - instance: "" => "i-0e737b25" - -Apply complete! Resources: 2 added, 0 changed, 0 destroyed. -``` - -It is clearer to see from actually running Terraform, but -Terraform creates the EC2 instance before the elastic IP -address. Due to the interpolation earlier where the elastic -IP requires the ID of the EC2 instance, Terraform is able -to infer a dependency, and knows to create the instance -first. - -## Implicit and Explicit Dependencies - -Most dependencies in Terraform are implicit: Terraform is able -to infer dependencies based on usage of attributes of other -resources. - -Using this information, Terraform builds a graph of resources. -This tells Terraform not only what order to create resources, -but also what resources can be created in parallel. In our example, -since the IP address depended on the EC2 instance, they could -not be created in parallel. - -Implicit dependencies work well and are usually all you ever need. -However, you can also specify explicit dependencies with the -`depends_on` parameter which is available on any resource. For example, -we could modify the "aws\_eip" resource to the following, which -effectively does the same thing and is redundant: - -``` -resource "aws_eip" "ip" { - instance = "${aws_instance.example.id}" - depends_on = ["aws_instance.example"] -} -``` - -If you're ever unsure about the dependency chain that Terraform -is creating, you can use the [`terraform graph` command](/docs/commands/graph.html) to view -the graph. This command outputs a dot-formatted graph which can be -viewed with -[Graphviz](http://www.graphviz.org/). - -## Non-Dependent Resources - -We can now augment the configuration with another EC2 instance. -Because this doesn't rely on any other resource, it can be -created in parallel to everything else. - -``` -resource "aws_instance" "another" { - ami = "ami-aa7ab6c2" - instance_type = "t1.micro" -} -``` - -You can view the graph with `terraform graph` to see that -nothing depends on this and that it will likely be created -in parallel. - -Before moving on, remove this resource from your configuration -and `terraform apply` again to destroy it. We won't use the -second instance anymore in the getting started guide. - -## Next - -In this page you were introduced to both multiple resources -as well as basic resource dependencies and resource attribute -interpolation. - -Moving on, [we'll use provisioners](/intro/getting-started/provision.html) -to do some basic bootstrapping of our launched instance. +--- +layout: "intro" +page_title: "Resource Dependencies" +sidebar_current: "gettingstarted-deps" +--- + +# Resource Dependencies + +In this page, we're going to introduce resource dependencies, +where we'll not only see a configuration with multiple resources +for the first time, but also scenarios where resource parameters +use information from other resources. + +Up to this point, our example has only contained a single resource. +Real infrastructure has a diverse set of resources and resource +types. Terraform configurations can contain multiple resources, +multiple resource types, and these types can even span multiple +providers. + +On this page, we'll show a basic example of multiple resources +and how to reference the attributes of other resources to configure +subsequent resources. + +## Assigning an Elastic IP + +We'll improve our configuration by assigning an elastic IP to +the EC2 instance we're managing. Modify your `example.tf` and +add the following: + +``` +resource "aws_eip" "ip" { + instance = "${aws_instance.example.id}" +} +``` + +This should look familiar from the earlier example of adding +an EC2 instance resource, except this time we're building +an "aws\_eip" resource type. This resource type allocates +and associates an +[elastic IP](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html) +to an EC2 instance. + +The only parameter for +[aws\_eip](/docs/providers/aws/r/eip.html) is "instance" which +is the EC2 instance to assign the IP to. For this value, we +use an interpolation to use an attribute from the EC2 instance +we managed earlier. + +The syntax for this interpolation should be straightforward: +it requests the "id" attribute from the "aws\_instance.example" +resource. + +## Plan and Execute + +Run `terraform plan` to view the execution plan. The output +will look something like the following: + +``` +$ terraform plan +... + ++ aws_eip.ip + instance: "" => "${aws_instance.example.id}" + private_ip: "" => "" + public_ip: "" => "" + ++ aws_instance.example + ami: "" => "ami-aa7ab6c2" + availability_zone: "" => "" + instance_type: "" => "t1.micro" + key_name: "" => "" + private_dns: "" => "" + private_ip: "" => "" + public_dns: "" => "" + public_ip: "" => "" + security_groups: "" => "" + subnet_id: "" => "" +``` + +Terraform will create two resources: the instance and the elastic +IP. In the "instance" value for the "aws\_eip", you can see the +raw interpolation is still present. This is because this variable +won't be known until the "aws\_instance" is created. It will be +replaced at apply-time. + +Next, run `terraform apply`. The output will look similar to the +following: + +``` +aws_instance.example: Creating... + ami: "" => "ami-aa7ab6c2" + instance_type: "" => "t1.micro" +aws_eip.ip: Creating... + instance: "" => "i-0e737b25" + +Apply complete! Resources: 2 added, 0 changed, 0 destroyed. +``` + +It is clearer to see from actually running Terraform, but +Terraform creates the EC2 instance before the elastic IP +address. Due to the interpolation earlier where the elastic +IP requires the ID of the EC2 instance, Terraform is able +to infer a dependency, and knows to create the instance +first. + +## Implicit and Explicit Dependencies + +Most dependencies in Terraform are implicit: Terraform is able +to infer dependencies based on usage of attributes of other +resources. + +Using this information, Terraform builds a graph of resources. +This tells Terraform not only what order to create resources, +but also what resources can be created in parallel. In our example, +since the IP address depended on the EC2 instance, they could +not be created in parallel. + +Implicit dependencies work well and are usually all you ever need. +However, you can also specify explicit dependencies with the +`depends_on` parameter which is available on any resource. For example, +we could modify the "aws\_eip" resource to the following, which +effectively does the same thing and is redundant: + +``` +resource "aws_eip" "ip" { + instance = "${aws_instance.example.id}" + depends_on = ["aws_instance.example"] +} +``` + +If you're ever unsure about the dependency chain that Terraform +is creating, you can use the [`terraform graph` command](/docs/commands/graph.html) to view +the graph. This command outputs a dot-formatted graph which can be +viewed with +[Graphviz](http://www.graphviz.org/). + +## Non-Dependent Resources + +We can now augment the configuration with another EC2 instance. +Because this doesn't rely on any other resource, it can be +created in parallel to everything else. + +``` +resource "aws_instance" "another" { + ami = "ami-aa7ab6c2" + instance_type = "t1.micro" +} +``` + +You can view the graph with `terraform graph` to see that +nothing depends on this and that it will likely be created +in parallel. + +Before moving on, remove this resource from your configuration +and `terraform apply` again to destroy it. We won't use the +second instance anymore in the getting started guide. + +## Next + +In this page you were introduced to both multiple resources +as well as basic resource dependencies and resource attribute +interpolation. + +Moving on, [we'll use provisioners](/intro/getting-started/provision.html) +to do some basic bootstrapping of our launched instance. diff --git a/website/source/intro/getting-started/destroy.html.md b/website/source/intro/getting-started/destroy.html.md index 896f8de1e..0fb0129c7 100644 --- a/website/source/intro/getting-started/destroy.html.md +++ b/website/source/intro/getting-started/destroy.html.md @@ -1,73 +1,73 @@ ---- -layout: "intro" -page_title: "Destroy Infrastructure" -sidebar_current: "gettingstarted-destroy" ---- - -# Destroy Infrastructure - -We've now seen how to build and change infrastructure. Before we -move on to creating multiple resources and showing resource -dependencies, we're going to go over how to completely destroy -the Terraform-managed infrastructure. - -Destroying your infrastructure is a rare event in production -environments. But if you're using Terraform to spin up multiple -environments such as development, test, QA environments, then -destroying is a useful action. - -## Plan - -For Terraform to destroy our infrastructure, we need to ask -Terraform to generate a destroy execution plan. This is a special -kind of execution plan that only destroys all Terraform-managed -infrastructure, and doesn't create or update any components. - -``` -$ terraform plan -destroy -out=terraform.tfplan -... - -- aws_instance.example -``` - -The plan command is given two new flags. - -The first flag, `-destroy` tells Terraform to create an execution -plan to destroy the infrastructure. You can see in the output that -our one EC2 instance will be destroyed. - -The second flag, `-out` tells Terraform to save the execution plan -to a file. We haven't seen this before, but it isn't limited to -only destroys. Any plan can be saved to a file. Terraform can then -apply a plan, ensuring that only exactly the plan you saw is executed. -For destroys, you must save into a plan, since there is no way to -tell `apply` to destroy otherwise. - -## Apply - -Let's apply the destroy: - -``` -$ terraform apply terraform.tfplan -aws_instance.example: Destroying... - -Apply complete! Resources: 0 added, 0 changed, 1 destroyed. - -... -``` - -Done. Terraform destroyed our one instance, and if you run a -`terraform show`, you'll see that the state file is now empty. - -For this command, we gave an argument to `apply` for the first -time. You can give apply a specific plan to execute. - -## Next - -You now know how to create, modify, and destroy infrastructure. -With these building blocks, you can effectively experiment with -any part of Terraform. - -Next, we move on to features that make Terraform configurations -slightly more useful: [variables, resource dependencies, provisioning, -and more](/intro/getting-started/dependencies.html). +--- +layout: "intro" +page_title: "Destroy Infrastructure" +sidebar_current: "gettingstarted-destroy" +--- + +# Destroy Infrastructure + +We've now seen how to build and change infrastructure. Before we +move on to creating multiple resources and showing resource +dependencies, we're going to go over how to completely destroy +the Terraform-managed infrastructure. + +Destroying your infrastructure is a rare event in production +environments. But if you're using Terraform to spin up multiple +environments such as development, test, QA environments, then +destroying is a useful action. + +## Plan + +For Terraform to destroy our infrastructure, we need to ask +Terraform to generate a destroy execution plan. This is a special +kind of execution plan that only destroys all Terraform-managed +infrastructure, and doesn't create or update any components. + +``` +$ terraform plan -destroy -out=terraform.tfplan +... + +- aws_instance.example +``` + +The plan command is given two new flags. + +The first flag, `-destroy` tells Terraform to create an execution +plan to destroy the infrastructure. You can see in the output that +our one EC2 instance will be destroyed. + +The second flag, `-out` tells Terraform to save the execution plan +to a file. We haven't seen this before, but it isn't limited to +only destroys. Any plan can be saved to a file. Terraform can then +apply a plan, ensuring that only exactly the plan you saw is executed. +For destroys, you must save into a plan, since there is no way to +tell `apply` to destroy otherwise. + +## Apply + +Let's apply the destroy: + +``` +$ terraform apply terraform.tfplan +aws_instance.example: Destroying... + +Apply complete! Resources: 0 added, 0 changed, 1 destroyed. + +... +``` + +Done. Terraform destroyed our one instance, and if you run a +`terraform show`, you'll see that the state file is now empty. + +For this command, we gave an argument to `apply` for the first +time. You can give apply a specific plan to execute. + +## Next + +You now know how to create, modify, and destroy infrastructure. +With these building blocks, you can effectively experiment with +any part of Terraform. + +Next, we move on to features that make Terraform configurations +slightly more useful: [variables, resource dependencies, provisioning, +and more](/intro/getting-started/dependencies.html). diff --git a/website/source/intro/getting-started/outputs.html.md b/website/source/intro/getting-started/outputs.html.md index 7273b98d0..82e55a77d 100644 --- a/website/source/intro/getting-started/outputs.html.md +++ b/website/source/intro/getting-started/outputs.html.md @@ -1,80 +1,80 @@ ---- -layout: "intro" -page_title: "Output Variables" -sidebar_current: "gettingstarted-outputs" ---- - -# Output Variables - -In the previous section, we introduced input variables as a way -to parameterize Terraform configurations. In this page, we -introduce output variables as a way to organize data to be -easily queried and shown back to the Terraform user. - -When building potentially complex infrastructure, Terraform -stores hundreds or thousands of attribute values for all your -resources. But as a user of Terraform, you may only be interested -in a few values of importance, such as a load balancer IP, -VPN address, etc. - -Outputs are a way to tell Terraform what data is important. -This data is outputted when `apply` is called, and can be -queried using the `terraform output` command. - -## Defining Outputs - -Let's define an output to show us the public IP address of the -elastic IP address that we create. Add this to any of your -`*.tf` files: - -``` -output "ip" { - value = "${aws_eip.ip.public_ip}" -} -``` - -This defines an output variables named "ip". The `value` field -specifies what the value will be, and almost always contains -one or more interpolations, since the output data is typically -dynamic. In this case, we're outputting the -`public_ip` attribute of the elastic IP address. - -Multiple `output` blocks can be defined to specify multiple -output variables. - -## Viewing Outputs - -Run `terraform apply` to populate the output. This only needs -to be done once after the output is defined. The apply output -should change slightly. At the end you should see this: - -``` -$ terraform apply -... - -Apply complete! Resources: 0 added, 0 changed, 0 destroyed. - -Outputs: - - ip = 50.17.232.209 -``` - -`apply` highlights the outputs. You can also query the outputs -after apply-time using `terraform output`: - -``` -$ terraform output ip -50.17.232.209 -``` - -This command is useful for scripts to extract outputs. - -## Next - -You now know how to parameterize configurations with input -variables, extract important data using output variables, -and bootstrap resources using provisioners. - -We've now concluded the getting started guide, however -there are a number of [next steps](/intro/getting-started/next-steps.html) -to get started with Terraform. +--- +layout: "intro" +page_title: "Output Variables" +sidebar_current: "gettingstarted-outputs" +--- + +# Output Variables + +In the previous section, we introduced input variables as a way +to parameterize Terraform configurations. In this page, we +introduce output variables as a way to organize data to be +easily queried and shown back to the Terraform user. + +When building potentially complex infrastructure, Terraform +stores hundreds or thousands of attribute values for all your +resources. But as a user of Terraform, you may only be interested +in a few values of importance, such as a load balancer IP, +VPN address, etc. + +Outputs are a way to tell Terraform what data is important. +This data is outputted when `apply` is called, and can be +queried using the `terraform output` command. + +## Defining Outputs + +Let's define an output to show us the public IP address of the +elastic IP address that we create. Add this to any of your +`*.tf` files: + +``` +output "ip" { + value = "${aws_eip.ip.public_ip}" +} +``` + +This defines an output variables named "ip". The `value` field +specifies what the value will be, and almost always contains +one or more interpolations, since the output data is typically +dynamic. In this case, we're outputting the +`public_ip` attribute of the elastic IP address. + +Multiple `output` blocks can be defined to specify multiple +output variables. + +## Viewing Outputs + +Run `terraform apply` to populate the output. This only needs +to be done once after the output is defined. The apply output +should change slightly. At the end you should see this: + +``` +$ terraform apply +... + +Apply complete! Resources: 0 added, 0 changed, 0 destroyed. + +Outputs: + + ip = 50.17.232.209 +``` + +`apply` highlights the outputs. You can also query the outputs +after apply-time using `terraform output`: + +``` +$ terraform output ip +50.17.232.209 +``` + +This command is useful for scripts to extract outputs. + +## Next + +You now know how to parameterize configurations with input +variables, extract important data using output variables, +and bootstrap resources using provisioners. + +We've now concluded the getting started guide, however +there are a number of [next steps](/intro/getting-started/next-steps.html) +to get started with Terraform. diff --git a/website/source/intro/getting-started/provision.html.md b/website/source/intro/getting-started/provision.html.md index ed6e8326d..188570b0c 100644 --- a/website/source/intro/getting-started/provision.html.md +++ b/website/source/intro/getting-started/provision.html.md @@ -1,110 +1,110 @@ ---- -layout: "intro" -page_title: "Provision" -sidebar_current: "gettingstarted-provision" ---- - -# Provision - -You're now able to create and modify infrastructure. This page -introduces how to use provisioners to run basic shell scripts on -instances when they're created. - -If you're using an image-based infrastructure (perhaps with images -created with [Packer](http://www.packer.io)), then what you've -learned so far is good enough. But if you need to do some initial -setup on your instances, provisioners let you upload files, -run shell scripts, etc. - -## Defining a Provisioner - -To define a provisioner, modify the resource block defining the -"example" EC2 instance to look like the following: - -``` -resource "aws_instance" "example" { - ami = "ami-aa7ab6c2" - instance_type = "t1.micro" - - provisioner "local-exec" { - command = "echo ${aws_instance.example.public_ip} > file.txt" - } -} -``` - -This adds a `provision` block within the `resource` block. Multiple -`provision` blocks can be added to define multiple provisoining steps. -Terraform supports -[multiple provisioners](/docs/provisioners/index.html), -but for this example we use the "local-exec" provisioner. - -The "local-exec" provisioner executes a command locally on the machine -running Terraform. We're using this provisioner versus the others so -we don't have to worry about specifying any -[connection info](/docs/provisioners/connection.html) right now. - -## Running Provisioners - -Provisioners are run only when a resource is _created_. They -are not a replacement for configuration management and changing -the software of an already-running server, and are instead just -meant as a way to bootstrap a server. For configuration management, -you should use Terraform provisioning to invoke a real configuration -management solution. - -Make sure that your infrastructure is -[destroyed](/intro/getting-started/destroy.html) if it isn't already, -then run `apply`: - -``` -$ terraform apply -aws_instance.example: Creating... - ami: "" => "ami-aa7ab6c2" - instance_type: "" => "t1.micro" -aws_eip.ip: Creating... - instance: "" => "i-213f350a" - -Apply complete! Resources: 2 added, 0 changed, 0 destroyed. -``` - -Terraform currently doesn't output anything to indicate the provisioners -have run. This is going to be fixed soon. However, we can verify -everything worked by looking at the "file.txt" file: - -``` -$ cat file.txt -54.192.26.128 -``` - -It contains the IP, just as we asked! - -## Failed Provisioners and Tainted Resources - -If a resource successfully creates but fails during provision, -Terraform will error and mark the resource as "tainted." A -resource that is tainted has been physically created, but can't -be considered safe to use since provisioning failed. - -When you generate your next execution plan, Terraform will remove -any tainted resources and create new resources, attempting to -provision again. It does not attempt to restart provisioning on the -same resource because it isn't guaranteed to be safe. - -Terraform does not automatically roll back and destroy the resource -during the apply when the failure happens, because that would go -against the execution plan: the execution plan would've said a -resource will be created, but does not say it will ever be deleted. -But if you create an execution plan with a tainted resource, the -plan will clearly state that the resource will be destroyed because -it is tainted. - -## Next - -Provisioning is important for being able to bootstrap instances. -As another reminder, it is not a replacement for configuration -management. It is meant to simply bootstrap machines. If you use -configuration management, you should use the provisioning as a way -to bootstrap the configuration management utility. - -In the next section, we start looking at [variables as a way to -parameterize our configurations](/intro/getting-started/variables.html). +--- +layout: "intro" +page_title: "Provision" +sidebar_current: "gettingstarted-provision" +--- + +# Provision + +You're now able to create and modify infrastructure. This page +introduces how to use provisioners to run basic shell scripts on +instances when they're created. + +If you're using an image-based infrastructure (perhaps with images +created with [Packer](http://www.packer.io)), then what you've +learned so far is good enough. But if you need to do some initial +setup on your instances, provisioners let you upload files, +run shell scripts, etc. + +## Defining a Provisioner + +To define a provisioner, modify the resource block defining the +"example" EC2 instance to look like the following: + +``` +resource "aws_instance" "example" { + ami = "ami-aa7ab6c2" + instance_type = "t1.micro" + + provisioner "local-exec" { + command = "echo ${aws_instance.example.public_ip} > file.txt" + } +} +``` + +This adds a `provision` block within the `resource` block. Multiple +`provision` blocks can be added to define multiple provisoining steps. +Terraform supports +[multiple provisioners](/docs/provisioners/index.html), +but for this example we use the "local-exec" provisioner. + +The "local-exec" provisioner executes a command locally on the machine +running Terraform. We're using this provisioner versus the others so +we don't have to worry about specifying any +[connection info](/docs/provisioners/connection.html) right now. + +## Running Provisioners + +Provisioners are run only when a resource is _created_. They +are not a replacement for configuration management and changing +the software of an already-running server, and are instead just +meant as a way to bootstrap a server. For configuration management, +you should use Terraform provisioning to invoke a real configuration +management solution. + +Make sure that your infrastructure is +[destroyed](/intro/getting-started/destroy.html) if it isn't already, +then run `apply`: + +``` +$ terraform apply +aws_instance.example: Creating... + ami: "" => "ami-aa7ab6c2" + instance_type: "" => "t1.micro" +aws_eip.ip: Creating... + instance: "" => "i-213f350a" + +Apply complete! Resources: 2 added, 0 changed, 0 destroyed. +``` + +Terraform currently doesn't output anything to indicate the provisioners +have run. This is going to be fixed soon. However, we can verify +everything worked by looking at the "file.txt" file: + +``` +$ cat file.txt +54.192.26.128 +``` + +It contains the IP, just as we asked! + +## Failed Provisioners and Tainted Resources + +If a resource successfully creates but fails during provision, +Terraform will error and mark the resource as "tainted." A +resource that is tainted has been physically created, but can't +be considered safe to use since provisioning failed. + +When you generate your next execution plan, Terraform will remove +any tainted resources and create new resources, attempting to +provision again. It does not attempt to restart provisioning on the +same resource because it isn't guaranteed to be safe. + +Terraform does not automatically roll back and destroy the resource +during the apply when the failure happens, because that would go +against the execution plan: the execution plan would've said a +resource will be created, but does not say it will ever be deleted. +But if you create an execution plan with a tainted resource, the +plan will clearly state that the resource will be destroyed because +it is tainted. + +## Next + +Provisioning is important for being able to bootstrap instances. +As another reminder, it is not a replacement for configuration +management. It is meant to simply bootstrap machines. If you use +configuration management, you should use the provisioning as a way +to bootstrap the configuration management utility. + +In the next section, we start looking at [variables as a way to +parameterize our configurations](/intro/getting-started/variables.html). diff --git a/website/source/intro/getting-started/variables.html.md b/website/source/intro/getting-started/variables.html.md index dba4c6951..a089d6aa4 100644 --- a/website/source/intro/getting-started/variables.html.md +++ b/website/source/intro/getting-started/variables.html.md @@ -1,141 +1,141 @@ ---- -layout: "intro" -page_title: "Input Variables" -sidebar_current: "gettingstarted-variables" ---- - -# Input Variables - -You now have enough Terraform knowledge to create useful -configurations, but we're still hardcoding access keys, -AMIs, etc. To become truly shareable and commitable to version -control, we need to parameterize the configurations. This page -introduces input variables as a way to do this. - -## Defining Variables - -Let's first extract our access key, secret key, and region -into a few variables. Create another file `variables.tf` with -the following contents. Note that the file can be named anything, -since Terraform loads all files ending in `.tf` in a directory. - -``` -variable "access_key" {} -variable "secret_key" {} -variable "region" { - default = "us-east-1" -} -``` - -This defines three variables within your Terraform configuration. -The first two have empty blocks `{}`. The third sets a default. If -a default value is set, the variable is optional. Otherwise, the -variable is required. If you run `terraform plan` now, Terraform will -error since the required variables are not set. - -## Using Variables in Configuration - -Next, replace the AWS provider configuration with the following: - -``` -provider "aws" { - access_key = "${var.access_key}" - secret_key = "${var.secret_key}" - region = "${var.region}" -} -``` - -This uses more interpolations, this time prefixed with `var.`. This -tells Terraform that you're accessing variables. This configures -the AWS provider with the given variables. - -## Assigning Variables - -There are two ways to assign variables. - -First, you can set it directly on the command-line with the -`-var` flag. Any command in Terraform that inspects the configuration -accepts this flag, such as `apply`, `plan`, and `refresh`: - -``` -$ terraform plan \ - -var 'access_key=foo' \ - -var 'secret_key=bar' -... -``` - -Second, you can create a file and assign variables directly. Create -a file named "terraform.tfvars" with the following contents: - -``` -access_key = "foo" -secret_key = "bar" -``` - -If a "terraform.tfvars" file is present, Terraform automatically loads -it to populate variables. If the file is named something else, you can -use the `-var-file` flag directly to specify a file. - -We recommend using the "terraform.tfvars" file, and ignoring it from -version control. - -## Mappings - -We've replaced our sensitive strings with variables, but we still -are hardcoding AMIs. Unfortunately, AMIs are specific to the region -that is in use. One option is to just ask the user to input the proper -AMI for the region, but Terraform can do better than that with -_mappings_. - -Mappings are a way to create variables that are lookup tables. An example -will show this best. Let's extract our AMIs into a mapping and add -support for the "us-west-2" region as well: - -``` -variable "amis" { - default = { - "us-east-1": "ami-aa7ab6c2", - "us-west-2": "ami-23f78e13", - } -} -``` - -A variable becomes a mapping when it has a default value that is a -map like above. There is no way to create a required map. - -Then, replace the "aws\_instance" with the following: - -``` -resource "aws_instance" "example" { - ami = "${lookup(var.amis, var.region)}" - instance_type = "t1.micro" -} -``` - -This introduces a new type of interpolation: a function call. The -`lookup` function does a dynamic lookup in a map for a key. The -key is `var.region`, which specifies that the value of the region -variables is the key. - -While we don't use it in our example, it is worth nothing that you -can also do a static lookup of a mapping directly with -`${var.amis.us-east-1}`. - -We set defaults, but mappings can also be overridden using the -`-var` and `-var-file` values. For example, if the user wanted to -specify an alternate AMI for us-east-1: - -``` -$ terraform plan -var 'amis.us-east-1=foo' -... -``` - -## Next - -Terraform provides variables for parameterizing your configurations. -Mappings let you build lookup tables in cases where that make sense. -Setting and using variables is uniform throughout your configurations. - -In the next section, we'll take a look at -[output variables](/intro/getting-started/outputs.html) as a mechanism -to expose certain values more prominently to the Terraform operator. +--- +layout: "intro" +page_title: "Input Variables" +sidebar_current: "gettingstarted-variables" +--- + +# Input Variables + +You now have enough Terraform knowledge to create useful +configurations, but we're still hardcoding access keys, +AMIs, etc. To become truly shareable and commitable to version +control, we need to parameterize the configurations. This page +introduces input variables as a way to do this. + +## Defining Variables + +Let's first extract our access key, secret key, and region +into a few variables. Create another file `variables.tf` with +the following contents. Note that the file can be named anything, +since Terraform loads all files ending in `.tf` in a directory. + +``` +variable "access_key" {} +variable "secret_key" {} +variable "region" { + default = "us-east-1" +} +``` + +This defines three variables within your Terraform configuration. +The first two have empty blocks `{}`. The third sets a default. If +a default value is set, the variable is optional. Otherwise, the +variable is required. If you run `terraform plan` now, Terraform will +error since the required variables are not set. + +## Using Variables in Configuration + +Next, replace the AWS provider configuration with the following: + +``` +provider "aws" { + access_key = "${var.access_key}" + secret_key = "${var.secret_key}" + region = "${var.region}" +} +``` + +This uses more interpolations, this time prefixed with `var.`. This +tells Terraform that you're accessing variables. This configures +the AWS provider with the given variables. + +## Assigning Variables + +There are two ways to assign variables. + +First, you can set it directly on the command-line with the +`-var` flag. Any command in Terraform that inspects the configuration +accepts this flag, such as `apply`, `plan`, and `refresh`: + +``` +$ terraform plan \ + -var 'access_key=foo' \ + -var 'secret_key=bar' +... +``` + +Second, you can create a file and assign variables directly. Create +a file named "terraform.tfvars" with the following contents: + +``` +access_key = "foo" +secret_key = "bar" +``` + +If a "terraform.tfvars" file is present, Terraform automatically loads +it to populate variables. If the file is named something else, you can +use the `-var-file` flag directly to specify a file. + +We recommend using the "terraform.tfvars" file, and ignoring it from +version control. + +## Mappings + +We've replaced our sensitive strings with variables, but we still +are hardcoding AMIs. Unfortunately, AMIs are specific to the region +that is in use. One option is to just ask the user to input the proper +AMI for the region, but Terraform can do better than that with +_mappings_. + +Mappings are a way to create variables that are lookup tables. An example +will show this best. Let's extract our AMIs into a mapping and add +support for the "us-west-2" region as well: + +``` +variable "amis" { + default = { + "us-east-1": "ami-aa7ab6c2", + "us-west-2": "ami-23f78e13", + } +} +``` + +A variable becomes a mapping when it has a default value that is a +map like above. There is no way to create a required map. + +Then, replace the "aws\_instance" with the following: + +``` +resource "aws_instance" "example" { + ami = "${lookup(var.amis, var.region)}" + instance_type = "t1.micro" +} +``` + +This introduces a new type of interpolation: a function call. The +`lookup` function does a dynamic lookup in a map for a key. The +key is `var.region`, which specifies that the value of the region +variables is the key. + +While we don't use it in our example, it is worth nothing that you +can also do a static lookup of a mapping directly with +`${var.amis.us-east-1}`. + +We set defaults, but mappings can also be overridden using the +`-var` and `-var-file` values. For example, if the user wanted to +specify an alternate AMI for us-east-1: + +``` +$ terraform plan -var 'amis.us-east-1=foo' +... +``` + +## Next + +Terraform provides variables for parameterizing your configurations. +Mappings let you build lookup tables in cases where that make sense. +Setting and using variables is uniform throughout your configurations. + +In the next section, we'll take a look at +[output variables](/intro/getting-started/outputs.html) as a mechanism +to expose certain values more prominently to the Terraform operator.