Quoi de neuf dans ADC 0.11 et 0.12 ?

Depuis la sortie de ADC (API Declarative CLI) version 0.10 il y a deux mois, nous avons travaillé sans relâche pour livrer deux mises à jour majeures—les versions 0.11 et 0.12, ainsi qu'une série de correctifs ciblés. Ces mises à jour se concentrent principalement sur le support d'Apache APISIX, l'amélioration des fonctionnalités existantes et la correction de bugs.

Ajout du support backend pour Apache APISIX

À partir de ADC 0.11, un support expérimental pour le backend Apache APISIX a été introduit.

ADC est désormais intégré à l'API Admin d'APISIX, permettant une exportation et une synchronisation efficaces des ressources. Nous continuerons à améliorer son utilité. L'option de backend apisix est activée par défaut dans ADC ; les utilisateurs n'ont qu'à configurer le point de terminaison de l'API Admin et la clé API pour se connecter.

Différences entre ADC et l'API Admin

Veuillez noter qu'ADC ne vise pas à s'aligner complètement sur toutes les fonctionnalités d'APISIX, mais se concentre plutôt sur un ensemble de fonctionnalités de base et des meilleures pratiques. Nous croyons qu'investir dans les fonctionnalités dont les utilisateurs ont réellement besoin, plutôt que de chercher à couvrir tout de manière exhaustive, est la voie à suivre pour le développement d'ADC.

Bien qu'APISIX offre une grande flexibilité de configuration, cette liberté s'accompagne souvent de la complexité de la maintenance à long terme. Lorsque la gestion de la configuration est transférée d'un mainteneur à un autre, le nouveau mainteneur est généralement confronté au défi de comprendre l'approche et le style de configuration uniques du mainteneur précédent, au lieu d'adopter directement un ensemble de règles de meilleures pratiques matures et largement reconnues.

Par exemple, sur la plateforme APISIX, les utilisateurs peuvent configurer des routes qui ne sont pas directement liées à des services spécifiques, mais qui spécifient plutôt des ressources en amont directement au niveau de la route. Cependant, cette méthode n'est pas nativement supportée par ADC. Pour s'aligner sur les normes logiques et les procédures opérationnelles standardisées, l'approche recommandée consiste à inclure les routes dans un service spécifique et à définir précisément les adresses en amont dans ce service.

Par exemple, dans un service de produits, nous définissons un service nommé Product Service et configurons l'en amont, activons les plugins et définissons les routes à l'intérieur. Dans ce modèle, plusieurs routes peuvent partager la même configuration en amont et de plugin, simplifiant grandement le processus de configuration.

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"]

L'exemple ci-dessus est un format minimal pour la définition de service. Au-delà de cela, ADC supporte également des fonctionnalités avancées telles que la découverte de services, les paramètres de délai d'attente, les politiques de réessai et la priorisation des routes, garantissant une configuration complète et flexible.

Étant donné qu'APISIX supporte des méthodes de configuration plus riches, ADC peut rencontrer des incohérences lors de l'exportation des configurations par rapport à l'affichage de l'API Admin d'APISIX, telles que :

• Les routes n'utilisant pas de services seront regroupées dans un service pour respecter la hiérarchie service-route.
• Les en amont référencés par ID seront intégrés au point d'utilisation.
• Les ressources de modèle de plugin seront remplacées par des services contenant des routes.

Par conséquent, les utilisateurs doivent examiner attentivement les fichiers de définition ADC générés lors du processus d'exportation pour s'assurer qu'ils répondent toujours à l'intention originale.

Pourquoi ADC est-il recommandé ?

Lors de l'utilisation du tableau de bord APISIX, les utilisateurs doivent souvent effectuer des opérations répétitives dans des formulaires, ce qui peut être fastidieux et sujet à des erreurs. En revanche, l'utilisation d'ADC pour la configuration déclarative consiste simplement à écrire des fichiers YAML et à exécuter des opérations de synchronisation. ADC convertira automatiquement les configurations en appels d'API Admin, permettant un déploiement et une gestion rapides.

Ainsi, ADC peut aider à simplifier le processus de gestion et de déploiement, et il peut facilement réaliser des scénarios GitOps. Cela implique de gérer les fichiers de définition YAML via un dépôt Git et d'utiliser des workflows de PR et des outils CI pour mettre à jour automatiquement les configurations. Cela réduit considérablement la quantité d'opérations manuelles nécessaires, évite les problèmes présents dans le tableau de bord APISIX et réduit la complexité de l'écriture de scripts pour appeler l'API Admin.

Pour les nouveaux projets, nous recommandons fortement de commencer à construire les configurations de passerelle avec ADC. Pour les projets existants, une migration progressive vers la gestion ADC peut être réalisée en exportant et en modifiant modérément les configurations.

Optimisation du backend d'API7 Enterprise

Inclus dans les versions 0.11/0.12

Dans les versions 0.11 et 0.12, nous avons implémenté plusieurs optimisations pour le backend d'API7 afin d'améliorer l'expérience des développeurs. ADC est entièrement compatible avec ces améliorations, ce qui signifie que les développeurs n'ont qu'à maintenir leur version d'ADC à jour pour bénéficier de ces améliorations sans aucune modification des fichiers de définition existants.

Optimisation des vérifications de définition ADC

Inclus dans la version 0.12

Nous avons optimisé et corrigé de manière exhaustive les règles de schéma pour les vérifications de définition ADC afin d'aider les développeurs à détecter et à éviter efficacement les problèmes de configuration potentiels à l'avance.

JSON Schema

De plus, nous supportons désormais l'exportation des règles de validation sous forme de JSON Schema pour aider les éditeurs utilisant des IDE. Les utilisateurs bénéficieront à la fois d'indications de syntaxe et de vérifications en temps réel dans leurs fichiers, améliorant considérablement l'efficacité et la qualité du codage.

Pour les développeurs qui préfèrent Visual Studio Code, l'activation du plugin YAML et l'ajout du commentaire suivant en haut du fichier activeront cette fonctionnalité :

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

Conclusion

Comme mentionné précédemment dans nos blogs, ADC sera finalement open-source. Après six mois de développement interne et plusieurs itérations, ADC a été entièrement restructuré en une base de code basée sur TypeScript, abandonnant complètement le code Go d'origine. Cela le rend plus facile à apprendre et à développer.

Avec la sortie publique de la version 0.12 d'ADC, nous invitons les développeurs du monde entier à participer à son développement et à son amélioration. La base de code est désormais ouverte à https://github.com/api7/adc, et nous attendons avec impatience vos contributions.