website: Copy fixes
This commit is contained in:
parent
5075b162d7
commit
a4f7401458
|
@ -12,7 +12,7 @@ some infrastructure.
|
|||
We'll build infrastructure on
|
||||
[AWS](http://aws.amazon.com) for the getting started guide
|
||||
since it is popular and generally understood, but Terraform
|
||||
can [manage many providers](#),
|
||||
can [manage many providers](/docs/providers/index.html),
|
||||
including multiple providers in a single configuration.
|
||||
Some examples of this are in the
|
||||
[use cases section](/intro/use-cases.html).
|
||||
|
@ -45,9 +45,9 @@ known as a Terraform _configuration_. We're going to write our first
|
|||
configuration now to launch a single AWS EC2 instance.
|
||||
|
||||
The format of the configuration files is
|
||||
[documented here](#).
|
||||
[documented here](/docs/configuration/index.html).
|
||||
Configuration files can
|
||||
[also be JSON](#), but we recommend only using JSON when the
|
||||
[also be JSON](/docs/configuration/syntax.html), but we recommend only using JSON when the
|
||||
configuration is generated by a machine.
|
||||
|
||||
The entire configuration is shown below. We'll go over each part
|
||||
|
@ -86,7 +86,7 @@ which is a common situation.
|
|||
The `resource` block defines a resource that exists within
|
||||
the infrastructure. A resource might be a physical component such
|
||||
as an EC2 instance, or it can be a logical resource such as
|
||||
a Heroku applcation.
|
||||
a Heroku application.
|
||||
|
||||
The resource block has two strings before opening the block:
|
||||
the resource type and the resource name. In our example, the
|
||||
|
@ -98,7 +98,7 @@ managed by the "aws" provider.
|
|||
Within the resource block itself is configuration for that
|
||||
resource. This is dependent on each resource provider and
|
||||
is fully documented within our
|
||||
[providers reference](#). For our EC2 instance, we specify
|
||||
[providers reference](/docs/providers/index.html). For our EC2 instance, we specify
|
||||
an AMI for Ubuntu, and request a "t1.micro" instance so we
|
||||
qualify under the free tier.
|
||||
|
||||
|
@ -213,4 +213,4 @@ Congratulations! You've built your first infrastructure with Terraform.
|
|||
You've seen the configuration syntax, an example of a basic execution
|
||||
plan, and understand the state file.
|
||||
|
||||
Next, we're going to move on to changing and destroying infrastructure.
|
||||
Next, we're going to move on to [changing and destroying infrastructure](/intro/getting-started/change.html).
|
||||
|
|
|
@ -92,4 +92,4 @@ again to see the new properties associated with this instance.
|
|||
|
||||
You've now seen how easy it is to modify infrastructure with
|
||||
Terraform. Feel free to play around with this more before continuing.
|
||||
In the next section we're going to destroy our infrastructure.
|
||||
In the next section we're going to [destroy our infrastructure](/intro/getting-started/destroy.html).
|
||||
|
|
|
@ -129,7 +129,7 @@ resource "aws_eip" "ip" {
|
|||
```
|
||||
|
||||
If you're ever unsure about the dependency chain that Terraform
|
||||
is creating, you can use the `terraform graph` command to view
|
||||
is creating, you can use the [`terraform graph` command](/docs/commands/graph.html) to view
|
||||
the graph. This command outputs a dot-formatted graph which can be
|
||||
viewed with
|
||||
[Graphviz](http://www.graphviz.org/).
|
||||
|
@ -161,5 +161,5 @@ In this page you were introduced to both multiple resources
|
|||
as well as basic resource dependencies and resource attribute
|
||||
interpolation.
|
||||
|
||||
Moving on, we'll use provisioners to do some basic bootstrapping
|
||||
of our launched instance.
|
||||
Moving on, [we'll use provisioners](/intro/getting-started/provision.html)
|
||||
to do some basic bootstrapping of our launched instance.
|
||||
|
|
|
@ -69,5 +69,5 @@ With these building blocks, you can effectively experiment with
|
|||
any part of Terraform.
|
||||
|
||||
Next, we move on to features that make Terraform configurations
|
||||
slightly more useful: variables, resource dependencies, provisioning,
|
||||
and more.
|
||||
slightly more useful: [variables, resource dependencies, provisioning,
|
||||
and more](/intro/getting-started/dependencies.html).
|
||||
|
|
|
@ -36,7 +36,7 @@ output "ip" {
|
|||
This defines an output variables named "ip". The `value` field
|
||||
specifies what the value will be, and almost always contains
|
||||
one or more interpolations, since the output data is typically
|
||||
dynamic in some form. In this case, we're outputting the
|
||||
dynamic. In this case, we're outputting the
|
||||
`public_ip` attribute of the elastic IP address.
|
||||
|
||||
Multiple `output` blocks can be defined to specify multiple
|
||||
|
@ -72,7 +72,9 @@ This command is useful for scripts to extract outputs.
|
|||
## Next
|
||||
|
||||
You now know how to parameterize configurations with input
|
||||
variables, and extract important data using output variables.
|
||||
variables, extract important data using output variables,
|
||||
and bootstrap resources using provisioners.
|
||||
|
||||
Next, we're going to use provisioners to install some software
|
||||
on the instances created on top of the base AMI used.
|
||||
We've now concluded the getting started guide, however
|
||||
there are a number of [next steps](/intro/getting-started/next-steps.html)
|
||||
to get started with Terraform.
|
||||
|
|
|
@ -49,7 +49,7 @@ Provisioners are run only when a resource is _created_. They
|
|||
are not a replacement for configuration management and changing
|
||||
the software of an already-running server, and are instead just
|
||||
meant as a way to bootstrap a server. For configuration management,
|
||||
you should use Terraform provisioning to bootstrap a real configuration
|
||||
you should use Terraform provisioning to invoke a real configuration
|
||||
management solution.
|
||||
|
||||
Make sure that your infrastructure is
|
||||
|
@ -76,7 +76,7 @@ $ cat file.txt
|
|||
54.192.26.128
|
||||
```
|
||||
|
||||
It contains the IP, just ask we asked!
|
||||
It contains the IP, just as we asked!
|
||||
|
||||
## Failed Provisioners and Tainted Resources
|
||||
|
||||
|
@ -106,5 +106,5 @@ management. It is meant to simply bootstrap machines. If you use
|
|||
configuration management, you should use the provisioning as a way
|
||||
to bootstrap the configuration management utility.
|
||||
|
||||
In the next section, we start looking at variables as a way to
|
||||
better parameterize our configurations.
|
||||
In the next section, we start looking at [variables as a way to
|
||||
parameterize our configurations](/intro/getting-started/variables.html).
|
||||
|
|
|
@ -136,6 +136,6 @@ Terraform provides variables for parameterizing your configurations.
|
|||
Mappings let you build lookup tables in cases where that make sense.
|
||||
Setting and using variables is uniform throughout your configurations.
|
||||
|
||||
In the next section, we'll take a look at output variables as a
|
||||
mechanism to expose certain values more prominently to the Terraform
|
||||
operator.
|
||||
In the next section, we'll take a look at
|
||||
[output variables](/intro/getting-started/outputs.html) as a mechanism
|
||||
to expose certain values more prominently to the Terraform operator.
|
||||
|
|
|
@ -16,7 +16,7 @@ developers to build their own tooling to build and manage their infrastructure.
|
|||
Terraform is not intended to give low-level programmatic access to
|
||||
providers, but instead provides a high level syntax for describing
|
||||
how cloud resources and services should be created, provisioned, and
|
||||
combined. It acts as a feature rich and flexible tool, using a
|
||||
a plugin-based model to support providers and provisioners, giving
|
||||
it the ability to support almost any service that exposes APIs.
|
||||
combined. Terraform is very flexible, using a a plugin-based model to
|
||||
support providers and provisioners, giving it the ability to support
|
||||
almost any service that exposes APIs.
|
||||
|
||||
|
|
|
@ -16,5 +16,5 @@ focuses on the higher-level abstraction of the datacenter and associated
|
|||
services, without sacrificing the ability to use configuration management
|
||||
tools to do what they do best. It also embraces the same codification that
|
||||
is responsible for the success of those tools, making entire infrastructure
|
||||
deployments just as easy and reliable.
|
||||
deployments easy and reliable.
|
||||
|
||||
|
|
|
@ -17,7 +17,7 @@ multiple providers and services to be combined and composed. For example,
|
|||
Terraform can be used to orchestrate an AWS and OpenStack cluster simultaneously,
|
||||
while enabling 3rd party services like CloudFlare and DNSimple to be integrated
|
||||
to provide CDN and DNS services. This enables Terraform to represent and
|
||||
manage the entire infrastructure and it's supporting services, instead of
|
||||
manage the entire infrastructure with it's supporting services, instead of
|
||||
only the subset that exists within a single provider. It provides a single
|
||||
unified syntax, instead of requiring operators to use independent and
|
||||
non-interoperable tools for each platform and service.
|
||||
|
|
|
@ -14,7 +14,7 @@ automate the mechanical processes involved.
|
|||
|
||||
These tools require time and resources to build and maintain.
|
||||
As tools of necessity, they represent the minimum viable
|
||||
features needed by an organization, being built to handling only
|
||||
features needed by an organization, being built to handle only
|
||||
the immediate needs. As a result they are often hard
|
||||
to extend and difficult to maintain. Because the tooling must be
|
||||
updated in lock step with any new features or infrastructure,
|
||||
|
|
|
@ -10,9 +10,10 @@ Terraform provides a flexible abstraction of resources and providers. This model
|
|||
allows for representing everything from physical hardware, virtual machines,
|
||||
containers, to email and DNS providers. Because of this flexibility, Terraform
|
||||
can be used to solve many different problems. This means there are a number of
|
||||
exiting tools that overlap with the capabilities of Terraform. We compare Terraform
|
||||
to a numbers of these tools, but it's good to note that Terraform is not mutual
|
||||
exclusive with any other system, nor does it require total buy-in to be useful.
|
||||
existing tools that overlap with the capabilities of Terraform. We compare Terraform
|
||||
to a numbers of these tools, but it's should be noted that Terraform is not mutual
|
||||
exclusive with other systems. It can be used to manage a single application, or the
|
||||
entire datacenter.
|
||||
|
||||
Use the navigation to the left to read the comparison of Terraform to specific
|
||||
systems.
|
||||
|
|
Loading…
Reference in New Issue