What's Wrong With The Terraform Remote State Data Source?

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

When you're trying to chain together multiple Terraform configurations, the remote state data source might seem like a perfect solution. But HashiCorp recommends against using it. Why? And what should you use instead? That's what we'll cover in this episode of Terraform Tuesday.
When you first start building out your IaC, there's a good chance you'll put everything into a single configuration and a single repository. But eventually you'll want to break up your monolithic configuration into separate, smaller configs. That's a good idea, but now you need to figure out how to share values across configurations.
The remote state data source would seem to solve this issue. It does, but there are some caveats you need to be aware of and some better alternatives.
In this video we'll cover:
🌮 Why you should break up your configurations
🌮 How the Remote State data source works
🌮 Why HashiCorp recommends against using it
🌮 Some useful alternatives for sharing values
Special thanks to Spacelift for supporting the channel and sponsoring a portion of this video.
Here's Lee Brigg's excellent post on breaking up your configurations: leebriggs.co.uk/blog/2023/08/...
🚨Sign up for Anton Babaneko's Weekly Terraform Newsletter🚨:www.weekly.tf/
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 Basics: Provider Plugins: • Terraform Basics: Prov...
📽️ Terraform Workspaces Are Bad: • Terraform Workspaces A...
📽️ Workload Identity with Terraform Cloud: • Using Workload Identit...
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
🌮 Timestamps:
⌚ 0:00 Intro
⌚ 1:27 Sharing Values Between Configurations
⌚ 4:48 The Remote State Data Source
⌚ 7:54 Problems With Remote State Data Sources
⌚ 9:53 Spacelift Promo
⌚ 11:13 Alternatives For Sharing Values
⌚ 13:21 Final Thoughts
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
#terraform #hashicorp #devops #cloudengineer #fireflyai
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
⭐ 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.

Пікірлер: 2

  • @chris.dillon
    @chris.dillon9 ай бұрын

    This reminds me of the microservices tradeoff. Yeah you can break up your app so it fits in your head but then you move your problem to the network and you have distributed systems problems and you need a whole bunch of tools to mitigate the tradeoff. Your foundations class was great btw. 👋

  • @silopolis-yt
    @silopolis-yt6 ай бұрын

    Another very good one of yours! I've been watching your videos for a good couple of hours and learned a lot while having a good moment. Awesome stuff man. Is there an option to delegate variables and secrets storage that could be used locally for dev, and easily migrated/switched to some shared target? Something like we have for state, where we'd only have to change the provider's config to take off from a self-contained local directory to the cloud. Thanks a ton for all the knowledge and experience shared with us Take care J

Келесі