How to deploy geoip-attack-map on Kubernetes

4 min readSep 11, 2022

This article is about to demonstrate how we fork a geoip-attack-map opensource project from this MatthewClarkMay/geoip-attack-map GitHub repository and containerize it to make it deployable on Kubernetes.

The geoip-attack-map is the project to real-time visualize the cyber security attack on the world map, please take a look this link for a demo. The point is, I don’t want to deploy the application by using the primitive way like install it on server directly. I want to run it on Kubernetes instead but based on the code and instruction from that repository it does not support yet.

In this article we will fork code from the repository and create docker files (containerize it), modify code a bit to make it configurable via environment variables setting. Then we will create Helm chart to simplify the process for deployment to Kubernetes.

The GitHub project we cloned uses JavaScript library from Mapbox to render the world map on web browser. We will need to register to Mapbox in order to gain a free public API key.

Source Code

The new forked code are kept in this repository geoip-attack-map. There are 2 services in the same repository. The 1st one is attack-map-server which works like a web application and the 2nd is attack-map-feeder which works like a data feeder who feeds the cyber attacks data to the web server via message queue (we’re using Redis for the message queue implementation). These are the enhancements I added into the forked repository.

Created 2 docker files in order to containerize the application.
Make the application to be more configurable via environment setting.
Created a Helm chart to simplify the application deployment process to Kubernetes cluster.
Created a CI/CD pipeline (GitHub Actions) to build chart and 2 docker files as well.

I only tested the application by deploying it to Rancher Kubernetes Engine (RKE) cluster. The application also runs behind the reverse proxy (NGINX ingress controller) who handles the TLS for us, this is the reason why we use “wss” scheme for the WebSocket in the code.

Containerizing the application

Because we want to deploy the application into Kubernetes cluster so, we need to create 2 docker images, one for attack-map-server and another for attack-map-feeder which later each container will run in its own pod.

Once both docker images are built, they will be kept in the Google Container Registry here gcr.io/its-artifact-commons/attack-map-server and gcr.io/its-artifact-commons/attack-map-feeder which I set to allow for public pulling.

Making the application to be more configurable

The code from original repository seems to do a lot of hard coding so I modified the forked code as the following.

Change the way to identify the endpoint where WebSocket should connect to but assuming to use wss scheme.
Pass the latitude and longitude of the head headquarter via the environment variables.
Pass the Mapbox API token via environment variable.
Pass the Redis IP address via environment variable.

Creating Helm chart for the application deployment

As mentioned earlier, we need to simplify the deploy process so I decided to create a Helm chart and keep it in the same repository here.

If we take a look deeper into the attack-map-feeder deployment, we will see that there are 2 containers in the same pod. The 1st container is the attack-map-feeder itself and the 2nd one is the syslog-ng container who is waiting for cyber attack data via Syslog protocol (the syslog-ng container is working like a sidecar container).

Once the syslog-ng container receives the cyber attack data, it then write the data to file /var/log/syslog as we configure in the syslog-ng.conf. Once the /var/log/syslog file is available then the attack-map-feeder starts to process the data in the file and feeds them to Redis for later used by attack-map-server.

By using the sub-chart from Bitnami, this Helm chart also deploy the standalone Redis for us. We also give a special thank for this generic-app sub-chart too.

Using test data generator script

There is a test data generator script provided in the original repository. I modified it a little bit here in the forked repository. Once the application is deployed, we can use kubectl exec into the attack-map-feeder pod and run the script as shown below.