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

Keine Kommentare

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.

deck dump

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

_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

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.

deleting plugin proxy-cache for service d9a029b8-5e5c-4f33-8131-a77197903275
Summary:
  Created: 0
  Updated: 0
  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:

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"

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.

kong api gateway

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

kong api gateway

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.

Daniel Kocot

Seit Oktober 2016 ist Daniel ein Teil des Teams der codecentric AG am Standort in Solingen. Schon seit Anfang der 2000er Jahre widmet er sich dem Thema der Digitalen Transformation. Neben den aktuellen Schwerpunkten API-Management, Application Lifecycle Management Tooling, Continuous Documentation und Voice UI ist er auch Experte für den Einsatz von Produktinformationssystemen (PIM) und Database-Publishing mithilfe von Rendering-Technologien.

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.