Déployer NGINX en tant que passerelle API, partie 3 : publication de services gRPC

Liam CrillyDirecteur senior de la gestion des produits

Ceci est le troisième article de notre série consacrée au déploiement de NGINX Open Source et de NGINX Plus en tant que passerelle API.

• Partie 1 fournit des instructions détaillées pour plusieurs cas d’utilisation de NGINX Open Source et NGINX Plus en tant que passerelle d’API pour les API RESTful basées sur HTTP.
• Partie 2 étend ces cas d’utilisation et examine un ensemble de mesures de protection pouvant être mises en œuvre pour protéger et sécuriser les services d’API backend en production.
• Cet article explique comment déployer NGINX Open Source et NGINX Plus en tant que passerelle API pour les services gRPC. Initialement publié en 2018, il a été mis à jour afin de tirer parti de la prise en charge introduite dans NGINX Plus version 23 du protocole natif de vérification de l’état de gRPC. Consultez Mise en œuvre des vérifications de l’état.

Remarque : Sauf indication contraire, toutes les informations contenues dans cet article s’appliquent à la fois à NGINX Plus et à NGINX Open Source. Pour faciliter la lecture, la suite de l’article utilise simplement « NGINX » lorsque les explications concernent les deux versions.

Les concepts et les avantages des architectures d’applications basées sur des microservices ont été largement documentés ces dernières années, notamment sur le blog NGINX. L’API HTTP est au cœur des applications basées sur des microservices, et les deux premiers articles de cette série s’appuient sur une API REST fictive pour illustrer la manière dont NGINX prend en charge ce type d’application.

Malgré la popularité des API REST utilisant des formats de message JSON pour les applications modernes, cette approche n’est pas idéale pour tous les cas de figure ni pour toutes les organisations. Les difficultés les plus courantes sont les suivantes :

• Normes de documentation – En l’absence de bonnes pratiques de la part des développeurs ou d’exigences obligatoires en matière de documentation, il est très facile de se retrouver avec plusieurs API REST dépourvues de définition précise. L’Open API Specification s’est imposée comme un langage générique de description d’interface pour les API REST, mais son utilisation reste facultative et nécessite une gouvernance rigoureuse au sein de l’organisation de développement.
• Événements et connexions persistantes – Les API REST, du fait qu’elles utilisent HTTP comme protocole de transport, imposent en grande partie un modèle requête-réponse à tous les appels d’API. Lorsque l’application nécessite des événements générés par le serveur, le recours à des solutions telles que le long polling HTTP et WebSocket peut être utile, mais l’utilisation de telles solutions nécessite en définitive de créer une API distincte et complémentaire.
• Transactions complexes – Les API REST reposent sur le concept de ressources uniques, chacune étant représentée par un URI. Lorsqu’un événement applicatif nécessite la mise à jour de plusieurs ressources, il faut soit effectuer plusieurs appels d’API, ce qui est inefficace, soit mettre en œuvre une transaction complexe côté serveur, ce qui va à l’encontre du principe fondamental de REST.

Ces dernières années, gRPC s’est imposé comme une autre approche pour créer des applications distribuées, et notamment des applications de microservices. Initialement développé chez Google, gRPC est devenu open source en 2015 et constitue désormais un projet de la Cloud Native Computing Foundation. Fait notable, gRPC utilise HTTP/2 comme mécanisme de transport, tirant parti de son format de données binaire et de ses capacités de diffusion en continu multiplexée.

Les principaux avantages de gRPC sont les suivants :

• Langage de définition d’interface étroitement intégré (Protocol Buffers)
• Prise en charge native des données en streaming (dans les deux sens)
• Format de données binaires efficace
• Génération automatisée de code pour de nombreux langages de programmation, permettant de créer un véritable environnement de développement polyglotte sans entraîner de problèmes d’interopérabilité

Définition de la passerelle gRPC

