Kong API Gateway – Deklarative Konfiguration mit decK und Visualisierung mit Konga

Seit dem letzten Post ist eine neue Version (1.4 ) des Kong API Gateways veröffentlicht worden. Die größte Neuerung stellt die /status-Route dar. Über diese lässt sich der Status eines Gateways direkt abfragen. Anfang Dezember ist auch ein Patch-Release (1.4.1 ) erschienen.

Nachdem nun die ersten zwei Services manuell angelegt wurden, ist es an der Zeit, über erste Möglichkeiten einer Automatisierung nachzudenken. Da der Design- und Entwicklungsprozess von APIs auf Basis kontinuierlicher Softwareentwicklungsprozessen stattfinden sollte, benötigen wir eine Möglichkeit, die Erstellung von Services, Routen und die Verknüpfung von Plug-ins in bestehende CI/CD-Prozesse einzubauen. Hier kann decK eine große Hilfe sein. Das Tool decK wurde von Harry Bagdi entwickelt. Harry arbeitet als Senior Cloud Engineer bei Kong.

decK

decK versetzt uns in die Lage, deklarative Konfigurationen in Form einer YAML-Datei für Kong zu erstellen und somit auch erweiterte Möglichkeiten der Pflege der Konfiguration des Kong API Gateways zu gewährleisten. Das wichtigste Feature ist hierbei reverse-sync , das decK in die Lage versetzt, aktuelle Entitäten in der Kong-Datenbank zu entdecken, die nicht noch Teil der Konfigurationsdatei sind.

Zu allererst möchte ich nun aus dem API Gateway die Konfiguration auslesen. Dies geschieht über einen Dump.

1deck dump

Durch Ausführen des Befehls wird die gesamte Konfiguration aus der Datenbank heraus in eine YAML-Datei geschrieben.

1_format_version: "1.1"
2services:
3- connect_timeout: 60000
4  host: host.docker.internal
5  name: service1
6  path: /api/service1
7  port: 80
8  protocol: http
9  read_timeout: 60000
10  retries: 5
11  write_timeout: 60000
12  routes:
13  - name: service1_route
14    methods:
15    - GET
16    paths:
17    - /service1
18    preserve_host: false
19    protocols:
20    - http
21    - https
22    regex_priority: 0
23    strip_path: true
24    https_redirect_status_code: 426
25  plugins:
26  - name: key-auth
27    config:
28      anonymous: null
29      hide_credentials: false
30      key_in_body: false
31      key_names:
32      - apikey
33      run_on_preflight: true
34    enabled: true
35    run_on: first
36    protocols:
37    - grpc
38    - grpcs
39    - http
40    - https
41- connect_timeout: 60000
42  host: host.docker.internal
43  name: service2
44  path: /api/service2
45  port: 80
46  protocol: http
47  read_timeout: 60000
48  retries: 5
49  write_timeout: 60000
50  routes:
51  - name: service2_route
52    methods:
53    - GET
54    paths:
55    - /service2
56    preserve_host: false
57    protocols:
58    - http
59    - https
60    regex_priority: 0
61    strip_path: true
62    https_redirect_status_code: 426
63  plugins:
64  - name: key-auth
65    config:
66      anonymous: null
67      hide_credentials: false
68      key_in_body: false
69      key_names:
70      - apikey
71      run_on_preflight: true
72    enabled: true
73    run_on: first
74    protocols:
75    - grpc
76    - grpcs
77    - http
78    - https
79consumers:
80- username: api-user
81  keyauth_credentials:
82  - key: secret_key

Wenn ich nun die Route /service1 mittels http POST :8001/services/service1/plugins name=proxy-cache config.strategy=memory -f mit dem Proxy-Cache-Plug-in belege, ist es im Anschluss möglich, mit deck diff die gesicherte Konfiguration mit den aktuellen Einträgen in der Kong-Datenbank zu vergleichen. Nun kommt die sogenannte drift detection zum Tragen, da das Cache-Plug-in in der YAML-Datei nicht existiert.

1deleting plugin proxy-cache for service d9a029b8-5e5c-4f33-8131-a77197903275
2Summary:
3  Created: 0
4  Updated: 0
5  Deleted: 1

Wenn ich nun im Anschluss einen Sync ausführe, wird das Plug-in aus der Datenbank gelöscht.

Dies zeigt, dass decK Änderungen durch Kongs Admin-API sehr einfach erkennen kann . Dies lässt sich nun in die CI-Pipeline entsprechend einbauen, um mittels eines Cronjobs auf Veränderungen in der Konfigurationsdatei reagieren zu können.

Konga

Grundsätzlich habe ich bisher das Kong Gateway nur über die Admin API bedient. Dies kann gerade in einem Team nicht wirklich zu einer besseren Transparenz hinsichtlich des API Gateways beitragen. Wir Menschen lieben ganz klar das Visuelle. Und deswegen finden wir auch immer wieder Gefallen an Dashboards. Für den Duden ist ein Dashboard: „Computerprogramm, das relevante Informationen zusammenfasst und übersichtlich darstellt“ (https://www.duden.de/rechtschreibung/Dashboard ). Genau ein solches Dashboard ist aber nicht Bestandteil des Kong API Gateways als Open-Source-Produkt. Deswegen entwickelte Panagis Tselentis , Software Engineer bei ING, Konga . Konga ist auch ein Open-Source-Produkt und versetzt uns in die Lage, alle Kong Admin-API-Objekte in einer grafischen Oberfläche zu verwalten.

Damit Konga ein Teil der vorhandenen Demo wird, erweitere ich unsere vorhandene docker-compose-Datei um die folgenden Zeilen:

1konga-prepare:
2    image: pantsel/konga:next
3    container_name: konga-prepare
4    command: "-c prepare -a postgres -u postgresql://kong@kong-database:5432/konga_db"
5    networks:
6      - kong-blogposts
7    restart: on-failure
8    depends_on: 
9      - kong-database
10
11  konga:
12    image: pantsel/konga:latest
13    container_name: konga
14    restart: always
15    networks:
16      - kong-blogposts
17    environment:
18      - DB_ADAPTER=postgres
19      - DB_HOST=kong-database
20      - DB_USER=kong
21      - TOKEN_SECRET=km1GUr4RkcQD7DewhJPNXrCuZwcKmqjb
22      - DB_DATABASE=konga_db
23      - NODE_ENV=production
24      - NO_AUTH=true
25    depends_on:
26      - kong-database
27      - konga-prepare
28    ports:
29      - "1337:1337"

Da Konga auch eine Datenbank benötigt, habe ich auch wieder einen Container für die Einrichtung der Datenbank (konga-prepare) erstellt. Die Applikation wird mittels http://localhost:1337 aufgerufen.

Nun muss noch eine Verbindung zum Kong API Gateway hergestellt werden.

Im Anschluss erhalte ich erste Informationen zu meinem Gateway in sehr einfacher Form.

Da ich das Hauptaugenmerk auf die Automatisierung des Kong API Gateways innerhalb von CI/CD-Prozessen legen möchte, soll dieser kurze Blick auf Konga reichen. Die Anpassungen findet ihr auch im Repo bei Github .