2 hours 48 minutes
welcome to Module 4.5. We will be discussing terra form state files in this particular module. So I've gone ahead, and I've opened up the get hub page for this training course and specifically drilled into the 05 directory
and you'll notice we have a link here to the terra form state file documentation on terra form dot io.
I'm gonna give that a second and open it up and explain what a state files purposes and when it's all about,
um, as you can see, here and again, the terra form documentation itself is is really good and thorough. Um,
but if you can imagine, we have the terra form files which are declaring an infrastructure that needs to take place in the cloud.
And then you have how that infrastructure is
created. In fact, in the various cloud providers, for example, we are saying we wanna have a virtual network. We want to put a virtual machine on that network, want that virtual machine to have
two gigabytes of memory, right?
And then you have this circumstance, though where somebody could going through, say, the is er portal with web make changes to how that machine is defined, the amount of memory they can go in through the Web. You I, and change it to three gigabytes of memory. Um,
and tear form would really be none the wiser.
Um, and and that's that's really not good, because then when you're coming back and you have your terra form file and you're declaring that the machine should be two gigabytes of memory and then you run it, you really want to have good confidence that indeed the machine is two gigabytes of memory in is aligned with the terra form speck that you've declared.
So one is it's a bad practice to be doing some of the work in terra form and then
coming back and making changes after the fact through another mechanism outside of terra form. But what terra form does to try to reconcile the reality that that does happen, it can be a problem is it has a state file. So this is where it keeps track of the metadata
on DNA mapping between the real world. Resource is what is that virtual machine that actually got created
the first time you ran terra form apply.
What is the idea of that virtual machine and mapping those to the configuration s O. The next time you run the terror form application in and apply your terra form script, it's going to not create yet another virtual machine. It recognizes. I already created that virtual machine, and it's
matching these particular specs. And this is the idea of that virtual machine as it sits out, and
azar or AWS or something of that nature.
So the state file does get synchronized when you first bite by default with terra form. When it's creating the plan or putting the three apply, the state filed by default has been residing on your local workstation. What we want to talk about here is, if we're in a larger group
type situation, we don't want to each have our own state files on our own work stations. Because even though it does synchronize things, um,
it can get out of sync if, say, multiple people are applying updates to the infrastructure. Concurrently, right? One person kicks off their update and it's gonna run for five minutes, and then another person makes other changes to the infrastructure, and then they decide they want to kick that off about one minute
into that five minute deployment that the infrastructure
individual A had already started. That's gonna create a problem. So having a remote shared state will speed up the amount of time that Terra Form spends recalculating and re validating the state file. In fact, when you get really large infrastructures, you will by default, you we want to turn off that
default behavior of sinking the
the State Files because it's gonna
be it's gonna add a lot of overhead in terms of time because the amount of information being sink is gonna continue to grow and grow more over. You're gonna wanna be able thio work across your team and leverage locking so that no two people are performing terra form deployments into the same environment at the same time.
So these are the things we're going to go into. I also want to note that there are is information in these terra form state files like passwords and keys, and it's not encrypted. So what we're going to do in this lab is we're going to set up a shared storage container in azar itself
that's gonna be used
to host these terror form state files,
and we also when we're doing it, we want to make sure that the security constraints around who can access this state file are also there. So nobody can go poking in and read potentially some secrets out of that file. This is a known shortcoming that this information's there in planes text right, the secrets and keys and so forth. So
we want to make sure when we set up the storage container that the individuals and scope of access to this read access in particular is minimal. And then, of course, read right access. We want that to be limited to just those individuals that should be performing, deploys and using and contributing to this state file.