
Lesson Description
The "Initializing Terraform" Lesson is part of the full, Cloud Infrastructure: Startup to Scale course featured in this preview video. Here's what you'd learn in this lesson:
Erik runs the `terraform init` command with the Terraform CLI in the "terraform" directory. A lock file is generated similar to a package.json.lock file with a Node project. This ensures the providers used in the project match for each user in the codebase.
Transcript from the "Initializing Terraform" Lesson
[00:00:00]
>> Erik Reinert: All right, so the next thing we want to do after we create our provider and again, hopefully that gives you a little bit more help around like at least creating Amazon resources and stuff. We're now going to create a backend TF file. And so this file, although I'm going to do Alt F4 because that was my unique bucket, this file actually tells Terraform where to store your state.
[00:00:25]
That means that Terraform does know how to integrate with Amazon. It has natural support. Again, it has support to connecting to Amazon via the provider. And that's what those providers are for. If you might be wondering why did we use. What is a provider? Why are we using it?
[00:00:42]
Terraform. The easiest way to put it is Terraform uses providers as a way to connect to the services that it needs to manage. And so basically Terraform will run against a provider and then that provider will go out to the Internet and communicate with the thing that you're trying to automate automate against.
[00:01:01]
There's tons of providers out there. Again, there's Proxmox, there's Spotify, there's whatever. But the main point of a provider is to be the interface between Terraform and the thing that you're trying to manage. And so because of that, Terraform can also work with a lot of these providers for other things.
[00:01:18]
And so in this case, Terraform is actually able to use S3 as a backend and set up Terraform state on that bucket. And so yeah, we're basically gonna say terraform backend s3 bucket fem-fd-service-altf4. The key is really just the file, right? That's the file where all of our state is going to go.
[00:01:40]
It can be whatever you want. It doesn't even have to be a dot just to put it out there. For anyone who doesn't or hasn't really worked with S3, you don't have to give file extensions in S3 if you don't want to. It doesn't have to work that way.
[00:01:56]
You could create UUIDs for all your files. It doesn't really matter. But normally this is for visual recognition knowing like, that's the Terraform state file. Okay, cool. But I've seen some places where they randomize everything. Anyways, we're gonna save that file and then what we're gonna do is we're gonna just do a terraform init.
[00:02:20]
When you run it, it should say initializing backend. It should say that it connects to S3 successfully. And then, yeah, you should basically Say initialize success. We did Terraform init. We all know that Terraform init now works. And you could run this as many times as you want, but preferably in the right directory.
[00:02:41]
It'll just make sure that everything is up to date for dependencies and connectivity and then you'll be good to go. Cool. Okay, so we have successfully set up remote state. We created a bucket, right? And then we configure Terraform to use that bucket. And we're using our AUTH credentials to allow Terraform to be able to connect to it.
[00:03:03]
>> Male: Are we supposed to see something in the bucket?
>> Erik Reinert: Nope. Yeah, we haven't created anything yet, so no. So Terraform won't update that file until we actually add a resource to our project. If we don't add a resource, it doesn't do anything, yeah. So I could, I could add more variables here if I wanted.
[00:03:20]
I could do whatever, but until I actually create something, that file won't get created. One other thing I want to note really fast is you got more than likely a Terraform lock file when you did the init. What is kind of nice about terraform is they do try and have some kind of consistency with all these providers cuz they have tons of them, right?
[00:03:40]
And one of the things that they are genuinely concerned about, which does make sense, is that somebody could hack or exploit a provider in a way that they could start provisioning or creating or maintaining or backdooring into systems and stuff like that, right? Like that would not be good.
[00:03:56]
This is all open source. And so what they do is they provide hashes as a way to verify that what you used before should be the same thing that you're using in other situations. This Terraform lock file basically just says, hey, these are all the dependencies for the HashiCorp version 5.97.0 provider and everything that it needs to uncompress and or move or whatever for it set up.
[00:04:27]
So, for example, if this provider was redownloaded but it didn't match the hashes exactly terraform would give an error. It would say, hey, it's great that you think this is that provider, but I don't recognize it as this. So these are beneficial, but at the same time they're also kind of super annoying.
[00:04:47]
A big reason for that is when you want to update a provider, it's a little bit more of an annoying process because you actually have to either let it manually or, I'm sorry, use the Terraform CLI to update the file. Or what I like to do, which is the same thing I do with package lock files, delete them and then let it recreate it.
[00:05:07]
So it's up to you. But it is nice if you want that additional security and caching as well, just to make sure that you're getting the exact same provider every single time.
>> Male: I looked at what other files are in there and there's this Terraform provider file. It's 695 megabytes.
[00:05:29]
>> Erik Reinert: Yeah, if you're talking about this one here, that's a binary. So this is the actual, I don't know if you can actually run it. Yeah, there you go. Yeah, so there's actually a lot of tools that do this. As a matter of fact, the tool I'm building does this as well, which is how do you have one person's code base work with your code base, especially if it's written in another language or whatever.
[00:05:59]
What Terraform does underneath the hood is these providers create binaries that are then ran by Terraform when you run Terraform, and they are normally set up as services or clis or whatever. So, yeah, you'll normally get a big binary depending on the provider. So if we add in another provider, we would see HashiCorp or whatever else and then in there would be a binary for that provider.
[00:06:26]
>> Male: And this one is so big because Amazon can do a lot of stuff.
>> Erik Reinert: Exactly. Yeah. They have all of the schema definitions in there. They have all the API endpoints in there. So I'm actually kind of surprised it's only 600 [LAUGH] you'd think it'd be huge.
[00:06:40]
And so, yeah, that's per provider, every provider. So it is kind of interesting to note that if you had tons of providers, this could be like a node module situation where it becomes huge.
Learn Straight from the Experts Who Shape the Modern Web
- In-depth Courses
- Industry Leading Experts
- Learning Paths
- Live Interactive Workshops