Acerca de los entornos

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.

En el siguiente código, se muestra un ejemplo de configuración de anulación en el que se definen varios entornos. 

namespace: my-namespace
org: my-organization
...
envs:
  - name: test
    serviceAccountPaths:
      synchronizer: "your_keypath/synchronizer-manager-service-account.json
      udca: "your_keypath/analytic-agent-service-account.json

  - name: prod
    serviceAccountPaths:
      synchronizer: "your_keypath/synchronizer-manager-service-account.json
      udca: "your_keypath/analytic-agent-service-account.json
...

Supongamos que un proxy con la ruta base /foo1 se implementa en la prueba del entorno. Puedes llamar al proxy de la siguiente manera: 

curl -k https://api.example.com/foo1

Cuando esta llamada llega a la entrada, la entrada sabe enviarla al procesador de mensajes asociado con el entorno test, que controla la solicitud.

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

curl -k https://apiprod.example.com/foo1

Y la llamada se enruta a través de la entrada al MP asociado con ese host.

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.

Limita la cantidad de implementaciones de proxy

Para los híbridos, el hecho de que muchos entornos puedan compartir los mismos hosts virtuales que se definen en los grupos de entornos significa que debes pensar cuidadosamente 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.

Grupos de entornos y hosts virtuales

Los grupos de entornos te permiten agrupar entornos. Los entornos dentro de cada grupo comparten los mismos nombres de host. Puedes agrupar los entornos por función, nombre de host y región, si implementas una instalación híbrida multirregional, o mediante cualquier otra métrica que elijas.

Debido a que el enrutamiento se administra mediante la combinación de los nombres de host del grupo de entornos, las rutas base del proxy de API y los entornos, cada host virtual solo necesita enumerar el nombre del grupo de entornos y cualquier certificado apropiado.

En el siguiente código, se muestra un ejemplo de configuración de anulación en el que se definen varios hosts virtuales. Ten en cuenta que los nombres de los hosts virtuales deben ser los nombres de los grupos de entornos. 

gcp:
  region: us-central1
  projectID: hybrid-example

k8sCluster:
  name: apigee-hybrid
  region: us-central1

org: hybrid-example

instanceID: "my_hybrid_example"

virtualhosts:
  - name: group-1  # the name of an environment group
    sslCertPath: ./certs/keystore.pem
    sslKeyPath: ./certs/keystore.key

virtualhosts:
  - name: group-2
    sslCertPath: ./certs/keystore.pem
    sslKeyPath: ./certs/keystore.key
...

Recursos adicionales