Containers on Azure Readiness starts here...

Azure Spring Clean - DCK, ACR, ACI, AKS, ACA, the Azure Container Alphabet Soup

Wed, 15 Mar 2023 00:00:00 +0000

Hey friends,

Welcome to #AzureSpringClean, an initiative from Joe Carlyle and Thomas Thornton where I’m honored to be able to participate in again for the 4th year already. Thanks guys for trusting me once more for sharing some Azure knowledge…

This time, I wanted to try and guide you through the buzzword of the last couple of years, containers… and more specifically, what different options you have in Azure to run your containerized workloads.

Containerization has become a popular way to deploy applications in the cloud, offering benefits such as scalability, portability, and reliability. Azure, Microsoft’s cloud platform, offers several services that allow running containerized workloads, each with its own strengths and limitations. In this article, we will explore the different Azure services for container orchestration and management, including Azure Container Instance, Azure Kubernetes Services, Azure App Services, and Azure Container Apps.

The starting point of a containerized workload, is having, or building a Docker container image.

Docker & Docker Desktop

Docker is a popular platform for building, shipping, and running containerized applications. It provides a consistent environment for developers and operators to develop and deploy applications across different platforms and infrastructures. Docker makes it easy to package applications and their dependencies into portable container images, which can be run on any machine that supports Docker.

Docker containers are lightweight, standalone, and executable packages of software that include everything needed to run an application. They contain the application code, runtime, system tools, libraries, and settings, making them highly portable and efficient. Docker containers run in isolation from the host operating system, providing consistent behavior and preventing conflicts with other applications.

Docker Desktop is a desktop application for Windows and macOS that provides a complete development environment for building and testing Docker applications. It includes the Docker Engine, Docker CLI, and a GUI-based interface for managing containers, images, and networks. With Docker Desktop, developers can easily build, test, and run Docker applications on their local machines, without having to set up a separate environment.

Docker Desktop provides a simple and intuitive user interface for managing Docker images and containers. It allows developers to create, edit, and run Docker containers with just a few clicks. Developers can also use Docker Desktop to deploy applications to remote Docker hosts, such as cloud-based container orchestration platforms like Kubernetes.

One of the major benefits of Docker Desktop is its ability to provide a consistent development environment across different platforms and operating systems. It eliminates the need for developers to set up and maintain complex development environments on their own machines, which can be time-consuming and error-prone. Docker Desktop also supports popular programming languages and frameworks, such as Java, Node.js, Python, and Ruby, making it a versatile tool for building modern applications.

Overall, Docker and Docker Desktop provide a powerful platform for building, shipping, and running containerized applications. They simplify the development and deployment of applications, provide a consistent environment across different platforms, and offer a flexible and scalable way to build modern applications. With the continued growth of containerization, Docker and Docker Desktop are essential tools for any developer or operator looking to stay ahead in the rapidly evolving world of software development.

For more information on Docker and Docker Desktop, head over to the Docker Downloads.

If you want a sample container to test your Docker / Docker Desktop, feel free to use my sample e-commerce workload container, which runs a sample .NET6 web app

Now you have your Docker environment ready to use, let’s take the next step, moving the container image into Azure.

Azure Container Registry (ACR) (https://learn.microsoft.com/en-us/azure/container-registry/)

ACR is a managed private registry for storing and managing container images in the cloud. With ACR, you can store and manage Docker images for all of your containerized applications, making it easy to deploy and manage them in the cloud.

The purpose of ACR is to provide a secure and reliable way to store, manage, and deploy container images. By using ACR, you can ensure that your container images are stored securely in the cloud, and that only authorized users have access to them. ACR also provides built-in integration with all other Azure Container Services (see below), making it easy to deploy your container images across the different services.

ACR supports Docker Hub as well as DevOps environments as sources for container images, and it provides a seamless experience for pushing and pulling images from the registry. ACR also supports advanced features, such as geo-replication and image security vulnerability scanning, which allows you to replicate your images to multiple regions for high availability and scan your images for security vulnerabilities (Backed by Defender for Containers and Defender for Cloud).

In summary, ACR serves as a central repository for storing and managing your container images, making it easy to deploy and manage your containerized applications in the cloud. It provides a secure and reliable way to store your images, with built-in integration with other Azure container services for easy deployment.

Some sample Azure CLI code to get you started:

1

az acr create --resource-group myresourcegroup --name myacr --sku Basic

Once you run this command, Azure will create a new ACR with the specified name and SKU in the specified resource group. You can then use the ACR to store and manage your container images.

With the ACR being ready, it’s time to upload (push) the Docker image into the registry. Here are a few steps to get you started:

1
2


az login
az acr login --name myacr

Before you can push a Docker image to the Azure Container Registry, it needs to be updated with the name of the registry. You can use Docker tag command to help with this:

1

docker tag pdetender/eshopwebmvc myacr.azurecr.io/eshopwebmvc

followed by:

1

docker push myacr.azurecr.io/eshopwebmvc

wait for the upload to complete.

Azure Container Instance (ACI) (https://learn.microsoft.com/en-us/azure/container-instances/)

Azure Container Instance (ACI) is a serverless solution for running containers in the cloud. With ACI, you can deploy and manage containers without worrying about the underlying infrastructure. ACI is an excellent choice for running short-lived containerized tasks that don’t require orchestration, such as batch processing, job scheduling, or testing.

ACI is easy to use, as it doesn’t require any knowledge of container orchestration tools such as Kubernetes or Docker Swarm. Instead, you can use the Azure portal, Azure CLI, or Azure PowerShell to deploy and manage your containers.

One of the strengths of ACI is its cost-effectiveness. With ACI, you only pay for the exact amount of compute and memory resources that your containerized tasks require, measured in seconds. This makes ACI an ideal solution for running sporadic, bursty workloads.

However, ACI has some limitations. First, ACI only supports running single containers or multi-container groups, not entire applications. Second, ACI doesn’t provide advanced features such as automatic scaling, self-healing, or load balancing. Finally, ACI has limited networking capabilities, as it doesn’t support virtual networks or custom IP addresses.

with the EshopOnWeb Docker image uploaded to the Azure Container Registry, use the following Az CLI command to deploy an Azure Container Instance:

1

az container create --resource-group myResourceGroup --name aci-springclean-app --image myacr.azurecr.io/eshopwebmvc --cpu 1 --memory 1 --registry-login-server myacr.azurecr.io --ip-address Public --dns-name-label aci-springclean-app --ports 80

Azure Kubernetes Services (AKS) (https://learn.microsoft.com/en-us/azure/aks/intro-kubernetes)

Azure Kubernetes Services (AKS) is a managed Kubernetes service that allows you to deploy and manage containerized applications in the cloud. Kubernetes is a powerful open-source container orchestration tool that automates the deployment, scaling, and management of containerized workloads.

AKS is an excellent choice for running complex, production-grade applications that require orchestration, such as microservices architectures or stateful applications. With AKS, you can take advantage of Kubernetes’ advanced features, such as automatic scaling, self-healing, and rolling updates.

AKS is easy to use, as it abstracts away the complexity of Kubernetes and provides an easy-to-use management interface. With AKS, you can deploy your Kubernetes clusters in minutes, using the Azure portal, Azure CLI, or Azure PowerShell.

One of the strengths of AKS is its scalability. With AKS, you can scale your clusters up or down based on demand, without worrying about the underlying infrastructure. AKS also provides advanced networking capabilities, such as virtual networks, load balancers, and custom IP addresses.

However, AKS has some limitations. First, AKS is more expensive than ACI, as it requires more resources and management overhead. Second, AKS requires some knowledge of Kubernetes, which can be challenging for beginners. Finally, AKS may have some limitations in terms of customization, as it is a managed service that abstracts away some of the lower-level details of Kubernetes.

Here are a few steps to get you started in deploying an AKS cluster:

1
2
3
4
5
6


az aks create \
 --resource-group myResourceGroup \
 --name myAKSCluster \
 --node-count 2 \
 --generate-ssh-keys \
 --attach-acr <acrName>

Deployment should take about 10-15 minutes, depending on the Azure region.

Once the AKS service is up-and-running, you can manage it using kubectl, the Kubernetes Command Line interface.

1

az aks install-cli

Next, connect to the cluster from Kubectl

1

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

From here, you can validate the Kubernetes cluster nodes:

1

kubectl get nodes

1
2
3
4
5


$ kubectl get nodes

NAME STATUS ROLES AGE VERSION
aks-nodepool1-37463671-vmss000000 Ready agent 2m37s v1.18.10
aks-nodepool1-37463671-vmss000001 Ready agent 2m28s v1.18.10

In order to get a containerized application runnig as a pod (=Kubernetes’ terminology for a running container…), you need to create a Kubernetes Manifest file, which uses a YAML syntax format.

There are a lot of options and configuration parameters possible, but below example should get you started: replace the image name pdtacr… with the name of your ACR image

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


apiVersion: apps/v1
kind: Deployment
metadata:
 name: secsample
spec:
 replicas: 3
 selector: 
 matchLabels:
 app: secsample
 template:
 metadata:
 labels:
 app: secsample
 spec:
 containers:
 - name: secsample
 image: pdtacr.azurecr.io/simplcdotnet31:latest
 ports:
 - containerPort: 80
 imagePullSecrets:
 - name: acr-auth


---
apiVersion: v1
kind: Service
metadata:
 name: secsample
spec:
 type: LoadBalancer
 ports:
 - port: 80
 selector:
 app: secsample

This deploys 3 pods (replicas parameter) of the same container, across the 2 nodes in the cluster. The service will get published behind the default Azure Load Balancer, running on port 80. You can verify this later on using the public IP address of the service.

Save the above file to your local machine, for example springcleanaks.yaml

use kubectl to import/inject the YAML configuration into the AKS cluster:

1

kubectl apply -f springcleanaks.yaml

After a few minutes, validate the running service by running the following kubectl command:

1

kubectl get service secsample --watch

If the IP-address mentions “pending”, give it a bit more time to load. Run the above command once more.

The outcome should know show both the internal pod IP, as well as the public IP. Open the browser to connect to the web application.

1

secsample LoadBalancer 10.0.33.125 24.17.23.13 80:30676/TCP 67s

If you want to play with the AKS Autoscaling features, I can recommend the following Microsoft Learn tutorial

Awesome, you are making good progress…

One could think you won’t need anything more than AKS, as it provides better high-availability, scalability as well as several other features, compared to the more standard Azure Container Instance. But you are wrong. While AKS is probably one of the more popular (if not the most popular…) ways to run containerized workloads in Azure, it is sometimes complex, overwhelming, and just “too much” for what you need.

Let’s have a look at 2 more services…

Azure App Services (https://learn.microsoft.com/en-us/training/modules/deploy-run-container-app-service/)

Azure App Service is a platform-as-a-service (PaaS) offering that allows developers to build, deploy, and scale web applications and APIs quickly and easily. With App Service, developers can deploy web apps and APIs written in various programming languages, including .NET, Java, Node.js, Python, and PHP, among others. App Service provides built-in DevOps capabilities and integration with other Azure services, such as Azure SQL Database, Azure Redis Cache, and Azure Storage.

One of the features of Azure App Service is the ability to run Docker containers. Developers can package their application and its dependencies into a Docker image and deploy it to Azure App Service. Azure App Service can then run the Docker image as a container, providing all the benefits of containerization, such as portability, scalability, and isolation.

Some of the benefits of running Docker containers in Azure App Service include:

Easy deployment: With App Service, developers can deploy their Docker containers quickly and easily using various deployment options, such as Git, GitHub, Azure DevOps, or the Azure Portal.
High availability: App Service provides built-in high availability, scaling, and load balancing capabilities, ensuring that containers are always available and responsive to incoming traffic.
Platform integration: App Service integrates with other Azure services, such as Azure SQL Database, Azure Redis Cache, and Azure Storage, making it easy to build end-to-end solutions with minimal effort.
Security: App Service provides a secure and isolated environment for running Docker containers, with features such as network isolation, private networking, and Azure Active Directory authentication.

However, Azure App Service is not the same as the previously discussed Azure Kubernetes Service (AKS), which is a container orchestration platform. AKS is designed for running and managing containerized applications at scale, with features such as automatic scaling, rolling updates, and self-healing. AKS is typically used for more complex applications that require multiple containers and need to be deployed across multiple nodes.

In summary, Azure App Service provides an easy and convenient way to run Docker containers in a PaaS environment, with built-in high availability, scalability, and integration with other Azure services. AKS, on the other hand, is a container orchestration platform designed for running and managing containerized applications at scale, with features such as automatic scaling, rolling updates, and self-healing.

The following Azure CLI code is what you need to get started with running a Docker image as an App Service:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Create a resource group
az group create --name myResourceGroup --location eastus

# Create an App Service plan
az appservice plan create --name myAppServicePlan --resource-group myResourceGroup --sku B1 --is-linux

# Create an App Service
az webapp create --name myAppService --plan myAppServicePlan --resource-group myResourceGroup --deployment-container-image-name <acr-name>.azurecr.io/<container-image-name>:<tag> --docker-registry-server-url https://<acr-name>.azurecr.io --docker-registry-server-user <acr-name> --docker-registry-server-password <acr-access-token>

# Configure the App Service
az webapp config appsettings set --name myAppService --resource-group myResourceGroup --settings DOCKER_CUSTOM_IMAGE_NAME=<acr-name>.azurecr.io/<container-image-name>:<tag> WEBSITES_PORT=80

# Set up continuous deployment
az webapp deployment container config --name myAppService --resource-group myResourceGroup --enable-cd true --docker-registry-server-url https://<acr-name>.azurecr.io --docker-registry-server-user <acr-name> --docker-registry-server-password <acr-access-token>

Azure Container Apps (https://learn.microsoft.com/en-us/azure/container-apps/overview)

Azure Container Apps is a serverless platform for deploying and managing containerized applications. It is designed to simplify the deployment and management of microservices-based applications by providing a seamless experience for developers and operators.

With Azure Container Apps, you can deploy and manage multiple containers as part of a single application, without worrying about the underlying infrastructure. This makes it an excellent choice for running complex, multi-container applications that require orchestration.

One of the strengths of Azure Container Apps is its flexibility. With Azure Container Apps, you can use any container image from any registry, including Docker Hub, Azure Container Registry, or your own private registry. You can also define your application’s infrastructure as code using YAML or JSON files, which allows you to version control and automate the deployment process.

Azure Container Apps also provides advanced features, such as automatic scaling, self-healing, and application-level load balancing. With Azure Container Apps, you can scale your application automatically based on demand, and Azure will handle the underlying infrastructure for you.

However, Azure Container Apps has some limitations. First, Azure Container Apps is still in preview, so it may not be suitable for production-grade applications. Second, Azure Container Apps has some limitations in terms of customization, as it abstracts away some of the lower-level details of container orchestration. Finally, Azure Container Apps has a pricing model that may be more expensive than other Azure container services, as it charges based on the number of requests processed by your application.

Use the following code example to get started with deploying an Azure Container Apps scenario:

1

az containerapp create -n MyContainerapp -g MyResourceGroup --image myregistry.azurecr.io/myimage:latest --environment MyContainerappEnv --cpu 0.5 --memory 1.0Gi --min-replicas 4 --max-replicas 8

Summary

As you can see, Azure offers several services that allow running containerized workloads, each with its own strengths and limitations. In this article, I walked you through different Azure services for container orchestration and management, including Azure Container Instance, Azure Kubernetes Services, Azure App Services, and Azure Container Apps. I tried to give you a few Azure CLI commands to get started and deploy baseline examples. This should allow you to validate your own opinions around which container service scenario to use for your specific business-critical or testing workloads.

I hope you learned something from reading the article, enjoy the rest of the Azure Spring Clean topics!!

Cheers!!

/Peter

Upgrading an AKS cluster in 20 min

Fri, 18 Jun 2021 00:00:00 +0000

Ever since I joined Microsoft (Sept 2019) and started working in the Azure Technical Trainer team, I deployed a demo Azure Kubernetes Service (AKS) with a few sample containers. Helping me in walking training attendees through the architecture, the management concepts and what it takes to run containerized workloads using the advanced capabilities coming with Kubernetes on Azure.

Knowing this AKS cluster got deployed about 20 months back, it also meant my setup was getting a little bit out-of-date. Interesting enough, it ran for almost 500 days (I considered waiting to publish this article to celebrate its anniversary…)

Version strategy

AKS is following the overall Kubernetes supportability in regards to versioning. More details from the below links in the docs:

In short, the Kubernetes community released minor versions about every 3 months, and major releases every 9 months approximately. As of version 1.19, this got extended to 12 months support.

What this means, is that you see a list of “versions” available in Azure, for both new and existing deployments of AKS environments. At the time of deploying my cluster, it seems the active version was 1.7.7 (I could pull this up from my AKS Resource Group / Deployment history)

I assume I picked the [default] version at the time of deploying, which would mean there were 3 minor versions before, and 3 minor versions ahead.

Version 1.18 End of Life

Earlier this week, I got an internal note from our back-end security team, informing me about the AKS version 1.18 getting deprecated by June 30th, 2021 (yes, in about 2 weeks from now), and I needed to upgrade to at least 1.19.

https://github.com/Azure/AKS/releases

Upgrade Process

One of the core strenghts of Kubernetes (AKS and other flavors) is how it handles seamless upgrades of its worker nodes. In short, each worker node in the cluster gets upgraded, and introduced to the cluster only when all health checks have passed successfully. If something would go wrong, the upgrade won’t be flagged - but your running containers won’t even notice any interruption either. After a successful upgrade of an existing (or introduction of a new) node to the cluster, your containerized workloads will just be started and running as expected.

To safe me from near-future upgrade tasks, I decided I wanted to upgrade to the most current version available (1.20.7 in my case). Which meant performing a “double” upgrade, from 1.18 major version to 1.19 major version, followed by another upgrade to the 1.20 major version.

I used the portal for these steps, as they are really easy to perform, but know Azure CLI or template based scenarios are also an option.

From the Azure Portal, browse to your AKS cluster resource. In the Overview section, notice the “Kubernetes version” parameter.
Select the version number; this brings you to the upgrade blade

Select the Upgrade Version and choose the version of choice. (In my case, the highest was 1.19.11). I also selected to upgrade control plane + all node pools
Confirm and wait for the upgrade process to kick off and complete successfully. This took about 6 minutes in my case.

Once this version 1.19.11 upgrade was done, I moved on with repeating the same steps, but this time selecting version 1.20.7

This process took another 7-8 minutes on my end.
That’s all!!

Summary

In this article, I wanted to share some insights on the Kubernetes, and more specific AKS upgrade policy and process. Thanks to the architecture and orchestration of Kubernetes, upgrading versions is a rather smooth and almost seamless process. While it worked fine for a almost 18-month all cluster setup, I would definitely recommend keeping up with versions faster, instead of - what I did - waiting longer.

Got any questions, don’t hesitate reaching out! peter@pdtit.be or @pdtit on Twitter :)

/Peter

AKS ErrImagePull and ImagePullBackOff on AKS after a year

Tue, 23 Mar 2021 00:00:00 +0000

Hi all,

I’ve deployed me an AKS - Azure Kubernetes Service environment that I use in my Azure training class deliveries almost every week (yes, every AZ-course touches on AKS and Containers…)

The Problem

My AKS environment was running fine all this time (a bit over a year), allowing me to rely on existing deployed Kubernetes services, as well as building new services as a live demo. Until this morning, where all of a sudden, my own services didn’t start at all, but the kube-system services did. The error message I noticed for this service was ImagePullBackOff and ErrImagePull.

If you know a bit about Kubernetes and custom services (= the PODs that are running your containerized workloads), you know they are pulled from a Container Registry, in my case ACR - Azure Container Registry. Which means that in this scenario, there was probably something wrong with the communication between AKS and ACR. And more specifically, the AKS resource (or the Service Principal representing my AKS cluster) not having (no more having…) the correct permissions to reach ACR. Interesting is that the Kubernetes system containers are still running fine.

![System_containers_up](../images/screenshot-2021-03-23-2744036e.png)

The fix

The fix consisted of a few different steps, but all in all, the steps made sense.

Check if the current AKS Service Principal was still valid
- After facing the problem, it struck me… an AKS Service Principal is valid for 1 year. Yes, my AKS cluster had been deployed for a bit more than year (405 days). So yes, my SP got expired
Although there is a way to renew the lifetime of a Service Principal, I couldn’t rely on that mechanism, as it only works for a non-expired-yet SP. Sounds normal to me. (In real life scenarios, you could automate this renewal from Azure Functions or Azure Automation)
This left me with the next option, creating a new Service Principal and linking it to the existing AKS Cluster Resource. Let’s go for that approach.

Get the resource ID for the existing AKS cluster

As we need to link a new Service Principal to the existing AKS Cluster, let’s check the resource ID by running the following:

1
2
3


SP_ID=$(az aks show --resource-group aksrg --name pdtaks\
 --query servicePrincipalProfile.clientId -o tsv)
az ad sp credential list --id $SP_ID --query "[].endDate" -o tsv

Copy the output aside as we need it again later on.

Create a new Service Principal

To manually create a service principal with the Azure CLI, use the az ad sp create-for-rbac command. By default, a Service Principal gets assigned to your subscription with Contributor rights, but this will change anytime soon. To avoid any misusage, add the –skip-assignment parameter to make sure the SP resource doesn’t get any assignments yet:

1

az ad sp create-for-rbac --skip-assignment --name pdtakssp

Copy the output aside as we need it again later on.

Update the AKS Cluster with the new Service Principal

Allocate the output of the Service Principal and link it to the variable “SP_ID”:

1

SP_ID=f0ef702d-7108-476c-8129-XXXXXXXX

Do the same for the Service Principal password: linking it to the variable “SP_SECRET”:

1

SP_SECRET=gbKclLRCLy1R4B6SzJ~lNVF5eb5ATvP.9l

Followed by the following command, which runs the actual update:

1
2
3
4
5
6


az aks update-credentials \
 --resource-group aksrg\
 --name pdtaks\
 --reset-service-principal \
 --service-principal $SP_ID \
 --client-secret $SP_SECRET

After a few minutes, this process should be completed successfully.

Define ACRPush permissions (RBAC) for this new Service Principal

The AKS Cluster got updated with the new Service Principal, but this resource cannot connect to the Azure Container Registry yet, as it is lacking the permissions to do so. But this can be fixed as follows (using the Portal approach, although CLI or PS could also do the trick):

From Azure Portal, browse to the Azure Container Registry you want to use
Select Access Control (IAM)
Select Add Role Assignment
Role = ACRPush (Pull would only allow Pulling, Push allows both Pull and Push operations)
Assign Access To = User, Group, Principal
Select = search for the name of your Service Principal (pdtakssp in my example)

Save the changes

Validate if the problem got fixed

AKS is pretty smart in retrying failed operations (it’s an Orchestrator after all ;). So let’s check if we fixed the problem.

Browse to your AKS Cluster resource
Select Services and Ingress
All services, system and custom workloads, should be up and running again

Awesome, AKS did it! (With a little help from Azure Active Directory)

Lesson Learned

When deploying AKS Clusters in Azure, remember they get linked to a Service Principal (or Managed Identity alternatively), which is valid for 1 year, but allows for renewal (extend). If your Service Principal got expired, the fix is in creating a new Service Principal, linking it to the AKS Cluster and specifying AcrPush RBAC permissions for the Container Registry you want to use.

Now I’m going to check on that automatic renewal or at least updating my calendar to renew my Service Principal in time next year.

Take care for now, feel free to reach out on Twitter or peter @ pdtit dot be for questions.

thanks, Peter

The weird case of the Visual Studio 2019 Dockerfile

Sun, 22 Nov 2020 00:00:00 +0000

Hey there,

I’ve been doing quite a lot with Docker and the different Azure Container Services offerings like Azure Container Instance and Azure Kubernetes Services.

As you probably know, the starting point of a containerized application is the Dockerfile. Look at this like an instruction script, which tells Docker what needs to happen, in order to grab the application source code, compile it and produce the container image.

Besides the complexity of running containers by itself, I personally think writing a Dockerfile is equally difficult and complex. So I am more than happy to know that Visual Studio (2017 and 2019) comes with some interesting Container Tools. Aside from helping in debugging containerized workloads, providing some interaction with the Docker engine, it also helps in compiling a Dockerfile for you.

Or at least “it pretends”… Read on to find out about my journey, messing around for 2,5 days before I actually got my Docker container working…

Add Docker Support

When you run Docker Desktop on the same machine as your Visual Studio development environment, you don’t need to do anything. The integration is just there (I honestly never looked into the details how this works, but hey, it is there…)

From VS2019 Solution Explorer, right click on the Project you want to containerize
Select Add…
Notice Docker Support

From here, it prompts for the Operating System for the container workload, being Linux or Windows; I guess this depends on the app language you are using though; since, in my case, my sample app is using dotnetcore3.1, which runs on both, I could choose.
From here, it produces the necessary Dockerfile, looking like this:

At first glance, all looks good, right? This is what the Dockerfile is doing:
- Grab the ASP.NET 3.1 base container image and specify the work directory as /app, and expose the application on port 80 and 443; this makes total sense, as we are working with a web application here
- Next, grab the DotnetCore 3.1 SDK base container image and specify the work directory as /src
- Followed by copying my application source code into it
- From here, it runs the usual dotnet restore, build, publish
- Producing a final Docker image, which executes “dotnet and start my SimplCommerce.Webhost web application within the Docker Container.
At second glance, all still looked good, where I was starting my container (F5). The “Build” process kicks off, similar to running this for a traditional code-based application, and going through the Docker compile process as expected:

Once the build process is done, it switches to the Container Tools view, exposing details about the actual running container (ports, logs,…)

As well as showing a running application in the browser

Where it goes wrong

I was super excited at this point; I got my web application running, moved it into a working Docker Container, just by going through 3 clicks. Awesome!!

Since the intention is to run my application outside of Visual Studio debug mode, I was obviously running a second test, by manually starting my container using the Docker command line.

Docker run -p 2500:80 fastcarcase:dev is the command to kick off my container instance, and all seemed fine when checking the running container state:

However, when browsing to http://localhost:2500, nothing is showing up; also, the container is not providing any logs. Not even when running in interactive mode.

From here, I started redoing a lot of steps, going through about all troubleshooting steps I could find online, starting all over from the application source code, going through the Add… Docker Support steps once more,… always resulting in the same. A workable containerized application in Visual Studio debug mode, but not when starting the exact same container manually. Frustrating :)

The life saver

After trying, trying again, trying once more,… I thought about why not creating a Dockerfile manually and testing from there. GOOD THOUGH apparently.

Here is the Dockerfile I came up with, after reading several Docker articles, blog posts and validating several of my other sample applications from earlier demo scenarios I used:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


FROM mcr.microsoft.com/dotnet/sdk:3.1 AS build
WORKDIR /app

Copy *.sln .

COPY . .

WORKDIR /app/src/SimplCommerce.WebHost

RUN dotnet restore 

RUN dotnet publish -c Release -o out

FROM mcr.microsoft.com/dotnet/aspnet:3.1 AS runtime
WORKDIR /app

COPY --from=build /app/src/SimplCommerce.WebHost/out ./

ENTRYPOINT ["dotnet", "SimplCommerce.WebHost.dll"]

Technically, this Dockerfile is doing almost the exact same as what the Visual Studio generated one did, using the exact same base images (dotnet sdk and dotnet asp.net), as well as copying all the files, and using “dotnet SimplCommerce.Webhost.dll” as the starting command when the container starts up.

Surprisingly, this seemed to work fine! I could start my container on my local machine, but also push it into Azure Container Instance and run it fine, and even tried using it in my Azure Kubernetes cluster. And all was working fine.

Closing

I guess I need to go through the concepts and details of a Dockerfile much more in detail to figure out where the differences were, but at least for now, I can move on with building my next demo scenario. Automating all this using Azure DevOps Pipelines. Which will be for a future blog post I promise…

See you all soon, reach out when you have any questions or comments on this post or on Azure in general,

Cheers, Peter

Use Docker Edge to Deploy Azure Container Instance - ACI

Sun, 05 Jul 2020 00:00:00 +0000

Hey there,

At the recent DockerCon (virtual) Conference, Docker announced a more tightened partnership with Microsoft, boosting the adoption and integration of Docker containers for Windows Server as well as Azure-running workloads. A first announcement involved a cool integration with Azure Container Instance (ACI), a low-level container runtime on Azure, allowing you to run a container without the typical complexity. While ACI has been around for 2 or more years already, it now becomes possible to manage and run your ACI-based containers directly from the Docker commandline.

And that’s exactly what I will guide you through in this post.

Prerequisites

This capability is in preview for now, and requiring Docker Desktop Edge 2.3.2 (I’ll show you how to upgrade if you already Run Docker)
An Azure subscription, allowing you to deploy and run Azure Container Instance
A sample Docker container (you can grab my example if you want, or use any other you like)

Upgrading to Edge Desktop

I was already running Docker Desktop on my Windows 10 machine, using Windows Subsystem for Linux (WSL) integration; I actually wrote another post on this a few weeks ago, on how to get this up and running.

From the Docker icon in the taskbar, select “About Docker Desktop”; this will show you the current version

As you can see, I’m using the stable version 2.3.0.3

Since I keep my demo containers in Docker Hub, I wasn’t too worried about losing them. However, if you want to keep a backup of your current Docker images, know you can store these in a Linux-tar file, using

1

docker save -o <nameforbackup.tar> <docker_image_name>

Uninstall Docker Desktop, by searching for “Docker Desktop” in the Start Menu, right-click it and select “Uninstall”

Follow the instructions to have the software removed from your machine.

From the Docker website, download the Docker Desktop Edge edition

Accept the options to create a desktop shortcut and allow the integration with WSL (if that is what you were using before…)

Wait for the component install to complete

After only a few minutes, Docker Desktop should run again fine. You can validate this from the Docker icon in the taskbar’s notification area; if it shouldn’t start automatically, you can start it from here as well, by right-clicking on it. (FYI, I actually had to restart my machine before it actually ran fine, but I am on Windows 10 Insider Preview 19640, if that should matter at all :))

Confirm Docker Desktop Edge is running fine from a Docker Perspective , by opening your Command Prompt, and running

1

Docker info

Nice, that upgrade went smooth already!

Before we move on to the next step, let’s restore our previously used Docker Image (if you created the backup), by running the following command:

1

Docker load -i <name_of_the_backupimage>.tar

and validate by running

1

docker images

On to the next step… Now we are running the latest Docker Desktop Edge, it is time to play around with the newest Azure Container Instance (ACI) integration - which is the whole point of this blog post.

In short, you go through the following steps:

Authenticate to Azure, directly from Docker
connect Docker to Azure Container Instance by creating a “Docker Context” (think of this as an environment with its own settings, much like dev/test, staging, production. Or in our case, the “default context” being your local machine running Docker, and the other one being “Azure”)
Allocate a Docker Hub image to run as an Azure Container Instance, and run it

Authenticate to Azure, directly from Docker

The first feature that is part of the Docker Desktop Edge, is allowing us to authenticate to Azure, directly from the Docker engine. Initiate the following command:

1

Docker Login Azure

This will prompt you for your Azure subscription credentials in a browser, just like a regular Azure authentication prompt (this also recognizes MFA, to make this a rather secure option)

Creating a Docker Context

From your Command Prompt, create a new Docker Context, by running the following command:

1

docker context create aci <name_for_the_context>

Based on the authenticated logon from the previous step, it will list up the different Azure subscriptions linked to your account; using the “arrow” keys, you can select the subscription you want to use. Next, it will list up the different Resource Group within your subscription.

If you don’t want to use an existing Resource Group, you can create a new one:

While this works, the naming convention for the newly created Resource Group is probably not going to work in any organization (naming convention policies etc…); so let’s run this command again, and create a new context, based on an already existing Resource Group we want to use, by running the following command:

1

docker context create aci <name_for_the_context> --location <azure_region_name> --resource-group <name_of_the_Azure_RG> --subscription <name_of_the_Azure_subscription>

The Docker Context, pointing to Azure ACI is available now. Let’s continue with running an actual container in the next step.

Running your ACI using a Docker Hub image

Running a Docker container within the ACI instance, is based on the exact same Docker command you would use if it was running on your local machine:

1

docker run -d -p <portmapping> <name_of_the_container_image>

which looks like this for my example:

where

80:80 tells the container to run the workload on port 80, and expose it to the outside world on port 80 as well
pdetender/simplcommerce points to an e-commerce application container I have available in my Docker Hub repository

At first, a new unique name for the Docker container runtime will get created (the “trusting-cartright”) in my example, followed by the deployment of a new Azure Container Instance

In less than a minute, the job is completed successfully. Time to validate the running container. This - again - is identical to validating your running Docker container instances on your local machine:

1

docker ps

which shows you the running container instance, as well as the necessary details about the public-IP address of the instance. From your browser, connect to this public IP address, and see our sample workload in action:

You can also validate this from the Azure Portal, by connecting to the Azure Container Instance (this could also be done from Azure CLI or Azure PowerShell to be complete…)

Wonderful! This new Docker Edge integration with ACI is a nice improvement, and saving several steps from the “old way”.

This completes the core of what I wanted to discuss in this post, showing you the nice capabilities from Docker Desktop Edge, to natively deploy and run an Azure Container Instance.

Running your ACI using an Azure Container Registry (ACR) image

The previous example was using a public Docker Hub container image. So I was wondering if this would also work for a (private) Docker image I already have in my Azure Container Registry. Let’s give it a try:

create a new Docker Context for ACI

Run the Docker Container, pointing to the Azure Container Registry image

Hmm, that’s an interesting error message… something “gcloud” related (=Google Cloud Platform :)). After some searching on the interwebs, it seems like my Docker instance is having some default authentication providers in its config.json file… interesting

Apparently it is safe to remove the section “CredHelpers”, saving the file and running the “Docker Run” again:

While that weird gcloud error is gone, we are not quite there yet. But this error makes more sense to me. What it says here, is that the Docker Context cannot connect to the Azure Container Registry. Of course not, I need to authenticate to ACR first (az acr login), just like when I am running this locally on my machine:

where -g refers to the name of the Resource Group having the Azure Container Registry, and -n refers to the name of the Azure Container Registry itself

which works much better now; similar to the first example, a new Azure Container Instance is getting deployed:

Let’s validate once more by initiating “docker ps”, which shows the following:

and checking from the browser, if the workload is actually showing what it needs to show (note it is the same workload, just a different product category):

and lastly, checking back on what it looks like from the Azure Portal

I love this!!

Summary

In this post, I introduced you to a brand new capability from Docker Desktop Edge, providing a direct (native almost) integration with Azure Container Instance. This allows you to deploy and run a container instance on Azure, without much hassle. I showed you how this works with public Docker Hub images, as well as with more private images from an Azure Container Registry.

How to delete a POD from Azure Kubernetes Services (AKS)

Sat, 06 Jun 2020 00:00:00 +0000

Hi again,

In about every Azure training delivered the last few months, I am talking about Docker and Azure Kubernetes Services - AKS

Along these months, the amount of “sample PODS” I am running within the Kubernetes cluster was continuously growing, resulting in a less efficient demo scenario to show.

So cleaning up these running PODS was my 5 seconds action this Saturday morning. While not super hard, it actually took me a bit longer than 5 seconds (more like 10min :)), since I forgot a few “basics” on how Kubernetes is running PODS.

