Consider the following: You’re migrating some microservices to Kubernetes with certain API dependencies, which are not yet reachable. There can be plenty of reasons for that: Some dependent services run in a highly secured data center on-prem and are not yet migrated, some APIs may not be fully developed yet.
In this post we explore the use of Mockoon in Kubernetes: We’ll expose Mockoon via internal DNS and make it reachable for a simple test web application.
Exploring the Mockoon GUI
I highly recommend checking out the desktop app over here: https://mockoon.com/download/. If you’re following on macOS, just use brew for convenience:
The Mockoon UI enables you a postman-y overview of all your mock routes. It’s quite intuitive, feel free to play around with it. If you find youself struggling with the navigation, check out their great Mockoon GUI cheat sheet.
In our demo app we’ll be using the plain demo API with faker.js in the background generating some random userdate on the route /users
. Right-click the “Demo API” in the left sidebar and grab the json file containing the config. That’s what we’ll need in the next step.
Mockoon + Docker = ♥️
We’ll be using the actively maintained Docker image Mockoon CLI. To try out the image locally, grab your exported json file and give it a spin:
Now curl your mock API:
Great! Your Mockoon server is exposed correctly. Now then, let’s build something in Go requesting our mock API.
Setting up the Go microservice
For my exemplary microservice I’m using a small Golang server handling three routes, /
, /healthz
and /mockoon
. /mockoon will HTTP GET the mock API from mockoon’s /users
path and print it as plain text. If you want to follow along, grab the code from this GitHub Gist.
To reproduce a common DevOps practice our server will pull the mockoon route /users
from the environmental variable MOCKURL
. Once we deploy our k8s manifests, we’ll set the variable to http://mockoon.mockoon.svc.cluster.local/users
. Let’s check out the relevant function in go:
Dockerizing our Go Microservice
I highly encourage you to check out Google’s distroless container images.
Restricting what’s in your runtime container to precisely what’s necessary for your app is a best practice employed by Google and other tech giants that have used containers in production for many years. It improves the signal to noise of scanners (e.g. CVE) and reduces the burden of establishing provenance to just what you need.
The Dockerfile of our Go server will look like that:
Dont forget to build, tag and push your image to the repository of your liking. Also make sure your Kubernetes Cluster has the ability to pull your image from your desired registry.
Exposing Mockoon in Kubernetes
The basic infrastructure will look like this:
The Go server pod (go-mockoon) will be requesting the Mockoon pod (mockoon) by its internal DNS. The Mockoon pod mounts /data/data.json
from the ConfigMap (mockoon-data). Check out the manifests:
Now check your pods:
Now test your Go server by requesting the host you set in your ingress resource, i.e. go-mockoon.example.com. Tail the logs of your go-mockoon pod:
Requesting go-mockoon.example.com/mockoon
will redirect to the internal Mockoon pod /users
route, located at http://mockoon.mockoon.svc.cluster.local/users
. You should see the faker.js generated user data originating from the Mockoon pod 🦝 🎉.