One of the coolest things about cloud platforms like Azure is just how fast and easy you can spin up new resources. No need to rack, stack, and cable stuff anymore. Heck, you don't even have
to set up the software if you don't want to. It can come way too easy
to cause environment and configuration drift
if you aren't careful. Today, I'm gonna show you the fundamentals on how to build and deploy
infrastructure as code in Azure through ARM templates so that this sort of
drift won't happen to you. (upbeat rock music) Dana Epp here, welcome to the channel that helps aspiring Azure administrators, like you and me, to know ops and, well, master the Microsoft cloud. I'm glad you're here. If you haven't yet, smash
the subscribe button, so you can be notified when I
release new videos each week. So the world of infrastructure
as code is here. In Azure, this can be accomplished using Azure Resource Manager with something called ARM templates. An ARM template is nothing
more than declarative code that describes Azure resources
and allows you to instruct the Azure Resource Manager backplane and how to deploy it. It's basically a JSON file
that describes everything. It can be as simple or
as complex as you want it allowing you to deploy virtually anything and everything in short order. You use ARM templates all the
time if you know it or not. Even when you're deploying
something through the portal that you selected from the marketplace, behind the scenes, ARM
gets the instructions on what to do through these templates. In fact, if you look closely just before you create a resource, there's a link to download
a template for automation. Click it sometime and check it out. That's an ARM template. There are other ways
to see an ARM template. One of my favorite ways is to go to the existing resource groups and click on the Export template blade. That will load up on screen where Azure will generate an ARM template from all of your existing resources within that resource group, even sets up the parameters for you so that if you ever wanted to deploy the exact same environment
in another resource group, subscription, or tenant, you can. Those parameters are used to
prompt you during deployment on what you want the values to be. When you're in the
portal, that will show up in these text fields and drop
downs that you see in the UI. If you use the Azure CLI,
those are the parameter you get prompted for. Of course, you can use
the Export template blade on individual resources in the same way so it becomes very easy
to generate ARM templates for individual resources or
entire deployments if you like. One tip though, when exporting a template from existing resources, there's a bunch of additional noise that's
created with the templates that relates specifically
to that deployment. These are things that
you'll want to strip out if you ever wish to reuse
the template elsewhere. There are several online resources
that you can walk through that will show you how to
do that if you ever need to. But let me show you an even better way to get clean ARM templates for use for infrastructure as code in Azure. Head on over to
azure.microsoft.com/resources/templates. This is the Azure
QuickStart Template gallery. It's a great site where you
can deploy Azure resources through the Azure Resource Manager with community contributed
templates to get more done. You can deploy, learn, fork, and even contribute back to GitHub everything you need for
infrastructure as code. Check it out, there are
literally hundreds upon hundreds of ARM templates already built for you to deploy everything from simple VMs all the way to complex
deployments with multiple servers, databases, and all the
networking configuration to make everything talk
together in a safe manner. What I like is that the
gallery includes a button to deploy these templates
straight to Azure. You're obviously responsible for knowing what the templates are doing and you will need to provide any values for the parameters required, but it's a quick way to
get new infrastructure up and running in a consistent manner in just a matter of minutes. Beside the button to deploy to Azure is another button that
gives you the option to look at the template in GitHub. I encourage you to check
out a few templates that interest you so that
you can get comfortable with the structure and
syntax of an ARM template before you start deploying it. To help you understand
how these templates work, why don't we jump into a session and I'll walk you through all the basics on how you can build your
first template from scratch? It's the best way to learn this in Azure and I'll show you a few to tools and tips to make this much easier on you. So let's start from the very basics. An ARM template is just a text file. It's written in a format called JSON which is a lightweight format for storing and transporting data. It stands for JavaScript Object
Notation, but don't worry, it's not some Evil dark art
left only for developers. More importantly, while
it's based on JSON, an ARM template is more than that. Its schema allows an ARM
template to do additional things like host comments that
JSON just can't do. That's helpful when we write
our infrastructure as code as we can document what we're
doing right in the template. So let's write our first template. I'm gonna use Visual
Studio code to do this, which is a free editor that
Microsoft makes available on many different platforms
like Windows, Mac, and Linux. Why I like VS code is that
it's a powerful framework that allows you to install extensions that can help you build and
work with pretty much anything. In our case, I've installed the Azure Resource
Manager tools extension, which is gonna really
help us here shortly. I'll leave a link to all
this in the show notes so that you can download it
later if you haven't already. To get started though, what I'm gonna do is make my first file. So let's say we want to
deploy a storage account. We have a .json extension and
we can see on the bottom right that VS code is saying, "Hey,
the language here is JSON "that we're gonna be using
as the language mode." But with that ARM toolkit extension, it can detect things and
use things like snippets to help with IntelliSense
to really help guide us along the process of
building an ARM template. So as an example, if I type ARM, it automatically will
create a skeleton for us if I just hit Enter, and
what you can see from this is an ability to build
off of the 2015 schema, but we'd also got prompt and said, "Hey, do you wanna use a newer schema?" And I'm gonna say, "Yes,
I wanna use the latest", and that's gonna convert
it to the 2019 format, which is a whole bunch of
new pieces in the templating that we can take advantage
of like that leaving comments and case sensitivity
doesn't matter as much, and there's like, just
a whole bunch of things to make our life a lot easier. So that scaffolding though is pretty nice and by approving it,
make sure you improve it to change it from the 2015 schema to 2019. Once we've done that now, let's go and build our first resource. So if you know anything
about how JSON works, you see things like
square brackets like this that typically usually means an array. Doesn't have to but that's
what it usually means. So in our case here, we're
gonna have the ability to put in multiple resources. We're just gonna start
by adding one resource, but you could add as many as you want to and it works by the order of precedence by what's at the top
that gets deployed first, then it's what's next, and what's next. So that way, if you have dependencies, you can make sure that
those get deployed first. In our case though, what we wanna do is we said we wanna do a storage account. So if I put a dash and
then hit S for storage, I can then select that and it
automatically scaffolds out the configuration for a resource. You need a name and a type,
any tags that might be there such as display name and the properties that might relate to
what we're building out. And this in itself is
actually all that's needed to create an ARM template. If I literally just saved this, I have everything I need to get going. So if I wanted to build
out and deploy this, I can easily do this. A way we can do this is that if you happen to have the Azure CLI as an example, which I have down here in the terminal, I can just check, make sure
I'm logged in, and I am, so what I'm gonna do is
I'm going to actually go and deploy this out. A way to do that is you type
az group deployment create. I have a group called KnowOps. And we have this template
file called deployStorage. And what we can see here
is a deployment fail because that storageaccount,
storageaccount1 has already been taken. Okay, well, that means
someone already has that name. So maybe we wanna change that. While we're going to change
it, the easiest way to do that would be to maybe change
it into a variable and change those values. So over here under the variables section, I can create a new variable. In this case, maybe I'll call it name. And I'll call it danastore. And then what I'd do is replace the actual hard-coded value I have here with a call to the variables. Now, to do this, there's actually, I need to put square
brackets inside a quote so it knows to look up the variables and then I can look up
the variable like the name so you can see right there. And what this will now do is it'll take whatever that variable is. And let's try running it again. And there we go. Now, we have this
storage account deployed. Now, here's a problem. In that case of having that variable, if I was gonna run this again, it's gonna fail just like the first time because there's already a storage account with a name danastore. So maybe a better way to do this, it would be not to use
a variable but instead to make it a parameter
so that you can prompt for the name and change it as you need to. So the best way that
we can probably do that is if we were to think about
how we wanna change it, we could go into the parameters value that's up here and we could create a new parameter. So we're gonna move that
variable which we called name and we'll move it up into here and you can notice as I'm typing in, it's auto completing and telling me the value type is a required
value and I need to know that. And it happens to be a type
of a string and some metadata. By putting something like
a metadata of description, whenever we get prompted, (keyboard clacking) we can see this. So if we're doing this in
the portal as an example, it will create a text field and it'll say, "Enter the name of your storage account", which is what we want there, and of course, we'll have
to get rid of this variable because can't have duplicate. And then of course, that
means that this is broken 'cause it's not a variable
anymore, it's a parameter. And there you go. Now, we have this parameters set up. Now, before we deploy this, one of things we might wanna do since we're making so many
changes is to validate that the template is working good and we can do that by typing
az group deployment validate. You'll see, one of the
first things it's doing is it's prompting me now
because I set up a parameter. And you'll see that it succeeded. Now, it didn't actually deploy it 'cause I just asked to validate it, but now I can use that exact same command, change it to a create. And now, it's gonna ask us. And do another deployment. And if we now look, we can see we now have
two storage accounts. So we did the first one where
everything was hard coded. The second one, we use by
passing at a parameter. The third way we can do it
is by using a parameters file and that gets useful because
on some larger templates, there could be literally
dozens of parameters and you're not gonna wanna try to have to hit Enter all those times especially if you're gonna
redeploying all the time. You could scrape this out
using DevOps pipelines or through parameter files
that are auto-generated to deploy the infrastructures you need to. So the way we do this is we
create a parameters file. So we'll create a new file here. We'll call this one
deployStorage.params.json. Again, this starts off as a JSON file, but if I type armp for
a parameter skeleton, boom, automatically
creates that skeleton file. And then I could just go in and put in the values that I want for the parameters, so in my case here, we have
a parameter called name. And it's gonna have a value of, we did two, so what we
call this one danastore3, and then we just have one other parameter that we pass in to the
create which is --parameters. And then you would include
that parameters file and then let's do another deployment. And there you have it. So if we take another look, you now have three storage accounts set up and deployed
automatically using ARM templates and it took no time at all. Now, we can know that we can deploy this consistently every single time. Now, we're just using a single
simple storage account here, but you could do this and deploy
this with multiple servers and storage accounts and
key vaults and web apps and have it all working
through a single template and parameter file which
you can then manage in your GitHub repos or your Azure repos and be able to consistently
deploy infrastructure as code the same way every single
time that you wanna do it. With ARM templates, infrastructure as code isn't that hard in Azure. Using it can save you tons of time and help prevent the unwanted environment and configuration drift that can happen in the cloud so easily. I hope I've been able
to show you the basics of ARM templates in a
way that will get you to start using them. Not only can you use them in the Azure CLI or in the portal like I've shown today, you can use them in things
like your DevOp pipelines to automate all this. What do you think? Was this helpful? Let me know by hitting the like button and if you haven't yet,
smash the Subscribe button so that you can be notified as I publish new content each week. Until then, thanks for watching. We'll see you in the next episode.
