Comment intégrer API Gateway et Consul ?

Informations de base

Consul est une solution de maillage de services. L'un de ses composants principaux, Consul KV, est une base de données clé-valeur distribuée dont l'objectif principal est de stocker des paramètres de configuration et des métadonnées, tout en permettant aux utilisateurs de stocker des objets indexés.

Dans le modèle d'architecture de microservices, lorsque les services en amont changent en raison d'une expansion de capacité, d'une défaillance matérielle, etc., la méthode consistant à maintenir les informations des services en amont en écrivant manuellement la configuration peut entraîner une augmentation significative des coûts de maintenance. En réponse, Apache APISIX fournit un registre de découverte de services pour obtenir dynamiquement les dernières informations sur les instances de services, afin de réduire les coûts de maintenance pour les utilisateurs.

Actuellement, Apache APISIX prend en charge le registre de découverte de services basé sur Consul KV avec le module consul_kv contribué par la communauté.

Fonctionnement

Apache APISIX utilise le module consul_kv de la capacité de stockage clé-valeur distribuée de Consul KV pour découpler le fournisseur et le consommateur d'un service et implémenter les deux fonctions principales d'un registre de découverte de services.

Enregistrement de service : Les fournisseurs de services enregistrent leurs services auprès du registre.
Découverte de service : Les consommateurs de services trouvent les informations de routage des fournisseurs de services via le registre.

Sur cette base, Apache APISIX sera plus flexible et s'adaptera mieux aux architectures de microservices existantes pour répondre aux besoins des utilisateurs.

architectures consul

Comment activer Consul dans Apache APISIX

Les environnements de test de cet article sont construits dans Docker en utilisant docker-compose.

Téléchargez Apache APISIX.
```
# Clonez le dépôt Git d'apisix-docker
git clone https://github.com/apache/apisix-docker.git
```

Créez un dossier Consul et les fichiers de configuration.

# Créez un dossier Consul
mkdir -p ~/docker-things/consul/ && cd $_
# Créez les fichiers de configuration
touch docker-compose.yml server1.json

Modifiez le fichier docker-compose.yml.

version: '3.8'

services:
consul-server1:
image: consul:1.9.3
container_name: consul-server1
restart: always
volumes:
  - ./server1.json:/consul/config/server1.json:ro
networks:
  - apisix
ports:
  - '8500:8500'
command: 'agent -bootstrap-expect=1'

networks:
apisix:
external: true
name: example_apisix

Modifiez le fichier server1.json.

{
node_name: consul-server1,
server: true,
addresses: {
http: 0.0.0.0
}
}

Ajoutez les informations de configuration relatives à Consul dans le fichier de configuration d'Apache APISIX apisix_conf/config.yaml.
```
# config.yml
# ...autres configurations
discovery:
consul_kv:
servers:
  - http://consul-server1:8500
prefix: upstreams
```

Démarrez Apache APISIX et Consul.

# Allez dans le dossier example, consul, démarrez APISIX et Consul
docker-compose up -d

Enregistrez le service de test dans Consul. L'exemple contient deux services web que vous pouvez utiliser directement pour tester.

# Vérifiez le docker-compose.yml de l'exemple
# Vous pouvez voir deux services Web
$ cat docker-compose.yml | grep web
# Sorties
web1:
- ./upstream/web1.conf:/etc/nginx/nginx.conf
web2:
- ./upstream/web2.conf:/etc/nginx/nginx.conf

Confirmez les adresses IP de ces services Web.

$ sudo docker inspect -f='{{.Name}} - {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $(sudo docker ps -aq) | grep web
# Sorties
/example-web1-1 - 172.26.0.7
/example-web2-1 - 172.26.0.2

Faites une requête à l'API HTTP de Consul dans le terminal pour enregistrer le service de test.
```
# Enregistrez avec l'IP correspondante
curl \
-X PUT \
-d ' {weight: 1, max_fails: 2, fail_timeout: 1}' \
http://127.0.0.1:8500/v1/kv/upstreams/webpages/172.26.0.7:80

curl \
-X PUT \
-d ' {weight: 1, max_fails: 2, fail_timeout: 1}' \
http://127.0.0.1:8500/v1/kv/upstreams/webpages/172.26.0.2:80
```
Le chemin après /v1/kv/ suit le format {Prefix}/{Nom du Service}/{IP}:{Port}.

