Was ist neu in ADC 0.11 & 0.12?

Seit der Veröffentlichung von ADC (API Declarative CLI) Version 0.10 vor zwei Monaten haben wir unermüdlich daran gearbeitet, zwei große Updates – die Versionen 0.11 und 0.12 – sowie eine Reihe gezielter Patch-Updates zu liefern. Diese Updates konzentrieren sich hauptsächlich auf die Unterstützung von Apache APISIX, die Verbesserung bestehender Funktionen und die Behebung von Fehlern.

Unterstützung für Apache APISIX hinzugefügt

Ab ADC 0.11 wurde die experimentelle Unterstützung für das Apache APISIX-Backend eingeführt.

ADC ist nun in die APISIX Admin API integriert, was einen effizienten Export und eine Synchronisierung von Ressourcen ermöglicht. Wir werden die Benutzerfreundlichkeit weiter verbessern. Die apisix-Backend-Option ist in ADC standardmäßig aktiviert; Benutzer müssen lediglich den Admin API-Endpunkt und den API-Schlüssel konfigurieren, um eine Verbindung herzustellen.

Unterschiede zwischen ADC und der Admin API

Bitte beachten Sie, dass ADC nicht darauf abzielt, alle Funktionen von APISIX vollständig abzudecken, sondern sich auf einen Kernfunktionsumfang und Best Practices konzentriert. Wir glauben, dass die Investition in Funktionen, die Benutzer wirklich benötigen, anstatt blind auf umfassende Abdeckung zu setzen, der Entwicklungsweg für ADC ist.

Obwohl APISIX ein hohes Maß an Konfigurationsflexibilität bietet, geht diese Freiheit oft mit der Komplexität der langfristigen Wartung einher. Wenn die Konfigurationsverwaltung von einem Betreuer auf einen anderen übertragen wird, steht der neue Betreuer typischerweise vor der Herausforderung, den einzigartigen Konfigurationsansatz und -stil des vorherigen Betreuers zu verstehen, anstatt direkt eine Reihe von ausgereiften und allgemein anerkannten Best-Practice-Regeln zu übernehmen.

Beispielsweise können Benutzer auf der APISIX-Plattform Routen konfigurieren, die nicht direkt an bestimmte Dienste gebunden sind, sondern stattdessen Upstream-Ressourcen direkt auf Routenebene angeben. Diese Methode wird jedoch von ADC nicht nativ unterstützt. Um sich an logische Normen und standardisierte Betriebsverfahren anzupassen, ist der empfohlene Ansatz, Routen in einen bestimmten Dienst einzubinden und die Upstream-Adressen genau innerhalb dieses Dienstes festzulegen.

Beispielsweise definieren wir in einem Produktdienst einen Dienst namens Product Service und konfigurieren den Upstream, aktivieren Plugins und legen Routen darin fest. In diesem Modell können mehrere Routen denselben Upstream und dieselbe Plugin-Konfiguration teilen, was den Konfigurationsprozess erheblich vereinfacht.

