Un entorno proporciona un contexto aislado o una “zona de pruebas” para ejecutar proxies de API. En una sola organización, puedes crear varios entornos. Para obtener más información, consulta Información acerca de los entornos y grupos de entornos.
Durante una instalación básica, agregaste un entorno a fin de realizar pruebas. Sin embargo, se recomienda crear varios entornos e implementar una cantidad limitada de proxies en cada uno.
Acerca de los entornos y hosts virtuales
Apigee Hybrid usa puertas de enlace de entrada de Istio para controlar el tráfico entrante de la API. Los servicios de entorno de ejecución y MART están configurados con puertas de enlace de entrada de Istio para administrar sus conexiones que se exponen fuera del clúster. Esto significa que, por ejemplo, todas las solicitudes HTTP y HTTPS a un proxy de API se controlan primero mediante una puerta de enlace de entrada de Istio.
En el híbrido, debes crear uno o más entornos y asignarle a cada uno un alias de host. El alias de host es un nombre de DNS. El tráfico entrante a ese nombre de DNS se enruta mediante la entrada a ese entorno. De forma interna, cada entorno se asigna a un solo procesador de mensajes, que se encarga de procesar solicitudes de proxy, aplicar políticas y enrutar el tráfico hacia y desde los servicios de destino. Por lo tanto, el alias de host determina qué procesador de mensajes reciben las solicitudes entrantes.
En el siguiente código, se muestra un ejemplo de configuración en el que se definen varios entornos. (Esas opciones de configuración pertenecen a tu archivo de anulaciones). Ten en cuenta que los entornos dev1 y prod1 tienen diferentes alias de host:
envs:
- name: dev1
hostAlias: "apitest.mydomain.net"
...
- name: prod1
hostAlias: "apiprod.mydomain.net"
...
Supongamos que un proxy con la ruta base /foo1 se implementa en el entorno dev1. Puedes llamar al proxy de la siguiente manera:
curl -k https://apitest.mydomain.net/foo1
Cuando esta llamada llega a la entrada, la entrada sabe enviarla al procesador de mensajes asociado con el entorno dev1, que controla la solicitud.
Del mismo modo, si foo1 también se implementa en el entorno prod1, puedes realizar una solicitud de proxy como esta, al alias de host apiprod.mydomain.net:
curl -k https://apiprod.mydomain.net/foo1
Y la llamada se enruta a través de la entrada al MP asociado con ese host.
En resumen, cada entorno que crees debe tener asignado un alias de host. Cada entorno se mapea a un solo procesador de mensajes, y el alias de host determina qué procesador de mensajes recibe una solicitud determinada.
Los entornos pueden compartir el mismo alias de host.
Apigee Hybrid te permite crear varios entornos que puedes administrar de la forma que desees. Por ejemplo, puedes crear varios entornos para desarrolladores, dev1, dev2, dev3, etc., y asignar un alias de host único a cada uno. Además, puedes implementar varios proxies en cada entorno.
Antipatrón: Implementa todos tus proxies en un entorno híbrido.
Prácticas recomendadas: Crea varios entornos e implementa una cantidad limitada de proxies en cada uno. La técnica para administrar cómo las rutas híbridas realizan llamadas al entorno correcto que comparten un alias de host se denomina enrutamiento de la ruta base.
Por ejemplo, en la siguiente configuración, los entornos dev1 y dev2 comparten el mismo alias de host:
envs:
- name: dev1
hostAlias: "apitest.mydomain.net"
...
- name: dev2
hostAlias: "apitest.mydomain.net"
...
Cuando varios entornos comparten el mismo alias de host, debes usar la técnica de configuración llamada enrutamiento de la ruta base para mapear rutas de base de proxy específicas a entornos específicos. Consulta Enrutamiento de la ruta base para obtener más información.
Limita la cantidad de implementaciones de proxy
Para los entornos híbridos, el hecho de que muchos entornos puedan compartir el mismo host virtual significa que debes pensar con cuidado sobre cómo administras tus implementaciones de proxy en cualquier entorno determinado. En el híbrido, se recomienda crear múltiples entornos e implementar una cantidad limitada de proxies en cada uno.
¿Cuántos proxies debería implementar en un entorno? No hay una respuesta establecida para esta pregunta. Sin embargo, en la siguiente tabla se proporciona orientación general sobre por qué es recomendable limitar la cantidad de proxies implementados en cada entorno y lo que debes tener en cuenta cuando administras las implementaciones de proxy:
.| Problema que se debe tener en cuenta | Descripción |
|---|---|
| Tiempo de inicio del procesador de mensajes | Existe una correlación directa entre el tiempo que toma el procesador de mensajes (MP) y la cantidad de proxies que se implementan en ese MP. En un entorno de Kubernetes con ajuste de escala automático, un aumento en el tiempo de inicio puede ser un problema. Cuantos más proxies se implementen en el MP, más tiempo le tomará aparecer a ese archivo en caso de que se deba escalar o volver a crear. |
| Escalamiento de rendimiento | Si tienes varios proxies implementados en un entorno y uno de ellos recibe mucho tráfico para que ajuste la escala de forma automática con frecuencia, todos los proxies de ese entorno escalarán con él. El efecto de rendimiento del escalamiento de varios proxies con un solo proxy de tráfico alto puede ser un problema. |
| Vecino ruidoso | Si tienes varios proxies implementados en el mismo entorno y uno falla, todos los proxies del entorno se borrarán mientras se reinician los MP. Cuando limitas la cantidad de proxies implementados en un entorno, minimizas el impacto de una falla de proxy único. |
Referencia de configuración del entorno
Para obtener una lista completa de los elementos de configuración del entorno, consulta envs en la referencia de la propiedad de configuración.
Trabajar con entornos
Para obtener más información sobre la configuración, consulta los siguientes temas: