Vous consultez la documentation d'Apigee X.
Consultez la documentation d'Apigee Edge.
Expérience
L'environnement d'exécution Apigee utilise l' appairage de réseaux VPC pour acheminer le trafic vers les services de backend. Cette interaction est illustrée dans le schéma simplifié ci-dessous:
Lors de la création d'une organisation Apigee, les clients doivent fournir un réseau avec lequel Apigee peut s'appairer:
curl -H "$AUTH" -X POST \
-H "Content-Type:application/json" \
"https://apigee.googleapis.com/v1/organizations?parent=projects/$PROJECT_ID" \
-d '{
"name":"'"$PROJECT_ID"'",
"analyticsRegion":"'"$ANALYTICS_REGION"'",
"runtimeType":"CLOUD",
"authorizedNetwork":"NETWORK_NAME",
"runtimeDatabaseEncryptionKeyName":"DATABASE_KEY_NAME"
}'Étant donné que les applications cibles/backends se trouvent sur le réseau appairé, Apigee peut accéder à n'importe quelle adresse IP et acheminer le trafic vers celles-ci.
De nombreuses entreprises possèdent plusieurs réseaux dans lesquels elles ont déployé leurs applications. Toutefois, Apigee est compatible avec l'appairage avec un seul réseau. Ce document explore une stratégie pour les clients devant utiliser Apigee pour envoyer du trafic vers plusieurs réseaux.
– Proposition
Apigee propose de créer un réseau (ou de réutiliser un réseau existant) en tant que réseau de transit. Le réseau de transit sert de hub pour tous les autres réseaux. Apigee sera l'un des spokes de ce hub.
Ce flux est illustré dans le schéma suivant.
Dans cet exemple, l'entreprise dispose de charges de travail dans network 1 et network
2 (sur Google Cloud) et network 3 (exécution sur site).
Le client crée (ou réutilise) un réseau appelé transit. Tous les réseaux appairés avec ce réseau, y compris celui réservé à Apigee.
Dans certains cas, un client peut ne pas souhaiter l'appairage réseau d'Apigee directement avec le réseau transit. Dans ce cas, le client provisionne un nouveau réseau (appelé apim) et effectue l'appairage de ce réseau avec Apigee. Le réseau apim est ensuite appairé au réseau transit.
Ce flux est illustré dans le schéma suivant.
Obtenir le trafic vers le VPC de transit
Dans le cas où le réseau Apigee n'est pas directement appairé au réseau transit, configurez un groupe d'instances géré (MIG) Compute Engine avec des règles iptable pour transférer tout le trafic vers le réseau de transit. comme illustré dans l'image suivante:
Le reste de ce document explore les stratégies permettant à Apigee d'envoyer du trafic aux charges de travail s'exécutant dans network 1, network 2, etc. à partir du réseau transit.
iptables
Utiliser iptables pour acheminer le trafic
Cette option utilise les règles iptable sur Compute Engine pour acheminer le trafic vers différents backends. Dans le proxy de l'API Apigee, le point de terminaison cible contient ILB_IP1:Port1 ou ILB_IP1:Port2, etc. Chaque port identifie de manière unique un service de backend différent.
Sur la machine virtuelle (VM) Compute Engine, le client doit définir des règles iptable pour acheminer Port1 vers DESTINATION_IP1:DestPort (dans le réseau RFC 1918), etc. Chaque fois qu'une nouvelle cible est intégrée, les règles iptable doivent être mises à jour.
Exemple :
Dans cet exemple, les appels d'API arrivant à Port1 seront routés vers DESTINATION_IP1:DestPort:
sysctl -w net.ipv4.ip_forward=1 # change source IP to (NAT) VM IP iptables -t nat -A POSTROUTING -j MASQUERADE # change the destination IP to the real target ip and port iptables -t nat -A PREROUTING -p tcp --dport Port1 -j DNAT --to-destination DESTINATION_IP1:DestPort
L7 ILB
Routage du trafic à l'aide de l'équilibreur de charge interne
Cette option utilise l'équilibreur de charge interne (L7) de Compute Engine pour acheminer les requêtes vers différents backends. L'équilibreur de charge interne (ILB) est compatible avec le routage basé sur le chemin d'accès (ou nom d'hôte + chemin). Voici un exemple url-map:
- hosts: - '*' pathMatcher: path-matcher-1 id: '3331829996983273293' kind: compute#urlMap name: apigee-l7-ilb pathMatchers: - defaultService: https://www.googleapis.com/compute/v1/projects/apigee-product-demo/regions/us-west1/backendServices/service-products name: path-matcher-1 pathRules: - paths: - /products/* service: https://www.googleapis.com/compute/v1/projects/apigee-product-demo/regions/us-west1/backendServices/service-products - paths: - /catalog/* service: https://www.googleapis.com/compute/v1/projects/apigee-product-demo/regions/us-west1/backendServices/service-catalog
Dans le proxy de l'API Apigee, le point de terminaison cible contiendra ILB_IP et Port (probablement 443) si le projet est directement appairé au réseau de transit.
L'ILB du projet transit transfère le trafic vers différents réseaux en fonction du routage de chemin d'URL (ou du nom d'hôte + du routage basé sur le chemin). Un MIG Compute Engine avec iptables est utilisé à nouveau pour acheminer le trafic vers différents réseaux.