services:
  - name: Product Service
    upstream:
      type: roundrobin
      nodes:
        - host: product.ecommerce.svc.cluster.local
          port: 443
          weight: 100
      scheme: https
    plugins:
      key-auth: {}
    routes:
      - name: List Products
        uris:
          - /products
        methods: ["GET"]
      - name: Get Product
        uris:
          - /product/*
        methods: ["GET"]

Das obige Beispiel ist ein minimales Format für die Dienstdefinition. Darüber hinaus unterstützt ADC auch erweiterte Funktionen wie Service Discovery, Timeout-Einstellungen, Wiederholungsrichtlinien und Routenpriorisierung, um eine umfassende und flexible Konfiguration zu gewährleisten.

Da APISIX reichhaltigere Konfigurationsmethoden unterstützt, kann es bei ADC zu Inkonsistenzen beim Export von Konfigurationen im Vergleich zur APISIX Admin API-Anzeige kommen, wie z.B.:

• Routen, die keine Dienste verwenden, werden in einen Dienst gruppiert, um die Dienst-Routen-Hierarchie zu erfüllen.
• Upstreams, die per ID referenziert werden, werden an der Verwendungsstelle inline gesetzt.
• Plugin-Vorlagenressourcen werden durch Dienste ersetzt, die Routen enthalten.

Daher müssen Benutzer die während des Exportprozesses generierten ADC-Definitionsdateien sorgfältig überprüfen, um sicherzustellen, dass sie den ursprünglichen Absichten entsprechen.

Warum wird ADC empfohlen?

Bei der Verwendung des APISIX Dashboards müssen Benutzer oft wiederholte Operationen in Formularen durchführen, was umständlich und fehleranfällig sein kann. Im Gegensatz dazu beinhaltet die deklarative Konfiguration mit ADC lediglich das Schreiben von YAML-Dateien und die Ausführung von Synchronisationsoperationen. ADC konvertiert die Konfigurationen automatisch in Admin API-Aufrufe, was eine schnelle Bereitstellung und Verwaltung ermöglicht.

Somit kann ADC helfen, den Verwaltungs- und Bereitstellungsprozess zu vereinfachen, und es kann leicht GitOps-Szenarien erreichen. Dies beinhaltet die Verwaltung von YAML-Definitionsdateien über ein Git-Repository und die Verwendung von PR-Workflows und CI-Tools, um Konfigurationen automatisch zu aktualisieren. Dies reduziert den manuellen Aufwand erheblich, vermeidet die Probleme des APISIX Dashboards und verringert die Komplexität des Schreibens von Skripten, um die Admin API aufzurufen.

Für neue Projekte empfehlen wir dringend, Gateway-Konfigurationen mit ADC zu beginnen. Für bestehende Projekte kann eine schrittweise Migration zur ADC-Verwaltung durch den Export und eine moderate Anpassung der Konfigurationen erreicht werden.

Backend-Optimierung von API7 Enterprise

Enthalten in den Versionen 0.11/0.12

In den Versionen 0.11 und 0.12 haben wir mehrere Optimierungen für das API7-Backend implementiert, um die Entwicklererfahrung zu verbessern. ADC ist vollständig mit diesen Verbesserungen kompatibel, was bedeutet, dass Entwickler lediglich ihre ADC-Version auf dem neuesten Stand halten müssen, um von diesen Verbesserungen zu profitieren, ohne bestehende Definitionsdateien ändern zu müssen.

Optimierung der ADC-Definitionsprüfungen

Enthalten in Version 0.12

Wir haben die Schema-Regeln für ADC-Definitionsprüfungen umfassend optimiert und korrigiert, um Entwicklern zu helfen, potenzielle Konfigurationsprobleme im Voraus zu erkennen und effektiv zu vermeiden.

JSON Schema

Darüber hinaus unterstützen wir jetzt den Export der Validierungsregeln als JSON Schema, um Editoren in IDEs zu unterstützen. Benutzer profitieren sowohl von Syntaxhinweisen als auch von Echtzeitprüfungen in ihren Dateien, was die Codierqualität und -effizienz erheblich verbessert.

Für Entwickler, die Visual Studio Code bevorzugen, kann diese Funktion aktiviert werden, indem das YAML-Plugin aktiviert und der folgende Kommentar am Anfang der Datei hinzugefügt wird:

# yaml-language-server: $schema=https://raw.githubusercontent.com/api7/adc/main/schema.json

Fazit

Wie bereits in unseren Blogs erwähnt, wird ADC schließlich Open Source sein. Nach sechs Monaten interner Entwicklung und mehreren Iterationen wurde ADC vollständig in eine TypeScript-basierte Codebasis umstrukturiert, wobei der ursprüngliche Go-Code vollständig aufgegeben wurde. Dies macht es einfacher zu lernen und zu entwickeln.

Mit der öffentlichen Veröffentlichung von ADC Version 0.12 laden wir Entwickler weltweit ein, an der Entwicklung und Verbesserung teilzunehmen. Die Codebasis ist jetzt unter https://github.com/api7/adc geöffnet, und wir freuen uns auf Ihre Beiträge.