Gain insights into DevOps in Azure, learn configuration management, CI/CD, and Infrastructure as Code. Explore tools as GitHub and Kubernetes through hands-on projects to become a DevOps professional.

admintodevops.tar.gz

Username

Password

AZURE_SUBSCRIPTION_ID

AZURE_CLIENT_ID

AZURE_SECRET

AZURE_TENANT

Git_Email

Git_Name

Azure

Ansible

Chrome

vscode 

Azure-VM

Terraform

az-boards

azure-instances

azure-pipelines

Docker

This course is for anyone in IT or software engineering who wants to learn more about DevOps and, specifically, how to follow DevOps practices in Azure. Whether you’re a system administrator, engineer, developer, or IT manager, this course will help you understand what it takes to deliver more value to customers with DevOps.

You will dive into concepts like configuration management, continuous integration/continuous delivery, and Infrastructure as Code. You will learn the key tools used by DevOps professionals such as: the command line, Visual Studio Code, GitHub, Kubernetes, and more.

You will complete various projects throughout the course where each chapter’s project is designed in a step-by-step manner to walk you through using the tool just as you would in your daily life.

By the time you finish, you will have the foundations in place to become a DevOps professional.

The Complete Guide to DevOps in Azure

## Introduction

Redundancy, high availability (HA), uptime, and service-level agreement (SLA) are all terms referenced around one important concept: application (app) availability. You can build the best application in the world with the fanciest whiz-bang features that can cure cancer, but if that app isn’t available to users, it’s worthless. Apps and the infrastructure they are built upon must stay online and available as much as humanly possible.

One of the most common ways an app can lose a few points off of its 99.999% SLA is infrastructure downtime. Stuff happens; power goes out, rack cabling gets “accidentally” disconnected, a rogue VM goes nuts on a shared hypervisor, and more. If an app is running on a set of VMs, one way to mitigate the risk of app downtime is by spreading the workload apart as far as possible.

You can spread out VM resources in many ways:

- Physical servers in the same rack

- Hypervisors across different racks in the same datacenter
- Different data centers all together

The more eggs you can put in different baskets, the better. Spreading VMs out reduces the risk of one VM going down, affecting too much functionality of an app. When creating VMs in Azure for an app, one way you can mitigate the risk of downtime by physical hardware failure is by spreading VMs across various **fault** and **update domains**. 

## Azure VM fault and update domains

When you build a VM on-prem in a datacenter, that VM is part of a much larger, holistic infrastructure that provides services to users. The VM is only a small component of an organization's overall technology presence.

VM —> Hypervisor —> Physical Server —> Rack —> Datacenter

That single VM relies on the hypervisor to be operational. That hypervisor relies on a physical server to be up and so on. If, say, the power to a data center is cut, all the VMs in that datacenter die because all of the servers in all of the racks die.

Think of a few Azure VMs running on a hypervisor on a server in a rack. Perhaps network connectivity or power to that rack is cut. All VMs in that rack would lose connectivity to the world and services running on those VMs would go dark. When Azure VMs are all dependent on the same source of network connectivity and power, they are in a *fault domain*.

> *Azure defines a fault domain as a logical group of the underlying hardware that shares a common power source and network switch, similar to a rack within an on-premises datacenter.*

Now, consider another way VMs can go down: intentional human  intervention. VMs, unfortunately, need to be patched and rebooted at times. If your app is built in a way to sustain one or more VMs briefly going down, the app users will be none the wiser. If, for example, you have a few database servers and web servers behind a load balancer, it's OK to temporarily lose a database or web server every now and then. Other VMs will pick up the load.

Having multiple VMs perform the same purpose behind a load balancer is an excellent way to maintain app uptime but not if all of that same type of VM are brought down at the same time. If you have three database servers serving up data to a web farm and all three database servers are rebooted at once, you're going to have a problem.

To ensure all VMs of a particular type (database and web, etc.) are not patched or rebooted at the same time, Azure VMs fall under an *update domain*. An update domain is essentially the same as a fault domain but enforces a rule to not *update* or reboot VMs in the same update domain at once.

# Introduction

Redundancy, high availability (HA), uptime, and service-level agreement (SLA) are all terms referenced around one important concept: application (app) availability. You can build the best application in the world with the fanciest whiz-bang features that can cure cancer, but if that app isn’t available to users, it’s worthless. Apps and the infrastructure they are built upon must stay online and available as much as humanly possible.

One of the most common ways an app can lose a few points off of its 99.999% SLA is infrastructure downtime. Stuff happens; power goes out, rack cabling gets “accidentally” disconnected, a rogue VM goes nuts on a shared hypervisor, and more. If an app is running on a set of VMs, one way to mitigate the risk of app downtime is by spreading the workload apart as far as possible.

You can spread out VM resources in many ways:

- Physical servers in the same rack

- Hypervisors across different racks in the same datacenter
- Different data centers all together

The more eggs you can put in different baskets, the better. Spreading VMs out reduces the risk of one VM going down, affecting too much functionality of an app. When creating VMs in Azure for an app, one way you can mitigate the risk of downtime by physical hardware failure is by spreading VMs across various **fault** and **update domains**. 

# Azure VM fault and update domains

When you build a VM on-prem in a datacenter, that VM is part of a much larger, holistic infrastructure that provides services to users. The VM is only a small component of an organization's overall technology presence.

VM —> Hypervisor —> Physical Server —> Rack —> Datacenter

That single VM relies on the hypervisor to be operational. That hypervisor relies on a physical server to be up and so on. If, say, the power to a data center is cut, all the VMs in that datacenter die because all of the servers in all of the racks die.

Think of a few Azure VMs running on a hypervisor on a server in a rack. Perhaps network connectivity or power to that rack is cut. All VMs in that rack would lose connectivity to the world and services running on those VMs would go dark. When Azure VMs are all dependent on the same source of network connectivity and power, they are in a *fault domain*.

> *Azure defines a fault domain as a logical group of the underlying hardware that shares a common power source and network switch, similar to a rack within an on-premises datacenter.*

Now, consider another way VMs can go down: intentional human  intervention. VMs, unfortunately, need to be patched and rebooted at times. If your app is built in a way to sustain one or more VMs briefly going down, the app users will be none the wiser. If, for example, you have a few database servers and web servers behind a load balancer, it's OK to temporarily lose a database or web server every now and then. Other VMs will pick up the load.

Having multiple VMs perform the same purpose behind a load balancer is an excellent way to maintain app uptime but not if all of that same type of VM are brought down at the same time. If you have three database servers serving up data to a web farm and all three database servers are rebooted at once, you're going to have a problem.

To ensure all VMs of a particular type (database and web, etc.) are not patched or rebooted at the same time, Azure VMs fall under an *update domain*. An update domain is essentially the same as a fault domain but enforces a rule to not *update* or reboot VMs in the same update domain at once.

A brief introduction of Azure VM faults and update domains.


Getting Started

Azure from the Command Line with Cloud Shell

Deploy a Flask Application Using Azure CLI

Visual Studio Code

Azure Boards

Git and GitHub

Azure VM Availability Sets

Azure Resource Manager (ARM) Templates

Terraform

Ansible

Azure Load Balancers

Monitoring in Azure

Azure Pipelines

Docker

Kubernetes

Conclusion

Azure VM Fault and Update Domains

Introduction