Good day, Cloud Gurus, and welcome back.
In this lesson, we're going to take a look
at deploying Azure Virtual Machines.
Let's take a look at what we're going to cover.
First up, we'll take a look at configuring
Azure Virtual Machine compute.
Then we'll take a look at the Azure VM sizes.
We'll take a look at VM disk types and VM disk performance,
and we'll take a look at some of the deployment methods
you can use to deploy your virtual machines
and we'll do a bit of a short demo.
And finally, we'll take a look
at creating virtual machine images.
Let's get started.
When deploying your Azure Virtual Machines,
there are a few key components you need to decide on.
The first set of decisions is around
the compute component of the VM.
The compute determines the availability, capabilities,
and performance of the VM.
Firstly, you'll need to decide the tier,
and there are 2 tiers.
The first tier is basic, which is for non-production
and development and test workloads,
and the second tier is standard,
which is for production workloads.
And most VMs you'll create will be in the standard tier.
Then you need to decide the size of your VM
and the size determines the processing power,
memory, and storage capacity of the VM.
And we'll dive into VM sizes in a bit more detail up next.
And then you need to decide your VM generation.
Most VMs will be generation 1,
but you can opt for generation 2,
which adds a few security features
and support the larger VMs
and larger operating system disks.
And finally, you'll need to select a VM image
which determines which operating system the VM will use
and which software will be pre-installed.
The image you choose will impact the available sizes,
generations, and tiers.
And you can select a Microsoft image or an image
from a Microsoft partner, or you can create your own images.
When you go to deploy your first Azure VM,
you're going to be presented with a huge variety of sizes
to choose from,
and the size will have some name like
F2s_V2
or D2as_v4.
And despite the crazy looking name
there actually is some logic to it.
Microsoft uses a naming convention
to determine VM size names.
The name is made up of the family
and there are quite a few VM families to choose from.
And each has different capabilities.
First, we have the A-Series family,
which is entry-level VMs used for development and test.
And then we have the Bs-Series Vms,
which are economical VMs with burstable performance.
And then we have the D-Series Vms,
which are general purpose virtual machines.
We have the F-Series, which are compute
or CPU optimized virtual machines.
And then we have the Ls-Series, which are storage optimized.
And finally, we have the M-Series,
which are memory optimized VMs.
And then you have the subfamily and it's not often used
but there may be an additional letter
to help differentiate the VM family,
and then you'll have the number of CPUs.
And the 2 VM sizes we have here both have 2 CPUs
and some VM sizes also have constrained CPUs,
which help with reducing the licensing costs
where software licenses are built per CPU core.
And then you have the additive features
and these are quite important.
If you want to select an AMD processor,
you'll need to select a VM with a lowercase a.
A lowercase l or m is used to indicate low or high memory
and a lowercase s is used to indicate premium disk support.
And of all of these additive features,
the lowercase s is probably the most important to remember,
and you can see that both the VM sizes we're using here
support premium storage, but only one has an AMD processor.
And then the VM size might also have an accelerator
and that'll be included in the name,
and it also may have version.
Microsoft might go through multiple versions
of the virtual machine and that's indicated
at the end of the name
and we have a version 2 VM and a version 4 VM.
When you create either VMs
with disks or you create new disks independently,
there are a few important decisions to make.
The first is the disk type, and there 3 disk types.
The first are operating system disks.
And as you would expect, these disks store
the bootable operating system
and there is a limit of one of these per VM.
Next, we have temporary disks and these are attached
to some VM sizes and are required for some functionality
like disk encryption.
And on Windows, they'll have a D drive letter,
and finally you can configure your own data disks,
and these are also limited by the size of the VM.
And then you'll need to choose
between managed and unmanaged disks.
Now, all Azure disks are stored in Azure storage accounts
and you can manage this storage account yourself
or you can have Microsoft manage it for you.
And this is actually a fairly simple decision to make.
Unmanaged disks have several limitations.
So you should choose managed disks
for improved management and scalability.
You can also choose to move from unmanaged
to managed disks if required, but you can't move back
from managed disks to unmanaged disks.
Then you'll need to decide the type
of storage your disk resides on,
and this will determine the base-level performance
offered by your disk.
You can choose standard performance and it will provide you
with either a hard disk drive type performance
(you know, those old school spinning disks),
or a relatively moderate speed solid state disk,
which is flash base storage standard disks are recommended
for light and noncritical workloads
and for development and testing.
And then you have premium disks
and premium disks are supported
on VM sizes with an s in the name,
and finally, ultra disks are a relatively new
disk performance type,
which offer the fastest performance available on Azure
and they're only available in select regions.
Another important consideration is around host caching.
The Hyper-V server in the Azure datacenter
that is running your virtual machine
can use some of its memory and local disks to cache data
and improve the performance of your disks.
And premium disk support caching,
and it can be configured as either read/write
or read-only.
And by default operating systems
operate using a read/write cache
and data disks operate using a read-only disk cache.
All right, now let's take a look
at some of the deployment methods you can use
to deploy your Azure VMs.
Firstly, we have the Azure portal
and it's the web-based interface that you can use
to deploy and manage your Azure infrastructure.
We also can use the Azure command-line interface, or CLI.
It's an open source command-line interface
focused at open source developers
that have experience with Linux-like command-line tools.
We also have Azure PowerShell.
It's feature identical to the Azure CLI,
but it is focused at people
with a preference for PowerShell.
And then we have the real production grade tools,
ARM templates, and Bicep.
ARM templates, and the newer Bicep functionality allow you
to declare multiple resources in a template
and then deploy them with dependencies.
So your resources are deployed in the correct order.
And with idempotency, you can deploy these resources
over and over again and receive the same result every time.
And ARM templates or Bicep should really be used
for your production deployments, wherever possible.
And then you can combine these tools together
and use something like Azure DevOps,
which provides source control, testing,
and release functionality.
You might combine your application code
with your infrastructure code and then test
and deploy all the resources
and the applications together using Azure DevOps.
All right, let's take a look at a demo
of deploying Azure VMs using some of these tools.
All right, let's take a look
at creating some virtual machines.
I'm in Visual Studio code here,
and we're going to create some VMs using the Azure CLI,
Azure PowerShell, and ARM templates.
Let's first take a look at the Azure CLI,
and VMs are created using the Azure CLI
using az vm create command.
And here we've specified the resource group RG1.
We've specified a VM name and an image to use
and we're also specifying the admin username.
And we're also specifying
that we want to use a standard SKU public IP
and this is important because only standard SKU public IPs
support network security groups
and they also have a higher level of availability.
Let's go ahead and run this command.
And it's asking for the password for the VM,
so I'll go ahead and provide that.
And again, all right, and the deployment is now running.
So we'll come back when this is done.
All right and that deployment is now complete.
Let's go ahead and take a look at creating a VM
using Azure PowerShell.
And VMs are created using Azure PowerShell
using the new AZ VM cmdlet.
And you can see here
we're specifying a resource group name, a name for the VM,
and then we're specifying which image we'd like to use
for the virtual machine.
And we're also asking it to request credentials.
Let's go ahead and run this
and it's asking for our credentials.
So we'll just go ahead and provide
a username and a password.
It's indicating here that we haven't provided
a size for the VM.
So it's going to go ahead and use
the default size of a standard D2s_V3.
So I'm going to let this run
and then we'll come back when this is done.
All right, with our PowerShell deployment now complete,
let's now take a look at an ARM template.
And I'll just collapse this resources node for a second,
and we can see here that an ARM template is made up
of a few key components.
First, we have the schema, then we have the content version,
and then we have the parameters section.
And the parameters section allows you
to make ARM templates reusable.
I'll expand this so we can take a look at it,
and you can see here that we have a parameter
for the VM name.
And this allows us to deploy multiple VMs
that are exactly the same only changing the VM name.
I'll just collapse the parameter section
and you can also use functions and variables
to increase the flexibility of your ARM templates.
Functions are reusable pieces of code
and variables are values that you might store once
and use multiple times within your template.
Let's take a look at the resources section.
And the resources section includes all of the resources
that you'd like to deploy as part of your template.
In this template, we're first deploying a virtual network
named vnet1.
We're also deploying a network interface
for our virtual machine, and you can see
where we're using the VM name parameter
for the network interface here.
I'll go ahead and collapse that,
and you can also see here
where we are deploying the virtual machine
using the parameter again for the VM name
using a parameter for the VM size, and also using parameters
for the admin username and the admin password.
And you can see here that we are deploying an image
that uses Windows Server 2022 Datacenter edition.
Now, I just want to show you one more property here
and that is dependsOn, and this allows you to
have your deployments deploy in a specific order.
So we're saying here that the virtual machine
is dependent on its network interface.
Let's take a look at the visualizer.
And you can see here that this ARM template
is first going to deploy our virtual network
because the network interface
depends on the virtual network.
And then it's going to deploy the network interface.
And then it will go ahead and deploy the virtual machine.
We'll go ahead and close the visualizer.
Now let's go ahead and deploy this template
using the Azure CLI.
We'll jump over to the Azure CLI
and you deploy a template to a resource group
using the az deployment group create command.
We're specifying the resource group name
and the template file we'd like to use,
which is azuredeploy.json.
Let's go ahead and run this command.
And you can see here it's asking for a VM name.
Let's go ahead and use VM5 for our VM name.
And it's also asking for the admin password.
So we'll go ahead and provide that.
All right, this will just take a moment to deploy.
So we'll come back when this is done.
All right with the deployment using the Azure CLI
and the ARM template now complete,
let's take a look at deploying the template
using Azure PowerShell.
We'll jump over to Azure PowerShell,
and templates are deployed using Azure PowerShell
using the new az resource group
deployment PowerShell cmdlet.
And you can see here
we're specifying the resource group name
and the template file that we'd like to deploy.
Let's go ahead and run this.
And because we specified the VM name as a parameter,
it allows us to reuse that template again
to deploy another virtual machine.
Let's deploy VM6
and it's asking for the admin password again.
So we'll go ahead and provide that.
All right, and this will just take a moment to deploy.
So we'll come back when this is done.
All right, and the deployment using Azure PowerShell
and the ARM template is now complete.
Now let's go and take a look
at creating your own custom images.
Now, as we mentioned earlier in this lesson
you're going to need to use an image
for the operating system disk that you use
for your virtual machines.
Now you can and choose an existing image
provided by Microsoft or their partners,
or you can create your own.
Let's look at the steps required to create a custom image
for a Windows operating system.
Firstly, you'll need to create your virtual machine
and customize it with the required software
and customizations that you'd like to include.
Then you need to generalize your VM
using the sysprep generalized command,
which removes the uniqueness from the VM
and performs some cleanup.
Then you need to stop and deallocate the VM.
And technically, deallocating the VM is not required
but it is recommended by Microsoft.
And you can do that using the Azure CLI
using the az vm deallocate command,
and I'll include some links to the PowerShell
equivalents in the resources.
And then you need to mark the VM as generalized
using the az vm generalized command.
And finally, you can capture the VM image
using the az image create command.
Now it's important for the exam
to remember the order of these steps,
but in real life, you'll get plenty of prompts
from the tools to remind you
if you've missed something along the way.
All right, let's take a look
at what we've covered in this lesson.
Use the Standard VM tier for your production VMs.
Use generation 2 VMs for larger VM operating system disks,
more memory, and advanced security features.
And use a VM size marked with the S additive feature
to have access to premium storage.
And always remember to generalize your VM using sysprep
before capturing it as a VM image.
All right, thanks for being with me in this lesson
and I hope you found it useful.
And I look forward to seeing you on the next lesson.