To safe myself some time in the future, and even more, helping readers from making the same mistake, I took note of it:

The Before Situation

I am not discussing how to deploy AKS on Azure, there is already enough documented on how to achieve this using the Azure Portal as well as using Azure CLI to do this.
Deploying PODS (=your Docker containerized application) to the Kubernetes cluster is done using a “Kubernetes.YAML” file, having settings on the application name, the amount of container replicas you want to run within the cluster for high availability, and the link to the Azure Container Registry where the container image can be found.

A sample such kubernetes.yml looks like this:

Some important settings in this file are:

metadata / name this is the name of the deployment (important for later…!) (agderkubdemo in my example) template / app this is the name of the application within the AKS cluster (agderkubdemo in my example) containers / name name of the Azure (or other or Public Docker Hub) Container Registry containers / image name of the Azure (or other or Public Docker hub Container Repository (=name of your Docker container image))

Once you have this file, you can run the following command to get the PODS deployed to your AKS cluster:

1

kubectl apply -f <path to the kubernetes.yml file>

So that’s what I currently had, a running AKS server with a couple of tens of these sample app containers running :)

How to delete PODS from AKS

If you want to know what PODS you are actually running on your AKS cluster, run the following command:

1

kubectl get pods

which looks similar to what I have in my environment:

Easy enough, there is a kubectl command to delete PODS, go figure:

