So far in this blog series, we’ve looked at the basics of troubleshooting applications on Windows containers as well as how to leverage the Log Monitor tool for that purpose. Today we’re going to start looking at ways to make the process of troubleshooting applications less manual. For that, we’ll be looking at the Containers extension on Windows Admin Center (WAC).
Containers extension on Windows Admin Center
I’m assuming you are already familiar with WAC. If not, I’d highly encourage you to take a look at it. One of the great things about WAC is its extensibility. There are multiple extensions available to manage all kinds of things – one of them is the Containers extension.
The Containers extension allows you to target a container host and see the available images, create new container images, push container images to Azure Container Registry (ACR), run new container instances both locally, or in Azure with AKS, Azure Container Instance, or AKS on Azure Stack HCI. For the purpose of this blog post, we’ll focus on the troubleshooting options under the Containers extension:
When you have multiple containers running on container host, you can see them all at a glance with the Containers tab. It shows which ones are running, which ones are stopped, their configuration, and additional details that can be expanded on the bar at the bottom. On the image above, we have additional details on the container selected, such as which image was used to create the container, its process ID, which networks the container is connected to and its IP address, and more. That in itself already gives a glimpse into what might be happening in case you have some issues with the app running inside the container. But there’s more.
Log Monitor integration
On the previous blog post, we covered the Log Monitor tool. I mentioned, the tool basically presents the logs and events collected to STDOUT and then “docker logs” gather that information. On the Logs tab, what Windows Admin Center does is to execute the “docker logs” command and return the output:
On the example above, I configured a new container image based on the Nano Server base container image that simply uses the Log Monitor tool to capture the output of a ping to localhost. Different from the example on my previous blog post, now we can check the logs from multiple containers with a few clicks, rather than executing “docker logs” multiple times on containers that you might not even know the name.
In case you’re interested, here’s the docker file to recreate the same image:
FROM mcr.microsoft.com/windows/nanoserver:1809 WORKDIR /LogMonitor COPY LogMonitor.exe . ENTRYPOINT C:LogMonitorLogMonitor.exe c:windowssystem32ping.exe -n 20 localhost
In fact, I created the image using Windows Admin Center under the Images tab:
I then executed a new container from Windows Admin Center using the Run option:
Just like I explained on earlier blogs, you have Event Viewer on every container – the Log Monitor tool just makes it easier to extract the logs you need. However, if you want to navigate on the Event Viewer of a container just like you do on a regular server, you can: Just use the Events tab:
To me, the coolest thing about this view is that is a view we’re all familiar with. We’ve all used Event Viewer (and probably still use) to check the logs of an application, what’s happening with the system, etc.
Keep in mind though, the Events tab is a live view of the container’s Event Viewer, while the Logs tab has the logs available even if the container is not running.
Finally, the console tab opens a PowerShell connection to the container host. That allows you to execute other docker commands, such as “docker inspect”:
In fact, you can run any PowerShell/CMD command you want in this session. You can troubleshoot the container host itself from there, but the main thing is to be able to run other container related commands right from the Containers extension.
Windows Admin Center and the Containers extension allow for easier troubleshooting of Windows Containers. The extension allows to easily visualize the container instances on a container host, their logs, events, and even open a PowerShell connection to the container host – amongst many other features and Azure connectivity.
So far, we looked at ways to troubleshoot Windows containers on environments where you have total control of the container host and instances running on it. On the next blog posts, we’ll start exploring ways to troubleshoot applications on Windows Containers running on Azure Kubernetes Service. Let me know if you have any questions and what you think of the series so far in the comments section below.