>> Hi, on the next episode of DevOps Lab,
join me and April as we dive into Terraform,
and she explains to us about state files.
[MUSIC].
>> Hi, my name is Abel,
welcome to the DevOps Lab.
On this episode, we are going to be diving
into Terraform and talking about.
>> State files.
>> With us today is April Edwards.
April I'm so happy for you to
be here, this is going to be really cool.
I'm a big fan of Terraform,
and state files have always been a
little bit confused about what the purpose is for.
>> Yeah, absolutely. Thank you for having me back, Abel.
>> So in the first episode, we talked
about Terraform, what it does.
I want to break down the different components
of what each of those things do,
and how we enable that in the real world, right?
>> Yeah.
>> So I'll start off with state file. So what is the state file?
The state file holds all of our data that
we're deploying in our environment. So let me give you an example.
So on the screen here,
I have to put a resource group to Azure already,
it's called Abel's resource group.
Now, I want to make changes to what I'm doing.
So I've already deployed this, is already sitting in Azure,
and to give you guys a bit a proof of
that I pull up the portal here,
and we have Abel's resource group.
Now there's nothing in it we're going to keep this really simple.
Abel's resource group has no resources but it is there.
So to make changes,
when we go into our code,
I'm just going to go ahead and add that resource group.
Just do a quick resource group on the fly,
I'm going to call it Abel's even better resource group.
So I'm just going to save those changes.
So that's saving to a file.
I'm going to go into my PowerShell, load it up,
and type in Terraform plan.
So what the plan is doing,
plan is going into the state file and going,
"I want you to go ahead and
write the changes that we've just made," and that's fine.
So I managed to fat fingers something already
because welcome to whatever data of the week it is.
>> It happens.
>> We do that again. So what I didn't do
is define the second resource group properly.
So that was my fault,
and hit Terraform plan,
and what it's going to do it's going to call that state file,
and say, "What is already existing."
It will see the existing resource group,
and it's going to spit back at us
actually there are some changes to be made,
and it's going to persist right now,
and it will say, "We're going to add a resource."
So the state file tells us when we're going to change resources,
when we're going to add them or when we're going to delete them.
So in this first example, we're just adding
a very simple resource group.
So that's running, it's refreshing the state file as we speak,
and it's actually not persisting anywhere,
it's just reading the state file.
So we haven't actually made any changes to
environment and we haven't made any changes
to the state file itself.
So we can see here if you look the screen,
it's going to add one resource.
So right here where it says, "Plan to add one resource".
So when I hit Terraform apply,
It's going to make that change.
>> When you say make that change,
do you mean it makes a change in Azure?
>> So it's going to write to the state file, it's going to add it.
It's going to reference that state file again, and say, "Oh,
I need to add this resource as we just discussed in our plan."
Great, and then when we go into Azure,
yes it's going to build at the same time.
>> All right.
>> So if I go in and refresh my portal,
we should see a new resource group come up.
I'm making sure that it all went through properly.
Yes, it did, it split,
yeah there we go, we want confirm that action.
It's going to run through the apply.
So it continuously writing
to the state file and deploying the resource for us as well.
So I'll go back and Azure, refresh,
and we should have a new resource group,
that says, "Abel's even better resource group".
>> All right. So it takes a little bit of time to apply.
>> It does, It's not instantaneous.
So we're also going up to the Cloud right now.
We're not doing on-premise now.
I'm writing to a state file on-prem,
and here we go, we have Abel's even better resource group.
So it's not quite instantaneous,
there's a little bit of a delay but
we've spun out that resource group.
>> So let me recap
because I just want to make sure I understand everything.
So the idea is with Terraform I get
to describe what my infrastructure should look like.
But the way that it does it is an empirical manner.
You basically script out the type
of resources that you want to create.
The way that Terraform protects from
drift I guess is by the state files.
So state files is now going to represent what
should be deployed up in Azure or in my resource group.
Yes. So in this file that I've deployed today,
we can see that I have a state file here.
So it actually shows us what's been deployed.
So this is great because we actually have a state file.
We know it's been deployed, we have record of what we actually
did and we can timestamp it and version it, right?
>> Yeah.
>> Now here's the problem, I've deployed this from my machine.
So in a real-world environment,
it's great to play around with but an enterprise,
what do you think is going to happen?
>> Well, I'm not going to be deploying from my machine.
Hopefully I'll have a pipeline or something like that,
they'll take care of this for me.
>> Absolutely. So I think it's really
critical to sit here and highlight.
We can deploy from our machines,
that's great, but we actually need to secure that state.
Most organizations want to know how
is this a secure solution in the Cloud?
Because we need to secure our Cloud.
>> Oh, that's right.
>> That's right?
>> Yep.
>> So the way we do this in Azure or even actually,
you can do this on-prem,
you can do in other Clouds,
we need to put our state file into a storage account,
and lock down the security keys to it and the access to it.
So we have a script that we can run that deploys it,
and what it does is it will deploy our state file out,
it will tell the state file not to write
locally but write to a storage account,
and then we can call it from that storage account.
>> So this state file,
this is really important to keep safe.
Because this is literally saying,
"This is what my environment should look like."
So if somebody hacks it in some way and goes in there,
they can really mess up our environment.
>> Absolutely. If you put it into like
a GitHub repo which is an option.
If it's a public repo people are
going to see all of your data out there.
>> I see.
>> So you don't want that.
>> Got it.
>> So I have in my resource group.
>> Does it include all the passwords and things like that?
>> Yes, so that's why I'm using Key Vault.
So in my portal here,
I've actually deployed a storage account.
So we can script this, we don't have to this manually.
You can do it manually or you can script it.
>> Sure.
>> I'll reference the script in
the sub-lines of the of the show, so people can have that.
So I can create a storage account and I can
secure the keys of that to the Key Vault.
So we've locked that down, we've secured it.
Now in an enterprise environment,
we have everything in a storage account.
We can make change that as a team not just one person.
>> Sure.
>> So the state file does is as soon as you hit Terraform plan,
it locks that state file.
So no one else can make changes to it, which is really important.
Because if we want to do a real-world demo
or real life implementation,
we're not going to just be deploying resource groups,
probably deploying resources to different environments.
So that state while lock prevents
other people from making changes while you're making changes.
>> Got it.
>> Then that also persists.
Now the other thing is it also isolated from the environment,
and we can isolate the state file per environment as well.
So you have multiple state files based on your environment.
>> Sure.
>> So there's different ways to do that.
So what I have for you is another deployment.
This one's a little bit more in depth.
So instead of deploying resource groups,
I want to deploy yes,
a resource group, some virtual networks,
some subnets, and some virtual machines.
Now, this is already deployed in Azure as we speak.
So if I go into my Azure deployment, and I've already done.
So I've already deployed another resource group.
I've call it scaleset production.
So what I've deployed is
a storage account for my virtual machines,
a load balancer, so we can load balance our workload,
a public IP address to get to our scaleset,
a virtual network, and production VMs.
So this isn't a scaleset.
So if we just go into this here,
and forget everything else I put up.
I put it in a basic infrastructure that
a lot of our customers are looking to do though.
They want to scale their apps in VMs,
though they want to use web apps.
I'm using VMs because there's a lot more continuity.
The customers want to know how to scale, right?
>> Sure.
>> So this is very practical. So right now if
you look at the portal,
we're running actually two virtual machines.
This is great, it's a nice base environment but actually,
I want to scale this to more,
and actually run a proper VM scaleset.
So I'm going to go into my configuration file here,
and where it says, "Capacity to",
we're going to scale that out, let's say 25.
So I'm going to save my changes.
I'm going to go into my PowerShell,
and we want to Terraform apply that, and we're going to run that.
So what it's going to do,
it's going to call that state file, and say,
"What is existing" and it's going to see two resources.
So it's going to change the two
to the element we just put in 25, if that makes sense.
>> So when you say state file,
you're talking about the state file that's
actually sitting in my Azure storage?
>> Exactly. So we've secured our state file,
it's calling it but it's locked to that.
So if anyone else in my organization is trying to make a change,
they'll see that state file is locked.
Because it will say, "State file is locked,
cannot make a change," they come speak to me or waits loaned on.
>> Got it.
>> So it's secured, it's locked down,
no one else can make changes, and we're scaling as we speak.
So with that, it's pretty cool.
So yes, I'm happy with the changes.
As you can see in the plan,
it says, "One item to change".
If we go up here, you can see it's
the capacity of the SKU of the type of VM.
So we're going to 25, great.
So yes that's fine,
I hit Enter, and it's now going to execute.
So what we'll have now is two VMs which will turn into 25.
So I'm going to go into the portal,
and impatiently it's going to hit refresh.
What we'll see is that will see
that they'll start deploying in a second.
>> So while we're waiting for the VMs to spin up,
earlier you showed a screen where you
said the state file is going to sit inside of Azure storage,
and you also had an instance of Key Vault I saw.
>> Yes.
>> What is the Key Vault for?
>> So the Key Vault is securing
my secrets for the storage account.
So when we create a storage account Azure,
we can lock it down and not just give
anonymous access to everyone. Private key access.
So we take the key that we get when
we create that storage account and we insert it into Key Vault,
so it has to call that to access the storage account.
>> I see. So only certain people or certain
machines or certain things that have the correct permissions,
they're able to access the Azure storage which has the state file?
>> Exactly. So it's not just
open and available to anyone in your organization,
just because they have access to Azure,
they don't have access to that resource per say.
So they won't be able to make those deployments.
>> Got it. So much better than just sticking into
my Git repo because now it's really secured and locked down.
>> Absolutely, and this follows best practice with what?
HashiCorp recommends, well, here at Microsoft we
recommend to lock that down
and secured and keep your Cloud secure.
>> Oh, look at that. There's all our machines there.
>> All of our machines are creating,
some are starting, some are running.
>> Sure.
>> We have 25 VMs,
you don't usually get this on on-prem to achieve this,
this is a really cool feature of Terraform.
So we're able to scale our environment,
give us more VMs, give us more capacity, and do it on the fly.
>> This is awesome stuff.
Then thank you so much for showing up on this show.
Thank you for telling us about state files.
It's always been something I've been a little bit curious about,
I kind of sort of knew but I didn't really,
but now I get it.
State files are important,
it represents the current state of my environment.
You showed us how you can lock it down,
so nobody can access it except for
the people or the the processes that need to.
So it's nice and secure.
By having these state files are very simple empirical scripts,
can now become stateful.
>> Absolutely.
>> Yeah, this is great stuff.
Thank you so much, April and I hope you can join us next time.
>> Great. Thank you Abel.
>> Thanks.
[MUSIC]