support gRPC dans Azure Front Door (aperçu)

S’applique à : ✔️ Front Door Standard ✔️ Front Door Premium

Dans cet article, vous apprenez à configurer et tester des services gRPC natifs via Azure Front Door Standard et Premium. Vous pouvez acheminer les appels par service et méthode, répartir le trafic entre des origines saines, et appliquer les contrôles de métadonnées de requête pris en charge.

Important

le support gRPC dans Azure Front Door est actuellement en aperçu public. Consultez les Conditions d’utilisation supplémentaires pour les préversions Microsoft Azure pour les conditions légales qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou qui ne sont pas encore publiées en disponibilité générale.

L’aperçu public est accessible à tous les clients Azure Front Door Standard et Premium. Vous n’avez pas besoin de vous inscrire à l’aperçu ni de remplir des exigences supplémentaires d’accès à l’aperçu.

Qu’est-ce que gRPC ?

gRPC est un framework open source d’appels de procédures à distance. Un client invoque une méthode sur un service distant via un contrat de service défini. Le gRPC natif utilise HTTP/2 et utilise couramment Protocol Buffers pour sérialiser les messages.

gRPC offre les avantages suivants :

  • Transport efficace via le tramage binaire HTTP/2, la compression des en-têtes et le multiplexage de connexion.
  • Des contrats de service fortement typés et du code client et serveur généré à travers les langages supportés.
  • Appels unaires, streaming client, streaming serveur et streaming bidirectionnel, avec prise en charge des échéances, annulations, métadonnées et codes de statut.

Pour plus d’informations, voir concepts fondamentaux, architecture et cycle de vie de gRPC.

Protocol Buffers et chemins de méthode

Protocol Buffers offrent une sérialisation de données structurées neutre en termes de langue et de plateforme. Un fichier .proto définit des messages, des services et des méthodes RPC. Le compilateur Protocol Buffers, protoc, génére le code correspondant.

L’exemple suivant greet.proto définit une méthode unaire SayHello :

syntax = "proto3";

package greet;

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

Le chemin de requête complet est /greet.Greeter/SayHello. Utilisez ce chemin pour faire correspondre la méthode dans un itinéraire Azure Front Door.

Comment gRPC fonctionne avec Azure Front Door

La connexion TLS du client se termine à la périphérie d’Azure Front Door. Front Door correspond à la route gRPC, évalue les politiques prises en charge par rapport aux métadonnées de requêtes HTTP/2, sélectionne une origine en bon état, et transmet l’appel via une connexion HTTPS et HTTP/2 distincte. Les messages de réponse et les métadonnées de fin gRPC reviennent au client.

Le comportement suivant s’applique aux routes compatibles gRPC pendant l’aperçu :

Area Comportement ou limitation
Niveaux Standard et Premium uniquement.
Transport HTTPS et HTTP/2 sont nécessaires du client à Front Door et de Front Door vers la source d’origine.
patterns RPC Les appels unaires, en flux du client, en flux du serveur et bidirectionnels sont pris en charge.
Correspondance d'itinéraire Utilisez un chemin complet /package.Service/Method , ou utilisez intentionnellement un motif large tel que /*.
Caching La mise en cache n’est pas prise en charge et est désactivée sur les routes compatibles gRPC.
Redirections et transferts Les redirections ne sont pas prises en charge pour le trafic gRPC. Gardez le routage et la redirection de l’ensemble de règles configurés pour HTTPS.
Ensembles de règles et actions Edge Pris en charge, sous réserve des exigences de transfert HTTPS et des limitations de prévisualisation dans ce tableau.
Private Link Private Link n'est pas pris en charge pour les origines compatibles gRPC lors de l'aperçu.
Remplacements de configuration d’itinéraire Un groupe d’origine activé par gRPC ne peut pas être la cible d’une règle de substitution de configuration de route lors de l’aperçu.
Pare-feu d’applications web (WAF) Les vérifications de métadonnées de requête prises en charge s’appliquent. Les messages Protobuf ne sont pas décodés pour l’inspection du corps de la requête.

Prerequisites

  • Un profil Azure Front Door Standard ou Premium. Pour en créer un, voir Créer un profil Azure Front Door.
  • Une origine gRPC qui accepte TLS et HTTP/2 sur son port d’origine HTTPS configuré. Chaque origine du groupe d’origine de la route doit être activée pour gRPC.

Configurez les origines et les sondes de santé

Configurez le groupe d’origine avant de l’attacher à une route gRPC :

  1. Dans le portail Azure, ouvrez votre profil Front Door.
  2. Sous Paramètres, sélectionnez Groupes d’origine, puis ajoutez ou modifiez le groupe d’origine pour votre service gRPC.
  3. Ajoutez ou modifiez chaque source. Activez gRPC pour chaque origine et configurez son port HTTPS pour qu’il corresponde au service gRPC. N'activez pas Private Link pour ces origines pendant l'aperçu.
  4. Configurez les sondes de santé en utilisant le tableau suivant.
  5. Enregistrez le groupe d’origine.