{Prefix} est le préfixe écrit lors de la configuration de Consul dans APISIX, tandis que {Nom du Service} et {IP}:{Port} doivent être déterminés par l'utilisateur en fonction du service en amont.

Le format des données est {"weight": , "max_fails": , "fail_timeout": }.

Vérifiez si le service de test est enregistré avec succès.

curl http://127.0.0.1:8500/v1/kv/upstreams/webpages?keys

Le message de retour suivant indique un enregistrement réussi.

[upstreams/webpages/172.26.0.2:80,upstreams/webpages/172.26.0.7:80]%

Créez une route et activez Consul

Ajoutez Consul à la route en utilisant l'API Admin fournie par Apache APISIX.

Le X-API-KEY et upstream.service_name doivent être déterminés avant de les ajouter.

X-API-KEY : Pour le jeton d'accès à l'API Admin, dans cet exemple, nous utilisons la valeur par défaut edd1c9f034335f136f87ad84b625c8f1.
upstream.service_name : Le nom du service en amont, qui spécifie le service dans un registre qui sera lié à une route, doit être défini sur l'URL utilisée pour enregistrer le service de test lors de l'utilisation de Consul, et la partie {IP}:{Port} doit être supprimée à la fin. Nous pouvons également utiliser l'API Memory Dump fournie par Apache APISIX pour obtenir l'URL du service et confirmer si le service en amont est correctement découvert.

$ curl http://127.0.0.1:9092/v1/discovery/consul_kv/dump | jq
# Sortie
{
  "services": {
    # Cette clé est l'URL requise
    "http://consul-server1:8500/v1/kv/upstreams/webpages/": [
      {
        "port": 80,
        "host": "172.26.0.7",
        "weight": 1
      },
      {
        "port": 80,
        "host": "172.26.0.2",
        "weight": 1
      }
    ]
  },
  "config": {
    # ...configurations
  }
}

Ajoutez une route

Ici, la requête avec l'URL /consul/* est routée vers http://consul-server1:8500/v1/kv/upstreams/webpages/. De plus, le discovery_type doit être défini sur consul_kv pour démarrer le module correspondant.

curl http://127.0.0.1:9080/apisix/admin/routes -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X POST -d '
{
    "uri": "/consul/*",
    "upstream": {
        "service_name": "http://consul-server1:8500/v1/kv/upstreams/webpages/",
        "type": "roundrobin",
        "discovery_type": "consul_kv"
    }
}'

Testez et vérifiez le résultat

Les résultats de la requête montrent que la nouvelle route dans Apache APISIX a pu trouver l'adresse de service correcte via Consul et la requête a été envoyée aux deux nœuds en fonction de la politique d'équilibrage de charge.

# première requête
curl -s http://127.0.0.1:9080/consul/
# Sortie
hello web1%

# deuxième requête
curl -s http://127.0.0.1:9080/consul/
# Sortie
hello web2%

# Remarque : Il est également possible que les deux requêtes renvoient
#            le même résultat que web1 ou web2.
#            Cela est dû à la nature de l'équilibrage de charge et
#            vous pouvez essayer de faire plus de requêtes.

Résumé

La première moitié de cet article décrit comment Apache APISIX fonctionne avec Consul pour implémenter le registre de découverte de services basé sur Consul KV afin de résoudre le problème de gestion et de maintenance des informations de service. La seconde moitié de cet article se concentre sur la manière d'utiliser Apache APISIX dans Docker avec Consul. Bien sûr, l'application dans un scénario réel doit être analysée en fonction du scénario métier et de l'architecture système existante.

Plus d'instructions sur l'utilisation du registre Consul dans Apache APISIX peuvent être trouvées dans la documentation officielle.

Apache APISIX travaille également actuellement sur des plugins supplémentaires pour prendre en charge l'intégration de services supplémentaires, donc si vous êtes intéressé, n'hésitez pas à démarrer une discussion dans GitHub Discussion, ou via la liste de diffusion pour communiquer.