Terraform Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 6: Line 6:


Terraform is a tool for building, changing and managing infrastructure, as code. It uses a configuration language named [[#Hashicorp_Configuration_Language_.28HCL.29|Hashicorp Configuration Language (HCL)]]. Terraform is platform agnostic, and achieves that by using different [[#Provider|provider]] APIs for [[#Resource|resource]] provisioning, via [[#Provider_Plug-In|plug-ins]]. A heterogenous environment can be managed with the same [[#Workflow|workflow]].
Terraform is a tool for building, changing and managing infrastructure, as code. It uses a configuration language named [[#Hashicorp_Configuration_Language_.28HCL.29|Hashicorp Configuration Language (HCL)]]. Terraform is platform agnostic, and achieves that by using different [[#Provider|provider]] APIs for [[#Resource|resource]] provisioning, via [[#Provider_Plug-In|plug-ins]]. A heterogenous environment can be managed with the same [[#Workflow|workflow]].
=Hashicorp Configuration Language (HCL)=
HCL is human-readable. Configuration can also be JSON, but JSON is only recommended when the configuration is generated by a machine. Internally, the declarative language that drives [[#Provider|provider]] API for [[#Resource|resource]] provisioning. For more details, see:
{{Internal|Hashicorp Configuration Language|Hashicorp Configuration Language}}


=Provider=
=Provider=

Revision as of 22:56, 13 November 2019

Internal

Overview

Terraform is a tool for building, changing and managing infrastructure, as code. It uses a configuration language named Hashicorp Configuration Language (HCL). Terraform is platform agnostic, and achieves that by using different provider APIs for resource provisioning, via plug-ins. A heterogenous environment can be managed with the same workflow.

Provider

https://www.terraform.io/docs/providers/index.html

A provider is responsible for creating and managing resources. Terraform uses provider plug-ins to translate its configuration into API instructions for the provider. In a configuration file, a provider is specified in a "provider" block. Multiple provider blocks can exist in a Terraform configuration file.

Configured in the “provider” block.

Provider Plug-In

Provider-specific resources are managed with provider plugins. Each provider plugin is a an encapsulated binary, distributed separated by Terraform. They are downloaded by terraform init and stored in a subdirectory of the current working directory.

Available Providers

AWS

AWS

Kubernetes

https://www.terraform.io/docs/providers/kubernetes/index.html

Helm

https://www.terraform.io/docs/providers/helm/index.html

Resource

https://www.terraform.io/docs/configuration/resources.html

A Terraform resource represents an actual resource that exists in the infrastructure. A resource can be a physical components, such an EC2 instance, or a logical resource, such an application. A Terraform resource has a type and a name. In a configuration file, a resource is described in a "resource" block.

Resource Type

The resource type and name together serve as an identifier for a given resource and so must be unique within a module.

Resource Name

The resource name is used to refer to this resource from elsewhere in the same Terraform module, but has no significance outside of the scope of a module. The resource type and name together serve as an identifier for a given resource and so must be unique within a module.

Resource Dependencies

https://learn.hashicorp.com/terraform/getting-started/dependencies

Resource parameters use information from other resources. This is called an interpolation expression.

instance = aws_instance.example.id

If the resources are not dependent, they can be created in parallel, which will be done whenever possible.

Implicit Dependency

Implicit dependencies via interpolation expressions are the primary way to inform Terraform about these relationships and should be used whenever possible.

Explicit Dependency

Explicit dependencies are expressed with “depends_on”. This is when the dependency is configured inside the application code, and it has to be explicitly mirrored in the infrastructure configuration.

depends_on = [aws_s3_bucket.example]

Tainted Resource

When provisioning fails, resources are marked as "tainted". Resources can be manually tainted with the “taint” command. This command does not modify infrastructure, but it modifies the state file to mark the resource as tainted – the next plan will show that the resource will be destroyed and recreated.

Provisioning

In this context, provisioning means initialization of the resources created by the “apply” step by performing software provisioning. Another name for provisioning is instance initialization.

Provisioner

https://www.terraform.io/docs/provisioners/index.html

A provisioner uploads files, runs shell scripts, installs and trigger other software like configuration management tools. A provisioner is only run when the resource is created. The provisioner is declared inside a resource block with the “provisioner” keyword.

resource "aws_instance" "example" {
  … 
  provisioner "local-exec" {
    command = "echo ${aws_instance.example.public_ip} > ip_address.txt"
  }
}

Multiple provisioner blocks can be added.

Failed Provisioner

https://learn.hashicorp.com/terraform/getting-started/provision#failed-provisioners-and-tainted-resources

If a resource is successfully created but fails during provisioning, it is marked as “tainted”.

Available Provisioners

Project

Configuration

The set of files used to describe infrastructure is known as Terraform configuration. Configuration files have a .tf extension.

terraform.tfstate State File

A state file is created when the project is first initialized. It is maintained in the root of the project as terraform.tfstate. State is used to create plans and manage changes to infrastructure. Prior to any operation, the state is refreshed from the real infrastructure – making the state the source of truth. The content of the file can be inspected with terraform show.

Remote State

https://www.terraform.io/docs/state/remote.html

It is recommended to setup remote state.

Workflow

The typical Terraform workflow is:

  • Scope - define what resources are needed.
  • Author - create the configuration file in HCL.
  • Initialize – run terraform init in the project directory with the config files. This will download the correct provider plugins.
  • Plan and Apply - terraform plan (verification) and then terraform apply.

Module