Integration eines Kong API Gateways für eine Spring Boot Anwendung mit Apache Camel

Teil 3

Im finalen Teil unserer Reihe behandeln wir nun die Integration und Konfiguration des Kong API Gateways für unsere Spring Boot Anwendung. Die hierfür verwendeten Komponenten sind in Abbildung 1 rot umrahmt.

Abbildung 1 Aufbau der Architektur

Vollständiger Code verfügbar unter:

https://git.opitz-consulting.de/scm/oclab/blue-335-api-gw-camel-integration.git

Konfiguration des API Gateways Kong:

Die Initiale Docker Konfiguration des API Gateways kann dem Docker Compose File im Verzeichnis „/docker“ entnommen werden. Diese beinhaltet die Container Konfigurationen für Kong, Konga, eine Autokonfiguration für Kong mittels decK, eine Postgres Datenbank, die mit Kong verknüpft ist, sowie unsere Spring Boot Anwendung.

Über Docker Compose können die Komponenten einfach gestartet werden. Die Kong Admin API ist dabei lokal unter der URL „http://localhost:8001“ verfügbar.

Wir möchten nun zeigen wie wir das API Gateway Kong konfigurieren können. Dabei verwenden wir zwei weitere Open Source Tools, Konga und decK.

Konga ist ein Open Source GUI Tool für Kong und eine kostenlose alternative zur Enterprise Kong Manager GUI. Konga ermöglicht eine einfache grafische Steuerung von Kong, hier können die gleichen Einstellungen wie über die REST basierte Admin API vorgenommen werden, die ausführlich auf der offiziellen Seite von Kong dokumentiert ist.

Konga läuft standardmäßig auf dem Port 1337. In unserem Setup muss für die erste Nutzung von Konga lediglich einmal manuell eine Verbindung zum Kong Admin Interface erstellt werden. Dafür müssen die Kong Admin URL und die für Kong konfigurierten Authentifikationsdaten (in unserem Fall nur die default Werte) eingegeben werden.

Abbildung 2 Verbindungskonfiguration Konga

Um das Kong Gateway unter einer bestimmten URL erreichbar zu machen benötigen wir zunächst einen Kong Service. Ein Service repräsentiert eine externe Upstream API oder einen Microservice. Der Service verweist also auf die von unserem Gateway geschützten Anwendung. Ein Service kann wiederum mehrere Kong Routen exponieren, mit den hier definierten URLs können Anfragen an unser Gateway gesendet werden. Ohne Route kann ein Service nicht angesteuert werden.

In unserer Beispielanwendung haben wir zwei Services über die Kong Admin API angelegt, die dafür benötigten Schritte können der offiziellen Dokumentation auf https://docs.konghq.com/getting-started-guide/2.1.x/expose-services/ entnommen werden. Diese Konfiguration ist ebenso grafisch über Konga möglich.

Abbildung 3 Routen mit dazugehörigen Services in Konga

In Abbildung 3 sind unsere zwei Kong Routen mit ihrem jeweiligen Service zu sehen. Über die hier definierten Routen „/servlet“ und „/greeting“ können wir diese nun über

ansprechen.

Wird nun beispielsweise die Route „/servlet“ aufgerufen wird eine Anfrage an den Upstream Service gestellt.

Abbildung 4 Kong „camle_service“ in Konga

In Abbildung 4 ist ein Teil der Konfiguration des Kong Services zu sehen. Unsere Anfrage an diesen werden weiter an die Route „/camel/hello/“ auf den Port 8080 geleitet, hier läuft standardmäßig unsere Spring Boot Anwendung. Eine Antwort der Anwendung wird dann auf dem umgekehrten Weg zurückgesendet.

