Infrastructure as a code technology. Helps you manage your backend infrastructure on 3rd party services like amazon with configurations.
This gist is a short introduction to the basics of Terraform.
Terraform uses its own language to define how your backend should look like, and it figues out automatically how to spin it yup in an efficient manner, using a dependency graph between components.
Configure the provider for the infrastructure hosting.
In the example, AWS access profile and availability region are defined.
provider "aws" {
profile = "default"
region = "us-east-1"
}
Once the provider is defined, the resources must be configured.
Resources are the building blocks of your backend, and it could be anything from a lambda function to a managed database.
Example: define a AWS EC2 instance.
resource "aws_instance" "example" {
ami = "ami-2757f631"
instance_type = "t2.micro"
}
After declaring the provider and required resources, the backend can be deployed (applied).
# apply configuration
terraform apply
Every time a config is applied, terraform will list the changes that will be done in the provider. Only the necessary changes will be made between applies, so not all the backend will be destroyed and redeployed every time.
Resources can be provisioned with custom scripts, although is discouraged.
If the provisioning step fails, the resource is marked as tainted
.
When deploying a configuration, 3 states are possible for resources:
- success: created successfuly
- error: failed to create
- tainted: failed to provision
Note: the resources that failed will be recreated on subsequent apply, and also the tainted
resources.
Custom variables can be passed to the terraform scripts. They can be passed through CLI, files, env variables or UI (discouraged).
# CLI
terraform apply -var 'region=us-east-1'
# file terraform.tfvars
region = "us-east-1"
Define information so it can be retrieved later.
Example: output variable a AWS elastic ip
resource "aws_eip" "ip" {
vpc = true
instance = aws_instance.example.id
}
output "ip" {
value = aws_eip.ip.public_ip
}
When running terraform locally, the provisioned backend state is store locally in terraform.tfstate
files.
When working in a team, running terraform remotely is recommended. Aka remote backend, version control your tensorflow configurations, the backend state, and their run logs in a provider (ex. Terraform Cloud).
With a remote backend, all the team has access to the same infractucutre, the canges can be viewed, etc.
Note that the commands must be run from the same directory where the BE configuration lays.
# validate the config
terraform validate
# apply the config
terraform apply
# show the current backend
terraform show
# destroy the backend
terraform destroy