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

## Pods 

At the end of the day, we don't care about containers or Kubernetes. We care about the application(s) the clusters are serving to our users. Many applications require more than one container, different storage, networking configurations, and so on. To manage applications more efficiently, Kubernetes has **Pods**.

Each Pod typically only runs a single instance of an application but isn't required.

> *Although allowed, running multiple applications in a single Pod is frowned upon. A Pod containing one container is like an everyday server cluster containing a single node. There’s no point because you are defeating the purpose of the cluster, which is to provide redundancy. Always follow the industry one-application-per-Pod norm.*

You can define a Pod via a manifest as you can see below. You can tell this is a Pod manifest by the `kind` attribute chosen. When you deploy the manifest below, K8S will create a Pod running one Nginx container.

```YAML
metadata:

spec:
  containers:
    ports:
```

You'll find that Pods alone are typically used for development and testing purposes primarily because they have no self-healing capabilities by themselves. To ensure applications maintain redundancy and automatic remediation, you should ensure Pods are replicated.

Pod replication is more than one pod running the same exact application. For example, if you had two `replicas` of the `nginx-pod`, that means you would have two Pods running the same exact configuration of Nginx.
> For more information on replication, check out a [brief overview](https://coreos.com/kubernetes/docs/latest/replication-controller.html) of replication.

## Deployments

Kubernetes is a container orchestration platform but doesn’t necessarily have to orchestrate containers directly. Once you start grouping containers in Pods, those Pods need to be orchestrated too! You need deployments. Deployments orchestrate Pods or, more specifically, allow admins to define the desired state of Pods to ensure they stay that way.

A Deployment provides declarative updates to Pods and [*Replica sets*](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/). In this chapter, we’re only going to focus on how deployments and Pods interact.

You must have a way to define the desired state of Pods within a deployment so each deployment contains a manifest. Just like the Pod defined in the manifest above, deployments can have manifests too by specifying a `kind` attribute of `Deployment`.

Kubernetes uses deployments to keep Pods in their desired state to self-heal and to automatically scale up or down Pods and containers if need be.

```YAML
metadata:

spec:
  selector:
    matchLabels:


  template:
    metadata:
      labels:

    spec:
      containers:

        ports:
```


Recall that deployments control Pods (that's more than one). The `replicas` attribute defines how many Pods that deployment will create and manage; in this case, it's `2`. When this deployment runs, it will create two identical Pods (replicas).

Deployments have many advantages like managing Pod replicas for redundancy, but they also inherently have self-healing capabilities. Kubernetes Deployments provide self-healing for all Pods and the containers inside of the Pods.

For example, perhaps you have an Nginx web server running in a container and the Nginx service stops. A Kubernetes Deployment can auto-detect the application that has stopped and automatically create a new container with the running Nginx web server. Kubernetes has self-healing capabilities like this built-in with no configuration needed.

> *With the Kubernetes default networking comes Kubernetes DNS. Out-of-the-box Kubernetes that are networking comes baked with CoreDNS, a popular open-source DNS platform. CoreDNS runs as a Pod inside of the Kubernetes cluster and manages all DNS settings so you don’t have to.*

# Pods 

At the end of the day, we don't care about containers or Kubernetes. We care about the application(s) the clusters are serving to our users. Many applications require more than one container, different storage, networking configurations, and so on. To manage applications more efficiently, Kubernetes has **Pods**.

Each Pod typically only runs a single instance of an application but isn't required.

> *Although allowed, running multiple applications in a single Pod is frowned upon. A Pod containing one container is like an everyday server cluster containing a single node. There’s no point because you are defeating the purpose of the cluster, which is to provide redundancy. Always follow the industry one-application-per-Pod norm.*

You can define a Pod via a manifest as you can see below. You can tell this is a Pod manifest by the `kind` attribute chosen. When you deploy the manifest below, K8S will create a Pod running one Nginx container.

```YAML
metadata:

spec:
  containers:
    ports:
```

You'll find that Pods alone are typically used for development and testing purposes primarily because they have no self-healing capabilities by themselves. To ensure applications maintain redundancy and automatic remediation, you should ensure Pods are replicated.

Pod replication is more than one pod running the same exact application. For example, if you had two `replicas` of the `nginx-pod`, that means you would have two Pods running the same exact configuration of Nginx.
> For more information on replication, check out a [brief overview](https://coreos.com/kubernetes/docs/latest/replication-controller.html) of replication.

# Deployments

Kubernetes is a container orchestration platform but doesn’t necessarily have to orchestrate containers directly. Once you start grouping containers in Pods, those Pods need to be orchestrated too! You need deployments. Deployments orchestrate Pods or, more specifically, allow admins to define the desired state of Pods to ensure they stay that way.

A Deployment provides declarative updates to Pods and [*Replica sets*](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/). In this chapter, we’re only going to focus on how deployments and Pods interact.

You must have a way to define the desired state of Pods within a deployment so each deployment contains a manifest. Just like the Pod defined in the manifest above, deployments can have manifests too by specifying a `kind` attribute of `Deployment`.

Kubernetes uses deployments to keep Pods in their desired state to self-heal and to automatically scale up or down Pods and containers if need be.

```YAML
metadata:

spec:
  selector:
    matchLabels:


  template:
    metadata:
      labels:

    spec:
      containers:

        ports:
```


Recall that deployments control Pods (that's more than one). The `replicas` attribute defines how many Pods that deployment will create and manage; in this case, it's `2`. When this deployment runs, it will create two identical Pods (replicas).

Deployments have many advantages like managing Pod replicas for redundancy, but they also inherently have self-healing capabilities. Kubernetes Deployments provide self-healing for all Pods and the containers inside of the Pods.

For example, perhaps you have an Nginx web server running in a container and the Nginx service stops. A Kubernetes Deployment can auto-detect the application that has stopped and automatically create a new container with the running Nginx web server. Kubernetes has self-healing capabilities like this built-in with no configuration needed.

> *With the Kubernetes default networking comes Kubernetes DNS. Out-of-the-box Kubernetes that are networking comes baked with CoreDNS, a popular open-source DNS platform. CoreDNS runs as a Pod inside of the Kubernetes cluster and manages all DNS settings so you don’t have to.*

Learn what Pods are and how deployments orchestrate Pods.