Setting Configuration
Sondes de santé Activez les sondes pour vérifier la santé du serveur d’origine.
Protocol Sélectionnez gRPC pour une sonde gRPC native. Chaque origine doit implémenter le RPC standard grpc.health.v1.Health/Check .
Sondes HTTP ou HTTPS Comme alternative aux sondes gRPC natives, sélectionnez HTTP ou HTTPS et configurez un point de terminaison de contrôle d’état HTTP sur les serveurs d’origine.
Intervalle de sondage et équilibrage de charge Sélectionnez les valeurs qui répondent aux exigences de détection de l’état de santé et de charge de l’origine de votre application.

Une sonde gRPC native nécessite le service d’intégrité gRPC standard, pas seulement un RPC applicatif tel que SayHello. Pour plus d’informations, voir la vérification de l’état de santé gRPC. Pour les sondes HTTP et HTTPS, voir Azure Front Door health probes.

Capture d’écran montrant un groupe d’origine avec les origines activées et le gRPC sélectionné comme protocole de la sonde d’intégrité.

La capture d’écran montre des exemples de sondes et de réglages d’équilibrage de charge. Sélectionnez des valeurs qui répondent aux exigences de votre application.

Configurez une route gRPC

Créer ou mettre à jour un itinéraire pour envoyer des appels gRPC au groupe d’origine :

  1. Dans votre profil Front Door, dans Paramètres, sélectionnez Front Door manager.
  2. Sélectionnez le point de terminaison, puis ajoutez ou modifiez une route.
  3. Sélectionnez le domaine et le groupe d’origine qui contiennent vos origines compatibles gRPC.
  4. Activez le gRPC.
  5. Configurez l’itinéraire en utilisant le tableau suivant.
  6. Enregistrer l’itinéraire