Les deux premiers articles de cette série expliquaient comment plusieurs API peuvent être proposées via un point d’entrée unique (par exemple, https://api.example.com). Le comportement par défaut et les caractéristiques du trafic gRPC nous conduisent à adopter la même approche lorsque NGINX est déployé en tant que passerelle gRPC. Bien qu’il soit possible de faire transiter les trafics HTTP et gRPC par le même nom d’hôte et le même port, il est préférable de les séparer pour plusieurs raisons :

• Les clients API des applications REST et gRPC s’attendent à recevoir des réponses d’erreur dans des formats différents
• Les champs pertinents des journaux d’accès diffèrent entre REST et gRPC
• Comme gRPC n’a jamais à prendre en charge les anciens navigateurs web, il peut appliquer une politique TLS plus stricte

Pour assurer cette séparation, nous plaçons la configuration de notre passerelle gRPC dans son propre bloc server{} au sein du fichier de configuration gRPC principal, grpc_gateway.conf, situé dans le répertoire /etc/nginx/conf.d.

Chargement de l’exemple de code…

Nous commençons par définir le format des entrées du journal d’accès pour le trafic gRPC (lignes 1 à 4). Dans cet exemple, nous utilisons un format JSON afin de recueillir les données les plus pertinentes de chaque requête. Notez, par exemple, que la méthode HTTP n’est pas incluse, car toutes les requêtes gRPC utilisent POST. Nous consignons également le code d’état gRPC ainsi que le code d’état HTTP. Toutefois, le code d’état gRPC peut être généré de différentes manières. Dans des conditions normales, grpc-status est renvoyé par le backend sous forme de champ de fin HTTP/2, mais dans certaines situations d’erreur, il peut être renvoyé sous forme d’en-tête HTTP/2, soit par le backend, soit par NGINX lui-même. Pour simplifier le journal d’accès, nous utilisons un bloc map (lignes 6 à 9) afin d’évaluer une nouvelle variable, $grpc_status, et d’obtenir l’état gRPC, quelle que soit son origine.

Cette configuration contient deux directives « listen » (lignes 12 et 13), ce qui nous permet de tester à la fois le trafic en clair (port 50051) et le trafic protégé par TLS (port 443). Le paramètre « http2 » configure NGINX pour accepter les connexions HTTP/2. Notez que ce paramètre est indépendant du paramètre « ssl ». Notez également que le port 50051 est le port conventionnel pour le trafic gRPC en clair, mais qu’il ne convient pas à une utilisation en production.

La configuration TLS est classique, à l’exception de la directive « ssl_protocols » (ligne 23), qui définit TLS 1.2 comme la version minimale acceptable du protocole. La spécification HTTP/2 impose l’utilisation de TLS 1.2 (ou d’une version ultérieure), ce qui garantit que tous les clients prennent en charge l’extension TLS Server Name Indication (SNI). Ainsi, la passerelle gRPC peut partager le port 443 avec des serveurs virtuels définis dans d’autres blocs server{}.

Exécution d’exemples de services gRPC

Pour explorer les fonctionnalités gRPC de NGINX, nous utilisons un environnement de test simple qui reproduit les principaux composants d’une passerelle gRPC et dans lequel plusieurs services gRPC sont déployés. Nous utilisons deux exemples d’applications tirés des guides officiels de gRPC : helloworld (écrite en Go) et RouteGuide (écrite en Python). L’application RouteGuide est particulièrement utile, car elle inclut chacune des quatre méthodes de service gRPC :

• RPC simple (une seule requête-réponse)
• RPC avec diffusion en continu de la réponse
• RPC avec diffusion en continu des requêtes
• RPC à diffusion bidirectionnelle

Les deux services gRPC sont installés sous forme de conteneurs Docker sur notre hôte NGINX. Pour obtenir les instructions complètes sur la création de l’environnement de test, consultez l’annexe.

Nous configurons NGINX pour qu’il connaisse les services RouteGuide et helloworld, ainsi que les adresses des conteneurs disponibles.

Chargement de l’exemple de code…

Nous ajoutons un bloc upstream pour chacun des services gRPC (lignes 40 à 45 et 47 à 51) et y indiquons les adresses des différents conteneurs qui exécutent le code du serveur gRPC.

Routage des requêtes gRPC

NGINX étant à l’écoute sur le port conventionnel en texte clair pour gRPC (50051), nous ajoutons des informations de routage à la configuration afin que les requêtes des clients atteignent le service backend approprié. Mais nous devons d’abord comprendre comment les appels de méthodes gRPC sont représentés sous forme de requêtes HTTP/2. Le schéma suivant présente une version abrégée du fichier route_guide.proto du service RouteGuide et illustre comment le package, le service et la méthode RPC constituent l’URI telle qu’elle est vue par NGINX.

Les informations contenues dans la requête HTTP/2 peuvent donc être utilisées à des fins de routage en effectuant simplement une correspondance avec le nom du package (ici, « routeguide » ou « helloworld »).

Chargement de l’exemple de code…

Le premier bloc location (ligne 26), sans aucun modificateur, définit une correspondance de préfixe de sorte que /routeguide. corresponde à tous les services et à toutes les méthodes RPC définis dans le fichier .proto correspondant à ce package. La directive grpc_pass (ligne 27) transmet donc toutes les requêtes du client RouteGuide au groupe en amont routeguide_service. Cette configuration (ainsi que la configuration analogue pour le service helloworld aux lignes 29 et 30) établit une correspondance simple entre un package gRPC et ses services backend.

Notez que l’argument des directives grpc_pass commence par le schéma grpc://, qui transmet les requêtes via une connexion gRPC en clair. Si le serveur backend est configuré pour utiliser TLS, nous pouvons utiliser le schéma grpcs:// afin de sécuriser la connexion gRPC avec un chiffrement de bout en bout.

Après avoir exécuté le client RouteGuide, nous pouvons confirmer le comportement du routage en examinant les entrées du fichier journal. Nous constatons ici que la méthode RPC RouteChat a été acheminée vers le conteneur s’exécutant sur le port 10002.

$ python route_guide_client.py...
$ tail -1 /var/log/nginx/grpc_log.json | jq
{
  "timestamp": "2021-01-20T12:17:56+01:00",
  "client": "127.0.0.1",
  "uri": "/routeguide.RouteGuide/RouteChat",
  "http-status": 200,
  "grpc-status": 0,
  "upstream": "127.0.0.1:10002",
  "rx-bytes": 161,
  "tx-bytes": 212
}

Routage précis

Comme indiqué ci-dessus, le routage de plusieurs services gRPC vers différents backends est simple, efficace et ne nécessite que très peu de lignes de configuration. Toutefois, dans un environnement de production, les exigences de routage peuvent être plus complexes et nécessiter un routage basé sur d’autres éléments de l’URI (le service gRPC, voire des méthodes RPC individuelles).

L’extrait de configuration suivant étend l’exemple précédent afin que la méthode RPC de streaming bidirectionnel « RouteChat » soit acheminée vers un backend et que toutes les autres méthodes « RouteGuide » soient acheminées vers un autre backend.

Chargement de l’exemple de code…

La deuxième directive « location » (ligne 7) utilise le modificateur « = » (signe égal) pour indiquer qu’il s’agit d’une correspondance exacte avec l’URI de la méthode RPC « RouteChat ». Les correspondances exactes sont traitées avant les correspondances de préfixe, ce qui signifie qu’aucun autre bloc « location » n’est pris en compte pour l’URI « RouteChat ».

Répondre aux erreurs

Les erreurs gRPC diffèrent quelque peu de celles du trafic HTTP classique. Les clients s’attendent à ce que les conditions d’erreur soient exprimées sous forme de réponses gRPC, ce qui rend les pages d’erreur NGINX par défaut (au format HTML) inadaptées lorsque NGINX est configuré comme passerelle gRPC. Pour y remédier, nous définissons un ensemble de réponses d’erreur personnalisées pour les clients gRPC.

Chargement de l’exemple de code…

L’ensemble complet des réponses d’erreur gRPC constitue une configuration relativement longue et en grande partie statique. Nous les conservons donc dans un fichier distinct, errors.grpc_conf, et utilisons la directive include (ligne 34) pour y faire référence. Contrairement aux clients HTTP/REST, les applications clientes gRPC ne sont pas censées gérer un large éventail de codes d’état HTTP. La documentation gRPC indique comment un proxy intermédiaire tel que NGINX doit convertir les codes d’erreur HTTP en codes d’état gRPC afin que les clients reçoivent toujours une réponse appropriée. Nous utilisons la directive error_page pour effectuer cette correspondance.

Chargement de l’exemple de code…

Chacun des codes d’état HTTP standard est transmis à un emplacement nommé à l’aide du préfixe « @ », afin de générer une réponse conforme à gRPC. Par exemple, la réponse HTTP 404 est redirigée en interne vers l’emplacement @grpc_unimplemented, défini plus loin dans le fichier :

Chargement de l’exemple de code…

L'emplacement nommé « @grpc_unimplemented » est uniquement accessible au traitement interne de NGINX : les clients ne peuvent pas le demander directement, car il n'existe aucun URI routable. Dans cet emplacement, nous construisons une réponse gRPC en renseignant les en-têtes gRPC obligatoires, puis en les envoyant sans corps de réponse avec le code d'état HTTP 204 (Aucun contenu).

Nous pouvons utiliser la commande curl(1) pour simuler un client gRPC au comportement incorrect qui demande une méthode gRPC inexistante. Notez toutefois que curl n’est généralement pas adapté pour tester un client gRPC, car les tampons de protocole utilisent un format de données binaire. Pour tester gRPC en ligne de commande, envisagez d’utiliser grpc_cli.

$ curl -i --http2 -H "Content-Type: application/grpc" -H "TE: trailers" -X POST https://grpc.example.com/does.Not/ExistHTTP/2 204 
server: nginx/1.19.5
date: Wed, 20 Jan 2021 15:03:41 GMT
grpc-status: 12
grpc-message: unimplemented

Le fichier grpc_errors.conf mentionné ci-dessus contient également des correspondances entre les codes d’état HTTP et gRPC pour d’autres réponses d’erreur que NGINX peut générer, telles que les expirations de délai et les erreurs de certificat client.

Authentification des clients à l’aide des métadonnées gRPC

Les métadonnées gRPC permettent aux clients d’envoyer des informations supplémentaires avec les appels de méthodes RPC, sans que ces données aient à faire partie de la spécification Protocol Buffers (fichier .proto). Les métadonnées se présentent sous la forme d’une simple liste de paires clé-valeur, chaque paire étant transmise dans un en-tête HTTP/2 distinct. Elles sont donc facilement accessibles à NGINX.

Parmi les nombreux cas d’utilisation des métadonnées, l’authentification des clients est le plus courant pour une passerelle d’API gRPC. L’extrait de configuration suivant montre comment NGINX Plus peut utiliser les métadonnées gRPC pour effectuer une authentification JWT (l’authentification JWT est une fonctionnalité exclusive à NGINX Plus). Dans cet exemple, le JWT est envoyé dans les métadonnées auth-token.

Chargement de l’exemple de code…

Chaque en-tête de requête HTTP est accessible à NGINX Plus sous la forme d’une variable appelée « $http_header ». Les traits d’union (« - ») dans le nom de l’en-tête sont remplacés par des traits de soulignement (« _ ») dans le nom de la variable. Le JWT est donc accessible via la variable « $http_auth_token » (ligne 2).

Si des clés d’API sont utilisées pour l’authentification, par exemple avec des API HTTP/REST existantes, elles peuvent également être transmises dans les métadonnées gRPC et validées par NGINX. Une configuration pour l’authentification par clé d’API<.htmla> est fournie dans la première partie de cette série d’articles.

Mise en œuvre des contrôles d’intégrité

Lors de la répartition de charge du trafic entre plusieurs serveurs backend, il est important d’éviter d’envoyer des requêtes à ceux qui sont en panne ou indisponibles. Avec NGINX Plus, nous pouvons utiliser des contrôles d’intégrité actifs pour envoyer de manière proactive des requêtes hors bande aux serveurs backend et les retirer de la rotation de répartition de charge lorsqu’ils ne répondent pas comme prévu aux contrôles d’intégrité. Ainsi, nous nous assurons que les requêtes des clients n’atteignent jamais les serveurs backend hors service.

L’extrait de configuration suivant active les contrôles d’intégrité actifs pour les services gRPC RouteGuide et helloworld. Afin de mettre en évidence la configuration pertinente, certaines directives incluses dans le fichier grpc_gateway.conf utilisé dans les sections précédentes ont été omises.

Chargement de l’exemple de code…

Pour chaque route, nous spécifions désormais également la directive health_check (lignes 17 et 21). Comme l’indique l’argument type=grpc, NGINX Plus utilise le protocole de vérification de l’état de gRPC pour envoyer une requête de vérification de l’état à chaque serveur du groupe en amont. Toutefois, nos services gRPC simples n’implémentent pas le protocole de vérification de l’état de gRPC. Nous nous attendons donc à ce qu’ils répondent avec le code d’état signifiant « non implémenté » (grpc_status=12). Cette réponse suffit à indiquer que nous communiquons avec un service gRPC actif.

Avec cette configuration en place, nous pouvons arrêter n’importe quel conteneur backend sans que les clients gRPC subissent de ralentissements ou d’expirations de délai. Les contrôles d’intégrité actifs sont une fonctionnalité exclusive de NGINX Plus ; découvrez-en davantage sur les contrôles d’intégrité gRPC sur notre blog.

Application de la limitation du débit et d’autres contrôles de passerelle API

L’exemple de configuration dans grpc_gateway.conf convient à une utilisation en production, moyennant quelques modifications mineures pour TLS. La possibilité d’acheminer les requêtes gRPC en fonction du package, du service ou de la méthode RPC permet d’appliquer les fonctionnalités existantes de NGINX au trafic gRPC exactement de la même manière qu’aux API HTTP/REST, ou même qu’au trafic web classique. Dans chaque cas, le bloc location concerné peut être complété par des paramètres supplémentaires, tels que la limitation du débit de requêtes ou le contrôle de la bande passante.

Résumé

Dans ce troisième et dernier article de notre série consacrée au déploiement de NGINX Open Source et de NGINX Plus en tant que passerelle d’API, nous nous sommes intéressés à gRPC, une technologie cloud native permettant de créer des applications basées sur des microservices. Nous avons montré que NGINX est capable de fournir des applications gRPC aussi efficacement que des API HTTP/REST, et que ces deux types d’API peuvent être publiés via NGINX, utilisé comme passerelle d’API polyvalente.

Les instructions permettant de configurer l’environnement de test utilisé dans cet article de blog figurent dans l’annexe ci-dessous, et vous pouvez télécharger tous les fichiers depuis notre dépôt GitHub Gist.

Découvrez les autres articles de blog de cette série :

• La partie 1 explique comment configurer NGINX pour certains cas d’usage essentiels de passerelle d’API basée sur HTTP.
• Partie 2 explore des cas d’utilisation plus avancés visant à protéger les services backend contre les clients malveillants ou au comportement inapproprié.

Pour essayer NGINX Plus comme passerelle d’API, commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation. Pendant votre période d’essai, utilisez l’ensemble complet des fichiers de configuration disponibles dans notre dépôt GitHub Gist.

Annexe : configuration de l’environnement de test

Les instructions suivantes permettent d’installer l’environnement de test sur une machine virtuelle afin qu’il soit isolé et reproductible. Toutefois, rien n’empêche de l’installer sur un serveur physique « bare metal ».

Pour simplifier l’environnement de test, nous utilisons des conteneurs Docker pour exécuter les services gRPC. Ainsi, nous n’avons pas besoin de plusieurs hôtes pour l’environnement de test, tout en permettant à NGINX d’établir des connexions par proxy via un appel réseau, comme dans un environnement de production.

L’utilisation de Docker nous permet également d’exécuter plusieurs instances de chaque service gRPC sur des ports différents sans avoir à modifier le code. Chaque service gRPC écoute le port 50051 au sein du conteneur, lequel est associé à un port localhost unique sur la machine virtuelle. Le port 50051 est ainsi libéré afin que NGINX puisse l’utiliser comme port d’écoute. Par conséquent, lorsque les clients de test se connectent à l’aide de leur port 50051 préconfiguré, ils accèdent à NGINX.

Installation de NGINX Open Source ou de NGINX Plus

1. Installez NGINX Open Source ou NGINX Plus conformément aux instructions du guide d’administration de NGINX Plus.
2. Copiez les fichiers suivants depuis le dépôt GitHub Gist vers /etc/nginx/conf.d : Remarque : si vous n’utilisez pas TLS, mettez en commentaire les directives ssl_* dans grpc_gateway.conf.
   • grpc_gateway.conf
   • errors.grpc_conf
3. Démarrez NGINX Open Source ou NGINX Plus.

$ sudo nginx

Installation de Docker

Pour Debian et Ubuntu, exécutez :

$ sudo apt-get install docker.io

Pour CentOS, RHEL et Oracle Linux, exécutez :

$ sudo yum install docker

Installation des conteneurs du service RouteGuide

1. Créez l’image Docker des conteneurs RouteGuide à partir du Dockerfile suivant.

   Chargement de l’exemple de code…

   Vous pouvez soit copier le Dockerfile dans un sous-répertoire local avant de lancer la création, soit indiquer l’URL du Gist contenant le Dockerfile comme argument de la commande docker build :

$ sudo docker build -t routeguide https://gist.githubusercontent.com/nginx-gists/87ed942d4ee9f7e7ebb2ccf757ed90be/raw/ce090f92f3bbcb5a94bbf8ded4d597cd47b43cbe/routeguide.Dockerfile

1. Le téléchargement et la création de l’image peuvent prendre quelques minutes. L’affichage du message « Successfully built » et d’une chaîne hexadécimale (l’ID de l’image) indique que la création est terminée.
2. Vérifiez que l’image a bien été créée en exécutant « docker images ».

$ sudo docker imagesREPOSITORY     TAG          IMAGE ID          CREATED         SIZE
routeguide     latest       63058a1cf8ca      1 minute ago    1.31 GB
python         latest       825141134528      9 days ago      923 MB

1. Démarrez les conteneurs RouteGuide.

$ sudo docker run --name rg1 -p 10001:50051 -d routeguide$ sudo docker run --name rg2 -p 10002:50051 -d routeguide
$ sudo docker run --name rg3 -p 10003:50051 -d routeguide

1. À chaque fois qu’une commande s’exécute correctement, une longue chaîne hexadécimale s’affiche. Elle représente le conteneur en cours d’exécution.
2. Vérifiez que les trois conteneurs sont en cours d’exécution en lançant docker ps. (L’exemple de sortie est réparti sur plusieurs lignes pour en faciliter la lecture.)

$ sudo docker psCONTAINER ID  IMAGE       COMMAND              STATUS        ...
d0cdaaeddf0f  routeguide  "python route_g..."  Up 2 seconds  ...
c04996ca3469  routeguide  "python route_g..."  Up 9 seconds  ...
2170ddb62898  routeguide  "python route_g..."  Up 1 minute   ...

      ... PORTS                     NAMES
      ... 0.0.0.0:10003->50051/tcp  rg3
      ... 0.0.0.0:10002->50051/tcp  rg2
      ... 0.0.0.0:10001->50051/tcp  rg1

1. La colonne PORTS de la sortie indique comment chacun des conteneurs a associé un port local différent au port 50051 à l’intérieur du conteneur.

Installation des conteneurs du service helloworld

1. Créez l’image Docker des conteneurs helloworld à partir du Dockerfile suivant.

   Chargement de l’exemple de code…

   Vous pouvez soit copier le Dockerfile dans un sous-répertoire local avant la création de l’image, soit indiquer l’URL du Gist contenant le Dockerfile comme argument de la commande docker build :

$ sudo docker build -t helloworld https://gist.githubusercontent.com/nginx-gists/87ed942d4ee9f7e7ebb2ccf757ed90be/raw/ce090f92f3bbcb5a94bbf8ded4d597cd47b43cbe/helloworld.Dockerfile

1. Le téléchargement et la création de l’image peuvent prendre quelques minutes. L’affichage du message « Successfully built » et d’une chaîne hexadécimale (l’ID de l’image) indique que la création est terminée.
2. Vérifiez que l’image a bien été créée en exécutant docker images.

$ sudo docker images
REPOSITORY     TAG          IMAGE ID          CREATED           SIZE
helloworld     latest       e5832dc0884a      10 seconds ago    926MB
routeguide     latest       170761fa3f03      4 minutes ago     1.31GB
python         latest       825141134528      9 days ago        923MB
golang         latest       d0e7a411e3da      3 weeks ago       794MB

1. Démarrez les conteneurs helloworld.

$ sudo docker run --name hw1 -p 20001:50051 -d helloworld$ sudo docker run --name hw2 -p 20002:50051 -d helloworld

1. À chaque commande exécutée avec succès, une longue chaîne hexadécimale s’affiche. Elle représente le conteneur en cours d’exécution.
2. Vérifiez que les deux conteneurs helloworld sont en cours d’exécution en lançant docker ps.

$ sudo docker psCONTAINER ID  IMAGE       COMMAND              STATUS        ... 
e0d204ae860a  helloworld  "go run greeter..."  Up 5 seconds  ... 
66f21d89be78  helloworld  "go run greeter..."  Up 9 seconds  ... 
d0cdaaeddf0f  routeguide  "python route_g..."  Up 4 minutes  ... 
c04996ca3469  routeguide  "python route_g..."  Up 4 minutes  ... 
2170ddb62898  routeguide  "python route_g..."  Up 5 minutes  ... 

      ... PORTS                     NAMES
      ... 0.0.0.0:20002->50051/tcp  hw2
      ... 0.0.0.0:20001->50051/tcp  hw1
      ... 0.0.0.0:10003->50051/tcp  rg3
      ... 0.0.0.0:10002->50051/tcp  rg2
      ... 0.0.0.0:10001->50051/tcp  rg1

Installation des applications clientes gRPC

1. Installez les prérequis des langages de programmation, dont certains sont peut-être déjà installés dans l’environnement de test. Notez que python-pip nécessite l’activation du dépôt EPEL (exécutez d’abord sudo yum install epel-release si nécessaire).
   • Pour Ubuntu et Debian, exécutez :

$ sudo apt-get install golang-go python3 python-pip git

• Pour CentOS, RHEL et Oracle Linux, exécutez :

$ sudo yum install golang python python-pip git

1. Téléchargez l’application helloworld :

$ go get google.golang.org/grpc

1. Téléchargez l’application RouteGuide :

$ git clone -b v1.14.1 https://github.com/grpc/grpc
$ pip install grpcio-tools

Tester la configuration

1. Exécutez le client helloworld :

$ go run go/src/google.golang.org/grpc/examples/helloworld/greeter_client/main.go

1. Exécutez le client RouteGuide :

$ cd grpc/examples/python/route_guide
$ python route_guide_client.py

1. Consultez les journaux NGINX pour vérifier que l’environnement de test est opérationnel :

$ tail /var/log/nginx/grpc_log.json

À propos de l’auteur

Liam CrillyDirecteur senior de la gestion des produits

Autres articles de Liam Crilly