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 d'API créée lorsque vous importez une définition d'API. Vous créez la définition d'API en tant que spécification OpenAPI. Si votre API gère des services gRPC sur Cloud Run, vous pouvez définir votre API 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. En d'autres termes, vous pouvez créer une configuration d'API, mais vous ne pourrez 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 que vous importez la définition de l'API modifiée, vous créez une configuration d'API.

  2. Passerelle : proxy évolutif hautes performances basé sur Envoy qui héberge la configuration d'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 d'API, une configuration d'API est déployée sur une passerelle, ce qui rend les API accessibles aux clients d'API.

Une passerelle :

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

  • Vous devez 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 la 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

Sélectionnez une région Google Cloud

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

  • 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 d'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 d'API utilisent ensuite une URL au format suivant pour accéder à la configuration d'API déployée :

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

où GATEWAY_ID est le nom de la passerelle, HASH le code de hachage unique généré lors du déploiement de l'API, et REGION_CODE le code de la région Cloud où 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 aux rôles accordés au compte de service utilisé pour créer la configuration d'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. De cette façon, vous pouvez 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 être attribué au rôle 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 de backend.

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

À propos du scaling à zéro instance

API Gateway est un service scale-to-zero. 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 scale-to-zero est contrôlé automatiquement par Google Cloud. 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. Vous n'êtes pas obligé 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 Déployer une API dans plusieurs régions.

Configurer l'accès SSL à une API

API Gateway est compatible avec 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.

Configurer 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 conjointement avec l'équilibrage de charge HTTP(S) pour API GatewayBÊTA. Pour personnaliser le nom de domaine, créez un équilibreur de charge afin d'utiliser votre nom de domaine personnalisé, puis redirigez les requêtes vers le domaine gateway.dev de votre API déployée. Pour en savoir plus, consultez 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 de la 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 des configurations d'API sur plusieurs passerelles dans 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 développement, une configuration d'API en test sur la plate-forme de préproduction et une configuration d'API 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 Google Cloud . Le déploiement dans plusieurs régions offre plusieurs avantages, y compris une latence de requête 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 s'exécutant dans d'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 déployée, 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 configurez 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 de les transférer vers la région appropriée. Pour en savoir plus, consultez Créer des déploiements multirégionaux pour API Gateway.

Mettre à jour une API

Vous pouvez mettre à jour une API déployée en modifiant sa définition dans la spécification OpenAPI, puis en important la spécification. L'importation d'une nouvelle spécification crée une configuration d'API.

API Gateway est compatible avec un modèle de mise à jour sans temps d'arrêt, ce qui signifie que votre API continue de traiter les requêtes pendant le déploiement de la configuration d'API mise à jour. Toutefois, pendant le déploiement de la nouvelle configuration d'API, il est possible que certaines requêtes soient encore traitées par la version précédente de la configuration d'API.

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

Étape suivante