website: move all examples into the GitHub repo
This commit is contained in:
Mitchell Hashimoto
parent
104ed0fb9b
commit
0bc21a928d
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
}
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
output "address" {
|
||||
value = "Instances: ${aws_instance.web.*.id}"
|
||||
}
|
||||
|
|
@ -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"
|
||||
}
|
||||
}
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
@ -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
|
||||
}
|
||||
}
|
||||
|
|
@ -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",
|
||||
}
|
||||
}
|
||||
|
|
@ -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.
|
||||
|
|
@ -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}"
|
||||
}
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
output "address" {
|
||||
value = "${dnsimple_record.web.hostname}"
|
||||
}
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
variable "dnsimple_domain" {
|
||||
description = "The domain we are creating a record for."
|
||||
}
|
||||
|
|
@ -6,6 +6,8 @@ sidebar_current: "examples-consul"
|
|||
|
||||
# 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
|
||||
and orchestration. The Key/Value store it provides is often used to store
|
||||
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
|
||||
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
|
||||
}
|
||||
}
|
||||
```
|
||||
|
|
|
|||
|
|
@ -6,73 +6,13 @@ sidebar_current: "examples-count"
|
|||
|
||||
# Count Example
|
||||
|
||||
[**Example Contents**](https://github.com/hashicorp/terraform/tree/master/examples/count)
|
||||
|
||||
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}"
|
||||
}
|
||||
```
|
||||
As with all examples, just copy and paste the example and run
|
||||
`terraform apply` to see it work.
|
||||
|
|
|
|||
|
|
@ -6,6 +6,8 @@ sidebar_current: "examples-cross-provider"
|
|||
|
||||
# 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
|
||||
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
|
||||
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}"
|
||||
}
|
||||
```
|
||||
As with all examples, just copy and paste the example and run
|
||||
`terraform apply` to see it work.
|
||||
|
|
|
|||
Loading…
Reference in New Issue