Since the last post, a new version (1.4) of the Kong API Gateway has been released. The biggest change is the /status route. The status of a gateway can be queried directly via this route. In December, a patch (1.4.1) was released.
Now that the first two services have been created manually, it is time to think about the first possibilities of automation. Since the design and development process of APIs should take place on the basis of continuous software development processes, we need a way to integrate the creation of services, routes and the linking of plug-ins into existing CI/CD processes. Here decK can be a big help. The tool was developed by Harry Bagdi. Harry works as a Senior Cloud Engineer at Kong.
decK
decK enables us to create declarative configurations in the form of a YAML file for Kong and thus to provide extended possibilities for maintaining the configuration of the Kong API gateway. The most important feature here is reverse-sync, which enables decK to detect current entities in the Kong database that are not yet part of the configuration file.
First of all, I want to read the configuration from the API gateway. This is done via a dump.
deck dump
By executing the command, the whole configuration is written from the database into a YAML file.
_format_version: "1.1"
services:
- connect_timeout: 60000
host: host.docker.internal
name: service1
path: /api/service1
port: 80
protocol: http
read_timeout: 60000
retries: 5
write_timeout: 60000
routes:
- name: service1_route
methods:
- GET
paths:
- /service1
preserve_host: false
protocols:
- http
- https
regex_priority: 0
strip_path: true
https_redirect_status_code: 426
plugins:
- name: key-auth
config:
anonymous: null
hide_credentials: false
key_in_body: false
key_names:
- apikey
run_on_preflight: true
enabled: true
run_on: first
protocols:
- grpc
- grpcs
- http
- https
- connect_timeout: 60000
host: host.docker.internal
name: service2
path: /api/service2
port: 80
protocol: http
read_timeout: 60000
retries: 5
write_timeout: 60000
routes:
- name: service2_route
methods:
- GET
paths:
- /service2
preserve_host: false
protocols:
- http
- https
regex_priority: 0
strip_path: true
https_redirect_status_code: 426
plugins:
- name: key-auth
config:
anonymous: null
hide_credentials: false
key_in_body: false
key_names:
- apikey
run_on_preflight: true
enabled: true
run_on: first
protocols:
- grpc
- grpcs
- http
- https
consumers:
- username: api-user
keyauth_credentials:
- key: secret_key
Assigning the route /service1 using http POST :8001/services/service1/plugins name=proxy-cache config.strategy=memory -f
with the Proxy-Cache-Plug-in will lead to a comparison of the saved configuration with the current entries in the Kong database using deck diff
. Now the so-called drift detection comes into effect, because the cache plug-in does not exist in the YAML file.
deleting plugin proxy-cache for service d9a029b8-5e5c-4f33-8131-a77197903275
Summary:
Created: 0
Updated: 0
Deleted: 1
If I execute a sync, the plug-in will be deleted from the database.
This shows that decK can easily detect changes by Kong’s Admin-API. This can be built into the CI pipeline to be able to react to changes in the configuration file with a cronjob.
Konga
So far I have only used the Kong Gateway via the Admin API. Especially in a team this can’t really contribute to a better transparency regarding the API gateway. We humans clearly love the visual. And that’s why we always like dashboards. For Lexico, a dashboard is: “A graphical summary of various pieces of important information, typically used to give an overview of a business.” (https://www.lexico.com/definition/dashboard). Exactly such a dashboard is not part of the Kong API gateway as an open source product. That’s why Panagis Tselentis, Software Engineer at ING, developed Konga. Konga is also an open source product that enables you to manage all Kong Admin API objects in one graphical interface.
To make Konga part of the existing demo, I extend our existing docker-compose-file by the following lines:
konga-prepare:
image: pantsel/konga:next
container_name: konga-prepare
command: "-c prepare -a postgres -u postgresql://kong@kong-database:5432/konga_db"
networks:
- kong-blogposts
restart: on-failure
depends_on:
- kong-database
konga:
image: pantsel/konga:latest
container_name: konga
restart: always
networks:
- kong-blogposts
environment:
- DB_ADAPTER=postgres
- DB_HOST=kong-database
- DB_USER=kong
- TOKEN_SECRET=km1GUr4RkcQD7DewhJPNXrCuZwcKmqjb
- DB_DATABASE=konga_db
- NODE_ENV=production
- NO_AUTH=true
depends_on:
- kong-database
- konga-prepare
ports:
- "1337:1337"
Since Konga also needs a database, I also created a container for the setup of the database (konga-prepare). The application is called by http://localhost:1337.
Now a connection to the Kong API gateway has to be established.

Afterwards I obtain first information about my gateway in a very simple form.

Since I want to focus on the automation of the Kong API gateway within CI/CD processes, this short look at Konga should suffice. You can also find the adjustments in the repo on GitHub.