Deploy a Kubernetes App & AWS Resources using Crossplane on Kubernetes: Part 2
Deploy a Kubernetes Application that deploys its AWS resources using Crossplane manifests
A Terragrunt boilerplate to minimize regrets on GCP
I built this boilerplate for a reason.
I saw what companies regret with how they implemented Terraform:
This is why they regretted the above:
terraform apply
could ruin an entire environmentAnd so, I built this boilerplate for our clients (and you) to minimize regrets.
The focus of this boilerplate is managing GCP resources.
If you're a CTO, a DevOps lead embarking on a new project on GCP, or simply in search of a template to organize your Terraform repositories, this project is for you. Finding a well-structured example for deploying GCP resources can be challenging. My own search for such a template was unfruitful, leading me to develop a solution that I've decided to share openly and discuss in this article.
By the conclusion of this guide, you'll have a thorough understanding of how to establish Terraform repositories using a best-practice folder structure for provisioning GCP resources. You'll also be equipped to execute a straightforward demo, witnessing an end-to-end workflow in action.
An exhaustive library of modules for every resource in GCP. We kept the boilerplate minimal, so that you can utilize it for your needs.
You can fairly easily utilize existing modules you created or found.
To begin, clone the essential repositories:
Primary Repository
Clone the terragrunt-gcp-projects
repository to get started.
git clone git@github.com:MeteorOps/terragrunt-gcp-projects.git
Modules Repository (Optional)
For the modules used, clone the terraform-gcp-modules
repository.
git clone git@github.com:MeteorOps/terraform-gcp-modules.git
The code organization follows a logical hierarchy to facilitate multiple projects, regions or environments.This structure gives you a number of benefits:
project
└ _global
└ region
└ _global
└ environment
└ resource
When dealing with multiple GCP projects or regions, passing common variables to modules can become repetitive. To avoid duplicating variables across each terragrunt.hcl
file, leverage root terragrunt.hcl
inputs to inherit variables seamlessly across regions and environments.
0.12.6
or newer and Terragrunt version v0.25.1
or newer.my-project/project.hcl
.gcloud auth login
.To deploy a single module:
cd
into the module's folder (e.g. cd my-project/us-central1/rnd-1/vpc
).terragrunt plan
to see the changes you're about to apply.terragrunt apply
.To deploy all modules within an environment:
cd
into the environment folder (e.g. cd my-project/us-central1/rnd-1
).terragrunt run-all plan
to see all the changes you're about to apply.terragrunt run-all apply
.Post-deployment, modules will output relevant information. For instance the IP of a deployed application:
Outputs:
ip = "35.240.219.84"
A minute or two after the deployment finishes, you should be able to test the ip
output in your browser or with curl
:
curl 35.240.219.84
# Output: Let MeteorOps know if the boilerplate needs any improvement!
To remove all deployed modules within an environment:
cd
into the environment folder (e.g. cd my-project/us-central1/rnd-1
).terragrunt run-all plan -destroy
to see all the destroy changes you're about to apply.terragrunt run-all destroy
.
This guide walks you through leveraging best practices for setting up and managing Terraform repositories for GCP with Terragrunt. These methodologies are designed to be straightforward, efficient, and easily adaptable to future projects or company needs.