Why provisioners run scripts on resources in Terraform - Why It Works This Way

Overview - Why provisioners run scripts on resources

What is it?

Provisioners in Terraform are tools that let you run scripts or commands on resources after they are created or before they are destroyed. They help customize or configure resources beyond what Terraform can do by itself. This means you can automate setup tasks like installing software or changing settings on servers. Provisioners act as a bridge between Terraform and the resource's internal setup.

Why it matters

Without provisioners, Terraform would only create resources but not configure them fully. This would mean manual work or separate tools to finish setup, causing delays and errors. Provisioners solve this by automating configuration right after resource creation, making infrastructure ready to use immediately. This saves time, reduces mistakes, and ensures consistent setups across environments.

Where it fits

Before learning about provisioners, you should understand basic Terraform resource creation and lifecycle. After mastering provisioners, you can explore configuration management tools like Ansible or Chef, and advanced Terraform features like modules and remote-exec connections.

Mental Model

Core Idea

Provisioners run scripts on resources to complete setup tasks that Terraform alone cannot perform during resource creation or destruction.

Think of it like...

It's like buying a new appliance that needs assembly and setup after delivery; provisioners are the instruction steps you follow right after getting the appliance to make it ready to use.

Terraform Resource Creation
┌─────────────────────────────┐
│ Create Cloud Resource        │
│ (e.g., VM, Database)         │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ Run Provisioner Scripts      │
│ (e.g., install software)     │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ Resource Fully Configured    │
│ Ready for Use                │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Terraform Resource Basics

Concept: Understand what Terraform resources are and how they represent cloud infrastructure components.

Terraform resources are the building blocks that describe cloud services like virtual machines, storage, or networks. When you write a resource block, Terraform creates that service in the cloud. However, this creation only sets up the basic infrastructure, not the detailed configuration inside the resource.

Result

You can create cloud resources like servers or databases using Terraform code.

Knowing that Terraform creates but does not configure resources internally sets the stage for why additional setup steps are needed.

2

Foundation

What Provisioners Do

Concept: Provisioners let you run scripts or commands on resources after creation or before destruction.

Provisioners are special blocks in Terraform that run scripts on the resource itself. For example, after creating a virtual machine, a provisioner can connect to it and install software or change settings. This happens automatically during Terraform apply or destroy.

Result

Resources can be customized automatically after they are created.

Understanding provisioners as automation tools for configuration helps see how Terraform extends beyond just creating resources.

3

Intermediate

Types of Provisioners

🤔Before reading on: do you think provisioners only run scripts locally or can they also run remotely? Commit to your answer.

Concept: There are different provisioners for running scripts locally or remotely on the resource.

Terraform has provisioners like 'local-exec' which runs commands on your machine, and 'remote-exec' which runs commands on the resource itself via SSH or WinRM. Choosing the right type depends on where the script needs to run.

Result

You can run setup scripts either on your computer or directly on the resource.

Knowing the difference between local and remote execution helps you pick the right tool for your configuration tasks.

4

Intermediate

When Provisioners Run

🤔Before reading on: do you think provisioners run only after resource creation, or also before destruction? Commit to your answer.

Concept: Provisioners can run after creation or before destruction of resources.

By default, provisioners run after a resource is created to configure it. They can also run before a resource is destroyed to perform cleanup tasks. This lifecycle integration ensures resources are properly set up and torn down.

Result

Scripts run at the right time to prepare or clean resources automatically.

Understanding the timing of provisioners prevents misconfigurations and helps automate full resource lifecycle management.

5

Intermediate

Limitations and Risks of Provisioners

🤔Before reading on: do you think provisioners are always reliable and recommended for all setups? Commit to your answer.

Concept: Provisioners have limitations and can cause issues if overused or misused.

Provisioners depend on network access and resource readiness, so they can fail if the resource is not ready or unreachable. Terraform also treats provisioner failures as errors, which can stop deployments. Because of this, provisioners are recommended only for tasks Terraform cannot do natively.

Result

You learn to use provisioners carefully and only when necessary.

Knowing the risks helps avoid fragile infrastructure and encourages better automation practices.

6

Advanced

Best Practices for Using Provisioners

🤔Before reading on: do you think provisioners should be the main way to configure resources? Commit to your answer.

Concept: Experts use provisioners sparingly and prefer other configuration tools when possible.

Best practice is to use provisioners only for simple, quick tasks that Terraform cannot handle. For complex setups, use dedicated configuration management tools like Ansible or cloud-init scripts. Also, always handle errors and timeouts in provisioners to avoid deployment failures.

Result

Infrastructure is more stable, maintainable, and easier to troubleshoot.

Understanding best practices prevents common pitfalls and leads to professional-grade infrastructure automation.

7

Expert

Internal Execution Flow of Provisioners

🤔Before reading on: do you think Terraform runs provisioners in parallel or sequentially? Commit to your answer.

Concept: Terraform runs provisioners sequentially and manages their execution as part of resource lifecycle.

When Terraform creates a resource, it waits until the resource is ready, then runs provisioners one by one in the order defined. If a provisioner fails, Terraform stops and reports an error. During destroy, it runs 'destroy' provisioners before deleting the resource. This strict flow ensures predictable configuration but can cause delays or failures if scripts hang or fail.

Result

You understand how provisioners affect deployment timing and error handling.

Knowing the internal flow helps design reliable scripts and troubleshoot provisioning issues effectively.

Under the Hood

Terraform creates a resource by calling the cloud provider API. After the resource is confirmed created and reachable, Terraform initiates provisioners by connecting to the resource (e.g., via SSH). It runs the specified scripts or commands in sequence. Terraform monitors the execution and waits for completion or failure. On destroy, it runs any defined cleanup scripts before deleting the resource. This process tightly couples resource lifecycle with configuration steps.