1

kubectl delete PODS <name of the POD>

which nicely deletes the identified POD

or did it?

Apparently the PODS were not really getting deleted in the way I wanted them to be completely removed from the cluster. My “active” PODS turned to a state “terminating”, but at the same time, there were 2 new PODS running the same application. What’s going on?

After a few seconds, it struck me what AKS was doing here… The built-in high availability of Kubernetes always tries to make sure it has container instances running, according to… what you defined in your deployment (=the kubernetes.yml file).

Let’s check that file again:

I had my specs / replicas set to “3”, which means Kubernetes runs 3 identical container instances of my application (for high availability). So in reality, when you run the delete action against a replica, AKS just starts up new instances, to comply to the 3 running instances you ask for.

So there must be another way to run the deletion.

One source I found on the internet recommended to set the replica parameter to “0”, but that felt a bit weird to me (although I actually tried and succeeded).

However, the best practice seems to be deleting the actual deployment. Remember I pointed this out earlier, this setting is in the “kubernetes.yml” file as well, saying this setting was important

metadata / name this is the name of the deployment (important for later…!) (agderkubdemo in my example)

Within Kubernetes, when you run a “kubectl apply” action, it remembers this state as a deployment. So by removing this deployment, it will also remove the corresponding PODS. Let’s give that a try:

