Managing Multiple Environments with Terraform

Ғылым және технология

One of the primary benefits of using IaC is to produce code that is reusable across multiple environments. But how do you actually create a workflow to support that scenario? That's what we're going to dig into today using Terraform, GitHub Actions and Microsoft Azure for examples.
The big three options for working with multiple environments are:
1. Using Git Branches - This is a scenario where you have a branch for each environment, and you deploy from that branch. Many Terraform automation platforms default to this workflow, so I guess it's pretty popular.
2. Using Folder Structure - This is a scenario where you have a folder for each environment in a single repository and single main branch. You deploy from that folder.
3. Using Separate Repos - This is a scenario where you have a separate repository for each environment. Each repository has its own main branch. You deploy from that repository.
Each has its pros and cons, and each has its own level of complexity. There are also other options out there, that might work better depending on your organization, preferred workflow, and requirements. You want to structure your environment management strategy in a way that makes it easier to maintain your infrastructure, not harder.
A special thanks to #Spacelift for helping to sponsor this video!
Repository Examples:
Branch-based - github.com/ned1313/tt-branch-...
Folder-based - github.com/ned1313/tt-folder-...
Repo-based - github.com/ned1313/tt-repo-ex...
The other repo-based repositories follow the same naming structure.
Thank you so much for watching! Subscribe if you think I’ve earned it. Hit the bell as well if you’re feeling swell.❤️&🌮
✅🔔 Subscribe ► nedinthecloud.com/SubscribeYT
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
🌮 Other videos to check out:
📽️ Terraform Check Block: • Terraform Check Block ...
📽️ Terraform and OPA: • Open Policy Agent and ...
📽️ Workload Identity with Terraform Cloud: • Using Workload Identit...
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
🌮 Timestamps:
⌚ 0:00 Intro
⌚ 1:37 Basic Assumptions
⌚ 2:51 Big Three Options
⌚ 3:50 Branch Based
⌚ 7:26 Folder Based
⌚ 9:22 Repo Based
⌚ 10:43 Spacelift Promo
⌚ 12:02 Banch Pros and Cons
⌚ 14:24 Folder Pros and Cons
⌚ 16:17 Repo Pros and Cons
⌚ 17:42 Terragrunt Option
⌚ 19:00 Final Thoughts
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
#terraform #hashicorp #devops #cloudengineer #tacos
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
⭐ CONNECT WITH ME 🏃🦖
🌐 Day Two Cloud: daytwocloud.io
🌐 Chaos Lever: chaoslever.com
🌐 Visit my Website ► nedinthecloud.com
🗳 Pluralsight ► app.pluralsight.com/profile/a...
🐙 Find the code at GitHub► github.com/ned1313
🐧 Twitter ► / ned1313
👨‍💼 LinkedIn► / ned-bellavance
For collaboration or any queries: ned@nedinthecloud.com
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
🌮 About Me 🌮
Ned is a curious human with a knack for creating entertaining and informative content. With over 20 years in the industry, Ned brings real-world experience to all his creative endeavours, whether that's pontificating on a podcast, delivering live instruction, writing certification guides, or producing technical training videos. He has been a helpdesk operator, systems administrator, cloud architect, and product manager. In his newest incarnation, Ned is the Founder of Ned in the Cloud LLC. As a one-man-tech juggernaut, he develops courses for Pluralsight, runs two podcasts (Day Two Cloud and Chaos Lever, and creates original content for technology vendors.
Ned has been a Microsoft MVP since 2017 and a HashiCorp Ambassador since 2020, and he holds a bunch of industry certifications that have no bearing on anything beyond his exceptional ability to take exams and pass them. When not in front of the camera, keyboard, and microphone, you can find Ned running the scenic trails of Pennsylvania or rocking out to live music in his hometown of Philadelphia. Ned has three guiding principles: Embrace discomfort, Fail often, and Be kind.

