Real-time Transport Tracking System on Azure - Part 7.1 - Fixing Docker Image Metrics in Azure

This is next post in series about real-time public transport tracking system development based on Azure infrastructure and services. This article is a part of Applied Cloud Stories initiative - aka.ms/applied-cloud-stories.

Blog posts in this series:

• Part 1 - Scene Background & Solution Architecture
• Part 2 - Data Collectors & Composer
• Part 3 - Event-Based Data Delivery
• Part 4 - Data Processing Pipelines
• Part 5 - Data Broadcast using gRPC
• Part 6 - Building Frontend
• Part 7 - Packing Everything Up
• Part 7.1 - Fixing Docker Image Metrics in Azure

Background

We finished previous blog post with disadvantage of running Windows based image in ACI by stating that guest OS metrics are not exposed in Azure Portal.

This is even mentioned in official docs. Metrics currently are only supported for Linux based images.

So let’s fix this by trying to build Linux image on Windows development machine. For this to happen - we gonna need some tools upfront.

Preparing Build Environment

Install WSL2

First, we would need something called “Windows Subsystem for Linux (v2)”. It’s easy installable via wsl command if you have joined “Windows Insiders Program” or you can just follow manual installation steps here.

Being able to see this screen is thrilling :)

Installing “Remote WSL” VSCode Extension

After we have installed Linux distro of your choice, we need to install VSCode extension (assuming that you do development in VSCode and know how to install that).

Search for “remote wsl” in extension list.

Install it.

Preparing Docker Engine to Talk to WSL2

You also will need to prepare Docker for Desktop engine to talk to WSL2. Do following steps:

• Head over to Docker Settings and enable WSL2 integration in “General” tab.

• Then under “Resources > WSL Integration” make sure that you see your distro and it’s enabled.

Building Image

Launching VSCode in WSL Mode

Now to get started:

• Open VS Code
• Open terminal
• Type wsl

• Then type code .

This basically means that new instance of VSCode is opened in WSL context (pretending that you are actually at Linux bash). A bit of mind-blowing, but I can chew that.

Changing Image Stages

Now we need to change image for the build and final stages - we need to switch from “Windows” to “Linux”.

Which distro you choose that’s entirely up to you, but I chose the very basic and straight forward edition - “Focal”.

We have to change from

FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
...
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-nanoserver-1809 AS final
...

to

FROM mcr.microsoft.com/dotnet/sdk:3.1-focal AS build
...
FROM mcr.microsoft.com/dotnet/aspnet:3.1-focal AS final
...

List of available SDK images you can get here and runtimes here.

Build the Image

Building the image inside WSL2 is exactly the same as we saw it already when we were building Docker image inside Windows OS.

Remote WSL makes it super easy. All docker commands are working and it feels almost like magic.

Deploying Image to Azure

Again, the deployment process to Azure is exactly the same as with Windows based images. Just if you would like to override OS type for the ACI - you will have to delete ACI resource before proceeding (as you just can’t change OS type on-fly).

After successful deployment and uptime for some period, we now do have nice metrics for the app.

Hope this helps! Happy containerizing!

[eof]