website: move all examples into the GitHub repo

This commit is contained in:
Mitchell Hashimoto 2014-10-13 22:18:45 -07:00
parent 104ed0fb9b
commit 0bc21a928d
15 changed files with 234 additions and 203 deletions

View File

@ -0,0 +1,10 @@
# 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.
As with all examples, just copy and paste the example and run
`terraform apply` to see it work.

View File

@ -0,0 +1,30 @@
# Specify the provider and access details
provider "aws" {
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
}

View File

@ -0,0 +1,3 @@
output "address" {
value = "Instances: ${aws_instance.web.*.id}"
}

View File

@ -0,0 +1,14 @@
variable "aws_region" {
description = "The AWS region to create things in."
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"
}
}

View File

@ -0,0 +1,18 @@
# Basic Two-Tier AWS Architecture
This provides a template for running a simple two-tier architecture on Amazon
Web services. The premise is that 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.
As with all examples, just copy and paste the example and run
`terraform apply` to see it work.

49
examples/consul/README.md Normal file
View File

@ -0,0 +1,49 @@
# 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 determined 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 its 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.

43
examples/consul/main.tf Normal file
View File

@ -0,0 +1,43 @@
# Setup the Consul provisioner to use the demo cluster
provider "consul" {
address = "demo.consul.io:80"
datacenter = "nyc1"
}
# Setup an AWS provider
provider "aws" {
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
}
}

View File

@ -0,0 +1,14 @@
variable "aws_region" {
description = "The AWS region to create resources in."
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",
}
}

View File

@ -0,0 +1,11 @@
# Cross Provider Examples
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.
As with all examples, just copy and paste the example and run
`terraform apply` to see it work.

View File

@ -0,0 +1,26 @@
# 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}"
}

View File

@ -0,0 +1,3 @@
output "address" {
value = "${dnsimple_record.web.hostname}"
}

View File

@ -0,0 +1,3 @@
variable "dnsimple_domain" {
description = "The domain we are creating a record for."
}

View File

@ -6,6 +6,8 @@ sidebar_current: "examples-consul"
# Consul Example # Consul Example
[**Example Contents**](https://github.com/hashicorp/terraform/tree/master/examples/consul)
[Consul](http://www.consul.io) is a tool for service discovery, configuration [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 and orchestration. The Key/Value store it provides is often used to store
application configuration and information about the infrastructure necessary application configuration and information about the infrastructure necessary
@ -52,79 +54,3 @@ application relies on ELB for routing, Terraform can update the application's
configuration directly by setting the ELB address into Consul. Any resource configuration directly by setting the ELB address into Consul. Any resource
attribute can be stored in Consul, allowing an operator to capture anything attribute can be stored in Consul, allowing an operator to capture anything
useful. 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
}
}
```

View File

@ -6,73 +6,13 @@ sidebar_current: "examples-count"
# Count Example # Count Example
[**Example Contents**](https://github.com/hashicorp/terraform/tree/master/examples/count)
The count parameter on resources can simplify configurations The count parameter on resources can simplify configurations
and let you scale resources by simply incrementing a number. and let you scale resources by simply incrementing a number.
Additionally, variables can be used to expand a list of resources Additionally, variables can be used to expand a list of resources
for use elsewhere. for use elsewhere.
## Command As with all examples, just copy and paste the example and run
`terraform apply` to see it work.
```
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}"
}
```

View File

@ -6,6 +6,8 @@ sidebar_current: "examples-cross-provider"
# Cross Provider Example # Cross Provider Example
[**Example Contents**](https://github.com/hashicorp/terraform/tree/master/examples/cross-provider)
This is a simple example of the cross-provider capabilities of This is a simple example of the cross-provider capabilities of
Terraform. Terraform.
@ -13,66 +15,5 @@ Very simply, this creates a Heroku application and points a DNS
CNAME record at the result via DNSimple. A `host` query to the outputted CNAME record at the result via DNSimple. A `host` query to the outputted
hostname should reveal the correct DNS configuration. hostname should reveal the correct DNS configuration.
## Command As with all examples, just copy and paste the example and run
`terraform apply` to see it work.
```
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}"
}
```