Modèle de déploiement de la passerelle API

À propos des composants d'API

Une API définie sur API Gateway comprend deux composants principaux :

  1. Configuration d'API : configuration de l'API créée lorsque vous importez une définition d'API. Vous créez la définition de l'API en tant que spécification OpenAPI. Si votre API gère des services gRPC sur Cloud Run, vous pouvez la définir avec une définition et une configuration de service gRPC.

    Chaque fois que vous importez une définition d'API, API Gateway crée une configuration d'API. Autrement dit, vous pouvez créer une configuration d'API, mais vous ne pouvez pas la modifier par la suite. Si vous modifiez ultérieurement la définition de l'API dans la spécification OpenAPI ou la définition du service gRPC, puis importez la définition de l'API modifiée, vous créez une nouvelle configuration d'API.

  2. Passerelle : proxy évolutif hautes performances basé sur Envoy qui héberge la configuration de l'API déployée. Le déploiement d'une configuration d'API sur une passerelle crée l'URL externe que vos clients API utilisent pour accéder à l'API.

L'image suivante montre ces composants :

La définition de l'API dans le volet d'API Gateway affiche trois composants de configuration de l'API et trois composants de la passerelle.

À propos du déploiement d'une configuration d'API sur une passerelle

Vous déployez une configuration d'API sur une passerelle pour rendre votre API accessible à vos clients d'API :

Dans trois exemples API, une configuration d'API est déployée sur une passerelle, ce qui rend les API accessibles aux clients API.

Une passerelle :

  • est déployé dans une région GCP spécifique ; Une région est une zone géographique spécifique sur GCP où vous pouvez déployer des ressources.

  • Doit héberger une configuration d'API. Vous ne pouvez pas créer de passerelle vide, c'est-à-dire sans configuration d'API. Toutefois, une fois une passerelle créée, vous pouvez la mettre à jour pour remplacer une configuration d'API par une autre.

  • Ne peut héberger qu'une seule configuration d'API. Vous ne pouvez pas déployer plusieurs configurations d'API sur la même passerelle.

Vous gérez ensuite chaque passerelle déployée séparément. Pour chaque passerelle, vous pouvez :

  • Démarrer/arrêter/supprimer la passerelle
  • Afficher les journaux et les métriques
  • Afficher les informations de trace

Choisir une région GCP

Chaque passerelle est déployée dans une région géographique spécifique sur GCP. API Gateway est compatible avec les régions GCP suivantes pour le déploiement:

  • asia-northeast1
  • australia-southeast1
  • europe-west1
  • europe-west2
  • us-east1
  • us-east4
  • us-central1
  • us-west2
  • us-west3
  • us-west4

Définir le point de terminaison de la configuration de l'API déployée

Lorsque vous déployez une configuration d'API sur une passerelle, API Gateway crée une URL unique pour la passerelle dans le domaine gateway.dev. Vos clients API Utilisez une URL au format ci-dessous pour accéder à la configuration de l'API déployée:

https://GATEWAY_ID-HASH.REGION_CODE.gateway.dev

où GATEWAY_ID est le nom de la passerelle, HASH est le code de hachage unique généré lorsque vous avez déployé l'API. et REGION_CODE est le code de la région GCP. sur laquelle vous avez déployé la passerelle.

Exemple :

my-gateway-a12bcd345e67f89g0h.uc.gateway.dev

Configurer un compte de service pour déployer des configurations d'API

Une configuration d'API déployée sur une passerelle s'exécute avec les autorisations associées au rôles attribués au compte de service utilisé pour créer la configuration de l'API. Par conséquent, vous définissez généralement un compte de service distinct pour créer des configurations d'API. Ce compte de service n'est ensuite attribué qu'aux rôles nécessaires pour accéder au service de backend. Vous pouvez ainsi limiter les autorisations associées à la configuration de l'API.

Outre les rôles nécessaires pour accéder au service de backend, le compte de service doit disposer des autorisations suivantes :

  • L'autorisation iam.serviceAccounts.actAs. Cette autorisation est incluse dans le rôle Utilisateur du compte de service.

  • Autorisations nécessaires pour accéder à votre service de backend. Par exemple, si votre backend est implémenté en tant que fonction Cloud, le compte de service doit au moins avoir le rôle de Demandeur Cloud Functions. Pour un backend Cloud Run, le rôle est Demandeur Cloud Run. En limitant les autorisations associées à la configuration de l'API, vous pouvez mieux sécuriser vos systèmes backend.

Pour en savoir plus, consultez la section Configurer votre environnement de développement.

À propos du scaling à zéro instance

API Gateway est un service scalable à zéro. Cela signifie qu'en l'absence de trafic, toutes les instances de passerelle sont supprimées. Lorsque le trafic augmente, des instances sont créées à la demande pour gérer la charge. Le scaling à zéro est contrôlé automatiquement par GCP. Vous n'avez pas besoin de le configurer ni de le gérer.

Utiliser un équilibreur de charge

Chaque passerelle déployée dans une région contient un équilibreur de charge intégré pour gérer les requêtes client envoyées à l'API déployée sur la passerelle. Il n'est pas nécessaire de créer un équilibreur de charge distinct pour chaque passerelle.

