Last Updated on June 16, 2024 by Arnav Sharma
In the vast landscape of Infrastructure as Code (IaC), Terraform stands out as a leading tool, enabling developers and operations teams to define and provision infrastructure using a declarative configuration language. One of its intriguing features is the use of ‘provisioners’, which allow for the execution of scripts or actions during various stages of a resource’s lifecycle. While they offer a powerful way to integrate custom logic into your infrastructure setup, they come with their own set of considerations and best practices. In this blog post, we’ll delve deep into Terraform provisioners, exploring their types, use cases, potential pitfalls, and how to wield them effectively in your IaC journey.
There are two types of Terraform provisioners:
local-exec Provisioner:
- This provisioner invokes a local executable, i.e., on the machine where Terraform is being run.
- It’s often used for tasks like invoking local scripts or tools after a resource has been created.
Example:
resource "aws_instance" "example" {
# ... instance configuration ...
provisioner "local-exec" {
command = "echo The instance ID is ${aws_instance.example.id} > instance_id.txt"
}
}
remote-exec Provisioner:
- This provisioner invokes a command or script on a remote resource, typically a newly created virtual machine or instance.
- It requires some form of remote connection to the machine, usually SSH for Linux-based systems or WinRM for Windows-based systems
Example:
resource "aws_instance" "example" {
# ... instance configuration ...
provisioner "remote-exec" {
inline = [
"echo 'Hello, World!' > /tmp/greeting.txt",
"cat /tmp/greeting.txt"
]
}
connection {
type = "ssh"
user = "ec2-user"
private_key = file("~/.ssh/id_rsa")
host = self.public_ip
}
}
While they can be powerful, there are several reasons why they should be used as a last resort:
- Imperative vs. Declarative: Terraform’s core principle is to provide a declarative way to define infrastructure. Provisioners introduce an imperative approach, which can lead to unpredictable results.
- State Management: If a provisioner fails, Terraform might end up in a state where it believes a resource was not created, even if it was. This can lead to inconsistencies in the state file and make it difficult to manage and troubleshoot.
- Idempotency: Terraform resources are designed to be idempotent, meaning you can run the same code multiple times and get the same result. Provisioners can break this idempotency, especially if the scripts they run are not carefully designed.
- Retry Logic: Terraform has built-in retry logic for providers. If a provisioner fails, there’s no built-in mechanism to retry the provisioner without recreating the entire resource.
- Tight Coupling: Using provisioners can tightly couple your infrastructure code with configuration management or application setup. This can make it harder to change one without affecting the other.
- Limited Debugging: Debugging provisioners, especially remote-exec ones, can be challenging. The logs might not be as detailed, and you might need to jump through hoops to get the necessary debugging information.
- Scalability: Provisioners can introduce scalability issues. For instance, if you’re spinning up many instances and each has a provisioner that takes a long time to run, it can significantly slow down the entire process.
- Security Concerns: Using provisioners, especially remote ones, can introduce security risks. You might need to open up additional ports or provide credentials, which can be a potential attack vector.
- Alternative Tools: There are often better-suited tools for configuration management and initialization tasks, like Ansible, Chef, Puppet, or cloud-init. These tools are designed specifically for these tasks and can provide more features and better reliability.
- Future Deprecation: HashiCorp, the company behind Terraform, has mentioned in various forums and discussions that they see provisioners as a last resort and might deprecate them in the future. Relying heavily on them now might lead to challenges down the road.
FAQ – Terraform Provisioner
Q: What are Terraform Provisioners?
A: Terraform Provisioners are a feature of Terraform that allow you to run scripts or commands on a local or remote machine as part of resource creation or destruction.
Q: How are provisioners used in Terraform?
A: Provisioners are used to execute scripts or commands on a local or remote machine during the resource lifecycle. They can be used to handle tasks such as bootstrapping, configuration management, or executing specific tasks after resource creation.
Q: What types of provisioners are available in Terraform?
A: Terraform provides multiple provisioners, including file provisioner, remote-exec provisioner, and local-exec provisioner, which can be used based on your requirements.
Q: When are creation-time provisioners used?
A: Creation-time provisioners are used to execute scripts on a newly created resource, after it has been created but before it is ready to use.
Q: When are destroy-time provisioners used?
A: Destroy-time provisioners are used to execute scripts on a resource that is being destroyed, after the resource has been marked for destruction but before it is actually destroyed.
Q: What is a connection block in Terraform?
A: A connection block in Terraform is used to establish a connection to the remote machine where provisioners will be executed. It defines the necessary connection details such as the host, username, and password.
Q: How can I use Terraform provisioners with AWS EC2 instances?
A: To use Terraform provisioners with AWS EC2 instances, you can define provisioner blocks within the resource block of the EC2 instance configuration. These provisioner blocks specify the scripts or commands to be executed on the EC2 instance.
Q: What should I do if a provisioner fails?
A: If a provisioner fails, Terraform will mark the associated resource as tainted. This means that the resource will be recreated on the next Terraform apply, including the execution of provisioners.
Q: Can I use multiple provisioners for a single resource?
A: Yes, you can use multiple provisioners for a single resource by defining multiple provisioner blocks within the resource configuration. Each provisioner block will specify a different script or command to be executed.
Q: How can I view provisioner logs in Terraform?
A: Terraform does not provide a built-in mechanism for viewing provisioner logs. However, you can redirect the output of the provisioner scripts or commands to a file or a logging service for monitoring and troubleshooting purposes.
keywords: local machine running terraform configuration file in creation-time provisioner fails resource is created like tainted resource in terraform provisioner is used and provisioners can be used