AZ-104: Deploy and manage Azure compute resources Flashcards
Introduction to Azure Virtual Machines
Azure Virtual Machines is an on-demand, scalable cloud-computing resource. They include processors, memory, storage, and networking resources. You can start and stop virtual machines at will and manage them from the Azure portal or with the Azure CLI. You can also use a remote Secure Shell (SSH) to connect directly to the running VM and execute commands as if you were on a local computer
Unmanaged
With unmanaged disks, you are responsible for the storage accounts that are used to hold the VHDs that correspond to your VM disks. You pay the storage account rates for the amount of space you use. A single storage account has a fixed rate limit of 20,000 I/O operations/sec. This means that a single storage account is capable of supporting 40 standard virtual hard disks at full throttle. If you need to scale out, then you need more than one storage account, which can get complicated
managed disks
Managed disks are the newer and recommended disk storage model. They elegantly solve this complexity by putting the burden of managing the storage accounts onto Azure. You specify the disk type (Premium or Standard) and the size of the disk, and Azure creates and manages both the disk and the storage it uses. You don’t have to worry about storage account limits, which makes them easier to scale out
managed disks BENEFITS
Increased reliability: Azure ensures that VHDs associated with high-reliability VMs will be placed in different parts of Azure Storage to provide similar levels of resilience.
Better security: Managed disks are real managed resources in the resource group. This means they can use role-based access control to restrict who can work with the VHD data.
Snapshot support: Snapshots can be used to create a read-only copy of a VHD. We recommend that you shut down the VM to clear out any processes that are in progress. Creating the snapshot only takes a few seconds. Once it’s done, you can power on the VM and use the snapshot to create a duplicate VM to troubleshoot a production issue or roll back the VM to the point in time that the snapshot was taken.
Backup support: Managed disks can be automatically backed up to different regions for disaster recovery with Azure Backup without affecting the service of the VM.
What is SSH?
Secure Shell (SSH) is an encrypted connection protocol that allows secure sign-ins over unsecured connections. SSH allows you to connect to a terminal shell from a remote location using a network connection
There are two approaches we can use to authenticate an SSH connection: username and password, or an SSH key pair
SSH key pair: a public key and a private key
The public key is placed on your Linux VM or any other service that you wish to use with public-key cryptography. This can be shared with anyone.
The private key is what you present to verify your identity to your Linux VM when you make an SSH connection. Consider this confidential information and protect this like you would a password or any other private data.
Connecting to the VM with SSH
To connect to the VM via SSH, you need:
the public IP address of the VM the username of the local account on the VM a public key configured in that account access to the corresponding private key port 22 open on the VM
Opening ports in Azure VMs
By default, new VMs are locked down.
Apps can make outgoing requests, but the only inbound traffic allowed is from the virtual network (e.g., other resources on the same local network) and from Azure Load Balancer (probe checks)
What is a network security group?
Virtual networks (VNets) are the foundation of the Azure networking model and provide isolation and protection. Network security groups (NSGs) are the primary tool you use to enforce and control network traffic rules at the networking level. NSGs are an optional security layer that provides a software firewall by filtering inbound and outbound traffic on the VNet
Security groups can be associated to a network interface (for per host rules), a subnet in the virtual network (to apply to multiple resources), or both levels
Security group rules
NSGs use rules to allow or deny traffic moving through the network. Each rule identifies the source and destination address (or range), protocol, port (or range), direction (inbound or outbound), a numeric priority, and whether to allow or deny the traffic that matches the rule.
How Azure uses network rules
For inbound traffic, Azure processes the security group associated to the subnet and then the security group applied to the network interface. Outbound traffic is handled in the opposite order (the network interface first, followed by the subnet)
Keep in mind that security groups are optional at both levels. If no security group is applied, then all traffic is allowed by Azure. If the VM has a public IP, this could be a serious risk, particularly if the OS doesn’t provide a built-in firewall.
Introduction to Windows virtual machines in Azure
Azure VMs are an on-demand scalable cloud computing resource.
Sizing your VM
There are quota limits on each subscription that can impact VM creation. By default, you cannot have more than 20 virtual cores across all VMs within a region. You can either split up VMs across regions or file an online request to increase your limit
Azure uses virtual hard disks (VHDs) to represent physical disks for the VM. VHDs replicate the logical format and data of a disk drive but are stored as page blobs in an Azure Storage account
Mapping storage to disks
Default DISK creation VM DISK
By default, two virtual hard disks (VHDs) will be created for your Windows VM:
The Operating System disk. This is your primary or C: drive and has a maximum capacity of 2048 GB.
A Temporary disk. This provides temporary storage for the OS or any apps. It is configured as the D: drive by default and is sized based on the VM size, making it an ideal location for the Windows paging file.
Temp Disk
The temporary disk is not persistent. You should only write data to this disk that you are willing to lose at any time.
What about data?
You can store data on the C: drive along with the OS, but a better approach is to create dedicated data disks. You can create and attach additional disks to the VM. Each data disk can hold up to 32,767 gibibytes (GiB) of data, with the maximum amount of storage determined by the VM size you select
RDP
When you connect, you’ll typically receive two warnings. These are:
Publisher warning - caused by the .rdp file not being publicly signed.
Certificate warning - caused by the machine certificate not being trusted.
In test environments, these warnings can be ignored. In production environments, the .rdp file can be signed using RDPSIGN.EXE and the machine certificate placed in the client’s Trusted Root Certification Authorities store
VMS
By default, new VMs are locked down
Apps can make outgoing requests, but the only inbound traffic allowed is from the virtual network (e.g. other resources on the same local network), and from Azure’s Load Balancer (probe checks
How Azure uses network rules 2
The rules are evaluated in priority-order, starting with the lowest priority rule. Deny rules always stop the evaluation. For example, if an outbound request is blocked by a network interface rule, any rules applied to the subnet will not be checked. In order for traffic to be allowed through the security group, it must pass through all applied groups.
The last rule is always a Deny All rule. This is a default rule added to every security group for both inbound and outbound traffic with a priority of 65500. That means to have traffic pass through the security group you must have an allow rule or it will be blocked by the default final rule
az vm create
This command is used to create a virtual machine in a resource group. There are several parameters you can pass to configure all the aspects of the new VM
verbose
lag to see progress while the VM is being created
VM Administrator specific
We are specifying the administrator account name through the –admin-username flag to be azureuser. If you omit this, the az vm create command will use your current user name. Since the rules for account names are different for each OS, it’s safer to specify a specific name
Public and Private IP
When you create a virtual machine, it gets assigned a public IP address that is reachable over the Internet, and a private IP address used within the Azure data center. You get both of those values in the returning JSON block from the create command
List of VMS
az vm image list –output table
This will output the most popular images that are part of an offline list built into the Azure CLI
Location-specific images
Some images are only available in certain locations. Try adding the –location [location] flag to the command to scope the results to ones available in the region where you want to create the virtual machine
VM sizing
Virtual machines must be sized appropriately for the expected work. A VM without the correct amount of memory or CPU will fail under load or run too slowly to be effective
viewing size by location
az vm list-sizes –location eastus –output table
Standard_DS1_v2
so Azure selected a default general-purpose size for us of Standard_DS1_v2
Number of vms per subscription
our subscription tier enforces limits on how many resources you can create, as well as the total size of those resources. For example, you are capped to 20 virtual CPUs with the pay-as-you-go subscription, and only 4 vCPUs for a free tier. The Azure CLI will let you know when you exceed this with a Quota Exceeded error. If you hit this error in your own paid subscription, you can request to raise the limits associated with your paid subscription (up to 10,000 vCPUs!) through a free online request
list available resize options
az vm list-vm-resize-options \
- -resource-group learn-0d648c7e-6889-4d0c-b5e6-35906e6bcbd0 \ - -name SampleVM \ - -output table
az vm list
This command will return all virtual machines defined in this subscription. The output can be filtered to a specific resource group through the –resource-group parameter
az vm list-ip-addresses -n SampleVM -o table
Another useful command is vm list-ip-addresses, which will list the public and private IP addresses for a VM. If they change, or you didn’t capture them during creation, you can retrieve them at any time
Getting VM details
az vm show –resource-group learn-0d648c7e-6889-4d0c-b5e6-35906e6bcbd0 –name SampleVM
Adding filters to queries with JMESPath
JMESPath is an industry-standard query language built around JSON objects. The simplest query is to specify an identifier that selects a key in the JSON object.
Stopping a VM
az vm stop \
- -name SampleVM \ - -resource-group learn-0d648c7e-6889-4d0c-b5e6-35906e6bcbd0
Confirm it’s stoped
az vm get-instance-view \
- -name SampleVM \ - -resource-group learn-0d648c7e-6889-4d0c-b5e6-35906e6bcbd0 \ - -query "instanceView.statuses[?starts_with(code, 'PowerState/')].displayStatus" -o tsv
az vm start
Starting a VM
Retrieve our default page
In Azure Cloud Shell, use curl to read the default page from your Linux web server using the following command, replacing with the public IP you found previously. Alternatively, you can open a new browser tab and try to browse to the public IP address
curl -m 10
opening a port
az vm open-port \
- -port 80 \ - -resource-group learn-0d648c7e-6889-4d0c-b5e6-35906e6bcbd0 \ - -name SampleVM
How disks are used by VMs
Operating system storage
Operating system storage. Every VM includes one disk that stores the operating system. This drive is registered as a SATA drive and labeled as the C: drive in Windows and mounted at “/” in Unix-like operating systems. It has a maximum capacity of 4,095 gibibytes (GiB), and its content is taken from the VM image you used to create the VM
Temporary storage
Temporary storage. Every VM includes a temporary VHD that is used for page and swap files. Data on this drive may be lost during a maintenance event or redeployment. The drive is labeled as D: on a Windows VM by default. Do not use this drive to store important data that you do not want to lose
Data storage
A data disk is any other disk attached to a VM. You use data disks to store files, databases, and any other data that you need to persist across reboots. Some VM images include data disks by default. You can also add additional data disks up to the maximum number specified by the size of the VM. Each data disk is registered as a SCSI drive and has a max capacity of 32,767 GiB. You can choose drive letters or mount points for your data drives
Storing VHD files
In Azure, VHDs are stored in an Azure storage account as page blobs
Storage account type
General-purpose standard
Services supported
Azure Blob storage, Azure Files, Azure Queue storage
Types of blobs supported
Block blobs, page blobs, and append blobs
General-purpose premium
Services supported
Blob storage
Types of blobs supported
Page blobs
Blob storage, hot and cool access tiers
Services supported
Blob storage
Types of blobs supported
Block blobs and append blobs
general and premium storage
Both general-purpose standard and premium storage support page blobs. Choose a standard storage account if cost is your primary concern. Premium storage will cost more, but will also deliver much higher I/O operations per second, or IOPS. If data performance is a requirement for your VM, consider using premium storage
Attach data disks to VMs
The VHD can’t be deleted from storage while it’s attached
Add-AzVhd
VHDS are created as ?
.vhd file as a page blob
Before you can use the new VHD to store data, you have to initialize, partition, and format the new disk. We’ll practice these steps in the next exercise
Azure Disks
Azure Disks are designed for 99.999% availability
Ultra disks
Azure ultra disks deliver high throughput, high IOPS, and consistent low latency disk storage for Azure IaaS VMs. Ultra disks include the ability to dynamically change the performance of the disk without the need to restart your virtual machines (VM). Ultra disks are suited for data-intensive workloads such as SAP HANA, top tier databases, and transaction-heavy workloads. Ultra disks can only be used as data disks. We recommend using premium SSDs as OS disks
Premium SSD disks
Premium SSD disks are backed by solid-state drives (SSDs), and deliver high-performance, low-latency disk support for VMs running I/O-intensive workloads. These drives tend to be more reliable because they have no moving parts. A read or write head doesn’t have to move to the correct location on a disk to find the data requested
You can use Premium SSD disks with VM sizes that include an “s” in the series name. For example, there is the Dv3-Series and the Dsv3-series, the Dsv3-series can be used with Premium SSD disks
Standard SSD
Standard SSDs are between standard HDDs and premium SSDs from a performance and cost perspective
What if you have a low-end VM, but you need SSD storage for I/O performance? That’s what Standard SSDs are for
Standard HDD storage
Standard HDD disks are backed by traditional hard disk drives (HDDs). Standard HDD disks are billed at a lower rate than the Premium disks. Standard HDD disks can be used with any VM size
Unmanaged
With unmanaged disks, you are responsible for the storage accounts that are used to hold the VHDs that correspond to your VM disks. You pay the storage account rates for the amount of space you use. A single storage account has a fixed rate limit of 20,000 I/O operations/sec. This means that a single storage account is capable of supporting 40 standard virtual hard disks at full throttle. If you need to scale out, then you need more than one storage account, which can get complicated
managed disks
Managed disks are the newer and recommended disk storage model. They elegantly solve this complexity by putting the burden of managing the storage accounts onto Azure. You specify the disk type, and the size of the disk and Azure creates and manages both the disk and the storage it uses. You don’t have to worry about storage account limits, which makes them easier to scale out. Here are some of the benefits you get over the older unmanaged disks
Benefits of Managed Disks
Increased reliability: Azure ensures that VHDs associated with high-reliability VMs will be placed in different parts of Azure storage to provide similar levels of resilience.
Better security: Managed disks are managed resources in the resource group. This means they can use role-based access control to restrict who can work with the VHD data.
Snapshot support: Snapshots can be used to create a read-only copy of a VHD. You have to shut down the owning VM but creating the snapshot only takes a few seconds. Once it’s done, you can power on the VM and use the snapshot to create a duplicate VM to troubleshoot a production issue or rollback the VM to the point in time that the snapshot was taken.
Backup support: Managed disks can be automatically backed up to different regions for disaster recovery with Azure Backup all without affecting the service of the VM.
Ultra Disk Comparison
Ultra disk = Disk Type = SSD / Purpose = IO-intensive workloads such as SAP HANA, top tier databases
Max Size = 65,536 gibibyte (GiB)
Premium SSD comparison
Disk Type = SDD / Purpose = Production and performance sensitive work loads / 32,767 GiB
Standard SSD comparison
web servers
32,767 GiB
disk type = ssd
HDD comparison
HDD
32,767 GiB
back ups
Locally redundant storage (LRS)
Azure replicates the data within the same Azure data center. The data remains available if a node fails. However, if an entire data center fails, data may be unavailable
Geo-redundant storage (GRS)
Azure replicates your data to a second region that is hundreds of miles away from the primary region. If your storage account has GRS enabled, then your data is durable even if there’s a complete regional outage or a disaster in which the primary region isn’t recoverable
Read-access geo-redundant storage (RA-GRS)
Azure provides read-only access to the data in the secondary location, and geo-replication across two regions. If a data center fails, the data remains readable but can’t be modified
Zone-redundant storage (ZRS)
Azure replicates your data synchronously across three storage clusters in a single region. Each storage cluster is physically separated from the others and resides in its own availability zone (AZ). With this type of replication, you can still access and manage your data in the event that a zone becomes unavailable
Geo-zone-redundant storage
Azure replicates your data synchronously across three availability zones in one region. Data is also replicated three times to another secondary region that’s paired with it.
Read-access geo-zone-redundant storage
Read-access geo-zone-redundant storage (RA-GZRS) - Azure provides read-only access to the data in the secondary location. Geo-replication is across three availability zones in two region. If a data center fails, the data remains readable but can’t be modified
Operations on VHDs
Cannot be performed with the VM running. The first step is to stop and deallocate the VM with az vm deallocate, supplying the VM name and resource group name.
Deallocating a VM, unlike just stopping a VM, releases the associated computing resources and allows Azure to make configuration changes to the virtualized hardware.
DEALLOCATED A VM
az vm deallocate \
- -resource-group \
- -name
UPDATE A DISK SIZE
az disk update \
- -resource-group \
- -name \
- -size-gb 200
Storage Service Encryption (SSE)
Storage Service Encryption is performed on the physical disks in the data center. If someone were to directly access the physical disk the data would be encrypted. When the data is accessed from the disk, it is decrypted and loaded into memory
Azure Disk Encryption (ADE)
Azure Disk Encryption encrypts the virtual machine’s virtual hard disks (VHDs). If VHD is protected with ADE, the disk image will only be accessible by the virtual machine that owns the disk
Storage Service Encryption (SSE) / 2
Azure Storage Service Encryption (SSE) is an encryption service built into Azure used to protect data at rest. The Azure storage platform automatically encrypts data before it’s stored to several storage services, including Azure Managed Disks. Encryption is enabled by default using 256-bit AES encryption, and is managed by the storage account administrator.
Azure Disk Encryption (ADE) /2
Azure Disk Encryption (ADE) is managed by the VM owner. It controls the encryption of Windows and Linux VM-controlled disks, using BitLocker on Windows VMs and DM-Crypt on Linux VMs. BitLocker Drive Encryption is a data protection feature that integrates with the operating system, and addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned computers. Similarly, DM-Crypt encrypts data at rest for Linux before writing to storage
and ADE is required for VMs backed up to the Recovery Vault
With ADE, VMs boot under customer-controlled keys and policies. ADE is integrated with Azure Key Vault for the management of these disk-encryption keys and secrets
data at rest
(saved to a storage device)
Azure Disk Encryption prerequisites
Before you can encrypt your VM disks, you need to:
Create a key vault.
Set the key vault access policy to support disk encryption.
Use the key vault to store the encryption keys for ADE.
Azure Key Vault
Azure Key Vault is a tool for securely storing and accessing secrets. A secret is anything that you want to tightly control access to, such as API keys, passwords, or certificates. This provides highly available and scalable secure storage, as defined in Federal Information Processing Standards (FIPS) 140-2 Level 2 validated Hardware Security Modules (HSMs). Using Key Vault, you keep full control of the keys used to encrypt your data, and you can manage and audit your key usage
Azure Disk Encryption requires that your key vault and your VMs are in the same Azure region; this ensures that encryption secrets do not cross regional boundaries
powershell and cli commands to manage keyvault
New-AzKeyVault -Location `
- ResourceGroupName ` - VaultName "myKeyVault" ` - EnabledForDiskEncryption
az keyvault create \
- -name "myKeyVault" \ - -resource-group \ - -location \ - -enabled-for-disk-encryption True
Enable access policies in the key vault
There are three policies you can enable.
Disk encryption - Required for Azure Disk encryption.
Deployment - (Optional) Enables the Microsoft.Compute resource provider to retrieve secrets from this key vault when this key vault is referenced in resource creation, for example when creating a VM.
Template deployment - (Optional) Enables Azure Resource Manager to get secrets from this key vault when this key vault is referenced in a template deployment
Encrypt an existing VM disk
Before you can turn on encryption, you must take a snapshot or a backup of managed disks. The following SkipVmBackup flag tells the tool that the backup is complete on managed disks. Without the backup, you will be unable to recover the VM if the encryption fails for some reason
What are Azure Resource Manager templates?
Resource Manager templates are JSON files used to define a set of resources to deploy to Azure. You can write them from scratch, and for some Azure resources, including VMs, you can use the Azure portal to generate them. You’ll need to complete the required information for a manual VM deployment, but instead of deploying the VM to Azure, you save the template. You can then reuse the template to create that specific VM configuration
Update Management overview
The Update Management solution allows you to manage and install operating system updates and patches for both Windows and Linux virtual machines that are deployed in Azure, on-premises, or even in other cloud providers. You can assess the status of available updates on computers and manage the process of installing required updates for servers
There are several advantages to the Update Management solution:
There are no agents or additional configuration within the virtual machine.
You can run updates without logging into the VM. You also don’t have to create passwords to install the update.
The Update Management solution lists missing updates and provides information about failed deployments in an easy-to-read format
Components Used by Update Management
The following configurations are used to perform assessment and update deployments:
Microsoft Monitoring Agent (MMA) for Windows or Linux.
PowerShell Desired State Configuration (DSC) for Linux.
Automation Hybrid Runbook Worker.
Microsoft Update or Windows Server Update Services (WSUS) for Windows computers
Hybrid Worker Groups
Windows computers that are directly connected to your Log Analytics workspace are automatically configured as a Hybrid Runbook Worker to support the runbooks that are included in this solution. Each Windows computer that’s managed by the solution shows up as a system hybrid worker group for the Automation account. The solutions use the naming convention Hostname FQDN_GUID
Operations Manager Management Packs
If your System Center Operations Manager management group is connected to a Log Analytics workspace, the following management packs are installed in Operations Manager. These management packs are also installed on directly connected Windows computers after you add the solution. You don’t need to configure or manage these management packs.
Microsoft System Center Advisor Update Assessment Intelligence Pack
Microsoft.IntelligencePack.UpdateAssessment.Configuration
Update Deployment MP
Compliance scan
Update Management will perform a scan for update compliance. A compliance scan is by default, performed every 12 hours on a Windows computer and every 3 hours on a Linux computer. In addition to the scan schedule, a compliance scan is initiated within 15 minutes if the MMA is restarted, before update installation, and after update installation. After a computer performs a scan for update compliance, the agent forwards the information in bulk to Azure Log Analytics.
It can take between 30 minutes and 6 hours for the dashboard to display updated data from managed computers
What’s Azure Resource Manager?
Azure Resource Manager is the interface for managing and organizing cloud resources. Think of Resource Manager as a way to deploy cloud resources
If you’re familiar with Azure resource groups, you know that they enable you to treat sets of related resources as a single unit. Resource Manager is what organizes the resource groups that let you deploy, manage, and delete all of the resources together in a single action
What are Resource Manager templates?
A Resource Manager template precisely defines all the Resource Manager resources in a deployment. You can deploy a Resource Manager template into a resource group as a single operation
A Resource Manager template is a JSON file, making it a form of declarative automation. Declarative automation means that you define what resources you need but not how to create them. Put another way, you define what you need and it is Resource Manager’s responsibility to ensure that resources are deployed correctly
ARM templates
Resource Manager templates
Why use Resource Manager templates?
Templates improve consistency
Templates help express complex deployments
Templates reduce manual, error-prone tasks
Templates are code
Templates promote reuse
Templates are linkable
What’s in a Resource Manager template?
{ "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#", "contentVersion": "", "parameters": { }, "variables": { }, "functions": [ ], "resources": [ ], "outputs": { } }
What are Azure Quickstart templates?
Azure Quickstart templates are Resource Manager templates that are provided by the Azure community. Quickstart templates are available on GitHub
Verifying a template
linter, a tool that verifies that the JSON syntax of your template is correct. You can find JSON linting tools that run on the command line, in a browser, or in your favorite code editor
Verify syntax of template
az deployment group validate
What’s the Custom Script Extension?
The Custom Script Extension is an easy way to download and run scripts on your Azure VMs. It’s just one of the many ways you can configure a VM once it’s up and running.
You can store your scripts in Azure storage or in a public location such as GitHub. You can run scripts manually or as part of a more automated deployment
How do I extend a Resource Manager template?
One way to extend your template is to create multiple templates, each defining one piece of the system. You then link or nest them together to build a more complete system. As you create your own templates, you can build a library of smaller, more granular templates and combine them how you need.
Another way is to modify an existing template to suit your needs. You’ll do that in this module because that’s often the fastest way to get started writing your own templates.
Specify dependent resources
You can’t run the Custom Script Extension until the VM is available. All template resources provide a dependsOn property. This property helps Resource Manager determine the correct order to apply resources.
Here’s what your template resource might look like after you add the dependsOn property
code azuredeploy.json
open json file editor
Compared to physical disks, VHDs have several advantages, including:
High availability: Managed disks are designed for 99.999% availability. Managed disks achieve this by providing you with three replicas of your data, allowing for high durability. If one or even two replicas experience issues, the remaining replicas help ensure persistence of your data and high tolerance against failures
What is a generalized image?
You must reset these items back to a default state before you use the image to create more virtual machines. Otherwise, you might end up with multiple virtual machines that have the same identities. The process of resetting this data is called generalization, and the result is a generalized image
After using sys prep for windows
After the virtual machine has been shut down, you must deallocate it while it’s in this clean state. If you’re using PowerShell, run the following command
Stop-AzVM -ResourceGroupName `
- Name ` - Force
generalize and image with PowerShell and cli
Set-AzVM -ResourceGroupName `
- Name ` - Generalize
az vm generalize \
–name
snapshot
A snapshot is a read-only copy of a VHD. You can use a snapshot to restore a VHD to the state it was in when the snapshot was taken
What is a virtual machine scale set?
Virtual machine scale sets in Azure are designed to allow you to deploy and manage many load-balanced, identical VMs. These machines run with the same configurations. Virtual machine scale sets are intelligent enough to automatically scale up or down the number of VM instances. A scale set can also change the size of VM instances
pinging health prob
health probe pings the root of the website through port 80
Autoscaling
Autoscaling is based on a set of scale conditions, rules, and limits. A scale condition combines time and a set of scale rules. If the current time falls within the period defined in the scale condition, the condition’s scale rules are evaluated
scale in scale out
A scale-out action increases the number of instances. A scale-in action reduces the instance count
What is an Azure custom script extension?
An Azure custom script extension downloads and runs a script on an Azure VM. It can automate the same tasks on all the VMs in a scale set
What is Azure Automation State Configuration?
Azure Automation State Configuration is an Azure service built on PowerShell. It allows you to consistently deploy, reliably monitor, and automatically update the desired state of all your resources. Azure Automation provides tools to define configurations and apply them to real and virtual machines
What is PowerShell DSC?
PowerShell DSC is a declarative management platform that Azure Automation State Configuration uses to configure, deploy, and control systems. A declarative programming language separates intent (what you want to do) from execution (how do you want to do it). You specify the desired state and let DSC do the work to get there. You don’t have to know how to implement or deploy a feature when a DSC resource is available. Instead, you focus on the structure of your deploymen
What is the LCM?
The local configuration manager (LCM) is a component of the Windows Management Framework (WMF) that’s on a Windows operating system. The LCM is responsible for updating the state of a node, like a VM, to match the desired state. Every time the LCM runs, it completes the following steps:
Get: Get the current state of the node.
Test: Compare the current state of a node against the desired state by using a compiled DSC script (.mof file).
Set: Update the node to match the desired state described in the .mof file.
Push and pull architectures in DSC
Push mode: An administrator manually sends, or pushes, the configurations toward one or more nodes. The LCM makes sure that the state on each node matches what the configuration specifies.
pull mode
A pull server holds the configuration information. The LCM on each node polls the pull server at regular intervals, by default every 15 minutes, to get the latest configuration details. These requests are denoted as step 1 in the following diagram. In step 2, the pull server sends the details about any configuration changes back to each node.
What is Container Registry?
Container Registry is an Azure service that you can use to create your own private Docker registries. Like Docker Hub, Container Registry is organized around repositories that contain one or more images. Container Registry also lets you automate tasks such as redeploying an app when an image is rebuilt.
Security is an important reason to choose Container Registry instead of Docker Hub
You have much more control over who can see and use your images.
You can sign images to increase trust and reduce the chances of an image becoming accidentally (or intentionally) corrupted or otherwise infected.
All images stored in a container registry are encrypted at rest
What is a webhook?
Azure App Service supports continuous deployment using webhooks. A webhook is a service offered by Azure Container Registry. Services and applications can subscribe to the webhook to receive notifications about updates to images in the registry. A web app that uses App Service can subscribe to an Azure Container Registry webhook to receive notifications about updates to the image that contains the web app. When the image is updated, and App Service receives a notification, your app automatically restarts the site and pulls the latest version of the image
What is the Container Registry tasks feature?
You use the tasks feature of Container Registry to rebuild your image whenever its source code changes automatically. You configure a Container Registry task to monitor the GitHub repository that contains your code and trigger a build each time it changes. If the build finishes successfully, Container Registry can store the image in the repository. If your web app is set up for continuous integration in App Service, it receives a notification via the webhook and updates the app.
Enable continuous integration from App Service
The Container settings page of an App Service resource in the Azure portal automates the setup of continuous integration. If you turn on Continuous Deployment, App Service configures a webhook in your container registry to notify an App Service endpoint. Notifications from the registry that reach this endpoint cause your app to restart and pull the latest version of the container image
Extend continuous integration to source control by using a Container Registry task
az acr task create –registry –name buildwebapp –image webimage –context https://github.com/MicrosoftDocs/mslearn-deploy-run-container-app-service.git –branch master –file Dockerfile –git-access-token
App Service plans and scalability
The Free tier provides 1 GB of disk space and support for up to 10 apps, but only a single shared instance and no SLA for availability. Each app has a compute quota of 60 minutes per day. The Free service plan is mainly suitable for app development and testing rather than production deployments.
The Shared tier provides support for more apps (up to 100) also running on a single shared instance. Apps have a compute quota of 240 minutes per day. There is no availability SLA.
The Basic tier supports an unlimited number of apps and provides more disk space. Apps can be scaled out to three dedicated instances. This tier provides an SLA of 99.95% availability. There are three levels in this tier that offer varying amounts of computing power, memory, and disk storage.
The Standard tier also supports an unlimited number of apps. This tier can scale to 10 dedicated instances and has an availability SLA of 99.95%. Like the Basic tier, this tier has three levels that offer an increasingly powerful set of computing, memory, and disk options.
The Premium tier gives you up to 20 dedicated instances, an availability SLA of 99.95%, and multiple levels of hardware.
The Isolated tier runs in a dedicated Azure virtual network, which gives you a network and computes isolation. This tier can scale out to 100 instances and has an availability SLA of 99.95%.
Working with images in Container Registry is like working with Docker Hub, but offers a few unique benefits
Container Registry runs in Azure. The registry can be replicated to store images near where they’re likely to be deployed.
Container Registry is highly scalable, providing enhanced throughput for Docker pulls that can span many nodes concurrently. The Premium SKU of Container Registry includes 500 GiB of storage.
When you create a web app from a Docker image, you configure the following properties:
When you create a web app from a Docker image, you configure the following properties:
The registry that contains the image. The registry can be Docker Hub, Azure Container Registry, or some other private registry.
The image. This item is the name of the repository.
The tag. This item indicates which version of the image to use from the repository. By convention, the most recent version is given the tag latest when it’s built.
Startup File. This item is the name of an executable file or a command to be run when the image is loaded. It’s equivalent to the command that you can supply to Docker when running an image from the command line by using docker run. If you’re deploying a ready-to-run, containerized app that already has the ENTRYPOINT and/or COMMAND values configured, you don’t need to fill this in
Why use Azure Container Instances?
Azure Container Instances is useful for scenarios that can operate in isolated containers, including simple applications, task automation, and build jobs. Here are some of the benefits:
Fast startup: Launch containers in seconds.
Per second billing: Incur costs only while the container is running.
Hypervisor-level security: Isolate your application as completely as it would be in a VM.
Custom sizes: Specify exact values for CPU cores and memory.
Persistent storage: Mount Azure Files shares directly to a container to retrieve and persist state.
Linux and Windows: Schedule both Windows and Linux containers using the same API
What are container restart policies?
Always Containers in the container group are always restarted. This policy makes sense for long-running tasks such as a web server. This is the default setting applied when no restart policy is specified at container creation.
Never Containers in the container group are never restarted. The containers run one time only.
OnFailure Containers in the container group are restarted only when the process executed in the container fails (when it terminates with a nonzero exit code). The containers are run at least once. This policy works well for con
What is a container ?
A container is an atomic unit of software that packages up code, dependencies, and configuration for a specific application. Containers allow us to split up monolithic applications into individual services that make up the solution. This rearchitecting of our application will enable us to deploy these separate services via containers.
he container concept gives us three major benefits:
A container is immutable - the unchanging nature of a container allows it to be deployed and run reliably with the same behavior from one compute environment to another. A container image tested in a QA environment is the same container image deployed to production.
A container is lightweight - you can think of a container as a VM image, but smaller. A VM image is normally installed on a physical host. The image contains both the OS and the application you want to run. In contrast, a container doesn’t need an OS, only the application. The container always relies on the host installed OS for Kernel-specific services. Containers are less resource-intensive, and multiple containers can be installed on the same compute environment.
Container startup is fast - containers can start up in few seconds instead of minutes, like a VM.
What is Azure Kubernetes Service?
Kubernetes is a portable, extensible open-source platform for automating deployment, scaling, and the management of containerized workloads. Kubernetes abstracts away complex container management and provides us with declarative configuration to orchestrate containers in different compute environments. This orchestration platform gives us the same ease of use and flexibility as with Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) offerings
What is Azure Kubernetes Service?
Azure Kubernetes Service (AKS) manages your hosted Kubernetes environment and makes it simple to deploy and manage containerized applications in Azure. Your AKS environment is enabled with features such as automated updates, self-healing, and easy scaling. The Kubernetes cluster master is managed by Azure and is free. You manage the agent nodes in the cluster and only pay for the VMs on which your nodes run
Connect services by using virtual network peering
The traffic uses only private IP addresses. It doesn’t rely on internet connectivity, gateways, or encrypted connections. The traffic is always private, and it takes advantage of the high bandwidth and low latency of the Azure backbone network
two types of peering connections
Virtual network peering connects virtual networks in the same Azure region, such as two virtual networks in North Europe.
Global virtual network peering connects virtual networks that are in different Azure regions, such as a virtual network in North Europe and a virtual network in West Europe
Reciprocal connections
When you create a virtual network peering connection in only one virtual network to connect to a peer in another network, you’re not connecting the networks together. To connect the networks by using virtual network peering, you have to create connections in each virtual network
Cross-subscription virtual network peering
You can use virtual network peering even when both virtual networks are in different subscriptions. This might be necessary for mergers and acquisitions or to connect virtual networks in subscriptions that different departments manage