Add meta descriptions to all pages

This commit is contained in:
Seth Vargo 2014-10-21 23:21:56 -04:00
parent 79aa19a121
commit 073a0f76c5
104 changed files with 211 additions and 4 deletions

View File

@ -1,6 +1,8 @@
@import 'bootstrap-sprockets';
@import 'bootstrap';
@import url("http://fonts.googleapis.com/css?family=Lato:300,400,700");
// Core variables and mixins
@import '_variables';
@import '_mixins';

View File

@ -1,6 +1,8 @@
---
layout: "inner"
page_title: "Community"
description: |-
Terraform is a new project with a growing community. Despite this, there are active, dedicated users willing to help you through various mediums.
---
<h1>Community</h1>

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Command: apply"
sidebar_current: "docs-commands-apply"
description: |-
The `terraform apply` command is used to apply the changes required to reach the desired state of the configuration, or the pre-determined set of actions generated by a `terraform plan` execution plan.
---
# Command: apply

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Command: destroy"
sidebar_current: "docs-commands-destroy"
description: |-
The `terraform destroy` command is used to destroy the Terraform-managed infrastructure.
---
# Command: destroy

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Command: get"
sidebar_current: "docs-commands-get"
description: |-
The `terraform get` command is used to download and update modules.
---
# Command: get

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Command: graph"
sidebar_current: "docs-commands-graph"
description: |-
The `terraform graph` command is used to generate a visual representation of either a configuration or execution plan. The output is in the DOT format, which can be used by GraphViz to generate charts.
---
# Command: graph

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Commands"
sidebar_current: "docs-commands"
description: |-
Terraform is controlled via a very easy to use command-line interface (CLI). Terraform is only a single command-line application: terraform. This application then takes a subcommand such as "apply" or "plan". The complete list of subcommands is in the navigation to the left.
---
# Terraform Commands (CLI)

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Command: init"
sidebar_current: "docs-commands-init"
description: |-
The `terraform init` command is used to initialize a Terraform configuration using another module as a skeleton.
---
# Command: init

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Command: output"
sidebar_current: "docs-commands-output"
description: |-
The `terraform output` command is used to extract the value of an output variable from the state file.
---
# Command: output

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Command: plan"
sidebar_current: "docs-commands-plan"
description: |-
The `terraform plan` command is used to create an execution plan. Terraform performs a refresh, unless explicitly disabled, and then determines what actions are necessary to achieve the desired state specified in the configuration files. The plan can be saved using `-out`, and then provided to `terraform apply` to ensure only the pre-planned actions are executed.
---
# Command: plan

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Command: refresh"
sidebar_current: "docs-commands-refresh"
description: |-
The `terraform refresh` command is used to reconcile the state Terraform knows about (via its state file) with the real-world infrastructure. This can be used to detect any drift from the last-known state, and to update the state file.
---
# Command: refresh

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Command: show"
sidebar_current: "docs-commands-show"
description: |-
The `terraform show` command is used to provide human-readable output from a state or plan file. This can be used to inspect a plan to ensure that the planned operations are expected, or to inspect the current state as terraform sees it.
---
# Command: show

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Configuration"
sidebar_current: "docs-config"
description: |-
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.
---
# Configuration

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Interpolation Syntax"
sidebar_current: "docs-config-interpolation"
description: |-
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}`.
---
# Interpolation Syntax

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Load Order and Semantics"
sidebar_current: "docs-config-load"
description: |-
When invoking any command that loads the Terraform configuration, Terraform loads all configuration files within the directory specified in alphabetical order.
---
# Load Order and Semantics

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Configuring Modules"
sidebar_current: "docs-config-modules"
description: |-
Modules are used in Terraform to modularize and encapsulate groups of resources in your infrastructure. For more information on modules, see the dedicated modules section.
---
# Module Configuration

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Configuring Outputs"
sidebar_current: "docs-config-outputs"
description: |-
Outputs define values that will be highlighted to the user when Terraform applies, and can be queried easily using the output command. Output usage is covered in more detail in the getting started guide. This page covers configuration syntax for outputs.
---
# Output Configuration

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Overrides"
sidebar_current: "docs-config-override"
description: |-
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

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Configuring Providers"
sidebar_current: "docs-config-providers"
description: |-
Providers are responsible in Terraform for managing the lifecycle of a resource: create, read, update, delete.
---
# Provider Configuration

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Configuring Resources"
sidebar_current: "docs-config-resources"
description: |-
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.
---
# Resource Configuration

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Configuration Syntax"
sidebar_current: "docs-config-syntax"
description: |-
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.
---
# Configuration Syntax

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Configuring Variables"
sidebar_current: "docs-config-variables"
description: |-
Variables define the parameterization of Terraform configurations. Variables can be overridden via the CLI. Variable usage is covered in more detail in the getting started guide. This page covers configuration syntax for variables.
---
# Variable Configuration

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Documentation"
sidebar_current: "docs-home"
description: |-
Welcome to the Terraform documentation! This documentation is more of a reference guide for all available features and options of Terraform. If you're just getting started with Terraform, please start with the introduction and getting started guide instead.
---
# Terraform Documentation

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Resource Graph"
sidebar_current: "docs-internals-graph"
description: |-
Terraform builds a dependency graph from the Terraform configurations, and walks this graph to generate plans, refresh state, and more. This page documents the details of what are contained in this graph, what types of nodes there are, and how the edges of the graph are determined.
---
# Resource Graph

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Internals"
sidebar_current: "docs-internals"
description: |-
This section covers the internals of Terraform and explains how plans are generated, the lifecycle of a provider, etc. The goal of this section is to remove any notion of "magic" from Terraform. We want you to be able to trust and understand what Terraform is doing to function.
---
# Terraform Internals

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Resource Lifecycle"
sidebar_current: "docs-internals-lifecycle"
description: |-
Resources have a strict lifecycle, and can be thought of as basic state machines. Understanding this lifecycle can help better understand how Terraform generates an execution plan, how it safely executes that plan, and what the resource provider is doing throughout all of this.
---
# Resource Lifecycle

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Creating Modules"
sidebar_current: "docs-modules-create"
description: |-
Creating modules in Terraform is easy. You may want to do this to better organize your code, to make a reusable component, or just to learn more about Terraform. For any reason, if you already know the basics of Terraform, creating a module is a piece of cake.
---
# Creating Modules

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Modules"
sidebar_current: "docs-modules"
description: |-
Modules in terraform are self-contained packages of Terraform configurations that are managed as a group. Modules are used to create reusable components in Terraform as well as for basic code organization.
---
# Modules

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Module Sources"
sidebar_current: "docs-modules-sources"
description: |-
As documented in usage, the only required parameter when using a module is the `source` paramter which tells Terraform where the module can be found and what constraints to put on the module if any (such as branches for git, versions, etc.).
---
# Module Sources

View File

@ -2,6 +2,7 @@
layout: "docs"
page_title: "Using Modules"
sidebar_current: "docs-modules-usage"
description: Using modules in Terraform is very similar to defining resources.
---
# Module Usage
@ -91,13 +92,13 @@ For example, with a configuration similar to what we've built above, here
is what the graph output looks like by default:
<div class="center">
<%= image_tag "docs/module_graph.png" %>
![Terraform Module Graph](images/docs/module_graph.png)
</div>
But if we set `-module-depth=-1`, the graph will look like this:
<div class="center">
<%= image_tag "docs/module_graph_expand.png" %>
![Terraform Expanded Module Graph](images/docs/module_graph_expand.png)
</div>
Other commands work similarly with modules. Note that the `-module-depth`

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Plugin Basics"
sidebar_current: "docs-plugins-basics"
description: |-
This page documents the basics of how the plugin system in Terraform works, and how to setup a basic development environment for plugin development if you're writing a Terraform plugin.
---
# Plugin Basics

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Plugins"
sidebar_current: "docs-plugins"
description: |-
Terraform is built on a plugin-based architecture. All providers and provisioners that are used in Terraform configurations are plugins, even the core types such as AWS and Heroku. Users of Terraform are able to write new plugins in order to support new functionality in Terraform.
---
# Plugins

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Provider Plugins"
sidebar_current: "docs-plugins-provider"
description: |-
A provider in Terraform is responsible for the lifecycle of a resource: create, read, update, delete. An example of a provider is AWS, which can manage resources of type `aws_instance`, `aws_eip`, `aws_elb`, etc.
---
# Provider Plugins

View File

@ -2,6 +2,8 @@
layout: "aws"
page_title: "Provider: AWS"
sidebar_current: "docs-aws-index"
description: |-
The Amazon Web Services (AWS) provider is used to interact with the many resources supported by AWS. The provider needs to be configured with the proper credentials before it can be used.
---
# AWS Provider

View File

@ -2,6 +2,8 @@
layout: "aws"
page_title: "AWS: aws_autoscaling_group"
sidebar_current: "docs-aws-resource-autoscale"
description: |-
Provides an AutoScaling Group resource.
---
# aws\_autoscaling\_group

View File

@ -2,6 +2,8 @@
layout: "aws"
page_title: "AWS: aws_db_instance"
sidebar_current: "docs-aws-resource-db-instance"
description: |-
Provides an RDS instance resource.
---
# aws\_db\_instance

View File

@ -2,6 +2,8 @@
layout: "aws"
page_title: "AWS: aws_db_security_group"
sidebar_current: "docs-aws-resource-db-security-group"
description: |-
Provides an RDS security group resource.
---
# aws\_db\_security\_group

View File

@ -2,6 +2,8 @@
layout: "aws"
page_title: "AWS: aws_db_subnet_group"
sidebar_current: "docs-aws-resource-db-subnet-group"
description: |-
Provides an RDS DB subnet group resource.
---
# aws\_db\_subnet\_group

View File

@ -2,6 +2,8 @@
layout: "aws"
page_title: "AWS: aws_eip"
sidebar_current: "docs-aws-resource-eip"
description: |-
Provides an Elastic IP resource.
---
# aws\_eip

View File

@ -2,6 +2,8 @@
layout: "aws"
page_title: "AWS: aws_elb"
sidebar_current: "docs-aws-resource-elb"
description: |-
Provides an Elastic Load Balancer resource.
---
# aws\_elb
@ -28,7 +30,7 @@ resource "aws_elb" "bar" {
instance_protocol = "http"
lb_port = 443
lb_protocol = "https"
ssl_certificate_id = "arn:aws:iam::123456789012:server-certificate/certName"
ssl_certificate_id = "arn:aws:iam::123456789012:server-certificate/certName"
}
health_check {

View File

@ -2,6 +2,8 @@
layout: "aws"
page_title: "AWS: aws_instance"
sidebar_current: "docs-aws-resource-instance"
description: |-
Provides an EC2 instance resource. This allows instances to be created, updated, and deleted. Instances also support provisioning.
---
# aws\_instance

View File

@ -2,6 +2,8 @@
layout: "aws"
page_title: "AWS: aws_internet_gateway"
sidebar_current: "docs-aws-resource-internet-gateway"
description: |-
Provides a resource to create a VPC Internet Gateway.
---
# aws\_internet\_gateway

View File

@ -2,6 +2,8 @@
layout: "aws"
page_title: "AWS: aws_launch_configuration"
sidebar_current: "docs-aws-resource-launch-config"
description: |-
Provides a resource to create a new launch configuration, used for autoscaling groups.
---
# aws\_launch\_configuration

View File

@ -2,6 +2,8 @@
layout: "aws"
page_title: "AWS: aws_route53_record"
sidebar_current: "docs-aws-resource-route53-record"
description: |-
Provides a Route53 record resource.
---
# aws\_route53\_record

View File

@ -2,6 +2,8 @@
layout: "aws"
page_title: "AWS: aws_route53_zone"
sidebar_current: "docs-aws-resource-route53-zone"
description: |-
Provides a Route53 Hosted Zone resource.
---
# aws\_route53\_zone

View File

@ -2,6 +2,8 @@
layout: "aws"
page_title: "AWS: aws_route_table"
sidebar_current: "docs-aws-resource-route-table|"
description: |-
Provides a resource to create a VPC routing table.
---
# aws\_route\_table

View File

@ -2,6 +2,8 @@
layout: "aws"
page_title: "AWS: aws_route_table_association"
sidebar_current: "docs-aws-resource-route-table-assoc"
description: |-
Provides a resource to create an association between a subnet and routing table.
---
# aws\_route\_table\_association

View File

@ -2,6 +2,8 @@
layout: "aws"
page_title: "AWS: aws_s3_bucket"
sidebar_current: "docs-aws-resource-s3-bucket"
description: |-
Provides a S3 bucket resource.
---
# aws\_s3\_bucket

View File

@ -2,6 +2,8 @@
layout: "aws"
page_title: "AWS: aws_security_group"
sidebar_current: "docs-aws-resource-security-group"
description: |-
Provides an security group resource.
---
# aws\_security\_group

View File

@ -2,6 +2,8 @@
layout: "aws"
page_title: "AWS: aws_subnet"
sidebar_current: "docs-aws-resource-subnet"
description: |-
Provides an VPC subnet resource.
---
# aws\_subnet

View File

@ -2,6 +2,8 @@
layout: "aws"
page_title: "AWS: aws_vpc"
sidebar_current: "docs-aws-resource-vpc"
description: |-
Provides an VPC resource.
---
# aws\_vpc

View File

@ -2,6 +2,8 @@
layout: "cloudflare"
page_title: "Provider: Cloudflare"
sidebar_current: "docs-cloudflare-index"
description: |-
The CloudFlare provider is used to interact with the DNS resources supported by CloudFlare. The provider needs to be configured with the proper credentials before it can be used.
---
# CloudFlare Provider

View File

@ -2,6 +2,8 @@
layout: "cloudflare"
page_title: "CloudFlare: cloudflare_record"
sidebar_current: "docs-cloudflare-resource-record"
description: |-
Provides a Cloudflare record resource.
---
# cloudflare\_record

View File

@ -2,6 +2,8 @@
layout: "consul"
page_title: "Provider: Consul"
sidebar_current: "docs-consul-index"
description: |-
Consul is a tool for service discovery, configuration and orchestration. The Consul provider exposes resources used to interact with a Consul cluster. Configuration of the provider is optional, as it provides defaults for all arguments.
---
# Consul Provider

View File

@ -2,6 +2,8 @@
layout: "consul"
page_title: "Consul: consul_keys"
sidebar_current: "docs-consul-resource-keys"
description: |-
Provides access to Key/Value data in Consul. This can be used to both read keys from Consul, but also to set the value of keys in Consul. This is a powerful way dynamically set values in templates, and to expose infrastructure details to clients.
---
# consul\_keys

View File

@ -2,6 +2,8 @@
layout: "dnsimple"
page_title: "Provider: DNSimple"
sidebar_current: "docs-dnsimple-index"
description: |-
The DNSimple provider is used to interact with the resources supported by DNSimple. The provider needs to be configured with the proper credentials before it can be used.
---
# DNSimple Provider

View File

@ -2,6 +2,8 @@
layout: "dnsimple"
page_title: "DNSimple: dnsimple_record"
sidebar_current: "docs-dnsimple-resource-record"
description: |-
Provides a DNSimple record resource.
---
# dnsimple\_record

View File

@ -2,6 +2,8 @@
layout: "digitalocean"
page_title: "Provider: DigitalOcean"
sidebar_current: "docs-do-index"
description: |-
The DigitalOcean (DO) provider is used to interact with the resources supported by DigitalOcean. The provider needs to be configured with the proper credentials before it can be used.
---
# DigitalOcean Provider

View File

@ -2,6 +2,8 @@
layout: "digitalocean"
page_title: "DigitalOcean: digitalocean_domain"
sidebar_current: "docs-do-resource-domain"
description: |-
Provides a DigitalOcean domain resource.
---
# digitalocean\_domain

View File

@ -2,6 +2,8 @@
layout: "digitalocean"
page_title: "DigitalOcean: digitalocean_droplet"
sidebar_current: "docs-do-resource-droplet"
description: |-
Provides a DigitalOcean droplet resource. This can be used to create, modify, and delete droplets. Droplets also support provisioning.
---
# digitalocean\_droplet

View File

@ -2,6 +2,8 @@
layout: "digitalocean"
page_title: "DigitalOcean: digitalocean_record"
sidebar_current: "docs-do-resource-record"
description: |-
Provides a DigitalOcean domain resource.
---
# digitalocean\_record

View File

@ -2,6 +2,8 @@
layout: "google"
page_title: "Provider: Google Cloud"
sidebar_current: "docs-google-index"
description: |-
The Google Cloud provider is used to interact with Google Cloud services. The provider needs to be configured with the proper credentials before it can be used.
---
# Google Cloud Provider

View File

@ -2,6 +2,8 @@
layout: "google"
page_title: "Google: google_compute_address"
sidebar_current: "docs-google-resource-address"
description: |-
Creates a static IP address resource for Google Compute Engine.
---
# google\_compute\_address

View File

@ -2,6 +2,8 @@
layout: "google"
page_title: "Google: google_compute_disk"
sidebar_current: "docs-google-resource-disk"
description: |-
Creates a new persistent disk within GCE, based on another disk.
---
# google\_compute\_disk

View File

@ -2,6 +2,8 @@
layout: "google"
page_title: "Google: google_compute_firewall"
sidebar_current: "docs-google-resource-firewall"
description: |-
Manages a firewall resource within GCE.
---
# google\_compute\_firewall

View File

@ -2,6 +2,8 @@
layout: "google"
page_title: "Google: google_compute_instance"
sidebar_current: "docs-google-resource-instance"
description: |-
Manages a VM instance resource within GCE.
---
# google\_compute\_instance

View File

@ -2,6 +2,8 @@
layout: "google"
page_title: "Google: google_compute_network"
sidebar_current: "docs-google-resource-network"
description: |-
Manages a network within GCE.
---
# google\_compute\_network

View File

@ -2,6 +2,8 @@
layout: "google"
page_title: "Google: google_compute_route"
sidebar_current: "docs-google-resource-route"
description: |-
Manages a network route within GCE.
---
# google\_compute\_route

View File

@ -2,6 +2,8 @@
layout: "heroku"
page_title: "Provider: Heroku"
sidebar_current: "docs-heroku-index"
description: |-
The Heroku provider is used to interact with the resources supported by Heroku. The provider needs to be configured with the proper credentials before it can be used.
---
# Heroku Provider

View File

@ -2,6 +2,8 @@
layout: "heroku"
page_title: "Heroku: heroku_addon"
sidebar_current: "docs-heroku-resource-addon"
description: |-
Provides a Heroku Add-On resource. These can be attach services to a Heroku app.
---
# heroku\_addon

View File

@ -2,6 +2,8 @@
layout: "heroku"
page_title: "Heroku: heroku_app"
sidebar_current: "docs-heroku-resource-app"
description: |-
Provides a Heroku App resource. This can be used to create and manage applications on Heroku.
---
# heroku\_app

View File

@ -2,6 +2,8 @@
layout: "heroku"
page_title: "Heroku: heroku_domain"
sidebar_current: "docs-heroku-resource-domain"
description: |-
Provides a Heroku App resource. This can be used to create and manage applications on Heroku.
---
# heroku\_domain

View File

@ -2,6 +2,8 @@
layout: "heroku"
page_title: "Heroku: heroku_drain"
sidebar_current: "docs-heroku-resource-drain"
description: |-
Provides a Heroku Drain resource. This can be used to create and manage Log Drains on Heroku.
---
# heroku\_drain

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Providers"
sidebar_current: "docs-providers"
description: |-
Terraform is used to create, manage, and manipulate infrastructure resources. Examples of resources include physical machines, VMs, network switches, containers, etc. Almost any infrastructure noun can be represented as a resource in Terraform.
---
# Providers

View File

@ -2,6 +2,8 @@
layout: "mailgun"
page_title: "Provider: Mailgun"
sidebar_current: "docs-mailgun-index"
description: |-
The Mailgun provider is used to interact with the resources supported by Mailgun. The provider needs to be configured with the proper credentials before it can be used.
---
# Provider

View File

@ -2,6 +2,8 @@
layout: "mailgun"
page_title: "Mailgun: mailgun_domain"
sidebar_current: "docs-mailgun-resource-domain"
description: |-
Provides a Mailgun App resource. This can be used to create and manage applications on Mailgun.
---
# mailgun\_domain

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Provisioner Connections"
sidebar_current: "docs-provisioners-connection"
description: |-
Many provisioners require access to the remote resource. For example, a provisioner may need to use ssh to connect to the resource.
---
# Provisioner Connections

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Provisioner: file"
sidebar_current: "docs-provisioners-file"
description: |-
The `file` provisioner is used to copy files or directories from the machine executing Terraform to the newly created resource. The `file` provisioner only supports `ssh` type connections.
---
# File Provisioner

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Provisioners"
sidebar_current: "docs-provisioners"
description: |-
When a resource is initially created, provisioners can be executed to initialize that resource. This can be used to add resources to an inventory management system, run a configuration management tool, bootstrap the resource into a cluster, etc.
---
# Provisioners

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Provisioner: local-exec"
sidebar_current: "docs-provisioners-local"
description: |-
The `local-exec` provisioner invokes a local executable after a resource is created. This invokes a process on the machine running Terraform, not on the resource. See the `remote-exec` provisioner to run commands on the resource.
---
# local-exec Provisioner

View File

@ -2,6 +2,8 @@
layout: "docs"
page_title: "Provisioner: remote-exec"
sidebar_current: "docs-provisioners-remote"
description: |-
The `remote-exec` provisioner invokes a script on a remote resource after it is created. This can be used to run a configuration management tool, bootstrap into a cluster, etc. To invoke a local process, see the `local-exec` provisioner instead. The `remote-exec` provisioner only supports `ssh` type connections.
---
# remote-exec Provisioner

View File

@ -2,6 +2,8 @@
layout: "downloads"
page_title: "Download Terraform"
sidebar_current: "downloads-terraform"
description: |-
Download Terraform
---
<h1>Download Terraform</h1>

View File

@ -2,6 +2,8 @@
layout: "intro"
page_title: "Basic 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

View File

@ -2,6 +2,8 @@
layout: "intro"
page_title: "Consul Example"
sidebar_current: "examples-consul"
description: |-
Consul 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.
---
# Consul Example

View File

@ -2,6 +2,8 @@
layout: "intro"
page_title: "Count"
sidebar_current: "examples-count"
description: |-
The count parameter on resources can simplify configurations and let you scale resources by simply incrementing a number.
---
# Count Example

View File

@ -2,6 +2,8 @@
layout: "intro"
page_title: "Cross Provider"
sidebar_current: "examples-cross-provider"
description: |-
This is a simple example of the cross-provider capabilities of Terraform.
---
# Cross Provider Example

View File

@ -2,6 +2,8 @@
layout: "intro"
page_title: "Example Configurations"
sidebar_current: "examples"
description: |-
These examples are designed to help you understand some of the ways Terraform can be used.
---
# Example Configurations

View File

@ -1,7 +1,9 @@
---
layout: "intro"
page_title: "Build Infrastructure"
sidebar_current: "gettingstarted-build"
sidebar_current: "gettingstarted-build
description: |-
With Terraform installed, let's dive right into it and start creating some infrastructure.
---
# Build Infrastructure

View File

@ -2,6 +2,8 @@
layout: "intro"
page_title: "Change Infrastructure"
sidebar_current: "gettingstarted-change"
description: |-
In the previous page, you created your first infrastructure with Terraform: a single EC2 instance. In this page, we're going to modify that resource, and see how Terraform handles change.
---
# Change Infrastructure

View File

@ -2,6 +2,8 @@
layout: "intro"
page_title: "Resource Dependencies"
sidebar_current: "gettingstarted-deps"
description: |-
In this page, we're going to introduce resource dependencies, where we'll not only see a configuration with multiple resources for the first time, but also scenarios where resource parameters use information from other resources.
---
# Resource Dependencies

View File

@ -2,6 +2,8 @@
layout: "intro"
page_title: "Destroy Infrastructure"
sidebar_current: "gettingstarted-destroy"
description: |-
We've now seen how to build and change infrastructure. Before we move on to creating multiple resources and showing resource dependencies, we're going to go over how to completely destroy the Terraform-managed infrastructure.
---
# Destroy Infrastructure

View File

@ -2,6 +2,8 @@
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.
---
# Install Terraform

View File

@ -2,6 +2,8 @@
layout: "intro"
page_title: "Modules"
sidebar_current: "gettingstarted-modules"
description: |-
Up to this point, we've been configuring Terraform by editing Terraform configurations directly. As our infrastructure grows, this practice has a few key problems: a lack of organization, a lack of reusability, and difficulties in management for teams.
---
# Modules

View File

@ -2,6 +2,8 @@
layout: "intro"
page_title: "Next Steps"
sidebar_current: "gettingstarted-nextsteps"
description: |-
That concludes the getting started guide for Terraform. Hopefully you're now able to not only see what Terraform is useful for, but you're also able to put this knowledge to use to improve building your own infrastructure.
---
# Next Steps

View File

@ -2,6 +2,8 @@
layout: "intro"
page_title: "Output Variables"
sidebar_current: "gettingstarted-outputs"
description: |-
In the previous section, we introduced input variables as a way to parameterize Terraform configurations. In this page, we introduce output variables as a way to organize data to be easily queried and shown back to the Terraform user.
---
# Output Variables

View File

@ -2,6 +2,8 @@
layout: "intro"
page_title: "Provision"
sidebar_current: "gettingstarted-provision"
description: |-
You're now able to create and modify infrastructure. This page introduces how to use provisioners to run basic shell scripts on instances when they're created.
---
# Provision

View File

@ -2,6 +2,8 @@
layout: "intro"
page_title: "Input Variables"
sidebar_current: "gettingstarted-variables"
description: |-
You now have enough Terraform knowledge to create useful configurations, but we're still hardcoding access keys, AMIs, etc. To become truly shareable and commitable to version control, we need to parameterize the configurations. This page introduces input variables as a way to do this.
---
# Input Variables

View File

@ -2,6 +2,8 @@
layout: "intro"
page_title: "Introduction"
sidebar_current: "what"
description: |-
Welcome to the intro guide to Terraform! This guide is the best place to start with Terraform. We cover what Terraform is, what problems it can solve, how it compares to existing software, and contains a quick start for using Terraform.
---
# Introduction to Terraform

View File

@ -2,6 +2,8 @@
layout: "intro"
page_title: "Use Cases"
sidebar_current: "use-cases"
description: |-
Before understanding use cases, it's useful to know what Terraform is. This page lists some concrete use cases for Terraform, but the possible use cases are 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.
---
# Use Cases

View File

@ -2,6 +2,8 @@
layout: "intro"
page_title: "Terraform vs. Boto, Fog, etc."
sidebar_current: "vs-other-boto"
description: |-
Libraries like Boto, Fog, etc. are used to provide native access to cloud providers and services by using their APIs. Some libraries are focused on specific clouds, while others attempt to bridge them all and mask the semantic differences. Using a client library only provides low-level access to APIs, requiring application developers to create their own tooling to build and manage their infrastructure.
---
# Terraform vs. Boto, Fog, etc.

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