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

## Ansible playbooks

Automating tasks in Ansible requires a set of instructions or “plays.” You must provide Ansible with instructions on what actions to perform on the resources it manages. You do that with *[playbooks](https://docs.ansible.com/ansible/latest/user_guide/playbooks.html)*. A playbook is a list of tasks that run in order from top to bottom.

Think of a playbook as a sports coach's playbook. A coach has a list of *plays* that they recommend their team take to win the game. Ansible intends to "win the game" with its sets of plays in its playbook to create or modify resources.

Each "play" in a playbook is called a **task**. Each task is a specific action Ansible takes on the resource it's controlling. For example, a task could be creating an Azure storage account, changing the password on a user account, creating a Docker container, or any other number of actions. Think of a task similar to a programming language function; it does one “thing.”

Each playbook starts off with the `PLAY` keyword. The `PLAY` keyword specifies on what resource the code will run. This resource could be the Ansible server itself or on a target server it's managing.

The second keyword is `TASK` where you see `[Gathering Facts]`. Gathering facts is Ansible retrieving metadata about the system. Facts are used if a playbook needs any kind of metadata about a target resource. For example, if Ansible was changing the size of a virtual machine in Azure, it would need to know the existing size prior to knowing if the size requested is the same, bigger, or smaller. The `TASK` tells you what action Ansible took. 

The final section of a playbook is the `PLAY RECAP`. The `PLAY RECAP` provides the playbook activity history of a particular run. There are five statuses in the recap.

- `ok`: Below, you'll see `ok=2`. This means that two tasks checked the state of the resource and found no changes needed to be made.
- `changed`: You'll also see below `changed=1`. The `changed` attribute increments if any task in the playbook made a change on the target resource.
- `unreachable`: This status will increment for each resource it was unable to connect to.
- `failed`: This status increments when Ansible is unable to perform the specified action from the playbook on the target server.
- `skipped`: This status increments if a particular task in the playbook is set to skip. There is a great explanation on StackOverflow, which you can find [here](https://devops.stackexchange.com/questions/4823/how-to-skip-play-in-ansible-playbook).
- `rescued`:  This status is similar to error handling. You can have an output stating that an error occurred and perhaps where/how it can be fixed.

# Ansible playbooks

Automating tasks in Ansible requires a set of instructions or “plays.” You must provide Ansible with instructions on what actions to perform on the resources it manages. You do that with *[playbooks](https://docs.ansible.com/ansible/latest/user_guide/playbooks.html)*. A playbook is a list of tasks that run in order from top to bottom.

Think of a playbook as a sports coach's playbook. A coach has a list of *plays* that they recommend their team take to win the game. Ansible intends to "win the game" with its sets of plays in its playbook to create or modify resources.

Each "play" in a playbook is called a **task**. Each task is a specific action Ansible takes on the resource it's controlling. For example, a task could be creating an Azure storage account, changing the password on a user account, creating a Docker container, or any other number of actions. Think of a task similar to a programming language function; it does one “thing.”

Each playbook starts off with the `PLAY` keyword. The `PLAY` keyword specifies on what resource the code will run. This resource could be the Ansible server itself or on a target server it's managing.

The second keyword is `TASK` where you see `[Gathering Facts]`. Gathering facts is Ansible retrieving metadata about the system. Facts are used if a playbook needs any kind of metadata about a target resource. For example, if Ansible was changing the size of a virtual machine in Azure, it would need to know the existing size prior to knowing if the size requested is the same, bigger, or smaller. The `TASK` tells you what action Ansible took. 

The final section of a playbook is the `PLAY RECAP`. The `PLAY RECAP` provides the playbook activity history of a particular run. There are five statuses in the recap.

- `ok`: Below, you'll see `ok=2`. This means that two tasks checked the state of the resource and found no changes needed to be made.
- `changed`: You'll also see below `changed=1`. The `changed` attribute increments if any task in the playbook made a change on the target resource.
- `unreachable`: This status will increment for each resource it was unable to connect to.
- `failed`: This status increments when Ansible is unable to perform the specified action from the playbook on the target server.
- `skipped`: This status increments if a particular task in the playbook is set to skip. There is a great explanation on StackOverflow, which you can find [here](https://devops.stackexchange.com/questions/4823/how-to-skip-play-in-ansible-playbook).
- `rescued`:  This status is similar to error handling. You can have an output stating that an error occurred and perhaps where/how it can be fixed.

Learn about the Ansible Playbooks in this lesson. 

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

Playbooks

Ansible playbooks