2 hours 48 minutes
really covered the state file and what it does and represents.
But we've always talked about it residing locally on the system that you're using to manage these terror form deployments. So I want you to open up directory 05 and, um, we're gonna get into creating a storage container that can be used. Tau host
this state file,
but in a remote storage to common location that the other folks on my team can also access, it's going to be a very common in good practice, right? If you can imagine, you have multiple environments that you're defining this infrastructure for. So you're using the infrastructure to finding a development environment
que environment stage, environment,
production environment. So one practices these common and shared state files, which your team's going to be accessing, creating a separate state file for each one of those environments.
The value of behind that is
you can set up permissions around accessing those state files different, and by that nature, you really enforcing who can actually make modifications to the production environment,
the development and so on and so forth. So so that's a very good practice when you're managing remote state files is separating access, control and permissions by the environment they represent, based on the policies you have within your team and organization of the remote state files. Also
going to be helpful when more than one of us is defining this terra form state. And we're collaborating
on that because it also brings to the table the concept of locking. So no two of us are port for forming a terra form deployment process at the same time to based on the same state file, because that could create a lot of corruptions. Right? So it's a very simplistic locking mechanism.
So go ahead again and open up 0.5 s o. We want to set up an area in Azar that can host this state file this capability that we're doing it in as er here you can use an S three bucket and Amazon. You can use comparable blob storage in Google Cloud.
So there's quite a few different
supported back ends to have this this information on a common area that that your entire team, this is sharing,
you can see here are terra form file is is defining a very simplistic storage account. It's also defining a storage container within that, that this is going to be the actual blob where the state files are going to be defined. So let's jump
over to that directory.
Um, keep in mind, we're going into the bootstrap subdirectory. Go ahead and run your terra form apply process. Actually ran it shortly before this. Just testing some things out and make sure you
are able to get the terra form storage accounts created. And so in my situation, you can see it's refreshing the state, right, Cause in this circumstance, I have the state file, which is defining the storage is, is local to my machines that we did talk about why, and the circumstances in which Terra formed by default is gonna synchronize the local state file.
Once you've completed your deployment, there are few outputs thicket printed out to the bottom.
Um, and I defined in the outputs of the Terra form. These are gonna be very important to set us up for the next step, where we're gonna deploy the Terra form files located directly beneath the 05 directory. And we're gonna
using a remote storage back end. So
copy these copy paste them off to the side or just leave them there visible, inaccessible in your terminal because we're going to need these in short order. So
in the root directory of this, this repositories, you'll notice there's a resource is and then I have a few environment scripts that I've set
or haven't said, but I've commented it out. What I want you to do is update the value of the arm access key. This is a specific environment variable when you're working with azar that it wants to see. Because this is a special key that allows us the user we have to access this storage. Ah, location,
the actual environment, variable names. When you're
using s three bucket as your remote storage back in for your state file, they're going to be a little bit different. But you can look those all up. In fact, just hopping over to the terra form site. Here, you can see the remote state directory, and what we want to do here
is find out. What are all the different providers
that it has. Here we go. So these air called back ends, right? And so what we're going to be using it is the user r m back ends of sea. So back ends, Okay,
Working as a team. Remote operations. That's so great. Here we go back in types. So we're going to use this is there are m You could use our factory that there's a whole listing there that you can definitely check out and then the enhanced back ends. That's if you are working with, like, the terra form cloud product.
Um, in the remote circumstance, if you want to use the remote one with care from cloud product. So
there's some additional functionality that those also give you. But in this circumstance, we're going to use the user R m back, back end. And we've already gone ahead, and we've set that up ourselves
by creating the blob storage account using terra form.
And so let's we're also going to set this environment variable here, So I'm going thio, just make a quick we're gonna back up here, Then I'm gonna make a quick call to that particular shell script to ensure that this environment variable gets
set in my circumstance. So resource is
setting and be. And if you're if you're using windows, I have Ah, power shell script also here. And so the same processes and then apply. You're just gonna cut and paste the access key into this environment. Variable. So I've gone ahead and executed that,
um a little little side note. I added a variety of other environment variables in here, which these will be helpful in other circumstances. Not necessarily for this. This activity one is TF log.
If you're ever caught in the need of debugging, what the heck is terra form thinking
If you enable this variable this environment variable to trace d bugger info terra form when it's running, it's gonna spit out a lot more information to you, so that could be very helpful.
The this is a environment variable specific to using a tzar, and it's saying this is the subscription idea and you would make the value the idea of the subscription similar with the tenant i d. The client ideas and client secrets. These air all environment variables,
when you're not lugging in, is an individual in running terra form.
But you you want to say to have a continuous integration job running that's deploying to terra form. If that job thief and these environment variables air set while that jobs executing the azar r M processed the provider within terra form,
it's gonna look at those environment variables. And it's gonna use those credentials when communicating with azar
to determine what are the rolls and who is the user that is performing the different deployment actions asked, as opposed to what we did was we did ese log in And then we went through the log in process Ah, little gooey, prompt upright And we went through that. They're so that's also why I have those. So when you get to that world,
you can use these as resource is to kind of jump start and get
other things going,
but heading back to the remote back end concept. So I have a very simple terra form file here, right? Just creating the resource group pretty much was the simplest thing that we made in the very first section of this model.
But right now, what we want to do is we want to set up the is er r m back in. So here you can see there are some great examples in the online documentation and, um,
what we're going to do is go ahead and we're gonna set up this and I've got a few little basics here. You could define the access key itself right here without doing the environment variable. You could define it in the actual terra form file that access keys, things of that nature.
not. Not not the best idea to be honest, to be putting those in your terra form because it's assumed your terra form file is going to be something that you are capturing in some sort of version control system. So if you're storing the access keys
in material that in your version control system anybody who has access to the version control system can do the access keys.
So even in this circumstance, yes, we updated this shell script, but you wouldn't want to check it in with this access key unless you really understood. And we're confident that
the people who have access to the code of people are gonna see this. They should all be given the appropriate entitlements and an ability to see that particular secret
Kali Linux Fundamentals
If you’re interested in penetration testing and ethical hacking, then this Kali Linux course is ...
1 CEU/CPE Hours Available
Certificate of Completion Offered