Terraform templates for AWS / GCP / Azure.
Forked from the Templates repo for which this is now a submodule.
new.pl
can instantiate these templates as new date-timestamped files, autopopulating the date, vim tags, GitHub URL and other headers and drops you in to your $EDITOR
of choice (eg. vim
).
You can give an exact filename like provider.tf
or backend.tf
to instantiate that exact template, or any filename ending in .tfvars
will instantitate some common terraform variables such as project
, region
, vpc_name
etc... otherwise any filename ending in tf
will give you a blank terraform template.
Examples:
new provider.tf
new backend.tf
new.pl
can be found in the DevOps Perl tools repo.
alias new=new.pl
(done automatically in the DevOps Bash tools repo .bash.d/
)
new terraform
or shorter:
new tf
Instantly creates and opens all standard files for a Terraform deployment in your $EDITOR
of choice:
all heavily commented to get a new Terraform environment up and running quickly - with links to things like AWS / GCP regions, Terraform backend providers, state locking etc.
Example:
│Error: error deleting IAM policy arn:aws:iam::***:policy/MYPOLICY: DeleteConflict: Cannot delete a policy attached to entities.
The Terraform AWS Provider does not help you when you recreate a resource that another resources depends on, such as recreating an IAM policy due to a rename, while it is still attached to a role, or recreating an AWS Batch compute environment while it's still attached to queues.
Unfortunately the Terraform AWS Provider isn't smart enough to know that for such dependencies with AWS specific API constraints that it should simply detach, and then reattach afterwards.
The quickest solution / workaround is to find the dependent resources, and terraform taint
them so that they are destroyed first using the generic implicit Terraform dependency ordering, eg. the role gets deleted first for recreation because its tainted, then the IAM policy is deleted and recreated with the new name, and then the role is recreated and attached to the new policy.
Example:
terraform taint <full_path_of_resource_in_terraform_state>
Production-grade Terraform CI/CD pipelines can be found for Jenkins and GitHub Actions in my adjacent repos:
-
Jenkins - runs terraform code with a specific version of Terraform:
fmt
(info only)validate
plan
(saves plan so apply is this exact plan, recommended)- prompts for plan approval
- runs
apply
- has full locking and milestones for Plan and Apply stages for serialized queuing to avoid terraform state lock failures
- skips intermediate queued runs for efficiency
-
GitHub Actions - similar to above, plus:
- optional environment / approvals (protects admin credentials for things like GitHub which doesn't have read-only repo API tokens)
- posts the full
terraform plan
result into the Pull Request that triggered the workflow, along with the status offmt
&validate
- applies once Pull Request is merged to the default branch or master or main
Applied, ignoring informational fmt check:
Plan found no changes so skipped Apply or asking for Approval:
Plan found changes but Approval was not authorized, so Apply did not proceed:
The rest of my original source repos are here.
Pre-built Docker images are available on my DockerHub.