Sie lesen die Dokumentation zu Apigee X.
Apigee Edge-Dokumentation aufrufen
Hintergrund
Die Apigee-Laufzeit verwendet VPC-Netzwerk-Peering, um Traffic an Back-End-Dienste weiterzuleiten. Diese Interaktion wird im vereinfachten Diagramm unten dargestellt:
Bei der Erstellung einer Apigee-Organisation müssen Kunden ein Netzwerk angeben, mit dem sich Peering verbinden kann:
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"
}'
Da sich die Ziel-/Back-End-Anwendungen im Peering-Netzwerk befinden, kann Apigee auf jede IP-Adresse zugreifen und Traffic an sie weiterleiten.
Viele Unternehmen haben mehrere Netzwerke, in denen Anwendungen bereitgestellt werden. Apigee unterstützt jedoch das Peering mit nur einem Netzwerk. In diesem Dokument wird eine Strategie für Kunden erläutert, die Apigee bitten, Traffic an mehrere Netzwerke zu senden.
Vorschlag
Apigee schlägt vor, ein neues Netzwerk zu erstellen oder ein vorhandenes noch einmal als Transitnetzwerk zu nutzen. Das Transitnetzwerk dient als Hub für alle anderen Netzwerke. Apigee ist eine der Spokes in diesem Hub.
Dies wird in der folgenden Abbildung veranschaulicht:
In diesem Beispiel verfügt das Unternehmen über Arbeitslasten in network 1 und network
2 (auf Google Cloud) und in network 3 (lokal).
Der Kunde erstellt oder verwendet ein Netzwerk mit dem Namen transit. Alle Netzwerke, die mit diesem Netzwerk verbunden sind, einschließlich des für Apigee reservierten Netzwerks.
Es kann vorkommen, dass ein Kunde das Netzwerk-Peering von Apigee nicht direkt mit dem Netzwerk transit wünschen. In solchen Fällen stellt der Kunde ein neues Netzwerk mit dem Namen apim bereit und verbindet dieses Netzwerk mit Apigee. Das apim-Netzwerk wird dann mit dem Netzwerk transit verbunden.
Dies wird in der folgenden Abbildung veranschaulicht:
Traffic zur Transit-VPC abrufen
Wenn das Apigee-Netzwerk nicht direkt mit dem transit-Netzwerk verbunden ist, richten Sie eine von Compute Engine verwaltete Instanzgruppe mit iptable-Regeln ein, um den gesamten Traffic an das Transitnetzwerk zu leiten, wie in der folgenden Abbildung dargestellt:
Im weiteren Verlauf dieses Dokuments werden Strategien untersucht, wie Apigee Traffic über das transit-Netzwerk an Arbeitslasten senden kann, die in network 1, network 2 usw. ausgeführt werden.
iptables
Traffic mit iptables weiterleiten
Diese Option verwendet iptable-Regeln in Compute Engine, um Traffic an verschiedene Back-Ends weiterzuleiten. Im Apigee API-Proxy enthält der Zielendpunkt ILB_IP1:Port1 oder ILB_IP1:Port2 und so weiter. Jeder Port identifiziert einen anderen Back-End-Dienst eindeutig.
Auf der virtuellen Maschine (VM) von Compute Engine würden Kunden iptable-Regeln einrichten, um Port1 an DESTINATION_IP1:DestPort (im RFC 1918-Netzwerk) usw. weiterzuleiten. Jedes Mal, wenn ein neues Ziel hinzugefügt wird, müssen iptable-Regeln aktualisiert werden.
Beispiel:
In diesem Beispiel werden API-Aufrufe an Port1 an DESTINATION_IP1:DestPort weitergeleitet:
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
Internen Load-Balancer zum Weiterleiten von Traffic verwenden
Diese Option verwendet den internen Load-Balancer (L7) von Compute Engine, um Anfragen an verschiedene Back-Ends weiterzuleiten. Das interne Load-Balancer (ILB) unterstützt pfad- oder hostname- und pfadbasiertes Routing. Ein url-map-Beispiel sieht so aus:
- 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
Im Apigee API-Proxy enthält der Zielendpunkt ILB_IP und Port (wahrscheinlich 443), wenn das Projekt direkt mit dem Transitnetzwerk verbunden ist.
Der ILB im Projekt transit leitet Traffic an verschiedene Netzwerke weiter, basierend auf der URL-Pfadweiterleitung (oder dem Hostnamen und dem pfadbasierten Routing). Eine Compute Engine- MIG mit iptables wird noch einmal verwendet, um den Traffic an verschiedene Netzwerke zu leiten.