1

kubectl delete deployment <deployment name> (=from the metadata / name setting in the YML file...)

Or you could also use parameter “–all” as follows, to delete all previous deployments at once:

1

kubectl delete deployment --all

If we know check what happens with the running PODS, they will all be nicely terminated, and eventually getting deleted from the AKS environment:

1

kubectl get pods

Summary

This post described how you can successfully delete running PODS from an AKS environment, using different scenarios.

See you all soon, reach out when you have any questions on AKS or Azure in general,

Cheers, Peter

Migrating Docker Desktop to WSL2

Sat, 30 May 2020 00:00:00 +0000

Hey there,

With the May update of Windows 10 (named Windows 2004 :) ) being available since this week, together with DockerCon virtual conference, I think it was the right time to (finally) migrate my current Docker Desktop in Hyper-V mode to the new WSL 2 (Windows Subsystem for Linux).

In short, the process was smooth, straight forward, and not having any real impact on my “demo environment” I’m using continuously during my Azure training workshops and public speaking gigs.

This also only took about 20min of my time, including writing this blog post. LOL.

Here we go:

Prerequisites

The main prerequisite I want to highlight here is you need the May 2020 update for your Windows 10 machine; If you don’t have it yet, here is a quick how-to-install the May 2020 Update:

Go to Settings / Update & Security / Windows Update. Here, select “Check for updates”.
Once the update is listed, select Download and install. (If you don’t see the notification to download and install, the update may not have been published yet for your machine/region, but you should receive it any time soon. I mean it’s the May update :) (actually was the April update, but due to COVID19 got pushed out a bit). Also make sure you currently are running Windows 10 version 1903 or version 1909.)
Once the download is finished and ready to install, you’ll get a notification to choose the right time to finish the installation and reboot your computer. I actually ran this automated over night, and it welcomed me this morning.
Why not required for my Docker and WSL 2 upgrade, I was suprised there is No Edge browser included with this release, so that’s the first application I updated…

Installing WSL 2

WSL (Windows Subsystem for Linux) was released almost 3 years ago, and got recently upgraded to v2, as part of the Windows 10 May update. It provides an almost full Linux distri (Ubuntu, openSUSE, Kali, Debian,…). WSL 2 comes with incredible performance improvements, nicer integration for mixed Windows/Linux platform developers (did somebody say dotnet core?) and also provides Docker support. If you were running the WSL v1 already, you don’t have to do anything but will get a notification from within the WSL environment to upgrade to WSL 2.

I wasn’t running WSL yet, so went through the following steps, per the Microsoft documentation:

Open a PowerShell session as Administrator, and run the following cmdlet to install the WSL feature:

1

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

Next, install the Virtual Machine (Hypervisor) feature, by running the following cmdlet:

1

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Enable WSL 2 as default by running the following cmdlet:

1

wsl --set-default-version 2

You can now install your Linux distri of choice, by launching the Microsoft Store App on your Windows 10 machine. I selected Ubuntu, but know you have a few other ones available as well

Click Install

Wait for the install to complete, and press launch to start the Ubuntu environment

Give it a few minutes to finalize the Ubuntu installation within the WSL environment. You are also prompted for a Linux local administrative username and password (this can - and SHOULD - be different from your Windows local admin account credentials for security reasons…!)

