I often need to learn how certain platforms work, and to achieve that there is no better way than deploying a sample workload and run some tests with it: for example for the “A day in the life of a packet on AKS” series that I wrote some years ago when AKS was something new I needed an application with which I could explore what the pod sees about the infrastructure (I have been reusing that app ever since to investigate Azure Red Hat OpenShift and Azure Container Apps). A single diagnostics pod isn’t enough, otherwise I would have used the beautiful Inspector Gadget by my admired colleague Jelle Druyts or kuard from the Kubernetes Up and Running book, because many questions refer to how applications communicate to each other, for example when you need to test network policies.
So I turned to existing demo apps. Something that bothered me of many “hello world” examples out there is that they demonstrate a cool app with some sort of “real world functionality” such as the well-used Voting App, but that kind of applications don’t tell you much about why they work, only whether they do or don’t. And yet something I realized is that the application should be relatively easy to use with an UI, and not a pure JSON-based API (as I had originally intended), so there was some merit to mimic a real-world app in some way.
Welcome to YADA
Hence, I decided to create YADA (Yet Another Demo App), a three-tier app that you can find in this GitHub repo. Or actually a two-tier one, because I only coded the web and application tiers, and the database could be anything (well, not anything, but either MySql, Postgres or SQL Server):
Where does it run?
Since YADA is containerized (on Linux), it can run everywhere where Linux containers are supported:
- Containers on your local system
- Azure Container Instances, great for testing applications
- Azure App Services (extra thanks to my admired colleague Victor Santana for fixing the web container!), which offer many nice goodies such as TLS or authentication proxy
- Virtual machines, either using a purpose-specific OS such as Flatcar or a general-purpose OS with Docker or any other compatible container runtime installed
YADA’s heart: the API
The heart of the app is the application tier, that offers a lot of API endpoints to try different things in the infrastructure where you roll it out (see the README file for the whole list):
- Provide some network information about the platform it is running on: local IP address, outbound public IP address when going to the Internet, DNS server, default gateway and more
- Get the HTTP headers of the received requests, which you really want to know if you have forward or reverse proxies in the data path
- Run DNS and reverse-DNS requests (very useful when you are investigating private link)
- Get a token from the Azure Instance Metadata Service, and through this way information about the underlying infrastructure where the container is running
- Try to get a secret out of an Azure Key Vault, to verify authentication schemes
- Perform a benchmark on its disk, so that you can compare performance of different disk backends
- Run a process to shoot up CPU utilization (calculating x digits of the number Pi), and so triggering CPU-based autoscaling
- Access the backend database and provide the IP address with which the database sees the app
- Send a user-specified query to the database
- And much more
YADA’s face: the frontend
First of all, here what it looks like:
In early YADA versions the web frontend was nothing else than a graphical façade for the app, but I added a few features as I tested different scenarios:
- Distinct branding themes for different public events where I have used this app. To the default YADA I added a WhatTheHack theme, and another one that you might find out looking at the source code (spoiler alert!)
- Option to only accept requests that take a certain HTTP Header and value, which is critical when integrating with Azure Front Door
- Different background colors, which is nice when testing multiple regions or environments (think blue/green, for example)
- The title can be obtained either from the Azure Instance Meta Data Service (IMDS) or from the hostname (where IMDS doesn’t work)
- Hello world for HTML (
/healthcheck.html) and PHP (/healthcheck.php), useful for healthchecks from reverse proxies - Showing the logged username, which can come handy when testing reverse proxies with authentication functionality
- Displaying all HTTP headers
The web tier has also a section to call some of the API tier endpoints without having to open a new window and curl your way:
How do I run it?
In the README file of the Github repo you can find instructions on how to run YADA on different platforms:
- Docker containers
- Azure Container Instances
- Azure Container Instances and nginx sidecar for TLS
- Kubernetes
- Web Apps
- Azure Virtual Machines
Anything missing?
Is this useful?
If you see a point in using YADA in your workshops, demos or troubleshooting sessions, please let me know how that goes!
Cloudtrooper 