Cette page s'applique à Apigee et à Apigee hybrid.
Consultez la documentation d'
Apigee Edge.
Cet article présente l'architecture du système Apigee. Il est destiné à vous aider à comprendre quels composants sont créés lors du provisionnement et quel est leur but dans le système global.
Apigee propose deux options de provisionnement : avec appairage de VPC et sans appairage de VPC. Les deux options sont décrites dans les sections suivantes.
- Architecture avec appairage de VPC activé
- Architecture avec appairage de VPC désactivé
- Une application cliente appelle un proxy d'API Apigee.
- La requête arrive sur un équilibreur de charge HTTPS externe L7 global. L'équilibreur de charge externe est configuré avec une adresse IP externe/publique et un certificat TLS.
- L'équilibreur de charge externe envoie la requête à une machine virtuelle (VM). La VM sert de passerelle entre votre VPC et le VPC de Google (géré par Apigee).
- La VM envoie la requête à Apigee, qui traite la requête de proxy d'API.
- Apigee envoie la requête au service de backend, et la réponse est renvoyée au client.
Architecture avec appairage de VPC activé
Cette section décrit l'architecture système Apigee lorsqu'Apigee est provisionné avec l'option d'appairage de VPC.
Présentation du provisionnement
Lors du provisionnement, les composants sont configurés et créés pour permettre une communication bidirectionnelle entre un réseau cloud privé virtuel (VPC) géré par vous et un réseau VPC géré par Apigee. Une fois que vous avez suivi les premières étapes de provisionnement, les deux VPC existent, mais ne peuvent pas encore communiquer entre eux. Une configuration supplémentaire est nécessaire pour permettre la communication bidirectionnelle (voir Figure 1).
Pour permettre la communication entre les VPC, nous utilisons l'appairage de réseaux VPC. L'appairage de réseaux permet d'établir une connectivité via des adresses IP internes sur deux réseaux cloud privé virtuel (VPC), qu'ils appartiennent ou non au même projet ou à la même organisation Google Cloud. Une fois l'étape d'appairage de réseaux terminée, la communication est possible entre les deux VPC (voir Figure 2).
Pour acheminer le trafic des applications clientes sur Internet vers Apigee, nous utilisons un équilibreur de charge HTTPS externe global. Un XLB peut communiquer entre différents projets Google Cloud (par exemple, entre le projet Google Cloud client et le projet Google Cloud Apigee) à l'aide du référencement de services inter-projets.
Vous pouvez également provisionner un groupe d'instances géré contenant des machines virtuelles (VM) servant de liaison réseau. Les VM du groupe d'instances géré peuvent communiquer de manière bidirectionnelle sur les réseaux appairés. Une fois le provisionnement terminé, les applications sur Internet communiquent avec l'équilibreur de charge externe, l'équilibreur de charge externe communique avec la VM servant de passerelle, et la VM servant de passerelle communique avec le réseau Apigee (voir les figures 3 et 4).
Dans cette configuration, le trafic est acheminé depuis Apigee (par exemple, depuis la règle MessageLogging) vers une charge de travail exécutée dans votre VPC interne. Dans ce cas, la communication avec votre VPC interne ne passe pas par une adresse IP NAT du trafic sortant. À la place, vous pouvez acheminer le trafic via l'une des adresses IP d'instance Apigee.
Cycle de vie des appels du proxy d'API
L'illustration suivante présente le cycle de vie d'un appel de proxy d'API à mesure qu'il transite par les composants du système Apigee provisionné (Figure 5) :
Architecture avec appairage de VPC désactivé
Cette section décrit l'architecture système Apigee lorsqu'Apigee n'est pas provisionné avec l'option d'appairage de VPC.
Lors du provisionnement, les composants sont configurés et créés pour permettre une communication bidirectionnelle entre un réseau cloud privé virtuel (VPC) géré par vous-même et un réseau VPC géré par Apigee. Une fois que vous avez suivi les premières étapes de provisionnement, les deux VPC existent, mais ne peuvent pas encore communiquer entre eux. Une configuration supplémentaire est nécessaire pour permettre la communication bidirectionnelle. Voir Figure 6.
Pour permettre la communication entre les VPC, nous utilisons Private Service Connect (PSC) pour acheminer le trafic Northbound vers Apigee et le trafic Southbound vers les services cibles exécutés dans vos projets Google Cloud.
PSC permet d'établir une connexion privée entre un producteur de services (Apigee) et un client du service (un ou plusieurs autres projets Cloud que vous contrôlez). Avec cette méthode (voir Figure 7), les requêtes transitent par un équilibreur de charge externe global ou par un équilibreur de charge externe régional vers un même point de rattachement (que l'on appelle un rattachement de service).
Pour connecter Apigee de manière privée à une cible de backend, vous devez créer deux entités : un rattachement de service sur le réseau VPC sur lequel la cible est déployée et un rattachement de point de terminaison dans le VPC Apigee. Ces deux entités permettent à Apigee de se connecter au service cible. Consultez la page Modèles de mise en réseau Southbound.
Les étapes de provisionnement d'Apigee avec PSC (sans appairage de VPC) sont décrites dans la section Effectuer un provisionnement en ligne de commande sans appairage de VPC.
