Add meta descriptions to all pages
This commit is contained in:
parent
79aa19a121
commit
073a0f76c5
|
@ -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';
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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`
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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 {
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -2,6 +2,8 @@
|
|||
layout: "aws"
|
||||
page_title: "AWS: aws_vpc"
|
||||
sidebar_current: "docs-aws-resource-vpc"
|
||||
description: |-
|
||||
Provides an VPC resource.
|
||||
---
|
||||
|
||||
# aws\_vpc
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -2,6 +2,8 @@
|
|||
layout: "downloads"
|
||||
page_title: "Download Terraform"
|
||||
sidebar_current: "downloads-terraform"
|
||||
description: |-
|
||||
Download Terraform
|
||||
---
|
||||
|
||||
<h1>Download Terraform</h1>
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
Loading…
Reference in New Issue