Пікірлер: 21

  • @stevenlam6163
    @stevenlam61636 ай бұрын

    These are the most in-depth explanations I've found online. The differences and pros & cons of each approach is broken down really well. Thank you!

  • @NedintheCloud

    @NedintheCloud

    6 ай бұрын

    Great to hear! Thanks for the feedback!

  • @JeffreyJBlanchard
    @JeffreyJBlanchard8 ай бұрын

    One of the best video's I've seen on repository strategies.

  • @manojR5

    @manojR5

    2 ай бұрын

    I agree, nailed it

  • @baptistegaillard3559
    @baptistegaillard35598 ай бұрын

    Thanks for this video Ned. I'm wondering if the new Terraform Stacks feature presented during the HashiConf 2023 would help to work on several environments too. Hard to say because it's in private preview I believe but they were talking about new "deployment" blocks which could perhaps be mapped to the notion of environments. Perhaps you tried this new Stacks feature already ? In any case it would be a good subject for an other video. Thanks for you work ❤

  • @VinceT565
    @VinceT5658 ай бұрын

    At my last place of employment we decided on using variable definition files for each env. This way we did not have to duplicate our TF files. There was some extra work involved to handle specific cases where you made have had to create multiple instances of the same resource, or in rare cases, you deployed a resource in one env, but not the other. But overall it make things much easier to create consistency because we didn't have different versions of a TF files in a branch or folder.

  • @juancitox77

    @juancitox77

    8 ай бұрын

    The only downsize about this approach is that there's no clear view of what has been deployed to each env. That's not the case of folder-based strategy.

  • @NedintheCloud

    @NedintheCloud

    8 ай бұрын

    There's a hybrid option that I didn't mention, where the each folder calls the root folder as a module and passes values and updates through there. But you still have the problem that updating the root folder configuration impacts all environments, so it's hard to do testing.

  • @asitha106

    @asitha106

    8 ай бұрын

    ​@@NedintheCloud the correct module abstraction is the key with hybrid approach. all environment should start with a module which builds the environment specifics things from scratch. the common objects shared between environments should have there own isolate repo, for eg if you are on hub and spoke model. the hub will live in isolation with separate tf repo. then environment modules will refer the resource directly when deploying. great video btw! :)

  • @chasing_the_horizon
    @chasing_the_horizon8 ай бұрын

    I'm glad you didn't mention workspaces, 'cause I would report your channel for using them 🤣

  • @NedintheCloud

    @NedintheCloud

    8 ай бұрын

    I may have done a whole video about workspaces 😉 kzread.info/dash/bejne/aIWbqq6nk7ObhqQ.html

  • @daverichardson4686
    @daverichardson46865 ай бұрын

    I love this, QQ what if we need to use different credentials for UAT and Production, than we use for Dev and QA?

  • @NedintheCloud

    @NedintheCloud

    5 ай бұрын

    If you're using GitHub environments, you can specify a different set of credentials for each environment in the GitHub Actions Environment Secrets.

  • @marsamuk
    @marsamuk8 ай бұрын

    Hi Ned. Are there any upcoming updates planned for the Terraform Azure course? Thanks

  • @NedintheCloud

    @NedintheCloud

    8 ай бұрын

    Yes! In fact, I am working on the course outline as in a separate tab on my browser.

  • @marsamuk

    @marsamuk

    8 ай бұрын

    Thank you for the update! I appreciate your efforts. Could you please provide an ETA for the course release?

  • @RashadAkachi
    @RashadAkachi8 ай бұрын

    Nice shirt

  • @Gonkers44
    @Gonkers448 ай бұрын

    So.... What about workspaces?

  • @NedintheCloud

    @NedintheCloud

    8 ай бұрын

    Terraform Core workspaces? I'd avoid them. kzread.info/dash/bejne/aIWbqq6nk7ObhqQ.html

  • @countbrapcula-espana
    @countbrapcula-espana7 ай бұрын

    Ned. I think an excellent video to do is relive the GitHub Actions CI/CD workflow with Terraform and Azure AD Federated Identity (OIDC) to map over a 100% GitOps form of that using Weaveworks FluxCD Terraform Controller (tf-controller). How does the imperative workflow of end-to-end GHA change to a declarative one using a setup of having a Control Plane K8s cluster (even using KinD) that has the tf-controller CRDs on there to watch and reconcile changes to Terraform code in Git.

  • @NedintheCloud

    @NedintheCloud

    6 ай бұрын

    Great suggestion! I took a look at the tf-controller a couple years ago. Sounds like it might be worth check out again.

Келесі