Tuesday, September 11, 2018

Configuring Kong API Gateway for your Service Endpoints

Kong provides a complete documentation on its installation and a quick-start guide to start using it, such as configuring a service in Kong

In this post we will briefly look into configuring Kong using its Docker container as an API gateway for your backend services. This document uses Kong version 0.14.0-alpine, which is the current latest version of Kong. Kong can be configured with Postgres or Cassandra backend for its persistent storage. Here we will configure Kong with Postgres.

Install and Start Kong with Postgres

You have 2 options. If you want to get it done quick, I recommend choosing the option #2 - installing via Docker containers.

1. Download Kong's native installation for your operating system

Download and install Kong for your respective operating system 

Configure with Postgres:
$ psql -U postgres
postgres=# CREATE USER kong; CREATE DATABASE kong OWNER kong;

Run the Kong migrations:
$ kong migrations up

Start Kong
$ kong start

You may choose to start with verbose logs:
$ kong start -vv

You may need to create a kong configuration file to load Kong with custom configurations:
$ sudo mkdir /etc/kong

$ sudo touch /etc/kong/kong.conf

Now your Kong is running. Confirm that by,


2.  Install Kong via Docker containers.

We have our own "kong-ldap" repository with scripts that will install and configure Kong with Postgres in a container. 

$ cd kong-ldap

$ sh buildRun.sh

Optionally, you may also use these scripts to configure OpenDJ LDAP directory as a Docker container a well, connected to Docker. However, the commands are commented out - therefore you will need to uncomment the relevant commands in the script buildRun script to get it working.

Kong has two interfaces. One is the user-facing interface and the other one is the admin interface. The admin interface by default listens to the port 8001 and should not be exposed to the public. The admin interface is used by the administrators to create and configure the routes to the services in the Kong API gateway. The user-facing interface by default listens to the port 8000. It is exposed to the public, and the users can consume the services defined by the admin previously using the user-facing interface. The user-facing interface is completely separated by Kong from the admin interface.

Configure Kong for your Services

Configuring Kong as an API gateway for your services is a 2-step procedure, starting from Kong 0.14. Previous versions of Kong provided a unified approach through its "api" objects, which is current depreciated and replaced by two entities known as "services" and "routes".

Make sure that you have Kong up and running. Then,  execute the below two commands from the server that hosts Kong.

First, you need to define a "service" in Kong to each of your service/API groups (i.e., your backend applications or web services).

1) Create a Kong Service using the Kong Admin API

$ curl -i -X POST --url http://localhost:8001/services/ --data 'name=radiology' --data 'url='

Above, we assume your web application is hosted in  and it has a set of services under the base path /services/v4/TCIA/query/. We pass the complete url of the backend of the original service deployments through the "url" flag, as shown above. We create a service named "radiology" in Kong for these services, using the Kong admin interface for the creation of services. Here, we assume Kong is hosted in localhost, with its admin interface using the default port option of 8001. /services/ let you create/modify the service definitions in Kong.

Second, you should add a "route" to the "radiology" service that you created.

2) Add a Route to the Kong Service

$ curl -i -X POST --url http://localhost:8001/services/radiology/routes --data 'paths=/radiology'

 As shown above, we use the KONG-ADMIN-INTERFACE/services/SERVICE-NAME/routes to configure the routes to the service that we defined above. Here the SERVICE-NAME is "radiology" as we defined above in the previous step. The "paths" flag indicate the paths that Kong should match to the service that we defined in the previous step.

Accessing your services via Kong

Now, you may access your services via Kong
the same way you access it directly

Here, we assume that you have deployed Kong in a server with a public address and your services are in

You may of course do additional tasks such as rate limiting, request/response transformations, logging, and analytics with the Kong API Gateway. You may refer to the Kong documentation on pointers to achieving this.

1 comment:

You are welcome to provide your opinions in the comments. Spam comments and comments with random links will be deleted.