This commit is contained in:
Mitchell Hashimoto 2014-07-28 10:43:00 -07:00
parent e9f058f919
commit d28e5a1638
117 changed files with 2995 additions and 2995 deletions

34
.gitignore vendored
View File

@ -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

View File

@ -1,3 +1,3 @@
resource "test_instance" "foo" {
ami = "${var.nope}"
}
resource "test_instance" "foo" {
ami = "${var.nope}"
}

View File

@ -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"
}

View File

@ -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}"
}

View File

@ -1,5 +1,5 @@
variable "foo" {}
resource "test_instance" "foo" {
value = "${var.foo}"
}
variable "foo" {}
resource "test_instance" "foo" {
value = "${var.foo}"
}

View File

@ -1,3 +1,3 @@
resource "test_instance" "foo" {
ami = "bar"
}
resource "test_instance" "foo" {
ami = "bar"
}

View File

@ -1,3 +1,3 @@
resource "test_instance" "foo" {
ami = "bar"
}
resource "test_instance" "foo" {
ami = "bar"
}

View File

@ -1,5 +1,5 @@
variable "foo" {}
resource "test_instance" "foo" {
value = "${var.foo}"
}
variable "foo" {}
resource "test_instance" "foo" {
value = "${var.foo}"
}

View File

@ -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"
}
}

View File

@ -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" {}

View File

@ -1,3 +1,3 @@
resource "test_instance" "foo" {
ami = "bar"
}
resource "test_instance" "foo" {
ami = "bar"
}

View File

@ -1 +1 @@
variable "foo" {}
variable "foo" {}

View File

@ -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}"
}
}
}

View File

@ -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"
}
}

View File

@ -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.

View File

@ -1,3 +1,3 @@
output "i-am-nested" {
value = "what"
}
output "i-am-nested" {
value = "what"
}

View File

@ -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}"
}

View File

@ -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"
}
}

View File

@ -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}"
}

View File

@ -1,2 +1,2 @@
resource "aws_instance" "db" {
}
resource "aws_instance" "db" {
}

View File

@ -1,9 +1,9 @@
{
"resource": {
"aws_instance": {
"web": {
"foo": "bar",
}
}
}
}
{
"resource": {
"aws_instance": {
"web": {
"foo": "bar",
}
}
}
}

View File

@ -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}"
}

View File

@ -1,10 +1,10 @@
{
"resource": {
"aws_instance": {
"db": {
"ami": "foo",
"security_groups": ""
}
}
}
}
{
"resource": {
"aws_instance": {
"db": {
"ami": "foo",
"security_groups": ""
}
}
}
}

View File

@ -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"
}
}

View File

@ -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" {}

View File

@ -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"
}
}

View File

@ -1,3 +1,3 @@
resource "aws_instance" "web" {
depends_on = ["aws_instance.db"]
}
resource "aws_instance" "web" {
depends_on = ["aws_instance.db"]
}

View File

@ -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}"
}

View File

@ -1,3 +1,3 @@
resource "aws_instance" "web" {
count = -1
}
resource "aws_instance" "web" {
count = -1
}

View File

@ -1,3 +1,3 @@
resource "aws_instance" "web" {
count = 0
}
resource "aws_instance" "web" {
count = 0
}

View File

@ -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
}

View File

@ -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"]
}

View File

@ -1,7 +1,7 @@
resource "aws_instance" "web" {
}
output "ip" {
value = "foo"
another = "nope"
}
resource "aws_instance" "web" {
}
output "ip" {
value = "foo"
another = "nope"
}

View File

@ -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}"
}

View File

@ -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}"
}

View File

@ -1 +1 @@
what "is this"
what "is this"

View File

@ -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}";
}

View File

@ -1,3 +1,3 @@
variable "foo" {
default = ["foo", "bar"]
}
variable "foo" {
default = ["foo", "bar"]
}

View File

@ -1,9 +1,9 @@
variable "foo" {
default = "bar"
}
variable "foo" {
default = {
"foo" = "bar"
}
}
variable "foo" {
default = "bar"
}
variable "foo" {
default = {
"foo" = "bar"
}
}

View File

@ -1,7 +1,7 @@
variable "foo" {}
variable "bar" {
default = ""
}
variable "baz" {
default = "foo"
}
variable "foo" {}
variable "bar" {
default = ""
}
variable "baz" {
default = "foo"
}