After a few moments, your Ubuntu environment is up-and-running. Again, this replaces any former Ubuntu virtual machine you had running on Hyper-V, Virtualbox, VMware Player,… on the same Windows 10 machine of yours.

Keep in mind you cannot install any “GUI” applications inside the WSL environment, but can use any commandline-based application. It’s a full Linux distri remember!!

Switching Docker to WSL 2

My setup here involved a “migration” from Docker using it’s own Moby Hyper-V VM to WSL 2; this means I’m losing the current Linux containers I already use within my Docker environment. If you want to reuse them within the WSL environment, make sure you get a list of them before switching the Docker mode, by running the following cmdlet (PowerShell or CMD Prompt):

1

docker images

which provides you an overview of the (Linux) Docker images you currently have on your machine

I only have a few left, since I did a nice cleanup before (docker rmi )

From the Docker Desktop context menu / Settings / enable the “Use the WSL 2 based engine”

While not really needed, it’s always nice to validate this is actually working fine; the first check I did is executing a “Docker info” command, which shows the running state of the Docker engine, while at the same time validating the former Docker Moby VM is down - obviousy this was the case:

We can now download and run our former Docker images again, to have the same setup as before; on my machine, I had a few images available, like “Ubuntu”, “SimplCommerce” (an e-commerce app I use in workload demos,…); let’s grab these by executing a “Docker run ” command:

for my pdetender/simplcommerce (on Docker Hub)

and

for a sample Ubuntu container; awesome! it works!

Updating (or installing) Visual Studio Code - Docker Extension

Managing Docker is all commandline based, and it’s not always that convenient to remember all commands during live demos. And even during day-to-day operations, I tend to make my life a bit easier, if there is a GUI available for “easy tasks”. That’s where VSCode extensions are powerful. Including the Docker one; if you haven’t installed it yet, please do so :).

Right after my upgrade to WSL 2 above, it got picked up by VSCode immediately, showing me the following notification:

which I obviously installed, ending up in (yet another) extension:

Next, I validated my version of the Docker extension, if it was updated to the latest one (if you installed this extension already, it typically runs a silent update by itself…)

Which allows us to manage our Docker environment from the VSCode GUI now:

and guaranteeing again for some nice upcoming demos during my Azure workshops!

Summary

In today’s post, I walked you through an upgrade (or installation…) of a Docker Desktop on Windows 10 from the Moby VM Hyper-V setup to the latest WSL 2, thanks to an upgrade in Windows 10 May 2020 update build. While I only did a few quick functional tests, making sure my environment is still running as before, I have a slight feeling this WSL 2 is going to be used much more, and not just for my Docker integration.

