Null Resources and Triggers

Terraform's null_resource is a special type of resource that doesn't directly create or manage any infrastructure object in your cloud provider.

Instead, it acts as a placeholder for running arbitrary commands or scripts, often used for tasks that fall outside the scope of typical resource provisioning.

You might wonder why you'd need a 'null' resource. It's incredibly useful for:

• Running Local Scripts: Executing commands on the machine where Terraform is run (e.g., preparing configuration files).
• Post-Deployment Actions: Performing setup or cleanup tasks after real resources are provisioned.
• Interacting with External APIs: When a dedicated Terraform provider doesn't exist for a specific service.
• Custom Logic: Orchestrating custom steps that aren't tied to a specific cloud resource.

A null_resource block looks like any other Terraform resource. By itself, without any provisioners or triggers, it simply creates a 'null' object in the Terraform state and does nothing else.

It's typically paired with provisioners to execute commands, and triggers to control when those commands run.

Here's a minimal null_resource. If you terraform apply this, it will be created in the state, but no external action will occur.

It's just a placeholder, ready to be enhanced with actions.

The real power of null_resource comes when you combine it with provisioners.

Provisioners allow you to execute scripts or commands on the machine running Terraform (local-exec) or on the remote resource itself (remote-exec, though less common with null_resource).

This lets null_resource become an action executor.

triggers are a map of arbitrary key-value pairs defined within a null_resource block.

Their purpose is to tell Terraform: 'If any value in this map changes, this null_resource (and its provisioners) needs to be re-run.'

This is crucial for making the null_resource react to changes in your infrastructure.

When a value in the triggers map changes, Terraform detects a modification to the null_resource.

During a terraform apply, Terraform will then:

• Destroy the existing null_resource (if it exists).
• Re-create the null_resource.
• Re-run any associated provisioners.

This mechanism ensures that your custom actions are executed only when relevant dependencies change.

Here, we use a null_resource to simulate updating a configuration file based on a simple variable. The local-exec provisioner runs a command, and the triggers ensure it re-runs if var.app_version changes.

While powerful, use null_resource judiciously:

• Prefer Providers: If a dedicated Terraform provider or resource exists for a task, use it instead.
• Keep it Idempotent: Ensure scripts run by provisioners can be safely re-run multiple times without side effects.
• Avoid State Management: Don't try to manage external state with null_resource; that's what remote state backends are for.
• Consider external Data Source: For complex external logic that returns structured data, external data source might be a cleaner alternative.

You've learned about null_resource and triggers. Let's test your understanding.

In this lesson, you discovered the versatility of Terraform's null_resource, a powerful tool for executing custom commands and scripts that don't map to concrete cloud resources.

You also learned about triggers, a mechanism within null_resource that allows you to define dependencies and ensure provisioners are re-executed whenever those dependencies change. This enables dynamic and reactive custom automation within your IaC.