Setting Configuration
Modèles à mettre en correspondance Pour un RPC, entrez le chemin complet /package.Service/Method , tel que /greet.Greeter/SayHello. Utilisez une route générique /* uniquement lorsque vous souhaitez exposer plusieurs méthodes ou la réflexion du serveur.
Protocole accepté L’activation de gRPC définit automatiquement cette valeur sur HTTPS uniquement.
Protocole de transfert L’activation de gRPC fixe automatiquement cette valeur sur HTTPS uniquement.
Caching Désactivé pour les routes compatibles avec gRPC.

Capture d’écran montrant Activer gRPC, un schéma de route spécifique à la méthode, ainsi que les protocoles acceptés et de transfert HTTPS uniquement.

La capture d’écran montre un exemple de route. Utilisez votre propre domaine, groupe d’origine et chemin de méthode RPC.

Les ensembles de règles et les Edge Actions sont pris en charge sur les routes compatibles gRPC. Si un ensemble de règles configure le protocole de redirection en HTTP, Azure Front Door renvoie une réponse HTTP 301 au client gRPC. Cette réponse ne permet pas les redirections du trafic gRPC. Gardez le routage et la redirection du jeu de règles configurés pour HTTPS.

Si vous configurez la route via l’infrastructure en tant que code, utilisez explicitement des paramètres HTTPS et gRPC compatibles. Les combinaisons de protocoles HTTP incompatibles sont rejetées.

Test avec grpcurl

Pour exécuter les exemples de test suivants, installez grpcurl. Vous n'avez pas besoin de cet outil pour configurer la prise en charge de gRPC dans Azure Front Door.

Utilisez le .proto fichier de votre service déployé ou le descripteur compilé pour tester une route spécifique à une méthode sans dépendre de la réflexion serveur. La réflexion côté serveur est une alternative optionnelle. Les exemples suivants utilisent le greet.Greeter contrat montré précédemment.

Remplacez contoso.azurefd.net par votre point d’extrémité Front Door ou votre domaine personnalisé. Utilisez le domaine qui correspond au certificat TLS du point de terminaison. Tous les exemples se connectent via TLS sur le port 443; n’ajoutez pas -plaintext.

Testez une route spécifique à une méthode avec un fichier proto local

Enregistrez la définition du service sous le nom greet.proto dans votre répertoire actuel. Pour une route correspondant à /greet.Greeter/SayHello, exécutez :

grpcurl -import-path "." -proto "greet.proto" -d "{}" contoso.azurefd.net:443 greet.Greeter/SayHello
Argument Purpose
-import-path "." Répertoire contenant vos fichiers proto. Remplacez . si les fichiers sont dans un autre répertoire.
-proto "greet.proto" Définition du service correspondant à l’origine déployée.
-d "{}" Corps de la requête JSON. Remplacez-le par le message exigé par votre service.
contoso.azurefd.net:443 Front Door Endpoint ou domaine personnalisé et port HTTPS.
greet.Greeter/SayHello Nom RPC entièrement qualifié, sans le terme / initial utilisé dans le modèle de route.

Fournir le proto local permet grpcurl d’invoquer la méthode d’application sans appel de réflexion préliminaire. Vous pouvez également fournir un descripteur compilé avec grpcurl au lieu d’un fichier proto.

Tester une route étendue intentionnelle avec réflexion sur le serveur

La reflection du serveur est optionnelle. Si vous ne fournissez pas un proto local ou un descripteur local, grpcurl utilise la réflexion serveur pour trouver le contrat de service. L’origine doit implémenter la réflexion, et la route Front Door doit correspondre à son chemin RPC.

Par exemple, le RPC grpc.reflection.v1alpha.ServerReflection/ServerReflectionInfo de réflexion utilise le chemin /grpc.reflection.v1alpha.ServerReflection/ServerReflectionInfode requête . Un itinéraire limité à /greet.Greeter/SayHello ne correspond pas à ce chemin. Le test peut échouer avant que le RPC de l’application ne soit invoqué, même si la route de l’application est correcte.

Si vous avez intentionnellement configuré une route large /* et activé la mise en miroir sur l’origine, listez les services :

grpcurl contoso.azurefd.net:443 list

Ensuite, invoquez la méthode en utilisant le reflected contract :

grpcurl -d "{}" contoso.azurefd.net:443 greet.Greeter/SayHello

Important

Exposez la réflexion uniquement lorsque c’est prévu. Privilégiez les fichiers proto-ou descripteurs locaux lors des tests de routes spécifiques à la méthode plutôt que d’élargir la route juste pour que la découverte fonctionne.

Résoudre les problèmes liés aux tests grpcurl

Symptôme Vérification ou action
grpcurl list échoue, mais un appel avec -proto réussit. Vérifiez si la route correspond au RPC de l’application mais pas au RPC de réflexion. Continuez à utiliser le proto ou descripteur local pour une route spécifique à la méthode.
La découverte par réflexion échoue. Vérifiez que l’origine implémente l’API de réflexion et que la route correspond à son chemin RPC. Sinon, fournissez un proto ou un descripteur local.
La méthode demandée ne correspond pas à la route. Comparez le package, le service et la méthode dans le proto-déployé avec le chemin de route complet. Incluez le / initial dans le schéma de route, mais pas dans l’argument RPC de grpcurl.
Une erreur de nom d’hôte ou de certificat TLS survient. Vérifiez que le nom d’hôte fourni à grpcurl correspond au domaine et au certificat Front Door. Utilisez TLS, pas -plaintext.

Considérations relatives au pare-feu d’application web

Azure Front Door WAF peut évaluer les métadonnées de requêtes HTTP/2 prises en charge, telles que l’URI, les en-têtes, l’adresse IP du client et la géographie. Des scénarios de limitation de débit basés sur les métadonnées pris en charge peuvent également s’appliquer.

Front Door ne décode pas les messages protobuf. Les règles WAF qui dépendent de l’inspection du corps du message gRPC ne fournissent pas d’inspection de la charge utile protobuf. Validez les messages dans l’application gRPC ou dans un autre composant qui comprend le schéma protobuf. Ne considérez pas les vérifications de métadonnées comme une protection au niveau des messages.

Pour plus d’informations, consultez Web Application Firewall sur Azure Front Door.

Surveiller le trafic gRPC

Configurez les journaux de diagnostic et corrélez les journaux d’accès Front Door avec les journaux d’application gRPC côté origine. Vérifiez à la fois le statut HTTP et le statut gRPC retourné dans les en-têtes de fin. Une réponse HTTP 200 peut toujours porter un statut d’application gRPC non OK.

Si vous envoyez les journaux d’accès à la AzureDiagnostics table dans un espace de travail Log Analytics, utilisez la requête suivante pour inspecter les métadonnées HTTP du service exemple :

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.CDN"
    and Category == "FrontDoorAccessLog"
| where TimeGenerated > ago(1d)
| where requestUri_s contains "/greet.Greeter/"
| project TimeGenerated, ResourceId, requestUri_s,
          httpVersion_s, httpStatusCode_s

Remplacez /greet.Greeter/ par votre chemin de service. La requête affiche les URI de requête, les versions HTTP et les codes d’état HTTP, et non le statut gRPC dans les en-têtes de fin de réponse. Utilisez les journaux gRPC côté origine pour enquêter sur l’état de l’application et corréler les défaillances avec les journaux d’accès de Front Door.

Contenu connexe

  • Dernière mise à jour :