>> 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]
