Seminar KrakenD – Erweiterung mit Go, Lua und benutzerdefinierter Logik

Inhaltsübersicht

1. Seminarprofil
2. Lernziele
3. Zielgruppe
4. Voraussetzungen
5. Seminarinhalte
6. Praxisübungen
7. Technische Arbeitsumgebung

Seminarprofil

Das Seminar zeigt, wie fehlende Funktionen ergänzt werden, ohne den Gatewaykern unnötig zu verkomplizieren. Zuerst werden deklarative Bordmittel, CEL und Lua geprüft; erst danach folgen Go-Plugins für Handler, Clients, Proxy und Request-/Response-Modifikation.

Ein Schwerpunkt liegt auf reproduzierbaren Builds, Versions- und Plattformkompatibilität, Tests, Sicherheitsprüfung und Releaseverfahren. Zusätzlich wird die Versionsstrategie für die kommende 3.x-Linie behandelt, in der Go-Plugins in der Community Edition nicht mehr vorgesehen sind, während sie in der Enterprise Edition fortgeführt werden.

Lernziele

• Built-in-Funktionen, CEL, Lua, Go-Plugins und eigene Builds nach klaren Kriterien auswählen
• Lua-Skripte für begrenzte Request- und Response-Aufgaben sicher einsetzen
• geeignete Go-Plugin-Typen und Erweiterungspunkte bestimmen
• Plugins reproduzierbar für Laufzeitversion und Zielarchitektur bauen
• Fehler, Abhängigkeiten, Performance und Sicherheitsrisiken automatisiert testen
• eine tragfähige Migrationsstrategie für die KrakenD-3.x-Linie entwickeln

Zielgruppe

Go-Entwicklung, API- und Plattform-Engineering, DevOps, Softwarearchitektur und technische Security.

Voraussetzungen

Gute KrakenD-Konfigurationskenntnisse, sichere Go-Grundlagen, Docker und Erfahrung mit HTTP-APIs. Lua-Vorkenntnisse sind nicht erforderlich.

Seminarinhalte

1. Entscheidungsmodell für Erweiterungen

Eigener Code ist die letzte Stufe einer Entscheidungskette und muss einen klaren, dauerhaft tragfähigen Nutzen haben.

1. Schritt 1: Anforderung präzisieren und prüfen, ob Endpoint-, Backend-, Transformations- oder Policy-Funktionen bereits ausreichen.
2. Schritt 2: CEL für deklarative Bedingungen und Lua für lokal begrenzte Logik bewerten.
3. Schritt 3: Go-Plugin oder eigener Build nur bei echten Integrations- oder Laufzeitanforderungen wählen.
4. Schritt 4: Wartung, Sicherheitsupdates, Testaufwand und Versionsbindung vor der Implementierung dokumentieren.

2. Lua für Request und Response

Lua eignet sich für kleine, klar begrenzte Transformationen, darf aber nicht zur versteckten Anwendungsplattform werden.

1. Schritt 1: Ausführungspunkt und verfügbare Request-, Backend- oder Response-Daten bestimmen.
2. Schritt 2: Ein kleines Skript mit eindeutigen Eingaben, Ausgaben und Fehlern erstellen.
3. Schritt 3: Nil-Werte, Datentypen, große Payloads und unerwartete Strukturen defensiv behandeln.
4. Schritt 4: Skriptlaufzeit, Fehlermeldungen und Regressionen mit festen Testfällen prüfen.

3. Plugin-Typen und Ausführungsfluss

Der Erweiterungspunkt entscheidet über Reichweite, Sicherheitswirkung und mögliche Seiteneffekte.

1. Schritt 1: HTTP-Server-Handler für frühe Requestverarbeitung und Zugangskontrolle einordnen.
2. Schritt 2: HTTP-Client-Plugins für spezielle Backendkommunikation bewerten.
3. Schritt 3: Proxy-Plugins sowie Request- und Response-Modifier entlang des Datenflusses zuordnen.
4. Schritt 4: Den kleinstmöglichen Erweiterungspunkt wählen und globale Seiteneffekte vermeiden.

4. Go-Plugin implementieren

Das Plugin wird als kleine, testbare Komponente mit stabiler Konfigurationsoberfläche entwickelt.

1. Schritt 1: Pluginvertrag, Namensraum und erwartete Konfigurationsfelder definieren.
2. Schritt 2: Initialisierung, Validierung und Laufzeitlogik voneinander trennen.
3. Schritt 3: Kontext, Zeitüberschreitung, Abbruch und kontrollierte Fehlerantworten berücksichtigen.
4. Schritt 4: Keine Zugangsdaten protokollieren und externe Abhängigkeiten auf das notwendige Minimum begrenzen.

5. Build- und Kompatibilitätskette

Go-Plugins benötigen eine exakt abgestimmte Toolchain aus KrakenD-Version, Go-Version, Abhängigkeiten, Architektur und C-Bibliothek.

1. Schritt 1: Builder und Zielimage auf dieselbe KrakenD-Patchlinie festlegen.
2. Schritt 2: Abhängigkeiten mit dem Plugin-Check prüfen und Konflikte vor dem Build beheben.
3. Schritt 3: AMD64- und ARM64-Artefakte getrennt erstellen und eindeutig kennzeichnen.
4. Schritt 4: Plugin und Gateway gemeinsam als unveränderliches Releaseartefakt testen.

6. Qualität, Sicherheit und Performance

Eigener Code läuft im Gatewayprozess und kann deshalb Verfügbarkeit und Vertrauensgrenzen des gesamten Systems beeinflussen.

1. Schritt 1: Unit Tests für Konfiguration, Fehler und Kernlogik erstellen.
2. Schritt 2: Integrationstests mit realer Gatewaylaufzeit und mehreren Parallelaufrufen ausführen.
3. Schritt 3: Panik, Speicherwachstum, blockierende I/O und langsame Abhängigkeiten gezielt provozieren.
4. Schritt 4: Codeprüfung, Abhängigkeitsanalyse, Lasttest und Rollback als Freigabepflicht festlegen.

7. Release und 3.x-Migrationsstrategie

Die Erweiterungsstrategie muss über die aktuelle 2.x-Linie hinaus geplant werden.

1. Schritt 1: Bestand an CE-Plugins nach Geschäftskritikalität und Ersatzmöglichkeiten inventarisieren.
2. Schritt 2: Für 3.x zwischen Enterprise-Plugin, eigener Community-Kompilierung, externem Dienst oder Rückbau entscheiden.
3. Schritt 3: Migrationspfad mit parallelen Tests und klarer Rückfalloption entwickeln.
4. Schritt 4: Versionsmatrix, Artefaktablage, Verantwortlichkeit und Supportgrenze dauerhaft dokumentieren.

Praxisübungen

• Bewertung einer Anforderung mit Built-in-, CEL-, Lua- und Plugin-Entscheidungsmatrix
• Lua-Modifikation einer Backendantwort mit Fehlerbehandlung
• Implementierung eines kleinen Go-Request- oder Response-Modifiers
• Reproduzierbarer Plugin-Build und Abhängigkeitsprüfung
• Last-, Fehler- und Rollbacktest des gemeinsamen Gateway-Artefakts
• Migrationsplan für ein vorhandenes Community-Plugin in Richtung 3.x

Technische Arbeitsumgebung

Benötigt werden Go, Docker, Git, ein passender KrakenD-Builder, ein JSON-fähiger Editor und lokale Beispieldienste. Für Architekturtests stehen AMD64- und ARM64-Szenarien als vorbereitete Aufgaben bereit.