App Service Plans

Auto-scaling offers us an option to support the high demand for our application. We can manually scale resources or set custom policies that automatically scale our App Service based on metric thresholds.

Creating App Service

For this resource, too, we will first show how to create it via Azure Portal and then automate the same process differently.

Azure Portal

As mentioned many times, Azure Portal is the most popular management tool among the IT population, but we have to choose each option manually. When we choose to create a new resource and search for an App Service plan, we will need to populate few basic parameters – Resource Group where App Service will be deployed, Name, Operating System, Region, and Tier (Figure 5-2).

We can then review and create our resource.

Creating a Web App

We will now go through the process of creating a base web app with Microsoft’s demo template within. Later, we will learn how we can change it and deploy our own.

Azure Portal

As always, we would search through the “Create a resource” option for “web app.” When we choose to create it, we will need to populate multiple parameters. We need to provide the resource group name, name for our web app, publishing type, runtime stack, region, and previously created plan (Figure 5-3). We may notice that for the publishing type, we have the option to choose Docker Container. That means that we can also deploy Docker images to an App Service plan, which we will cover later in this chapter.

In the next step, we can enable Application Insights (an Azure service that provides us with the ability to monitor other services and applications – we will cover this in this chapter too), but we will skip this. Finally, we just need to review our choices and create a web app. After the app is created, we will be able to visit the page (name of the web app) to confirm that all went well for now. We should get the demo template as in Figure 5-4.

Publishing a Web Application

Now that we have successfully deployed our web app, it is time to work on deploying our code into it. As always, we have multiple choices to do that.

Deploying via FTP

Within our web app, there is a Deployment menu. There, we can choose Deployment Center and FTP as one of many (Figure 5-5).

This will give us the necessary parameter information for the deployment – FTPS Endpoint, Username, and Password.

Deploying from Local Git

If we want to leverage this, we need to have the repository cloned locally. Initiate the following command to test:

# Cloning template repository

git clone https://github.com/Azure-Samples/app-service-web-html-get-started

# Configuring a deployment user

az webapp deployment user set --user-name 'apress' --password 'V3ryStr0ngPa55!'

# Get the deployment URL

$url = az webapp deployment source config-local-git --name apress --resource-group apress-ch05-rg

$url

# Deploy the Web App

git remote add azure "https://[email protected]/apress.git"

git push azure

# You will be asked to enter the password you created for the deployment user

The result should look similar to the one in Figure 5-6.

CI/CD with Web Apps

Within this part of the chapter, we will go through the process of creating an organization in Azure DevOps. Then we will connect it with our Azure subscription and start building the first CI/CD pipelines for our application. When we visit the page dev.azure.com, we will be taken to the home page of Azure DevOps. There, we need to log in with a Microsoft account.

We will then be asked to create an organization under which we will create our projects later on. When we create an organization, we can then create multiple projects under it. Inside the projects, we will have our repositories, CI/CD pipelines, and others.

To use Azure DevOps, we need to connect it to our Azure subscription. Under Organization Settings, we need to choose Azure Active Directory and Connect directory (Figure 5-8).

The easiest way to proceed after connecting Azure DevOps and the subscription is to go back to our previously deployed App Service and choose Deployment Center ➤ Azure Repos.

In the next step, choose Azure Pipelines and continue. Then we will need to choose from the dropdown menus the organization we created, project, repository, branch, and framework used for the application (Figure 5-10).

Ending this process will create all needed CI/CD pipelines within the Azure DevOps project. We can now switch to our Azure DevOps project and continue working on our code. Each new push to the repository will trigger a new build. A successful build will then trigger release. That easy. Furthermore, we now have an automated CI/CD process for our application.

Blue-Green Deployment

With the Standard S1 App Service plan comes one more great functionality – staging slots. When we create App Service, by default, it has one deployment slot named Production (Figure 5-11).

