Update intro section
This commit is contained in:
Seth Vargo
parent
487c6daf94
commit
9c68595d61
|
|
@ -12,10 +12,16 @@
|
|||
margin-bottom: 0;
|
||||
}
|
||||
|
||||
pre {
|
||||
pre,
|
||||
code,
|
||||
pre code,
|
||||
tt {
|
||||
font-family: $font-family-monospace;
|
||||
font-size: ($font-size - 3);
|
||||
font-weight: normal;
|
||||
font-size: $font-size - 2;
|
||||
line-height: 1.6;
|
||||
}
|
||||
|
||||
pre {
|
||||
padding: 20px;
|
||||
margin: 0 0 $font-size;
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
@import 'bootstrap-sprockets';
|
||||
@import 'bootstrap';
|
||||
|
||||
@import url('https://fonts.googleapis.com/css?family=Fira+Mono:500|Open+Sans:400,600');
|
||||
@import url('https://fonts.googleapis.com/css?family=Fira+Mono|Open+Sans:400,600');
|
||||
|
||||
// Mega Nav
|
||||
@import 'hashicorp/mega-nav';
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
---
|
||||
layout: "intro"
|
||||
page_title: "Basic Two-Tier AWS Architecture"
|
||||
page_title: "Two-Tier AWS Architecture"
|
||||
sidebar_current: "examples-aws"
|
||||
description: |-
|
||||
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.
|
||||
---
|
||||
|
||||
# Basic Two-Tier AWS Architecture
|
||||
# Two-Tier AWS Architecture
|
||||
|
||||
[**Example Source Code**](https://github.com/hashicorp/terraform/tree/master/examples/aws-two-tier)
|
||||
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ 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.
|
||||
|
||||
```
|
||||
```hcl
|
||||
provider "aws" {
|
||||
access_key = "ACCESS_KEY_HERE"
|
||||
secret_key = "SECRET_KEY_HERE"
|
||||
|
|
@ -122,7 +122,7 @@ truncated some of the output to save space.
|
|||
|
||||
```
|
||||
$ terraform plan
|
||||
...
|
||||
# ...
|
||||
|
||||
+ aws_instance.example
|
||||
ami: "ami-2757f631"
|
||||
|
|
@ -156,7 +156,7 @@ 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 displayed
|
||||
it shows the attributes that will be set. When the value displayed
|
||||
is `<computed>`, it means that the value won't be known
|
||||
until the resource is created.
|
||||
|
||||
|
|
@ -179,7 +179,7 @@ aws_instance.example: Creation complete
|
|||
|
||||
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
|
||||
|
||||
...
|
||||
# ...
|
||||
```
|
||||
|
||||
Done! You can go to the AWS console to prove to yourself that the
|
||||
|
|
@ -189,7 +189,7 @@ Terraform also puts 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. It is generally recommended to
|
||||
to anyone who might run Terraform. It is generally recommended to
|
||||
[setup remote state](https://www.terraform.io/docs/state/remote.html)
|
||||
when working with Terraform. This will mean that any potential secrets
|
||||
stored in the state file, will not be checked into version control
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ can see how the infrastructure evolved over time.
|
|||
Let's modify the `ami` of our instance. Edit the `aws_instance.example`
|
||||
resource in your configuration and change it to the following:
|
||||
|
||||
```
|
||||
```hcl
|
||||
resource "aws_instance" "example" {
|
||||
ami = "ami-b374d5a5"
|
||||
instance_type = "t2.micro"
|
||||
|
|
@ -46,7 +46,7 @@ Let's see what Terraform will do with the change we made.
|
|||
|
||||
```
|
||||
$ terraform plan
|
||||
...
|
||||
# ...
|
||||
|
||||
-/+ aws_instance.example
|
||||
ami: "ami-2757f631" => "ami-b374d5a5" (forces new resource)
|
||||
|
|
@ -110,7 +110,7 @@ aws_instance.example: Creation complete
|
|||
|
||||
Apply complete! Resources: 1 added, 0 changed, 1 destroyed.
|
||||
|
||||
...
|
||||
# ...
|
||||
```
|
||||
|
||||
As the plan predicted, Terraform started by destroying our old
|
||||
|
|
|
|||
|
|
@ -29,9 +29,9 @@ 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:
|
||||
|
||||
```
|
||||
```hcl
|
||||
resource "aws_eip" "ip" {
|
||||
instance = "${aws_instance.example.id}"
|
||||
instance = "${aws_instance.example.id}"
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -145,10 +145,10 @@ However, you can also specify explicit dependencies with the
|
|||
we could modify the "aws\_eip" resource to the following, which
|
||||
effectively does the same thing and is redundant:
|
||||
|
||||
```
|
||||
```hcl
|
||||
resource "aws_eip" "ip" {
|
||||
instance = "${aws_instance.example.id}"
|
||||
depends_on = ["aws_instance.example"]
|
||||
instance = "${aws_instance.example.id}"
|
||||
depends_on = ["aws_instance.example"]
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -164,7 +164,7 @@ 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.
|
||||
|
||||
```
|
||||
```hcl
|
||||
resource "aws_instance" "another" {
|
||||
ami = "ami-b374d5a5"
|
||||
instance_type = "t2.micro"
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ to see what resources Terraform will destroy.
|
|||
|
||||
```
|
||||
$ terraform plan -destroy
|
||||
...
|
||||
# ...
|
||||
|
||||
- aws_instance.example
|
||||
```
|
||||
|
|
@ -45,7 +45,7 @@ aws_instance.example: Destroying...
|
|||
|
||||
Apply complete! Resources: 0 added, 0 changed, 1 destroyed.
|
||||
|
||||
...
|
||||
# ...
|
||||
```
|
||||
|
||||
The `terraform destroy` command should ask you to verify that you
|
||||
|
|
|
|||
|
|
@ -3,44 +3,41 @@ layout: "intro"
|
|||
page_title: "Installing Terraform"
|
||||
sidebar_current: "gettingstarted-install"
|
||||
description: |-
|
||||
Terraform must first be installed on your machine. Terraform is distributed as a binary package for all supported platforms and architecture. This page will not cover how to compile Terraform from source.
|
||||
Terraform must first be installed on your machine. Terraform is distributed as
|
||||
a binary package for all supported platforms and architecture. This page will
|
||||
not cover how to compile Terraform from source.
|
||||
---
|
||||
|
||||
# Install Terraform
|
||||
|
||||
Terraform must first be installed on your machine. Terraform is distributed
|
||||
as a [binary package](/downloads.html) for all supported platforms and
|
||||
architecture. This page will not cover how to compile Terraform from
|
||||
source.
|
||||
Terraform must first be installed on your machine. Terraform is distributed as a
|
||||
[binary package](/downloads.html) for all supported platforms and architectures.
|
||||
This page will not cover how to compile Terraform from source, but compiling
|
||||
from source is covered in the [documentation](/docs/index.html) for those who
|
||||
want to be sure they're compiling source they trust into the final binary.
|
||||
|
||||
## Installing Terraform
|
||||
|
||||
To install Terraform, find the [appropriate package](/downloads.html) for
|
||||
your system and download it. Terraform is packaged as a zip archive.
|
||||
To install Terraform, find the [appropriate package](/downloads.html) for your
|
||||
system and download it. Terraform is packaged as a zip archive.
|
||||
|
||||
After downloading Terraform, unzip the package into a directory where
|
||||
Terraform will be installed. The directory will contain a binary program `terraform`. The final
|
||||
step is to make sure the directory you installed Terraform to is on the
|
||||
PATH. See
|
||||
[this page](https://stackoverflow.com/questions/14637979/how-to-permanently-set-path-on-linux)
|
||||
After downloading Terraform, unzip the package. Terraform runs as a single
|
||||
binary named `terraform`. Any other files in the package can be safely removed
|
||||
and Terraform will still function.
|
||||
|
||||
The final step is to make sure that the `terraform` binary is available on the `PATH`.
|
||||
See [this page](https://stackoverflow.com/questions/14637979/how-to-permanently-set-path-on-linux)
|
||||
for instructions on setting the PATH on Linux and Mac.
|
||||
[This page](https://stackoverflow.com/questions/1618280/where-can-i-set-path-to-make-exe-on-windows)
|
||||
contains instructions for setting the PATH on Windows.
|
||||
|
||||
Example for Linux/Mac - Type the following into your terminal:
|
||||
>`PATH=/usr/local/terraform/bin:/home/your-user-name:$PATH`
|
||||
|
||||
Example for Windows - Type the following into Powershell:
|
||||
>`[Environment]::SetEnvironmentVariable("PATH", $env:PATH + ({;C:\terraform},{C:\terraform})[$env:PATH[-1] -eq ';'], "User")`
|
||||
|
||||
|
||||
## Verifying the Installation
|
||||
|
||||
After installing Terraform, verify the installation worked by opening a new
|
||||
terminal session and checking that `terraform` is available. By executing
|
||||
`terraform` you should see help output similar to that below:
|
||||
`terraform` you should see help output similar to this:
|
||||
|
||||
```
|
||||
```text
|
||||
$ terraform
|
||||
Usage: terraform [--version] [--help] <command> [args]
|
||||
|
||||
|
|
@ -53,37 +50,15 @@ other commands, please read the help and docs before usage.
|
|||
Common commands:
|
||||
apply Builds or changes infrastructure
|
||||
console Interactive console for Terraform interpolations
|
||||
destroy Destroy Terraform-managed infrastructure
|
||||
env Environment management
|
||||
fmt Rewrites config files to canonical format
|
||||
get Download and install modules for the configuration
|
||||
graph Create a visual graph of Terraform resources
|
||||
import Import existing infrastructure into Terraform
|
||||
init Initialize a new or existing Terraform configuration
|
||||
output Read an output from a state file
|
||||
plan Generate and show an execution plan
|
||||
push Upload this Terraform module to Atlas to run
|
||||
refresh Update local state file against real resources
|
||||
show Inspect Terraform state or plan
|
||||
taint Manually mark a resource for recreation
|
||||
untaint Manually unmark a resource as tainted
|
||||
validate Validates the Terraform files
|
||||
version Prints the Terraform version
|
||||
|
||||
All other commands:
|
||||
debug Debug output management (experimental)
|
||||
force-unlock Manually unlock the terraform state
|
||||
state Advanced state management
|
||||
# ...
|
||||
```
|
||||
|
||||
If you get an error that `terraform` could not be found, then your PATH
|
||||
environment variable was not setup properly. Please go back and ensure
|
||||
that your PATH variable contains the directory where Terraform was installed.
|
||||
If you get an error that `terraform` could not be found, your `PATH` environment
|
||||
variable was not set up properly. Please go back and ensure that your `PATH`
|
||||
variable contains the directory where Terraform was installed.
|
||||
|
||||
Otherwise, Terraform is installed and ready to go! Nice!
|
||||
## Next Steps
|
||||
|
||||
## Next Step
|
||||
|
||||
Time to [build infrastructure](/intro/getting-started/build.html)
|
||||
using a minimal Terraform configuration file. You will be able to
|
||||
examine Terraform's execution plan before you deploy it to AWS.
|
||||
Time to [build infrastructure](/intro/getting-started/build.html) using a
|
||||
minimal Terraform configuration file. You will be able to examine Terraform's
|
||||
execution plan before you deploy it to AWS.
|
||||
|
|
|
|||
|
|
@ -38,20 +38,20 @@ for us.
|
|||
|
||||
Create a configuration file with the following contents:
|
||||
|
||||
```
|
||||
```hcl
|
||||
provider "aws" {
|
||||
access_key = "AWS ACCESS KEY"
|
||||
secret_key = "AWS SECRET KEY"
|
||||
region = "AWS REGION"
|
||||
access_key = "AWS ACCESS KEY"
|
||||
secret_key = "AWS SECRET KEY"
|
||||
region = "AWS REGION"
|
||||
}
|
||||
|
||||
module "consul" {
|
||||
source = "github.com/hashicorp/consul/terraform/aws"
|
||||
source = "github.com/hashicorp/consul/terraform/aws"
|
||||
|
||||
key_name = "AWS SSH KEY NAME"
|
||||
key_path = "PATH TO ABOVE PRIVATE KEY"
|
||||
region = "us-east-1"
|
||||
servers = "3"
|
||||
key_name = "AWS SSH KEY NAME"
|
||||
key_path = "PATH TO ABOVE PRIVATE KEY"
|
||||
region = "us-east-1"
|
||||
servers = "3"
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -78,7 +78,7 @@ This is done using the [get command](/docs/commands/get.html).
|
|||
|
||||
```
|
||||
$ terraform get
|
||||
...
|
||||
# ...
|
||||
```
|
||||
|
||||
This command will download the modules if they haven't been already.
|
||||
|
|
@ -93,15 +93,16 @@ With the modules downloaded, we can now plan and apply it. If you run
|
|||
|
||||
```
|
||||
$ terraform plan
|
||||
...
|
||||
# ...
|
||||
+ module.consul.aws_instance.server.0
|
||||
...
|
||||
# ...
|
||||
+ module.consul.aws_instance.server.1
|
||||
...
|
||||
# ...
|
||||
+ module.consul.aws_instance.server.2
|
||||
...
|
||||
# ...
|
||||
+ module.consul.aws_security_group.consul
|
||||
...
|
||||
# ...
|
||||
|
||||
Plan: 4 to add, 0 to change, 0 to destroy.
|
||||
```
|
||||
|
||||
|
|
@ -117,7 +118,7 @@ will have some cost associated with it.
|
|||
|
||||
```
|
||||
$ terraform apply
|
||||
...
|
||||
# ...
|
||||
Apply complete! Resources: 3 added, 0 changed, 0 destroyed.
|
||||
```
|
||||
|
||||
|
|
@ -140,9 +141,9 @@ To reference this, we'll just put it into our own output variable. But this
|
|||
value could be used anywhere: in another resource, to configure another
|
||||
provider, etc.
|
||||
|
||||
```
|
||||
```hcl
|
||||
output "consul_address" {
|
||||
value = "${module.consul.server_address}"
|
||||
value = "${module.consul.server_address}"
|
||||
}
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -29,9 +29,9 @@ 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:
|
||||
|
||||
```
|
||||
```hcl
|
||||
output "ip" {
|
||||
value = "${aws_eip.ip.public_ip}"
|
||||
value = "${aws_eip.ip.public_ip}"
|
||||
}
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ configuration management tools, etc.
|
|||
To define a provisioner, modify the resource block defining the
|
||||
"example" EC2 instance to look like the following:
|
||||
|
||||
```
|
||||
```hcl
|
||||
resource "aws_instance" "example" {
|
||||
ami = "ami-b374d5a5"
|
||||
instance_type = "t2.micro"
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ you'll have to run your own Consul server or use a backend that supports locking
|
|||
|
||||
First, configure the backend in your configuration:
|
||||
|
||||
```
|
||||
```hcl
|
||||
terraform {
|
||||
backend "consul" {
|
||||
address = "demo.consul.io"
|
||||
|
|
@ -71,7 +71,7 @@ no changes:
|
|||
|
||||
```
|
||||
$ terraform plan
|
||||
...
|
||||
# ...
|
||||
|
||||
No changes. Infrastructure is up-to-date.
|
||||
|
||||
|
|
@ -115,7 +115,7 @@ $ export ATLAS_TOKEN=ATLAS_ACCESS_TOKEN
|
|||
Replace `ATLAS_ACCESS_TOKEN` with the token generated earlier. Next,
|
||||
configure the Terraform Enterprise backend:
|
||||
|
||||
```
|
||||
```hcl
|
||||
terraform {
|
||||
backend "atlas" {
|
||||
name = "USERNAME/getting-started"
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ the following contents.
|
|||
-> **Note**: that the file can be named anything, since Terraform loads all
|
||||
files ending in `.tf` in a directory.
|
||||
|
||||
```
|
||||
```hcl
|
||||
variable "access_key" {}
|
||||
variable "secret_key" {}
|
||||
variable "region" {
|
||||
|
|
@ -41,7 +41,7 @@ variables.
|
|||
|
||||
Next, replace the AWS provider configuration with the following:
|
||||
|
||||
```
|
||||
```hcl
|
||||
provider "aws" {
|
||||
access_key = "${var.access_key}"
|
||||
secret_key = "${var.secret_key}"
|
||||
|
|
@ -69,7 +69,7 @@ accepts this flag, such as `apply`, `plan`, and `refresh`:
|
|||
$ terraform plan \
|
||||
-var 'access_key=foo' \
|
||||
-var 'secret_key=bar'
|
||||
...
|
||||
# ...
|
||||
```
|
||||
|
||||
Once again, setting variables this way will not save them, and they'll
|
||||
|
|
@ -81,7 +81,7 @@ To persist variable values, create a file and assign variables within
|
|||
this file. Create a file named `terraform.tfvars` with the following
|
||||
contents:
|
||||
|
||||
```
|
||||
```hcl
|
||||
access_key = "foo"
|
||||
secret_key = "bar"
|
||||
```
|
||||
|
|
@ -111,7 +111,7 @@ Terraform will read environment variables in the form of `TF_VAR_name`
|
|||
to find the value for a variable. For example, the `TF_VAR_access_key`
|
||||
variable can be set to set the `access_key` variable.
|
||||
|
||||
-> **Note**: Environment variables can only populate string-type variables.
|
||||
-> **Note**: Environment variables can only populate string-type variables.
|
||||
List and map type variables must be populated via one of the other mechanisms.
|
||||
|
||||
#### UI Input
|
||||
|
|
@ -135,7 +135,7 @@ for the variable.
|
|||
|
||||
Lists are defined either explicitly or implicitly
|
||||
|
||||
```
|
||||
```hcl
|
||||
# implicitly by using brackets [...]
|
||||
variable "cidrs" { default = [] }
|
||||
|
||||
|
|
@ -145,12 +145,10 @@ variable "cidrs" { type = "list" }
|
|||
|
||||
You can specify lists in a `terraform.tfvars` file:
|
||||
|
||||
```
|
||||
```hcl
|
||||
cidrs = [ "10.0.0.0/16", "10.1.0.0/16" ]
|
||||
```
|
||||
|
||||
<a id="mappings"></a>
|
||||
<a id="maps"></a>
|
||||
## Maps
|
||||
|
||||
We've replaced our sensitive strings with variables, but we still
|
||||
|
|
@ -163,12 +161,12 @@ Maps are a way to create variables that are lookup tables. An example
|
|||
will show this best. Let's extract our AMIs into a map and add
|
||||
support for the `us-west-2` region as well:
|
||||
|
||||
```
|
||||
```hcl
|
||||
variable "amis" {
|
||||
type = "map"
|
||||
default = {
|
||||
us-east-1 = "ami-b374d5a5"
|
||||
us-west-2 = "ami-4b32be2b"
|
||||
"us-east-1" = "ami-b374d5a5"
|
||||
"us-west-2" = "ami-4b32be2b"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
|
@ -179,7 +177,7 @@ demonstrates both.
|
|||
|
||||
Then, replace the `aws_instance` with the following:
|
||||
|
||||
```
|
||||
```hcl
|
||||
resource "aws_instance" "example" {
|
||||
ami = "${lookup(var.amis, var.region)}"
|
||||
instance_type = "t2.micro"
|
||||
|
|
@ -195,7 +193,6 @@ While we don't use it in our example, it is worth noting that you
|
|||
can also do a static lookup of a map directly with
|
||||
`${var.amis["us-east-1"]}`.
|
||||
|
||||
<a id="assigning-maps"></a>
|
||||
## Assigning Maps
|
||||
|
||||
We set defaults above, but maps can also be set using the `-var` and
|
||||
|
|
@ -203,7 +200,7 @@ We set defaults above, but maps can also be set using the `-var` and
|
|||
|
||||
```
|
||||
$ terraform plan -var 'amis={ us-east-1 = "foo", us-west-2 = "bar" }'
|
||||
...
|
||||
# ...
|
||||
```
|
||||
|
||||
-> **Note**: Even if every key will be assigned as input, the variable must be
|
||||
|
|
@ -212,7 +209,7 @@ established as a map by setting its default to `{}`.
|
|||
Here is an example of setting a map's keys from a file. Starting with these
|
||||
variable definitions:
|
||||
|
||||
```
|
||||
```hcl
|
||||
variable "region" {}
|
||||
variable "amis" {
|
||||
type = "map"
|
||||
|
|
@ -221,16 +218,16 @@ variable "amis" {
|
|||
|
||||
You can specify keys in a `terraform.tfvars` file:
|
||||
|
||||
```
|
||||
```hcl
|
||||
amis = {
|
||||
us-east-1 = "ami-abc123"
|
||||
us-west-2 = "ami-def456"
|
||||
"us-east-1" = "ami-abc123"
|
||||
"us-west-2" = "ami-def456"
|
||||
}
|
||||
```
|
||||
|
||||
And access them via `lookup()`:
|
||||
|
||||
```
|
||||
```hcl
|
||||
output "ami" {
|
||||
value = "${lookup(var.amis, var.region)}"
|
||||
}
|
||||
|
|
@ -246,7 +243,6 @@ Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
|
|||
Outputs:
|
||||
|
||||
ami = ami-def456
|
||||
|
||||
```
|
||||
|
||||
## Next
|
||||
|
|
|
|||
|
|
@ -41,27 +41,31 @@ Examples work best to showcase Terraform. Please see the
|
|||
|
||||
The key features of Terraform are:
|
||||
|
||||
* **Infrastructure as Code**: Infrastructure is described using a high-level
|
||||
configuration syntax. This allows a blueprint of your datacenter to be
|
||||
versioned and treated as you would any other code. Additionally,
|
||||
infrastructure can be shared and re-used.
|
||||
### Infrastructure as Code
|
||||
|
||||
* **Execution Plans**: Terraform has a "planning" step where it generates
|
||||
an _execution plan_. The execution plan shows what Terraform will do when
|
||||
you call apply. This lets you avoid any surprises when Terraform
|
||||
manipulates infrastructure.
|
||||
Infrastructure is described using a high-level configuration syntax. This allows
|
||||
a blueprint of your datacenter to be versioned and treated as you would any
|
||||
other code. Additionally, infrastructure can be shared and re-used.
|
||||
|
||||
* **Resource Graph**: Terraform builds a graph of all your resources,
|
||||
and parallelizes the creation and modification of any non-dependent
|
||||
resources. Because of this, Terraform builds infrastructure as efficiently
|
||||
as possible, and operators get insight into dependencies in their
|
||||
infrastructure.
|
||||
### Execution Plans
|
||||
|
||||
* **Change Automation**: Complex changesets can be applied to
|
||||
your infrastructure with minimal human interaction.
|
||||
With the previously mentioned execution
|
||||
plan and resource graph, you know exactly what Terraform will change
|
||||
and in what order, avoiding many possible human errors.
|
||||
Terraform has a "planning" step where it generates an _execution plan_. The
|
||||
execution plan shows what Terraform will do when you call apply. This lets you
|
||||
avoid any surprises when Terraform manipulates infrastructure.
|
||||
|
||||
### Resource Graph
|
||||
|
||||
Terraform builds a graph of all your resources, and parallelizes the creation
|
||||
and modification of any non-dependent resources. Because of this, Terraform
|
||||
builds infrastructure as efficiently as possible, and operators get insight into
|
||||
dependencies in their infrastructure.
|
||||
|
||||
### Change Automation
|
||||
|
||||
Complex changesets can be applied to your infrastructure with minimal human
|
||||
interaction. With the previously mentioned execution plan and resource graph,
|
||||
you know exactly what Terraform will change and in what order, avoiding many
|
||||
possible human errors.
|
||||
|
||||
## Next Steps
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ This page lists some concrete use cases for Terraform, but the possible use case
|
|||
much broader than what we cover. Due to its extensible nature, providers and provisioners
|
||||
can be added to further extend Terraform's ability to manipulate resources.
|
||||
|
||||
#### Heroku App Setup
|
||||
## Heroku App Setup
|
||||
|
||||
Heroku is a popular PaaS for hosting web apps. Developers create an app, and then
|
||||
attach add-ons, such as a database, or email provider. One of the best features is
|
||||
|
|
@ -26,7 +26,7 @@ DNSimple to set a CNAME, or setting up Cloudflare as a CDN for the
|
|||
app. Best of all, Terraform can do all of this in under 30 seconds without
|
||||
using a web interface.
|
||||
|
||||
#### Multi-Tier Applications
|
||||
## Multi-Tier Applications
|
||||
|
||||
A very common pattern is the N-tier architecture. The most common 2-tier architecture is
|
||||
a pool of web servers that use a database tier. Additional tiers get added for API servers,
|
||||
|
|
@ -41,7 +41,7 @@ scaled easily using Terraform by modifying a single `count` configuration value.
|
|||
the creation and provisioning of a resource is codified and automated, elastically scaling
|
||||
with load becomes trivial.
|
||||
|
||||
#### Self-Service Clusters
|
||||
## Self-Service Clusters
|
||||
|
||||
At a certain organizational size, it becomes very challenging for a centralized
|
||||
operations team to manage a large and growing infrastructure. Instead it becomes
|
||||
|
|
@ -53,7 +53,7 @@ in a configuration. Terraform configurations can be shared within an organizatio
|
|||
enabling customer teams to use the configuration as a black box and use Terraform as
|
||||
a tool to manage their services.
|
||||
|
||||
#### Software Demos
|
||||
## Software Demos
|
||||
|
||||
Modern software is increasingly networked and distributed. Although tools like
|
||||
[Vagrant](https://www.vagrantup.com/) exist to build virtualized environments
|
||||
|
|
@ -65,7 +65,7 @@ bootstrap a demo on cloud providers like AWS. This allows end users to easily de
|
|||
the software on their own infrastructure, and even enables tweaking parameters like
|
||||
cluster size to more rigorously test tools at any scale.
|
||||
|
||||
#### Disposable Environments
|
||||
## Disposable Environments
|
||||
|
||||
It is common practice to have both a production and staging or QA environment.
|
||||
These environments are smaller clones of their production counterpart, but are
|
||||
|
|
@ -79,7 +79,7 @@ environments to test in, and then be easily disposed of. Terraform can help tame
|
|||
the difficulty of maintaining parallel environments, and makes it practical
|
||||
to elastically create and destroy them.
|
||||
|
||||
#### Software Defined Networking
|
||||
## Software Defined Networking
|
||||
|
||||
Software Defined Networking (SDN) is becoming increasingly prevalent in the
|
||||
datacenter, as it provides more control to operators and developers and
|
||||
|
|
@ -93,7 +93,7 @@ versioned and changes to be automated. As an example, [AWS VPC](https://aws.amaz
|
|||
is one of the most commonly used SDN implementations, and [can be configured by
|
||||
Terraform](/docs/providers/aws/r/vpc.html).
|
||||
|
||||
#### Resource Schedulers
|
||||
## Resource Schedulers
|
||||
|
||||
In large-scale infrastructures, static assignment of applications to machines
|
||||
becomes increasingly challenging. To solve that problem, there are a number
|
||||
|
|
@ -106,7 +106,7 @@ can be treated as a provider, enabling Terraform to request resources from them.
|
|||
This allows Terraform to be used in layers: to setup the physical infrastructure
|
||||
running the schedulers as well as provisioning onto the scheduled grid.
|
||||
|
||||
#### Multi-Cloud Deployment
|
||||
## Multi-Cloud Deployment
|
||||
|
||||
It's often attractive to spread infrastructure across multiple clouds to increase
|
||||
fault-tolerance. By using only a single region or cloud provider, fault tolerance
|
||||
|
|
@ -118,4 +118,3 @@ for infrastructure management are cloud-specific. Terraform is cloud-agnostic
|
|||
and allows a single configuration to be used to manage multiple providers, and
|
||||
to even handle cross-cloud dependencies. This simplifies management and orchestration,
|
||||
helping operators build large-scale multi-cloud infrastructures.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
</li>
|
||||
|
||||
<li<%= sidebar_current("vs-other") %>>
|
||||
<a href="/intro/vs/index.html">Terraform vs. Other Software</a>
|
||||
<a href="/intro/vs/index.html">Terraform vs. Other</a>
|
||||
<ul class="nav">
|
||||
<li<%= sidebar_current("vs-other-chef") %>>
|
||||
<a href="/intro/vs/chef-puppet.html">Chef, Puppet, etc.</a>
|
||||
|
|
@ -70,7 +70,7 @@
|
|||
<a href="/intro/examples/index.html">Example Configurations</a>
|
||||
<ul class="nav">
|
||||
<li<%= sidebar_current("examples-aws") %>>
|
||||
<a href="/intro/examples/aws.html">Basic Two-Tier AWS Architecture</a>
|
||||
<a href="/intro/examples/aws.html">Two-Tier AWS Architecture</a>
|
||||
</li>
|
||||
<li<%= sidebar_current("examples-cross-provider") %>>
|
||||
<a href="/intro/examples/cross-provider.html">Cross Provider</a>
|
||||
|
|
|
|||
Loading…
Reference in New Issue