Why designed this way?

Provisioners were designed to fill gaps where Terraform's declarative model cannot express imperative setup steps. Running scripts directly on resources allows flexible customization without waiting for external tools. The sequential execution and error handling ensure predictable and safe deployments, avoiding partial or inconsistent states. Alternatives like external configuration tools exist but require separate orchestration, so provisioners offer a simple integrated solution.

Terraform Apply Process
┌───────────────────────────────┐
│ 1. Create Resource via API     │
└───────────────┬───────────────┘
                │
                ▼
┌───────────────────────────────┐
│ 2. Wait for Resource Ready     │
└───────────────┬───────────────┘
                │
                ▼
┌───────────────────────────────┐
│ 3. Connect to Resource (SSH)   │
└───────────────┬───────────────┘
                │
                ▼
┌───────────────────────────────┐
│ 4. Run Provisioner Scripts     │
│    - Script 1                  │
│    - Script 2                  │
└───────────────┬───────────────┘
                │
                ▼
┌───────────────────────────────┐
│ 5. Report Success or Failure   │
└───────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: do you think provisioners always run successfully if the resource is created? Commit to yes or no.

Common Belief: Provisioners always run successfully once the resource is created.

Reality: Provisioners can fail if the resource is not ready, unreachable, or the script has errors.

Why it matters: Assuming provisioners always succeed leads to fragile deployments and unexpected errors during Terraform runs.

Quick: do you think provisioners are the best way to configure all resource settings? Commit to yes or no.

Common Belief: Provisioners are the best and only way to configure resource internals after creation.

Reality: Provisioners are only recommended for tasks Terraform cannot do; native resource arguments or external tools are preferred for configuration.

Why it matters: Overusing provisioners can cause complex, hard-to-maintain infrastructure and increase failure risk.

Quick: do you think Terraform runs all provisioners in parallel to speed up deployment? Commit to yes or no.

Common Belief: Terraform runs all provisioners in parallel to save time.

Reality: Terraform runs provisioners sequentially in the order defined to ensure predictable setup.

Why it matters: Expecting parallel execution can cause confusion when scripts depend on order or when debugging failures.

Quick: do you think provisioners run only after resource creation? Commit to yes or no.

Common Belief: Provisioners run only after resource creation.

Reality: Provisioners can also run before resource destruction to perform cleanup tasks.

Why it matters: Ignoring destroy-time provisioners can lead to leftover resources or incomplete cleanup.

Expert Zone

1

Provisioners can cause Terraform state to become out of sync if scripts change resource state outside Terraform's knowledge.

2

Using provisioners with sensitive data requires careful handling to avoid exposing secrets in logs or state files.

3

Provisioners do not retry automatically on failure; adding retry logic in scripts or using external tools improves reliability.

When NOT to use

Avoid provisioners for complex configuration or software installation; instead, use cloud-init, configuration management tools (Ansible, Chef), or Terraform native resource arguments. Provisioners are also not suitable when resources are managed by multiple teams or tools to prevent conflicts.

Production Patterns

In production, provisioners are used sparingly for simple bootstrapping tasks like setting up SSH keys or running quick fixes. Most configuration is handled by dedicated tools or baked into machine images. Provisioners are often combined with remote-exec and local-exec for flexible automation during deployments.

Connections

Configuration Management

Provisioners complement configuration management by handling simple setup tasks that configuration tools handle in depth.

Understanding provisioners clarifies where Terraform ends and configuration management begins, helping design clean automation pipelines.

Infrastructure as Code (IaC)

Provisioners extend IaC by adding imperative steps to declarative resource creation.

Knowing how provisioners fit into IaC helps balance declarative and imperative automation for robust infrastructure.

Software Installation Processes

Provisioners automate software installation on resources, similar to how installers run setup scripts on new computers.

Seeing provisioners as automated installers helps appreciate their role in making resources ready for use.

Common Pitfalls

#1 Running provisioners without ensuring resource readiness causes failures.

Wrong approach:

provisioner "remote-exec" {
inline = ["sudo apt-get update"]
}
# No wait or check for SSH availability

Correct approach:

provisioner "remote-exec" {
connection {
type = "ssh"
host = self.public_ip
user = "ubuntu"
timeout = "2m"
}
inline = ["sudo apt-get update"]
}

Root cause:

Misunderstanding that provisioners require the resource to be fully accessible before running scripts.

#2 Using provisioners for all configuration leads to complex, fragile setups.

Wrong approach:

provisioner "remote-exec" {
inline = ["install complex app with many steps"]
}
# No use of configuration management or native resource options

Correct approach:

# Use cloud-init or Ansible for complex setups
resource "aws_instance" "example" {
user_data = file("setup.sh")
}
# Or run Ansible separately after creation

Root cause:

Not recognizing the limits of provisioners and ignoring better tools for configuration.

#3 Ignoring errors in provisioner scripts causes silent failures.

Wrong approach:

provisioner "remote-exec" {
inline = ["some-command || true"]
}
# Forces success even if command fails

Correct approach:

provisioner "remote-exec" {
inline = ["some-command"]
}
# Let Terraform detect failure and stop

Root cause:

Trying to hide errors instead of fixing them leads to unreliable infrastructure.

Key Takeaways

Provisioners let Terraform run scripts on resources to complete setup tasks that Terraform alone cannot perform.

They run scripts after resource creation or before destruction, connecting resource lifecycle with configuration.

Provisioners come in types like local-exec and remote-exec, running scripts locally or on the resource.

Use provisioners sparingly and prefer native resource options or configuration management tools for complex setups.

Understanding provisioners' internal flow and limitations helps build reliable, maintainable infrastructure automation.