We can easily add additional slots for our environments (Dev, Test, QA). Besides giving it a name, we can choose to clone the current state from the Production slot.

Now we can set up multiple stages within our release pipeline that would target different slots of App Service. When we are done testing new features or any kind of change, we can easily, with just one click, swap the slots (Figure 5-12). That way, the one that was Production would become a Development one.

If, by any chance, we notice that there is a problem with the new code, we can always make an additional swap reverting to the previous state. All this is done with minimal downtime. One more thing we can use before swapping is traffic percentage – this gives us the option to send a specific % of traffic to the Development slot and track further how the new code is working with the load of the Production one.

Auto-scaling with Web Apps

Auto-scaling can be achieved based on the scale-out scenario (Figure 5-13). The first App Service plan that allows us to use auto-scaling as a feature is Standard S1.

To use this feature in an automated way, we need to create rules that will trigger both the increase and decrease in the number of instances (scale-out or scale-in), as shown in Figure 5-14.

Rules are created based on the specific metrics that are available for App Service like

• CPU percentage

• Memory percentage

• Data in or out

• Disk or HTTP queue length

It is also essential to set the minimum and the maximum number of instances. That could save us from potential money loss in case of an unpredictable scale-out.

Web Apps Monitoring

There are multiple options for monitoring App Service:

• Alerts: It is possible to create alert rules that will trigger a specific action (Figure 5-15). For example, we can monitor the number of connections, and if it goes beyond a specific value, the Send email action will be triggered.

• Metrics: This is live monitoring of the different App Service metrics. They can also be added to the dashboard for teams monitoring apps in real time.

• Logs: They are powered by Azure Log Analytics. To use them, we need to set a few more things so that our App Service sends data to the Log Analytics workspace (LAW).

• Diagnostic settings: This is where we set all the available logs to be sent to LAW (Figure 5-16).

After we have set diagnostic settings and our App Service started sending data to the Log Analytics workspace, we can start using logs and the Microsoft Kusto query language to read needed data. Many predefined queries can help us in the beginning.

Azure Container Registry (ACR)

Azure Container Registry is a service that provides us with the ability to build, store, and manage container images in a private Docker registry. It is used as a repository for our container images to be pulled to various targets like Azure Kubernetes Service, Docker Swarm, App Service, and others.

Since it is based on the open source Docker Registry 2.0, we can use standard Docker commands against it. We will later show when and how to do that.

Creating Azure Container Registry

Before we explain the usage of ACR, let us see how to create it in already known ways.

Azure Portal

In the search bar after clicking “Create a resource,” we need to search for “container registry.” The options we need to populate are straightforward and consist of resource group, name for the registry, location, and SKU (taking the higher SKU gives us more performance and scale).

Since we have chosen to go with Standard SKU, Private Endpoint and Encryption are not available (need Premium for both). We can now review and create our resource.

ARM Template, PowerShell, and Azure CLI

Since the deployment code could be pretty big, all ARM template, Azure PowerShell, and Azure CLI scripts are stored in the Apress GitHub account, available at the following URL:

https://github.com/Apress/pro-azure-admin-and-automation

Now when we have our Container Registry prepared, we can, with few more prerequisites, upload our first image. First, we need to enable admin user access (Figure 5-18), which is vital for interaction with ACR if we cannot leverage RBAC.

Now we can, using PowerShell, log in to the registry. We also need to have Docker installed locally (can be obtained from this link if you do not have it – https://hub.docker.com/editions/community/docker-ce-desktop-windows/):

# Login procedure for Azure Container Registry

$registry    = Get-AzContainerRegistry -Name apress -ResourceGroupName apress-ch05-rg

$credentials = Get-AzContainerRegistryCredential -Registry $registry

$credentials.Password | docker login $registry.LoginServer -u $credentials.Username --password-stdin

The next step would be to push the image to the registry and run it from there:

# Pull the image from the official Docker registry

docker pull hello-world

# Tag the image

docker tag hello-world apress.azurecr.io/hello-world:v1

# Push image to the registry

docker push apress.azurecr.io/hello-world:v1

# Local cleanup

docker rmi apress.azurecr.io/hello-world:v1

# Run from registry

docker run apress.azurecr.io/hello-world:v1

      The output of previous commands should look like this:

PS C:drscoding> docker pull hello-world

Using default tag: latest

latest: Pulling from library/hello-world

0e03bdcc26d7: Pull complete

Digest: sha256:31b9c7d48790f0d8c50ab433d9c3b7e17666d6993084c002c2ff1ca09b96391d

Status: Downloaded newer image for hello-world:latest

docker.io/library/hello-world:latest

PS C:drscoding> docker tag hello-world apress.azurecr.io/hello-world:v1

PS C:drscoding> docker push apress.azurecr.io/hello-world:v1

The push refers to repository [apress.azurecr.io/hello-world]

9c27e219663c: Pushed

v1: digest: sha256:90659bf80b44ce6be8234e6ff90a1ac34acbeb826903b02cfa0da11c82cbc042 size: 525

PS C:drscoding> docker rmi apress.azurecr.io/hello-world:v1

Untagged: apress.azurecr.io/hello-world:v1

Untagged: apress.azurecr.io/hello-world@sha256:90659bf80b44ce6be8234e6ff90a1ac34acbeb826903b02cfa0da11c82cbc042

PS C:drscoding> docker run apress.azurecr.io/hello-world:v1

Unable to find image 'apress.azurecr.io/hello-world:v1' locally

v1: Pulling from hello-world

Digest: sha256:90659bf80b44ce6be8234e6ff90a1ac34acbeb826903b02cfa0da11c82cbc042

Status: Downloaded newer image for apress.azurecr.io/hello-world:v1

Hello from Docker!

This message shows that your installation appears to be working correctly.

Azure Container Instances

Azure Container Instances is a service that provides us with the fastest way to run a container in Azure. It is the best solution for isolated containers. With Azure Container Instances, we avoid provisioning and managing VMs or App Service as host for our containers. During the creation of the Container Instance, we can specify a DNS name for our application and make it reachable over the Internet.

ACI offers exact specifications of CPU and memory, and we are billed by the second of our application uptime. It offers connectivity via an Azure virtual network. That means that it can communicate securely with other resources within the VNet or through peering.

Creating Azure Container Instances

With the already known options, we will see how easy and quickly it is to create an Azure Container Instance and be live with the containerized application.

Azure Portal

After choosing Create a resource, we should search for “container instances.” We need to provide a resource group for deployment, name, region, and – the most crucial parameter – image source (Figure 5-19).

An image source could be chosen from

• QuickStart images: Provided by Microsoft

• Azure Container Registry: If we have built one of our own

• Docker Hub or other registries

For this deployment, we will choose a QuickStart image:

• “mcr.microsoft.com/azuredocs/aci-helloworld:latest”

After successful deployment, we should be able to open the FQDN assigned to the instance.

Azure Kubernetes Service

Azure Kubernetes Service is a Microsoft offering for deploying a managed Kubernetes cluster. Since it is a hosted service, Microsoft is responsible for health monitoring, maintenance, and managing the masters. AKS offers us a full container orchestration, service discovery across containers, automatic scaling, and coordinated application upgrades.

From a security perspective, AKS is protected by Kubernetes role-based access control. With RBAC, we can manage who can access resources and namespaces and with which level of access. It can also be integrated with Azure AD.

For already more than two years, Azure Kubernetes Service can be monitored by Azure Monitor. This way, we can monitor the health and performance of the clusters. AKS nodes are based on Azure virtual machines, which means that they can be upgraded and scaled on the same basis. As it supports deployment into a virtual network, pods in a cluster can communicate with each other through peering with other Azure resources or through ExpressRoute with on-premises resources.

Creating Azure Kubernetes Cluster