[MUSIC]. >> Welcome to the DevOps Lab. On this episode, we're joined
by a very special guest, April Edward. How the going April? >> Thank you Able. Awesome,
glad to be here again. >> Today we're going to do
more deep dive into Terraform. You told me we're going to
talk about modules, correct? >> We are, yes. >> All right. Explain to
me what a module even is. >> So when we wrote our
Terraform files before we had everything in a
main.tf file in one file. But when we start building
bigger environments, we need to break those
up and call variables. So we use modules instead
of calling a resource. Because those main files get
really long, really complex. Remember, when we talked about arm templates versus Terraform files, event Terraforms we can
do it in shorter code. >> Sure. >> So we're going to
condense it use the modules, but it makes it repeatable
and makes it redeploy. Which is the advantage of the Cloud. So not just one Datacenter, one environment.
Multiple environments. >> So a module, would you say is kind of like a
function when you're programming? Or a method when you're programming? >> Yes, it's very much
calling a method. So what we'd need to do is
call that quote method, which is a module in this case and
tell Terraform to deploy that. It'll be in a much
larger environment. So that we're not just appoint one big file and scrolling
through so much code. We can call the module and we can
just make changes to the module. We don't to make changes to
our entire Codebase as well. >> Right. So would you say a
module is a deployable unit? >> Yes, so if you look
at the screen here. So in our previous deployments, we call what's called
a resource here. We're calling the resource. We're using the Azure provider here, and calling the resource group, and we're giving it a title. So we're putting in variables and places set of getting
a discrete name. >> Sure. >> In the previous
deployments with you, I've just put in the
actual location like, West Europe, East US, wherever. We're using a variable instead of doing we want to make it
repeatable and scalable. >> Yes. >> I'm also adding tags
into this deployment. So tagging is really great for environments because you
know what's been deployed. It helps with the
billing cycle and also giving access permissions
across the environments. So I'm just adding an extra
layer of neatness to it. So that's a resource. So instead of calling your resource, I'm going to now call a module. So what Terraform does and this
is our main.tf templates tell. It's going to find the resource
group, and then an order. They're going to call
the modules in line. >> I see. Yes. >> So we're going to call the module, and it's called application-VNet, and the source is modules/VNet. So if I go to my modules folder here, I have one that's calls VNet. Now, each one of these modules
folder also will have a main file, and output file, and
a variable's file. So it has a very similar main file. So let's use the example
of the VNet one here. We go into the main want and
it's calling the variables. But it's defining the resource. So if we want to expand this and
add in other resources to it, we'd add it to the module. So we can create modules for
elements the environment we want to, either add or take away. So we could add security roles, we could add web apps,
we could add functions, we could add a whole other slew
stuff and add it module by module, or take it away module
by module, right? >> Yeah. >> So the only downside
of the module. I'm saying really
downside, the caveat is, it's dependent on the entire
environment that you're deploying to. So everything in that environment is going to call on that module set. So in this case, what we want to do is build
out our data center in Azure. We want to Develop a
little bit of a framework. Now when you go to organizations and talk to them about
how they're deploying, how they're testing and
running their code, do they ever had the
same environments for Dev test and production? >> Very rarely. >> Right. It's a big complaint. You go and talk to
a Dev team and they laugh because they're
out of capacity, or it's not the same hardware, it's not the same OS levels,
everything's different. So in real life, how
are we actually able to test our code if our
environments are different? We're adding in
extremely options that could completely blow our
applications on the water. What we're going to do today is built three identical
environments in Azure, using modules so they have
the exact same configuration. >> Okay. >> Yes, we're building three
different environments, but what we're also going
to do is separate them out to the manage a
little bit independently. So before when we talked
about the state file, we add another element
called a workspace. >> Okay. >> So when we do one main file, we have what's called
the default workspace, and we had one state file. Because I wanted to put three
different environments. I actually want to manage
them separately but have the exact same infrastructure
in them. If that make sense. >> Sure. >> So these modules are going to
deploy the same infrastructure. But as you can see, I haven't
listed here my folder structure, I have a Dev environment, a test environment, and to
production environment. Now they're all going
to call in the modules to organize the main file. What we've done is
put in a tvars file, which actually is going to give us different variables
for that environment. >> Got it. >> So I need to know how do I
differentiate my environments. So we're just going to call it environment C9 demo for Channel nine. The environment is Dev. Now I've chosen my
location and my capacity. So that capacity again
it's going to tie to our Virtual Machines scale set. >> Yeah. >> If I go into my test environment, we've called the exact same variables except I've put in three VMs and
I've call the environment test. So everything is going to
have that tag added to it, so I can differentiate my
three different environments. >> Got it. >> On top of that,
it's going to write to three different state files. So what that means is, if I'm working in my test
to my Dev environment, it's not going to affect production. >> Got it. >> So we have separation
of environments. >> So let me run this back really really quickly just to make
sure I understand again. Using one main.tf file, which is basically
like the blueprint. This is how I want my environments
to be built out here. You're now able to create
three identical environments, your Dev, your Q&A and your
production environments. Then by passing in variables
using the same main.tf file, now you're able to tweak the different environments
based off into variables. So maybe you want your Dev
environment in Western Europe, and then maybe you want
your QA environment in Western US, for whatever reason. >> Absolutely, and we have
customers that do that. Because they have Dev
teams across the globe. But I think I want to focus just on that we're deploying
this all to one location. >> Okay. Sure. >> So what we can do is change
that variable to another location. So maybe we want to
take this environment and spin it up somewhere
entirely different, like the East US, or Western Europe, or UK, West or wherever. All we have to do is change
that variable and we have the exact same environment. So for global organizations, this is key. This is a game changer. >> Yeah. >> So now your Dev team
isn't going back to your ops team going," I
need these resources". They're like," oh we don't have it. Oh everything's different". We can deploy the exact same
environments across the globe? >> Fantastic. >> Cool. So I want to actually just show you what
I've done a little bit. So I told you will have state
files in different environments. So remember that label called the
variable for Dev test and prod. It's attached to the state file. So these state files are sitting
in my Azure storage account. It's calling Key Vault,
so I've secured it out. So we just did, we talked about the state files
and how those work. But I have actually
separated those out. Also with this in my code, I've implemented a workspace. So my Dev environment
has its state file, its own environment, its own
virtual networks so its segmented. It has what's called a workspace. So I can edit our Dev environment
and not touched the others, and not have that risk of
bringing everything down. >> Yes. >> Again, another game changer. So how does a workspace work? So I want to just go back into
my resource group in Azure. If you can see up here, I've already created our Dev
test and prod environment. So let's go into Dev. I talked about we had two virtual
machines running. Here we go. So we have our Virtual
Machines scale set. We have our own virtual networks. So we can set up a peer to
talk to the other networks. But right now these are three
independent environments built identically with
virtual machines skill sets. So I go into my skill set here, I can see that I have two
instances running right there. I also talked about
the tagging thing. I've tagged my environment
right down here. So I know what the
application is listed as. It was deployed by Terraform and what environment I'm in and
what type of environment in. So the m skill set environment. We could do the exact same thing
for our data environments, our web apps, our
containers environments. We can put tags to it so we know exactly what we're deploying to
and we get real record of it. Someone who likes to handle the billing side can
also see that, right? >> Right. >> We've cover all our bases. >> Right. So I want to manipulate
what we've done. So let's say for instance we have our Dev environment and maybe we need to rebuild
it, or we don't like it. Let's get rid of it. Let's get rid of Dev. But not affect test or
production environments. So it talks about this
element of workspace. So I create this workspace for Dev. If you see here, instead
of going Terraform minute, Terraform plan, Terraform apply,
if we'd done in the past. We have to select
our workspace first. >> Got it. >> We're not working off
that default workspace, we have divided it up and cut it out. We've given it a logical separation. So with Terraform workspace, I'm going to select where to go. Dev, type in " Dev". What it's going to do
it's going to say, I've switched the workspace Dev here. Now I can type in prod or test, and we'll also switch to those. So what I want to do is I want to actually destroy
that environment, because maybe we don't need it. Or we want to do something
different with it. So what I'm going to do is I'm
calling the variable file. If you remember, I had the Dev. Remember that variable
file that we call it? I'm just calling that
now in my lot of code, and say, I want to destroy that variable file
and everything in it. >> Got you. >> All right. >> Yeah. >> So I've called the workspace. So it's acquiring state locks. Remember we talked about
state files, right? We're locking out that
state file only in Dev, and we're not going to
touch production and test. It's going to lock it out so
no one else can touch it. >> Cool. >> Then it's going to come
up and it's going through the resources and saying what is
existing in that environment. Then it's going to go," Are you
sure you want to delete? ". >> Sure. >> Let's do it. So it's pulling everything up. It's
listing everything up. Again, we can output this to
a file, we can document it, we can do other things with it, we can have different
versioning as well. So " Yes". Let's destroy it. >> Perfect. >> Then see what happens. >> So now it's going
to go into Azure and just destroy my Dev environment? >> Exactly. Devs going
to be gone in a moment. So that would be really cool. >> Very, very cool stuff. >> Definitely. I think
we've worked with so many organizations that struggle
to get identical environments, and to manage those environments. Because the teams are having
to manually do things etc. Terraform can take over that
element of management, right? >> Sure. >> This has been pretty
easy to do today. You can do this On-Prem. We can't do scale sets, but we can manage our
On-Prem environments. We can also do the other Cloud. So with a multi-Cloud strategy
or an On-Prem environment, we can start managing with our
operations teams more efficiently. >> Awesome stuff. Very cool. So basically today you've shown us the power of Terraform especially
when you start using modules, when you start using variables
and also workspaces. This has been great
stuff. Thank you again. So all you Devs out there, go to Terraform,
check this stuff out, start building out your
infrastructure with Terraform. Fun stuff. Thank you so much April. >> Thank you Able. [MUSIC]
