Hands-on: Try the Terraform: Get Started tutorials.
Resources are the most important element in the Terraform language. Each resource block describes one or more infrastructure objects, such as virtual networks, compute instances, or higher-level components such as DNS records.
To see how Terraform manages resources when applying a configuration, see Resource Behavior.
A "resource" block declares a resource of a specific type with a specific local name. The name is used to refer to this resource in the same Terraform module but has no meaning outside that module's scope.
The resource type ("aws_instance") and name ("Web") together must be unique within a module because they serve as an identifier for a given resource.
resource "aws_instance" "web" {
ami = "ami-a1b2c3d4"
instance_type = "t2.micro"
}
Within the block body (between { and }) are the configuration arguments for the resource itself. The arguments often depend on the resource type. In this example, both ami and instance_type are special arguments for the aws_instance resource type.
Note: Resource names must start with a letter or underscore, and may contain only letters, digits, underscores, and dashes.
Resource declarations can include more advanced features, such as single resource declarations that produce multiple similar remote objects, but only a small subset is required for initial use. You will learn more later in this page.
Each resource is associated with a single resource type, which determines the kind of infrastructure object it manages and what arguments and other attributes the resource supports.
ProvidersA provider is a plugin for Terraform that offers a collection of resource types. Each resource type is implemented by a provider. A provider provides resources to manage a single cloud or on-premises infrastructure platform. Providers are distributed separately from Terraform, but Terraform can automatically install most providers when initializing a working directory.
To manage resources, a Terraform module must specify the required providers, see Provider Requirements.
Most providers need some configuration to access their remote API, which is provided by the root module, see Provider Configuration
Based on a resource type's name, Terraform can usually determine which provider to use. By convention, resource type names start with their provider's preferred local name. When using multiple configurations of a provider (or non-preferred local provider names), you must use the provider meta-argument to manually choose a provider configuration.
Most of the arguments within the body of a resource block are specific to the selected resource type. The resource type's documentation lists which arguments are available and how their values should be formatted.
The values for resource arguments can make full use of expressions and other dynamic Terraform language features.
Meta-Arguments are defined by Terraform itself and apply across all resource types.
Documentation for Resource TypesEvery Terraform provider has its own documentation, describing its resource types and their arguments.
Some provider documentation is still part of Terraform's core documentation but the Terraform Registry is now the main home for all publicly available provider docs.
When viewing a provider's page on the Terraform Registry, you can click the "Documentation" link in the header to browse its documentation, which is versioned. Use the dropdown version menu in the header to switch the version.
The Terraform language defines the following meta-arguments, which can be used with any resource type to change the behavior of resources:
depends_on, for specifying hidden dependenciescount, for creating multiple resource instances according to a countfor_each, to create multiple instances according to a map, or set of stringsprovider, for selecting a non-default provider configurationlifecycle, for lifecycle customizationsprovisioner, for taking extra actions after resource creationYou can use precondition and postcondition blocks to specify assumptions and guarantees about how the resource operates. The following example creates a precondition that checks whether the AMI is properly configured.
resource "aws_instance" "example" {
instance_type = "t2.micro"
ami = "ami-abc123"
lifecycle {
# The AMI ID must refer to an AMI that contains an operating system
# for the `x86_64` architecture.
precondition {
condition = data.aws_ami.example.architecture == "x86_64"
error_message = "The selected AMI must be for the x86_64 architecture."
}
}
}
Custom Condition Checks can help capture assumptions, helping future maintainers understand the configuration design and intent. They also return useful information about errors earlier and in context, helping consumers to diagnose issues in their configuration.
Some resource types provide a special timeouts nested block argument that allows you to customize how long certain operations are allowed to take before being considered to have failed. For example, aws_db_instance allows configurable timeouts for create, update, and delete operations.
Timeouts are handled entirely by the resource type implementation in the provider, but resource types offering these features follow the convention of defining a child block called timeouts that has a nested argument named after each operation that has a configurable timeout value. Each of these arguments takes a string representation of a duration, such as "60m" for 60 minutes, "10s" for ten seconds, or "2h" for two hours.
resource "aws_db_instance" "example" {
# ...
timeouts {
create = "60m"
delete = "2h"
}
}
The set of configurable operations is chosen by each resource type. Most resource types do not support the timeouts block at all. Consult the documentation for each resource type to see which operations it offers for configuration, if any.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4