terragrunt-infrastructure-live-example
flux2-kustomize-helm-example
terragrunt-infrastructure-live-example | flux2-kustomize-helm-example | |
---|---|---|
23 | 9 | |
731 | 887 | |
2.5% | 4.3% | |
2.8 | 3.8 | |
about 2 months ago | 22 days ago | |
HCL | Shell | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
terragrunt-infrastructure-live-example
-
Terragrunt for Multi-Region/Multi-Account Deployments
In the official Terragrunt documentation there is a good article about how to set up a Terragrunt project and where to place modules. In fact, there is also a repository on GitHub providing an example project on how the creators recommend setting up Terragrunt. I certainly recommend going through that repository, because it is a good reference for a starting point. Having that said, I like to structure mine a little bit differently. My recommendation is to have different AWS accounts for each environment. Getting a new account usually is relatively easy to accomplish even if we are working in a corporate environment (your workplace most likely is using AWS Organizations to manage accounts). The existence of multiple accounts does not require additional costs, we only pay for what we use.
-
Seamless Cloud Infrastructure: Integrating Terragrunt and Terraform with AWS
NOTE: More information about the terragrunt.hcl file can be found in this example repository.
-
Manage multiple terraform environments in a single terraform workspace state file
Here's a pointer to an example repository with a Terragrunt monorepo (good, easy to manage), and each module called gets its unique statefile (good, smaller blast radius) where the tradeoff is learning a new tool and paradigm: https://github.com/gruntwork-io/terragrunt-infrastructure-live-example.
-
Migrate from terragrunt to terraform
I also highly recommend to check out how terragrunt recommends structuring your repo and even further details on this documentation page.
-
Conditionally set resource provider
https://github.com/gruntwork-io/terragrunt-infrastructure-live-example/blob/master/_envcommon/mysql.hcl https://terragrunt.gruntwork.io/docs/features/keep-your-terraform-code-dry/
-
Deploying globally (to all regions) on AWS with terragrunt
did you have a look at this example? https://github.com/gruntwork-io/terragrunt-infrastructure-live-example/blob/master/terragrunt.hcl
- How to structure Terraform with multi-env + multi-regions for TBD in monorepo
-
How to you segregate your dev and prod environments in the repository
Terragrunt! Using a scaffolding approach like this for inspiration https://github.com/gruntwork-io/terragrunt-infrastructure-live-example
-
Terraform / Terragrunt multi-environment - Pass in environment name
I would recommend taking a look at the example repo here: https://github.com/gruntwork-io/terragrunt-infrastructure-live-example. The layout you have doesn't look like a structure that would work well with terragrunt.
-
How you structure your terraform state?
A good example is in gruntwork-io / terragrunt-infrastructure-live-example repository and further documentation on Terragrunt's own documentation page.
flux2-kustomize-helm-example
- Flux: can I add a monitored path after bootstrap?
- Is it possible to deploy to KIND cluster via GitHub actions?
-
How to structure Terraform with multi-env + multi-regions for TBD in monorepo
Any public repo show-casing a nice structure? (I am used to the Gitops world on K8s, and for the case of FluxCD for instance I would recommend this repo as a good practice to start multi-tenancy. https://github.com/fluxcd/flux2-kustomize-helm-example. I am looking for a similar "boilerplate" but for TF π )
- Am I wrong for avoiding helm completely?
- fluxcd/flux2-kustomize-helm-example: A GitOps workflow example for multi-env deployments with Flux, Kustomize and Helm.
-
Helm chart release management between environments
My recommendation would be to take a look at their documented example of this exact scenario with various overlays for production and staging, but you could ofc add as many as you wanted. All you would do is for production point flux to the production overlay/ directory, which then calls all your normal files but overrides some values you desire. Further to this you can keep your helm chart focused on lets say the "most-common" use case, then just call it with whatever additional values you would like, E.G here in the same repo as above. Notice the values at the bottom of the yaml file which override the charts default values.
-
Multi clusters deploy/automation
Here's an example using flux v2 to deploy to multiple environments/clusters: https://github.com/fluxcd/flux2-kustomize-helm-example
-
How do you manage multiple environments with GitOps?
We are using flux2, which uses Kustomize under the hood. It takes a little bit of time to learn about the different CRD's which are available but once you do it works excellent. They also have an example project which sounds like it might fit your use case https://github.com/fluxcd/flux2-kustomize-helm-example
-
Version Control / Tracked Changes For K8
As /u/vincentdesmet mentioned Kustomize will most likely to solve your many "apps" with slightly difference issue, this is a good example https://github.com/fluxcd/flux2-kustomize-helm-example (also include helm one)
What are some alternatives?
terragrunt-infrastructure-modules-example - A repo used to show examples file/folder structures you can use with Terragrunt and Terraform
flux2-multi-tenancy - Manage multi-tenant clusters with Flux
terragrunt-atlantis-config - Generate Atlantis config for Terragrunt projects.
k8s-gitops - GitOps principles to define kubernetes cluster state via code
atlantis - Terraform Pull Request Automation
release-please-action - automated releases based on conventional commits
terraform-yaml-stack-config - Terraform module that loads an opinionated 'stack' configuration from local or remote YAML sources. It supports deep-merged variables, settings, ENV variables, backend config, and remote state outputs for Terraform and helmfile components.
gitops-playground - Creates a complete GitOps-based operational stack on your Kubernetes clusters
terraform-aws-eks - Terraform module to create AWS Elastic Kubernetes (EKS) resources πΊπ¦
k8s-wait-for - A simple script that allows to wait for a k8s service, job or pods to enter a desired state
modules.tf-demo - Real modules.tf demo (updated May 2021)
reliza-cli - CLI to interact with Reliza Hub