Terraform Workspaces Are Bad Actually, And Here's Why.
Ғылым және технология
The workspace feature in Terraform OSS seems like a great solution for managing multiple environments with the same body of code. But appearances can be deceiving! There's a reason third-party solutions like GitHub Actions, Azure DevOps, and env0 exist to help manage Terraform infrastructure as code deployments. One of the primary reasons is handling the integration between your Terraform configuration, your infrastructure environments, the input values you want to use, and the state data storage for each instance.
Once you start thinking through how to promote code changes from one environment to another, how to secure your Terraform state data, and how to implement a policy of least privilege access with your developers and CI/CD pipelines; you'll quickly discover that Terraform OSS workspaces are just not up to the task.
That's not to say that Terraform OSS workspaces are always bad! They certainly have their place, for use with short-lived, testing environments that live outside your regular CI/CD processes. But once you start working with long-lived, shared environments like Staging and Production, it's time to find another solution.
In the video we'll cover the following:
🌮 The problem Terraform workspaces are meant to solve
🌮 How Terraform workspaces work
🌮 The shortcomings of Terraform workspaces
🌮 Alternatives approaches to using Terraform workspaces
Special thanks to sponsor env0 (env0.com) for supporting the channel and sponsoring this video!
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:
📽️ What's New in the Terraform Associate Exam 003: • Terraform Certified As...
📽️ Using OPA with Terraform - Rego Basics: • Using OPA with Terrafo...
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
🌮 Timestamps:
⌚ 0:00 Intro
⌚ 1:31 Terraform workspaces background
⌚ 2:21 What problem are we trying to solve?
⌚ 4:35 What solutions are available?
⌚ 5:56 How do workspaces, er, work?
⌚ 7:46 Shared codebase issues
⌚ 10:22 Shared state data issues
⌚ 13:49 env0 Sponorship
⌚ 15:08 Shared providers and modules issue
⌚ 17:06 Are workspaces actually bad?
⌚ 19:08 Conclusions
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
#terraform #hashicorp #devops #cloudengineer #techlearning
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
⭐ 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
Are you using Terraform OSS workspaces for today? Do you agree with HashiCorp's guidance?
Using an Azure Storage Account for a backend - I have... 1 - A different Storage Account for each ENV 2 - Use the same TF code and modules for all ENVs 3 - Use TFVARS files for each ENV 4 - Submit changes to a repo that triggers a CI/CD pipeline that does a PLAN for each ENV 5 - Have a approve/deny CI/CD pipeline stage to APPLY No one user can access the backend Storage Account for any ENV - only the Azure Service Connection/Principal the pipeline runs as can access the backend The only issue I have is, as the video highlights, when your PRD ENV is mixed quite differently from the others - e.g. load balancers and resources where they just aren't used in the other ENVs. It's a constant churn to work out shared code and modules to adapt to all of this
@NedintheCloud
Жыл бұрын
Thanks for sharing Neil! This is exactly the type of setup I've used in the past. And yeah, Prod can be a real beast!
Thanks for explanation. So in regards to possible alternatives, you mentioned a few. Would really love to hear your vision on best alternative. What is the best practice for separating environments when not using workspaces?
@NedintheCloud
3 ай бұрын
My current preference is to use branches in Git. The other most popular way is to use a single config with different tfvars files and use the automation platform to configure the backend for a different state data instance.
@Max-cq6hl
3 ай бұрын
@@NedintheCloud Thanks!
We use an artifact and per-env tfvars. Our source code tree is identical for all environments, with separate tfvars with the different env configuration. Our CI in dev creates a new artifact after each merge to main and the code automatically applied in dev (CD). Once approved for staging, the artifact is copied to the staging binary artifact repo and the terraform applied in staging using the staging.tfvars. Same pattern when promoted to production using prod.tfvars. We chose this method because all of our other components use the same binary artifact promotion procedure to copy artifacts from dev to stage to production. We have per-env separate state. We also share modules between applications using the same artifact tooling for each module. Modules can be pinned per application as needed.
On AWS with s3 backend, each workspace creates a separate folders based on the key provided in the provider block, inside one bucket.
Hope your going to cover those other options in a future video. This was great content.
@NedintheCloud
Жыл бұрын
Happy to! I think I'd like to take a look at using GitHub Actions and Environments to handle separation of duties and state.
@guyyefet5804
Жыл бұрын
@@NedintheCloud please do!!!
@user-ux4ct7nv3y
10 ай бұрын
Incredible video, and I concur with this. I have watched the env0 video but I wonder about the other options.
Drift and workspaces really threw me for a loop with my first Terraform file. That's a lesson you only learn once, but I don't find myself paying much attention to workspaces anymore.
Agreed. We would like to know about whether TFC workspaces can resolve those issues in Terraform OSS workspaces? And can we achieve the DRY principle using TFC?
@NedintheCloud
Жыл бұрын
You can absolutely use TFC workspaces to resolve many of the issues. I'll detail that process in a future video.
Can you link/reference the part where Terraform state workspaces are not ideal for production? Also, does the same apply to Workspaces when using Terraform Cloud? I have previously used multiple branches with multiple workspaces - each branch linked to a particular workspace so all merged PRs for that branch automatically open a plan for that workspace on TF cloud.
@NedintheCloud
Жыл бұрын
Here's the doc that I was referencing: developer.hashicorp.com/terraform/language/state/workspaces#using-workspaces Workspaces in Terraform Cloud are a totally different beast despite having the same name. They include access control, separate variable values, and linking to specific repo tags or branches.
Also not forget that in test you will use a shared RDS for cost optimization ,and on prod you will have your own RDS , do that with workspaces xD!
Really well explained!
I simply keep my various environments in separate backend storages.
nice video but video and audio are out of sync wich drives me crazy