Vous devez créer un équilibreur de charge lorsque vous déployez la même API sur des passerelles situées dans différentes régions. L'équilibreur de charge dirige ensuite les requêtes d'API vers les différentes régions. Pour en savoir plus, consultez la section Déployer une API dans plusieurs régions ci-dessous.

Configurer l'accès SSL à une API

API Gateway accepte l'accès HTTPS à une API déployée sur une passerelle. Étant donné que vos API sont déployées sur le domaine gateway.dev, Google crée et gère le certificat SSL sur l'équilibreur de charge intégré à la passerelle. Vous n'avez pas besoin de créer ni d'importer votre propre certificat.

Configuration d'un serveur de noms de domaine

Par défaut, les clients API envoient des requêtes à un domaine gateway.dev pour accéder à une API déployée, comme indiqué ci-dessus.

Les noms de domaine personnalisés sont destinés à API Gateway lorsqu'ils sont utilisés avec l'BÊTA de l'équilibrage de charge HTTP(S) pour API Gateway. Pour personnaliser le nom de domaine, créez un équilibreur de charge pour utiliser votre nom de domaine personnalisé, puis dirigez les requêtes vers le domaine gateway.dev de votre API déployée. Pour en savoir plus, consultez la page Utiliser un domaine personnalisé avec API Gateway.

Déployer plusieurs configurations d'API dans la même API

Vous ne pouvez déployer qu'une seule configuration d'API sur une passerelle. Toutefois, vous pouvez déployer plusieurs configurations d'API sur plusieurs passerelles au sein d'une même API.

Cette section décrit deux scénarios dans lesquels vous pouvez déployer plusieurs configurations d'API sur plusieurs passerelles au sein d'une même API.

Déployer les configurations d'API sur plusieurs passerelles de la même région

Lors de la création d'une API, les développeurs d'API créent souvent des environnements de développement, de préproduction et de production, où :

  • L'environnement de développement est utilisé par les développeurs pour créer l'API.
  • L'environnement de préproduction permet de tester l'API en vue de lancer une version en production.
  • L'environnement de production est celui dans lequel vos clients API externes sont autorisés à accéder à l'API.

Pour prendre en charge ce type d'environnement de développement, vous devez définir plusieurs configurations d'API. Par exemple, vous pouvez avoir plusieurs configurations d'API en cours de développement, une configuration d'API en cours de test en préproduction et une configuration d'API actuellement déployée en production.

API Gateway vous permet de créer plusieurs configurations d'API au sein d'une même API, puis de déployer chaque configuration d'API sur une passerelle différente :

Dans l'API 1, trois configurations d'API appelées "API Config Dev", "API Config Stage" et "API Config Prod" sont déployées sur trois passerelles respectives.

Dans cet exemple, vous avez trois configurations d'API différentes : dev, stage et prod. Vous allez ensuite déployer chaque configuration d'API sur une passerelle différente, où chaque passerelle définit sa propre URL de point de terminaison unique.

Déployer une configuration d'API dans plusieurs régions

Vous déployez souvent une API dans plusieurs régions GCP. Le déploiement dans plusieurs régions offre plusieurs avantages. Par exemple, la latence des requêtes est réduite, car les requêtes sont dirigées vers une API s'exécutant dans une région géographiquement proche du client, et une fiabilité améliorée, car une défaillance dans une région n'affecte pas les API exécutées dans les autres régions.

Pour déployer une API dans plusieurs régions, vous devez déployer une configuration d'API sur une passerelle dans chaque région. Chaque configuration d'API est spécifique à la région de déploiement, car elle doit faire référence au service de backend de cette région.

Dans l'image suivante, les API 1 et 2 sont déployées dans une seule région, et l'API 3 est déployée dans plusieurs régions :

L'API 1 et l'API 2 sont déployées dans la région 1, et l'API 3 dans la région 1, la région 2 et la région 3 à l'aide d'un équilibreur de charge.

Dans cet exemple, chaque configuration d'API déployée sur une passerelle pour l'API 3 possède un point de terminaison d'URL unique, au format suivant :

https://my-gateway1-a12bcd345e67f89g0h.uc.gateway.dev
https://my-gateway2-b12cde345f67g89h0i.en.gateway.dev
https://my-gateway3-c12bde345g67h89i0j.uw.gateway.dev

Vous configurerez ensuite un équilibreur de charge à l'aide de l'équilibrage de charge HTTP(S) pour API GatewayPREVIEW afin de gérer les requêtes adressées à l'API et transférer les à la région appropriée. Pour en savoir plus, consultez Créer des déploiements multirégionaux pour API Gateway.

Mettre à jour une API

Pour mettre à jour une API déployée, modifiez la définition de l'API dans la spécification OpenAPI, puis importez la spécification. L'importation d'une nouvelle spécification crée une configuration d'API.

API Gateway accepte un modèle de mise à jour sans temps d'arrêt, ce qui signifie que vos L'API continue de gérer les requêtes pendant le déploiement de la configuration d'API mise à jour. Toutefois, le déploiement de la nouvelle configuration d'API dispose d'un certain temps peuvent toujours être gérées par la version précédente de la configuration d'API.

Si vous avez déployé la configuration de l'API dans plusieurs régions et passerelles, vous devez redéployer la configuration de l'API mise à jour dans chaque région séparément.

Étape suivante