Estás viendo la documentación de Apigee X.
Consulta la documentación de Apigee Edge.
Antecedentes
El entorno de ejecución de Apigee usa el intercambio de tráfico de redes de VPC para enrutar el tráfico a los servicios de backend. Esta interacción se muestra en el siguiente diagrama simplificado:
Cuando se crea una organización de Apigee, los clientes deben proporcionar una red con la que Apigee pueda intercambiar tráfico:
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"
}'
Dado que las aplicaciones de destino/backend se encuentran en la red con intercambio de tráfico, Apigee puede acceder a cualquiera de las direcciones IP y enrutar el tráfico hacia ellas.
Muchas empresas cuentan con varias redes en las que implementaron sus aplicaciones. Sin embargo, Apigee admite el intercambio de tráfico con una sola red. En este documento, se analiza una estrategia para los clientes que necesitan que Apigee envíe tráfico a varias redes.
Propuesta
Apigee propone crear una red nueva (o reutilizar una existente) como red de tránsito. La red de tránsito actúa como concentrador para todas las demás redes. Apigee será uno de los radios de este centro.
Esto se ilustra en la siguiente imagen:
En este ejemplo, las empresas tienen cargas de trabajo en network 1 y network
2 (en Google Cloud) y network 3 (ejecutar en las instalaciones locales).
El cliente crea (o vuelve a usar) una red llamada transit. Todas las redes intercambian tráfico con esta red, incluida la reservada para Apigee.
Hay casos en los que un cliente no desea que se realice un intercambio de tráfico de red de Apigee directamente con la red transit. En esos casos, el cliente aprovisiona una red nueva (llamada apim) intercambia el tráfico de esa red con Apigee. Luego, la red apim realiza un intercambio de tráfico con la red transit.
Esto se ilustra en la siguiente imagen:
Dirige el tráfico a la VPC de tránsito
En el caso en el que la red de Apigee no intercambia tráfico de forma directa con la red transit, configura un grupo de instancias administrado de Compute Engine (MIG) con reglas iptable para reenviar todo el tráfico a la red de tránsito como se muestra en la siguiente imagen:
En el resto de este documento, se exploran estrategias para que Apigee envíe tráfico a cargas de trabajo que se ejecutan en network 1 y network 2, entre otros, desde la red transit.
iptables
Usa iptables para enrutar el tráfico
En esta opción, se usan reglas iptable en Compute Engine para enrutar el tráfico a backends diferentes. En el proxy de API de Apigee, el extremo de destino contendrá ILB_IP1:Port1 o ILB_IP1:Port2, etcétera. Cada puerto identifica de forma única un servicio de backend diferente.
En la máquina virtual (VM) de Compute Engine, el cliente configuró reglas iptable para enrutar Port1 a DESTINATION_IP1:DestPort (en la red RFC 1918), etcétera. Cada vez que se incorpore un nuevo objetivo, se deberán actualizar las reglas iptable.
Ejemplo:
En este ejemplo, las llamadas a la API que llegan a Port1 se enrutarán a 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
Usa el balanceador de cargas interno para enrutar el tráfico
En esta opción, se usa el balanceador de cargas interno (L7) de Compute Engine para enrutar las solicitudes a varios backends. El balanceador de cargas interno (ILB) admite el enrutamiento basado en rutas de acceso (o nombre de host). Un ejemplo de url-map es el siguiente:
- 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
En el proxy de la API de Apigee, el extremo de destino contendrá ILB_IP y Port (probablemente 443) si el proyecto intercambia tráfico directamente con la red de tránsito.
El ILB del proyecto transit reenviará el tráfico a varias redes según el enrutamiento de la ruta de URL (o el enrutamiento basado en el nombre de host más la ruta). Un MIG de Compute Engine con iptables se vuelve a usar para conectar el tráfico a diferentes redes.