Docker first poked a finger in the eyes of monolithic applications about 10 years ago. Since then, it has become an industry standard for containerized microservices applications. Docker microservices offer many benefits including effective use of IT infrastructure, cross-platform compatibility, easier configuration and maintenance, strong encapsulation, rapid deployment, and more. However, debugging Docker microservices also presents a set of challenges unique to that architecture. Microservices are deployed with redundancy, so when an error occurs, you need to isolate the precise microservice that took part in or manifested the error. Also, an error in functionality may involve code execution across several different microservices, which can be nearly impossible to trace. And then there’s the possibility that you have different versions of the same microservice running at the same time, and you need to understand which of them manifested the error.
Ozcode Live Debugger’s autonomous exception capture traces events leading up to an error across all microservices enabling you to debug Docker microservices with time-travel debug information across the complete error execution flow.
This is the fourth in our series of blog posts that help you get started with Ozcode. Previously, we covered:
- Getting Started with Ozcode for Remote Debugging on IIS
- Getting Started with Ozcode for .NET Debugging on an Azure App Service
- How to Debug WPF Applications with Ozcode for Desktop
The beauty of Docker containers is that they abstract away the underlying operating system so you can write your application in any technology you want, including .NET.
In this post, I’ll show you how to get started with Ozcode to debug a .NET application running as Docker microservices on Linux in 3 easy steps.
- Step 1: Create or sign in to your account
- Step 2: Create your application in Ozcode Live Debugger
- Step 3: Copy a code snippet into your dockerfile
Once an Ozcode agent is running in your container, any exceptions thrown by the container will be recorded through Ozcode’s autonomous exception capture and you can start debugging Docker microservices by tracing the steps back through the error execution flow. I’ll show you how that works after you’ve got Ozcode set up to debug your Docker microservices, and it works just as well whether you’re running your microservices locally or in the cloud.
Step 1: Create or sign in to your account
Step 2: Create your application
First time you sign into Ozcode Production Debugger, you will be prompted to create a new application. Otherwise, you can select Add Application under the Applications menu:
Either way, once you create your application Ozcode will generate your application token.
Step 3: Copy the code snippet into your dockerfile
Ozcode Production Debugger will also create the code snippet for you to insert directly in your dockerfile:
Note that your application token is already embedded in the snippet.
Now, all you need to do is copy the snippet and paste it into your dockerfile to be built with your base image or into one of the other images in your microservice.
Note that while building the image, the Ozcode agent is downloaded using WGET. If the image in which you included the code snippet doesn’t support WGET, you can simply replace that line with with the following one that uses cURL instead:
curl "https://clouddbgprodstorage.blob.core.windows.net/install/linux/ozcode-pd-agent-linux.tar.gz" > ozcode-pd-agent-linux.tar.gz && \
Alternatively, you can also use apt-get by copying the following command to the top of your dockerfile:
RUN apt-get update && apt-get -f install && apt-get -y install wget
Using Visual Studio?
Visual Studio uses a multi-stage build format to generate Dockerfiles. Therefore, to ensure our snippet gets embedded into the right place in the Dockerfile, insert it after the following line:
FROM base AS final
Now build your image and run the container. You’ll be notified once the agent connects.
Here’s the whole installation process from start to finish.
You can click any error in the dashboard to step through the error execution flow.