Ping me if you got any questions!

/Peter

Happy to announce my newest Azure book got (self) published

Fri, 03 Jan 2020 00:00:00 +0000

I’m excited about this next project that finally got live, thanks to a bit of quiet time during the Holidays. While it is not up to the full 100% of what I had in mind, I didn’t want to hold back the content any longer, since Azure is moving already that fast…

The original idea of this material was based on a workshop I created for Microsoft Internal (Azure Developer Series) in Sept 2018 as a contractor, which was a combination of slides, videos and lab guides. The workshop existed in both in-person and virtual delivery format. At that time, the sample application was rather basic. Early July 2019, I got asked to work on an update of the content, and extend it with Azure DevOps, which was well-adopted in the market already, but still unknown to a lot. Instead of just working on “updates”, I decided to start from scratch, and work towards a more “business ready” application, using SimplCommerce, an Open Sourced E-commerce platform application, built in .NET / .NET Core, and supporting different database back-ends.

Flipping the presentations and lab guides into a book seemed like an interesting idea at that time.

Talking to several people about this, it became clear that – given the focus on the technical side of the Azure platform, together with the focus on the hands-on aspect of the workshop, most vouched for a hands-on guide, and leaving the ‘speaker notes’ behind. Next, me moving to Microsoft as a full-time employee mid September 2019, was another good reason to shorten the format of this book. It would still take me another 3 months (Christmas Holidays aka slower pace…) to go through all labs again myself, guaranteeing the book was ready for usage, even without having a trainer available to ask questions.

This is the first book I’m doing in self-publishing, and my 6th book overall (see /publications) for more details on the other material I wrote along the years.

The benefit for you as a reader is that you will get continuous updates. Whether these are bug-fixes, additional chapters/lab steps or major updates to existing labs, you will get notified about it. The advantage for me as the author, is that it is probably one of the best ways to publish content on a topic that is as fast moving as Azure.

As always, I hope this book maps with your interests and helps in your journey to Azure. Do not hesitate reaching out or sharing your feedback,

Here is some more info about the actual book contents:

Hands-On-Lab Scenario

You are part of an organization that is running a dotnetcore e-commerce platform application, using Windows Server infrastructure on-premises today, comprising a WebVM running Windows Server 2012 R2 with Internet Information Server (IIS) and a 2nd SQLVM running Windows Server 2012 R2 and SQL Server 2014.

The business has approved a migration of this business-critical workload to Azure, and you are nominated as the cloud solution architect for this project. No decision has been made yet on what the final architecture should or will look like. Your first task is building a Proof-of-Concept in your Azure environment, to test out the different architectures possible:

Infrastructure as a Service (IAAS)
Platform as a Service (PAAS)
Containers as a Service (CaaS)

At the same time, your CIO wants to make use of this project to switch from a more traditional mode of operations, with barriers between IT sysadmin teams and Developer teams, to a DevOps way of working. Therefore, you are tasked to explore Azure DevOps and determine where CI/CD Pipelines can assist in optimizing the deployment and running operations of this e-commerce platform, especially when deploying updates to the application.

As you are new to the continuous changes in Azure, you want to make sure this process goes as smooth as possible, starting from the assessment to migration to day-to-day operations.

Abstract and Learning Objectives

This workshop enables anyone to learn, understand and build a Proof of Concept, in performing a multi-tiered .Net Core web application (SimplCommerce Open Source http://www.simplcommerce.com) using Microsoft SQL Server database, platform migration to Azure public cloud, leveraging on different Azure Infrastructure as a Service, Azure Platform as a Service (PaaS) and Azure Container offerings like Azure Container Instance (ACI) and Azure Kubernetes Services (AKS).

Immediately in lab 1, students get introduced to the basics of automating Azure resources deployments using Visual Studio and Azure Resource Manager (ARM) templates. Next, readers learn about the importance of performing proper assessments, and what tools Microsoft offers to help in this migration preparation phase. Once the application has been deployed on Azure Virtual Machines, students learn about Microsoft SQL database migration to SQL Azure PaaS, as well as deploying and migrating web applications to Azure Web Apps.

After these foundational platform components, the next exercises will totally focus on the core concepts and advantages of using containers for running business workloads, based on Docker, Azure Container Registry (ACR), Azure Container Instance (ACI) and WebApps for Containers, as well as how to enable container orchestration and cloud-scale using Azure Kubernetes Service (AKS).

In the last part of the workshop, readers get introduced to Azure DevOps, the new Microsoft Application Lifecycle environment, helping in building a CI/CD Pipeline to publish workloads using the DevOps principals and concepts, showing the integration with the rest of the already touched on Azure services like Azure Web Apps and Azure Kubernetes Services (AKS), closing the workshop with a module on overall Azure monitoring and operations and what tools Azure has available to assist your IT teams in this challenge.

The focus of the material is having a Hands-On-only Lab experience, by going through the following exercises and tasks:

· Deploying a 2-tier Azure Virtual Machine (Webserver and SQL database Server) using ARM-template automation with Visual Studio 2019;

· Publishing a .NET Core e-commerce application to an Azure Web Virtual Machine and SQL DB Virtual Machine;

· Performing a proper assessment of the as-is Web and SQL infrastructure using Microsoft Assessment Tools;

· Migrating a SQL 2014 database to Azure SQL PaaS (Lift & Shift);

· Migrating a .NET Core web application to Azure Web Apps (Lift & Shift);

· Containerizing a .NET Core web application using Docker, and pushing to Azure Container Registry (ACR);

· Running Azure Container Instance (ACI) and WebApp for Containers;

· Deploy and run Azure Azure Kubernetes Services (AKS);

· Deploying Azure DevOps and building a CI/CD Pipeline for the subject e-commerce application;

· Managing and Monitoring Azure Kubernetes Services (AKS);

At last…,

I also want to thank Amita Thukral, a far-away friend from India, with whom I had the pleasure to work along the years when doing Azure virtual workshop deliveries, where she was moderating the questions from the audience, and overall a very nice and professional person to work with. She did a tremendous job in screening the scenario, going through all lab steps, to make sure it all made sense. Even for less Azure-experienced folks.

If this got your attention, head over to Leanpub, and grab yourself a copy of the book. And start learning Azure :).

Looking forward to your feedback,

best regards, Peter /Peter