Kong API Gateway – Declarative configuration using decK and visualizations with Konga

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.