Cloud Endpoints est un système de gestion d'API distribué comprenant des services, des environnements d'exécution et des outils. Cloud Endpoints assure les tâches de gestion, de surveillance et d'authentification.
Cloud Endpoints est constitué des éléments suivants :
Extensible Service Proxy (ESP) ou Extensible Service Proxy v2 (ESPv2), qui permet d'injecter les fonctionnalités Cloud Endpoints.
Service Control, qui permet d'appliquer les règles de gestion des API.
Service Management, qui permet de configurer les règles de gestion des API.
Google Cloud CLI, pour le déploiement et la gestion
La console Google Cloud, qui permet la journalisation, la surveillance et le partage.
Architecture Endpoints
Éléments Cloud Endpoints
ESP
ESP est un proxy basé sur NGINX qui s'exécute avant le backend et injecte des fonctionnalités Endpoints telles que l'authentification, la surveillance et la journalisation. ESP récupère une configuration de service à partir de Service Management et s'en sert pour valider les requêtes entrantes.
ESP est conçu pour être déployé sur un environnement conteneurisé et pour valider les jetons JWT et les jetons d'ID Google. Il utilise diverses techniques telles que la mise en cache intensive et les appels asynchrones pour rester léger et performant.
La compatibilité avec ESP est assurée sur les plates-formes suivantes :
ESPv2
ESPv2 est un proxy évolutif hautes performances basé sur Envoy qui s'exécute devant un backend d'API OpenAPI ou gRPC. Sur ESPv2, Endpoints est compatible avec la version 2 de la spécification OpenAPI et les spécifications gRPC.
ESPv2 s'intègre à l'infrastructure de services Google pour proposer des fonctionnalités de gestion d'API à grande échelle, telles que l'authentification, les rapports de télémétrie, les métriques et la sécurité.
La compatibilité avec ESPv2 est disponible pour les plates-formes suivantes :Service Control
Service Control applique les règles de gestion des API lors de l'exécution, telles que l'authentification par clé, la surveillance et la journalisation. Service Control utilise les méthodes suivantes :
Vérification : vérifie les clés d'authentification et les clés API et indique si un appel doit être autorisé.
Rapport : notifie les systèmes lors d'enregistrements de journalisation et de surveillance
Service Management
Avec Service Management, vous décrivez le comportement de votre service gRPC dans un fichier YAML appelé configuration Endpoints. Vous déployez la configuration Endpoints et vos fichiers.proto compilés sur Service Management à l'aide de la gcloud CLI, qui configure les règles de gestion de l'API.
D'autres tâches liées à la configuration sont également effectuées ici, telles que le partage de votre API avec d'autres développeurs, l'activation et la désactivation de l'API dans différents projets et la génération de clés API.
gcloud CLI
La gcloud CLI fournit la Google Cloud CLI qui vous permet d'appeler divers services Google Cloud. Utilisez la Google Cloud CLI pour déployer votre configuration Endpoints sur Service Management.
Console Google Cloud
La console Google Cloud est l'interface utilisateur graphique de Google Cloud. Endpoints utilise la console Google Cloud pour exposer les données de surveillance et de journalisation envoyées à partir d'ESP ou ESPv2, et enregistrées par Service Control et partager des API avec d'autres développeurs, ainsi que pour générer des clés API permettant d'appeler l'API.
Scénarios de déploiement
Les options de déploiement varient en fonction de l'utilisation d'ESP ou d'ESPv2 en tant que proxy Endpoints. ESPv2 peut être déployé en tant que proxy distant, et ESPv2 et ESP peuvent être déployés en mode side-car, comme expliqué dans les sections suivantes.
Mode proxy distant
Si vous utilisez ESPv2, Endpoints peut être déployé en tant que proxy distant. Ce mode permet de gérer les applications exécutées sur des plates-formes sans serveur telles que Cloud Run, Cloud Functions et App Engine pour les environnements standards.
Dans ce mode, ESPv2 est déployé en tant qu'application Cloud Run. L'application est configurée pour faire appel à ESPv2 en tant que backend distant à l'aide du champ x-google-backend de la configuration du service OpenAPI. Lorsqu'il est utilisé comme proxy distant dans ce mode de déploiement, une seule version d'ESPv2 peut prendre en charge plusieurs backends distants.
Mode side-car
ESP et ESPv2 sont compatibles avec le déploiement dans un conteneur avec chaque instance de votre backend. Cette topologie locale au serveur est idéale pour les API Web ainsi que pour les microservices. Elle évite les sauts de réseau généralement associés aux proxys centralisés et permet une gestion des API performante et évolutive.
L'équilibrage de charge est généralement appliqué avant que le trafic n'atteigne ESP ou ESPv2. Sur Compute Engine, cette opération est réalisée par Cloud Load Balancing. Pour les déploiements Kubernetes, un proxy d'entrée peut être utilisé pour l'équilibrage de charge. Dans Google Kubernetes Engine, Cloud Load Balancing ou un proxy d'entrée peut être utilisé pour l'équilibrage de charge.
Au démarrage, ESP ou ESPv2 obtient sa configuration de service auprès de Service Management. La configuration du service est générée à partir de la spécification OpenAPI ou depuis gRPC, le fichier YAML de configuration du service. Il indique au proxy ESP ou ESPv2 la surface de l'API à gérer ainsi que les règles, telles que les méthodes nécessitant une authentification et celles requérant des clés API.
Routage des requêtes
Lorsqu'une requête est reçue, ESP ou ESPv2 crée un jeton de trace pour Cloud Trace.
Ensuite, ESP ou ESPv2 fait correspondre le chemin d'accès des requêtes entrantes avec la surface de l'API. Après avoir trouvé le chemin correspondant, ESP ou ESPv2 effectue toutes les étapes d'authentification pour la méthode spécifiée.
Si la validation JWT est nécessaire, ESP ou ESPv2 valide l'authentification à l'aide de la clé publique appropriée pour le signataire et valide le champ d'audience dans le JWT. Si une clé API est requise, ESP ou ESPv2 appelle l'API Service Control pour la valider.
Service Control recherche la clé pour la valider et s'assure que le projet qui lui est associé a activé l'API. Si la clé n'est pas valide ou si le projet n'a pas activé l'API, l'appel est rejeté et est consigné via l'API Service Control.
Si Service Control valide la clé, la requête, ainsi que tous les en-têtes d'origine, et l'en-tête de validation JWT le cas échéant, sont transmis au backend.
Lorsqu'une réponse est reçue du backend, ESP ou ESPv2 renvoie la réponse à l'appelant et envoie les informations de date et heure finales à Stackdriver Trace. Les points d'appel sont enregistrés par l'API Service Control, qui écrit les métriques et les journaux dans les destinations appropriées.
ESP ou ESPv2 sur Kubernetes
Le schéma suivant illustre l'architecture globale dans laquelle ESP s'exécute en tant que conteneur "side-car" devant le conteneur d'applications de service d'API, avec l'API my-api hébergée sur my-api.com et reposant sur un service Kubernetes. L'architecture est la même pour un déploiement side-car avec ESPv2.