In diesem Beispiel hat unser Gateway noch nichts weiter als ein Re-routing gemacht. Um nun verschiedene Gateway Features zu implementieren bietet Kong eine Reihe verschiedener Plugins. Wir werden beispielhaft die Verwendung eines dieser Plugins für unsere zweite Route „/greeting“ darstellen. Die Konfiguration nehmen wir hierbei mittels HTTPie (https://httpie.org/) über die Kong Admin API vor. Alternativ ist dies auch über curl möglich.

Wir möchten hier unsere Route über einen einfachen Authentifizierungsmechanismus absichern. Dafür verwenden wir das Plugin Key-Auth und fügen dies zu unserer Route „/greeting“ hinzu. Dafür verwenden wir folgenden Befehl:

http :8001/routes/greeting/plugins name=key-auth

Nach der Installation dieses Plugins wird Kong Anfragen auf dieser URL nur noch mit einem gültigen API Key an unsere im Service hinterlegte Spring Boot Route weiterleiten. Um nun eine erfolgreiche Authentifikation zu ermöglichen muss zunächst ein Kong Consumer angelegt werden.

Per Kong Admin API kann man mit dem Befehl:

http :8001/consumers username=consumer custom_id=consumer

einen Consumer mit der Id consumer anlegen.

Zusätzlich fügen wir diesem Consumer dann noch einenen API Key hinzu:

http :8001/consumers/consumer/key-auth key=apikey

Nun kann man die URL mithilfe des API Keys beispielsweise mit

http :8000/greeting apikey:apikey

aufrufen. Unsere Authentifizierung ist nun erfolgreich und unsere Anfrage wird wie zuvor auf unsere Spring Boot Anwendung weitergeleitet.

Wir haben hier in diesem Beispiel den API Key explizit zugewiesen, in konkreten Anwendungsfällen ist es Best-practice diese automatisch von Kong generieren zu lassen. Dafür muss lediglich der vorherige Befehl für key-auth ohne expliziten key aufgerufen werden.

http :8001/consumers/consumer/key-auth <<< {}

Danach erhlält man einen generierten API Key von Kong in der HTTP Response.

Um nun unser Kong Gateway nicht auf jedem System neu konfigurieren zu müssen, möchten wir unsere Konfiguration automatisch beim Start unserer Anwendung laden. Hierfür gibt es mit decK ein Konfigurationstool mit dem Kong über eine deklarative Beschreibung konfiguriert werden kann. Dieses ist mit einem übersichtlich gestalteten CLI einfach zu bedienen. Des weiteren wäre es einfach möglich mit decK die aktuelle Kong Konfiguration im Zuge eines CI/CD Prozesses bei Änderungen zu aktualisieren.

Deck kann ein Konfigurationsfile „kong.yaml“ mit dem Befehl „deck sync“ in die aktuelle Kong Instanz laden. Dieses File kann theoretisch manuell geschrieben werden, einfacher ist es jedoch die Konfiguration einer einmal konfigurierten Instanz mit dem Befehl „deck dump“ automatisch abzuspeichern.

_format_version: "1.1"
services:
- connect_timeout: 60000
  host: gateway
  name: api_service
  path: /greeting
  port: 8080
  protocol: http
  read_timeout: 60000
  retries: 5
  write_timeout: 60000
  routes:
  - name: greeting
    paths:
    - /greeting
    path_handling: v0
    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
      protocols:
      - grpc
      - grpcs
      - http
      - https
- connect_timeout: 60000
  host: gateway
  name: camel_service
  path: /camel/hello
  port: 8080
  protocol: http
  read_timeout: 60000
  retries: 5
  write_timeout: 60000
  routes:
  - name: camel
    paths:
    - /servlet
    path_handling: v0
    preserve_host: false
    protocols:
    - http
    - https
    regex_priority: 0
    strip_path: true
    https_redirect_status_code: 426
consumers:
- custom_id: consumer
  username: consumer
  keyauth_credentials:
  - key: apikey

In unserer Beispielanwendung haben wir einmal unsere Einstellungen manuell vorgenommen und diese mit „deck dump“ abgespeichert.

Um diese Konfiguration nun beim Start von Kong über Docker Compose zu laden muss noch ein Job erstellt werden, der die abgespeicherte Konfiguration automatisch mit „deck sync“ lädt. Dafür wurde der hier definierte Container erstellt. Dieser beinhaltet das deck Image und synchronisiert beim Start von Docker Compose die zuvor abgespeicherte Kong Konfiguration.

  # deck kong config
  deck-kong:
    image: hbagdi/deck:latest
    networks:
      - internal
    depends_on:
      - kong
      - konga
    volumes:
      - './kong/kong.yaml:/kong.yaml:Z'
    command:
      - sync
    container_name: deck-kong
    environment:
      DECK_KONG_ADDR: "http://kong:8001"

Mit dem hier beschriebenen Set Up können wir also Kong mit Hilfe von Docker Compose und decK „out of the box“ mit einer beliebigen zuvor erstellten Konfiguration verwenden.

Um die vollständige Beispielapplikation auszuführen muss zunächst das Image der Spring Boot Anwendung erstellt worden sein. Anschließend kann nun das Docker Compose File in „/docker“ gestartet werden.

Zusammenfassung und Fazit

Die in dieser Reihe dargestellte Anwendung bietet einen kurzen Einblick in die grundlegenden Funktionalitäten von Kong und Camel im Zusammenspiel mit einer Spring Boot Anwendung. Durch das Setup mit Docker Compose und hier zusätzlich mit dem Konfigurationstool decK für Kong ist auch ein Deployment eines komplexeren Systems mit dieser Architektur einfach realisierbar.

Kong bietet mit seinem Plugin Konzept eine Reihe von einfach zu konfigurierenden Gateway Features. Die Evaluierung weiterer Features wie beispielsweise eines Authentifizierungsmechanismus über oAuth2 wären spannende Themen für weitere Blog Beiträge. Die Implementation von Camel erfordert bei fehlenden Kenntnissen zu Enterprise Integration Patterns eine gewisse Einarbeitungszeit, bietet aber dafür eine große Flexibilität bei der Implementierung von unterschiedlichen Integrationsanforderungen.

3 thoughts on “Integration eines Kong API Gateways für eine Spring Boot Anwendung mit Apache Camel”

    1. Hi Pascal, beide Anwendungen haben da erstmal grundsätzlich andere Ziele. Kong ist ein API Gateway und dient daher als Proxy. Es verwaltet den Zugriff auf womöglich mehrere dahinterligende Services mit Funktionen wie Authentifizierung, Traffic Managment etc. Kong bietet keine Funktionen um implementierungsrelevante APIs etc zu spezifizieren. Swagger würde man dann nach wie vor noch in der dahinterliegenden Anwendung verwenden.

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

%d Bloggern gefällt das: