Información sobre los entornos

Un entorno proporciona un contexto aislado o un "entorno aislado" para ejecutar proxies de API. En una misma organización, puedes crear varios entornos. Para obtener más información, consulta Acerca de los entornos y los grupos de entornos.

Durante una instalación básica, añadiste un entorno para hacer pruebas. Sin embargo, es una práctica recomendada crear varios entornos e implementar un número limitado de proxies en cada uno.

Acerca de los hosts virtuales y los entornos

Apigee hybrid usa pasarelas de entrada de Istio para gestionar el tráfico de APIs entrante. Los servicios de tiempo de ejecución y MART se configuran con las pasarelas de entrada de Istio para gestionar sus conexiones expuestas fuera del clúster. Esto significa, por ejemplo, que todas las solicitudes HTTP y HTTPS a un proxy de API se gestionan primero mediante una pasarela de entrada de Istio.

En el modelo híbrido, se crean uno o varios entornos y se asigna un alias de host a cada uno. El alias de host es un nombre de DNS. El tráfico entrante a ese nombre de DNS se enruta mediante el ingreso a ese entorno. Internamente, cada entorno se asigna a un único procesador de mensajes, que se encarga de procesar las solicitudes de proxy, aplicar las 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 recibe una solicitud entrante determinada.

En el siguiente código se muestra un ejemplo de configuración en el que se definen varios entornos. Estas configuraciones deben estar en el archivo de anulaciones. Ten en cuenta que los entornos dev1 y prod1 tienen alias de host diferentes: 

envs:
  - name: dev1
    hostAlias: "apitest.mydomain.net"
    ...

  - name: prod1
    hostAlias: "apiprod.mydomain.net"
    ...

Supongamos que un proxy con la ruta base /foo1 se despliega en el entorno dev1. Puedes llamar al proxy de esta forma: 

curl -k https://apitest.mydomain.net/foo1

Cuando esta llamada llega al ingress, este sabe que debe enviarla al procesador de mensajes asociado al entorno dev1, que gestiona la solicitud.

Del mismo modo, si foo1 también se ha implementado en el entorno prod1, puedes hacer una solicitud proxy como esta al alias de host apiprod.mydomain.net: 

curl -k https://apiprod.mydomain.net/foo1

La llamada se enruta a través del ingreso al MP asociado a ese host.

En resumen, cada entorno que cree debe tener asignado un alias de host. Cada entorno se asigna a un único 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 gestionar como quieras. Por ejemplo, puedes crear varios entornos de desarrollo (dev1, dev2, dev3, etc.) y asignar un único alias de host a cada uno. Además, puedes desplegar varios proxies en cada entorno.

Antipatrón: despliega todos tus proxies en un entorno híbrido.

Práctica recomendada: Crea varios entornos y despliega un número limitado de proxies en cada uno. La técnica para gestionar cómo las rutas híbridas proxy llaman al entorno correcto que comparte un alias de host se denomina enrutamiento de 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 ruta base para asignar rutas base de proxy específicas a entornos específicos. Consulta enrutamiento de ruta base para obtener más información.

Limitar el número de implementaciones de proxy

En el caso de los entornos híbridos, el hecho de que muchos entornos puedan compartir el mismo host virtual significa que debes pensar detenidamente cómo gestionas tus implementaciones de proxy en un entorno concreto. En los entornos híbridos, lo más recomendable es crear varios entornos y desplegar un número limitado de proxies en cada uno.

¿Cuántos proxies debes implementar en un entorno? No hay una respuesta concreta a esta pregunta, pero en la siguiente tabla se ofrecen directrices generales sobre por qué es recomendable limitar el número de proxies desplegados en cada entorno y qué debes tener en cuenta al gestionar los despliegues de proxies:

Problema que debes tener en cuenta Descripción
Tiempo de arranque del procesador de mensajes Existe una correlación directa entre el tiempo que tarda en iniciarse un procesador de mensajes y el número de proxies implementados en ese procesador. En un entorno de Kubernetes con escalado automático, un aumento del tiempo de arranque puede ser un problema. Cuantos más proxies se implementen en el MP, más tiempo tardará en iniciarse si necesita escalarse o recrearse.
Rendimiento de escalado Si tienes varios proxies desplegados en un entorno y uno de ellos recibe mucho tráfico, de forma que se escala automáticamente con frecuencia, todos los proxies de ese entorno se escalarán con él. El efecto en el rendimiento de escalar varios proxies con un solo proxy de alto tráfico puede ser un problema.
Vecino ruidoso Si tienes varios proxies desplegados en el mismo entorno y uno de ellos falla, todos los proxies del entorno se desactivarán mientras se reinician los MPs. Si limitas el número de proxies implementados en un entorno, minimizas el impacto de un fallo de un solo proxy.

Referencia de configuración del entorno

Para ver 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: