Day 16 of #30daysofawsterraform challenge
π― Do you want to execute the script or implement some configuration during resource creation or destruction using Terraform in any cloud providers? Here is the "Terraform Provisioners"
β Terraform Provisioners are used to run scripts or commands on a resource after it is created (or before it is destroyed).
β
Key Features:
1. Provisioners run during resource lifecycle events (creation or destruction)
2. They are a "last resort" - Terraform recommends using native cloud-init, user_data, or configuration management tools when possible
3. They execute only once during resource creation (not on updates)
4. Failure handling: By default, if a provisioner fails, the resource is marked as "tainted" and will be recreated on next apply
π‘ Types of Provisioners:
π "local-exec" Provisioner:
Runs a command on the machine where Terraform is executed, NOT on the resource.
Eg:
provisioner "local-exec" {
command = "echo 'Local-exec: created instance ${self.id} with IP ${self.public_ip}'"
}
π "remote-exec" Provisioner:
Runs commands inside the created server (EC2, VM).
Eg:
π"file" Provisioner:
Copies files from local machine to remote server.
Eg:
β οΈWhy Terraform Provisioners Are NOT Recommended
Provisioners:
1. Run after resource creation
2. Depend on SSH / network readiness
3. Are not idempotent (can fail on re-run)
4. Mix infrastructure creation with server configuration
β
Better Alternatives:
1. user_data (Cloud-init) - A script that runs automatically when the server boots. (Best for Bootstrapping)
2. Custom AMIs - Pre-built machine images with software already installed.
3. Configure servers after creation, but in a controlled, idempotent way using Ansible, Chef, Puppet.
4. Run commands on EC2 using AWS agent like AWS Systems Manager.
For more details refer:
Youtube: https://youtu.be/DkhAgYa0448?si=R_b7sBYuC7CPCV2i
Github: https://github.com/Nandan3/Terraform-Full-Course-Aws/tree/main/lessons/day19


Top comments (0)