Apache APISIX 2.13.0 publié

Cela fait plus de six mois que la dernière version LTS d'Apache APISIX est sortie.Aujourd'hui, la communauté Apache APISIX a apporté une toute nouvelle version LTS - 2.13.0. Cette version LTS a non seulement des performances plus stables, mais prend également en charge plus d'observabilité, des plug-ins de découverte de services et un système de développement multilingue plus complet.

Si vous souhaitez essayer de nouvelles fonctionnalités tout en recherchant la stabilité globale, envisagez de mettre à niveau votre Apache APISIX existant vers la version 2.13.0. Les communautés suivantes publieront également une série de versions de correctifs basées sur la version 2.13.0.

Mise à jour des fonctionnalités

Nouveau : l'API n'est plus exposée par défaut

Dans les versions antérieures à 2.13.0, nous permettions aux plugins d'enregistrer des API pouvant être appelées par les clients. Par exemple, le jwt-authplug-in enregistre une interface de signature JWT à laquelle les clients peuvent accéder pour générer des signatures à des fins de vérification. Mais cette conception a un défaut potentiel - puisque l'interface est exposée au lieu de la route, elle ne peut pas être sécurisée autant que la route. Bien que le mécanisme existant permette aux utilisateurs d'intercepter l'accès à l'interface en écrivant l'intercepteur de plugin correspondant, cette méthode présente toujours des risques de sécurité.

Donc à partir de la version 2.13.0, nous avons décidé de faire un changement cassant et de ne plus exposer l' API par défaut **. ** Si l'utilisateur a besoin d'exposer l'interface, il doit lier l'interface à la route correspondante via le public-apiplugin . Cette approche apporte deux avantages :

L'API enregistrée aura une plus grande visibilité. Actuellement, l'API enregistrée ne prendra effet que via la configuration de l'affichage, et la méthode d'accès est également personnalisée par l'utilisateur.
Permet plus d'options de protection de sécurité, les API et les routes enregistrées ont le même contrôle d'autorisation.

Bien sûr, il y a d'autres nouveaux changements dans la version 2.13.0, comme la correction du comportement déraisonnable des versions historiques. Pour des informations d'optimisation spécifiques, voir 2.13.0 Changelog .

Nouvelle fonctionnalité : connectez davantage de systèmes de surveillance au niveau de l'observabilité

En tant que passerelle API, Apache APISIX s'est engagé à connecter plus de services et à connecter plus d'observabilité en amont et en aval. Nous nous appuyons sur cela à chaque version, et la 2.13.0 ne fait pas exception.

Cette fois, nous avons ajouté un plugin de traçage :**opentelemetry** **, qui permet d'envoyer des données de traçage OpenTelemetry au collecteur configuré. ** Voyons cela simplement à travers un exemple.

Le collecteur est défini dans la configuration statique :

plugin_attr:
  opentelemetry:
    resource:
      service.name: APISIX
      tenant.id: business_id
    collector:
      address: "127.0.0.1:4317"
    batch_span_processor:
      drop_on_queue_full: false
      max_queue_size: 6
      batch_timeout: 2
      inactive_timeout: 1
      max_export_batch_size: 2

Ensuite, vous pouvez activer le traçage sur une route spécifique :

curl http://127.0.0.1:9080/apisix/admin/routes/1  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "methods": ["GET"],
    "uris": [
        "/uid/*"
    ],
    "plugins": {
        "opentelemetry": {
            "sampler": {
                "name": "always_on"
            }
        }
    },
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:8089": 1
        }
    }
}'

Les requêtes qui atteignent cette route rapporteront les données OpenTelemetry au collecteur correspondant.

De plus, nous avons ajouté deux plugins de journal pour prendre en charge les journaux de rapport à ClickHouse et Loggly.

ClickHouse est l'une des bases de données OLAP les plus rapides de la planète. Apache APISIX prend en charge l'envoi du journal d'accès et du journal des erreurs à ClickHouse, les exemples sont les suivants :

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
      "plugins": {
            "clickhouse-logger": {
                "user": "default",
                "password": "a",
                "database": "default",
                "logtable": "test",
                "endpoint_addr": "http://127.0.0.1:8123"
            }
       },
      "upstream": {
           "type": "roundrobin",
           "nodes": {
               "127.0.0.1:1980": 1
           }
      },
      "uri": "/hello"
}'
curl http://127.0.0.1:9080/apisix/admin/plugin_metadata/error-log-logger -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
  "clickhouse": {
      "user": "default",
      "password": "a",
      "database": "error_log",
      "logtable": "t",
      "endpoint_addr": "http://127.0.0.1:8123"
  }
}'

Loggly est une plate-forme SaaS de traitement de journaux sous SolarWinds. Nous prenons en charge l'envoi de journaux d'accès via syslog ou HTTP/HTTPS. Un exemple est le suivant :

Configurer la méthode de rapport

curl http://127.0.0.1:9080/apisix/admin/plugin_metadata/loggly -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
   "protocol": "http"
}'

Configurer l'itinéraire à signaler

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins":{
        "loggly":{
            "customer_token":"xxx",
        }
    },
    "upstream":{
        "type":"roundrobin",
        "nodes":{
            "127.0.0.1:80":1
        }
    },
    "uri":"/index.html"
}'

Un système de développement multilingue plus complet

Apache APISIX prend en charge Wasm (Proxy Wasm SDK) depuis la version 2.11, mais la version LTS n'a pas fourni de prise en charge correspondante. Dans cette version d'Apache APISIX 2.13.0, nous avons ajouté et amélioré cette fonctionnalité.

Après six mois de développement avec plus de 10 000 lignes de code (y compris les tests et la documentation), APISIX prend désormais entièrement en charge l'exécution du code Wasm en quatre étapes de traitement des en-têtes de requête, des corps de requête, des en-têtes de réponse et des corps de réponse . La version 2.13.0 est la première version LTS à prendre en charge Wasm, ce qui peut être considéré comme une nouvelle étape.

En plus de Wasm, nous développons également un système de plug-in polyglotte traditionnel basé sur RPC. Il n'y a pas si longtemps, nous avons publié la version 0.2.0 de Python Runner. Dans quelques jours, nous publierons également Go Runner 0.3.0.

correction d'un bug

SkyWalking et OpenTelemetry ne suivent pas les échecs d'authentification.
log-rotateLe journal de coupe ne prend pas en charge l'achèvement à l'heure.
deepcopyPas de copie metatable.
request-validateGestion des clés en double dans JSON.
prometheusCalcul répété des métriques.
Quand conf.headersmanque , proxy-rewriten'a conf.methodaucun effet.
traffic-splitÉchec de correspondance lorsque la première règle échoue.
délai d'expiration etcd déclenché resync_delay.
protoConflit de définition.
limit-countLa configuration est inchangée et le compteur est réinitialisé.
Les nombres et pour plugin-metadatal' API d'administration sont incorrects.global-rule
Les étiquettes sont perdues lors de la fusion de l'itinéraire et du service.

plus de détails

Outre les fonctionnalités et composants ci-dessus, la version Apache APISIX 2.13.0 met également à jour les fonctionnalités suivantes :

grpc-transcode prend en charge la gestion des définitions de proto avec des importations via un .pbfichier .
Prise en charge de l'obtention de nœuds en amont à partir de la configuration K8s.
Ajout d'un csrfplugin pour fournir une protection contre la falsification des requêtes intersites.
Un nouveau mockingplugin est ajouté pour faciliter la génération de données de test.