View File

@ -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.

View File

@ -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}"
}

View File

@ -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}"
}

View File

@ -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"
}

View File

@ -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}"
}

View File

@ -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"
}

View File

@ -1,2 +1,2 @@
resource "aws_instance" "foo" {
}
resource "aws_instance" "foo" {
}

View File

@ -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}"
}

View File

@ -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}"
}

View File

@ -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}"
}

View File

@ -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" {}
}

View File

@ -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}"
}
}

View File

@ -1,4 +1,4 @@
resource "aws_instance" "bar" {
id = "foo"
num = "2"
}
resource "aws_instance" "bar" {
id = "foo"
num = "2"
}

View File

@ -1,4 +1,4 @@
resource "aws_instance" "foo" {
num = "2"
compute = "foo"
}
resource "aws_instance" "foo" {
num = "2"
compute = "foo"
}

View File

@ -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}"
}

View File

@ -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}"
}

View File

@ -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}"
}

View File

@ -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}"
]
}

View File

@ -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"]
}

View File

@ -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}"
}

View File

@ -1,2 +1,2 @@
resource "aws_instance" "foo" {
}
resource "aws_instance" "foo" {
}

View File

@ -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}"
}
}
}

View File

@ -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" {}

View File

@ -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}"
}

View File

@ -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" {}

View File

@ -1,5 +1,5 @@
provider "aws" {
foo = "bar"
}
resource "aws_instance" "foo" {}
provider "aws" {
foo = "bar"
}
resource "aws_instance" "foo" {}

View File

@ -1,4 +1,4 @@
variable "foo" {}
variable "bar" {
default = "baz"
}
variable "foo" {}
variable "bar" {
default = "baz"
}

View File

@ -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}"
}

View File

@ -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"
}

View File

@ -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"
}

View File

@ -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}"
}

View File

@ -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}"
}

View File

@ -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}"
}

View File

@ -1,5 +1,5 @@
resource "aws_instance" "foo" {
}
resource "aws_instance" "bar" {
}
resource "aws_instance" "foo" {
}
resource "aws_instance" "bar" {
}

View File

@ -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}"
}

View File

@ -1,3 +1,3 @@
resource "aws_instance" "foo" {
nil = "1"
}
resource "aws_instance" "foo" {
nil = "1"
}

View File

@ -1,3 +1,3 @@
resource "aws_instance" "foo" {
num = "2"
}
resource "aws_instance" "foo" {
num = "2"
}

View File

@ -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" {}

View File

@ -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}"
}

View File

@ -1 +1 @@
resource "aws_instance" "web" {}
resource "aws_instance" "web" {}

View File

@ -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}"
}

View File

@ -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";
}
}

View File

@ -1,5 +1,5 @@
provider "aws" {
foo = "bar"
}
resource "aws_instance" "test" {}
provider "aws" {
foo = "bar"
}
resource "aws_instance" "test" {}

View File

@ -1,7 +1,7 @@
provider "aws" {
foo = "bar"
}
resource "aws_instance" "test" {
provisioner "shell" {}
}
provider "aws" {
foo = "bar"
}
resource "aws_instance" "test" {
provisioner "shell" {}
}

View File

@ -1,3 +1,3 @@
resource "aws_instance" "test" {
foo = "bar"
}
resource "aws_instance" "test" {
foo = "bar"
}

View File

@ -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}"
}

View File

@ -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"
}

View File

@ -1,5 +1,5 @@
variable "foo" {}
resource "aws_instance" "web" {
ami = "${var.foo}"
}
variable "foo" {}
resource "aws_instance" "web" {
ami = "${var.foo}"
}

View File

@ -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
}

View File

@ -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
}

View File

@ -1,3 +1,3 @@
resource "aws_instance" "web" {
foo = "${aws_instance.web.foo}"
}
resource "aws_instance" "web" {
foo = "${aws_instance.web.foo}"
}

View File

@ -1,4 +1,4 @@
providers {
"aws" = "foo"
"do" = "bar"
}
providers {
"aws" = "foo"
"do" = "bar"
}

View File

@ -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.

View File

@ -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.

View File

@ -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.

View File

@ -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
}
```

View File

@ -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.

View File

@ -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
}
```

View File

@ -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]
}
```

View File

@ -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.

Some files were not shown because too many files have changed in this diff Show More