Acerca de los entornos y los grupos de entornos

Esta página se aplica a Apigee y Apigee Hybrid.

Consulta la documentación de Apigee Edge.

En esta sección se describen los entornos y los grupos de entornos.

Información general

Un entorno de Apigee es un entorno de software dentro de una organización que permite crear y desplegar proxies de API. Debes desplegar un proxy de API en un entorno para poder acceder a él. Puedes desplegar un proxy de API en un solo entorno o en varios.

Cada entorno está sujeto a límites en el número de proxies de API, flujos compartidos y otros recursos que se pueden desplegar en él. Estos límites varían en función del tipo de organización de Apigee (Suscripción, Pago por uso o Híbrida) que utilice el entorno. Para obtener información más detallada, consulta la documentación sobre límites.

Un grupo de entornos (a veces denominado envgroup en la API de Apigee) es el mecanismo básico para definir la forma en que se enrutan las solicitudes a entornos concretos. Los nombres de host se definen en los grupos de entornos (no en entornos concretos) y Apigee enruta las solicitudes a los entornos de un grupo mediante esas definiciones de nombres de host.

Un entorno debe pertenecer al menos a un grupo de entornos para que puedas acceder a los proxies implementados en él. Es decir, debes asignar un entorno a un grupo para poder usarlo.

La agrupación lógica de entornos por grupo de entornos ofrece las siguientes ventajas:

• Gestión centralizada de nombres de host: los grupos de entornos proporcionan un lugar centralizado para gestionar los nombres de host.
• Estadísticas agregadas: con los grupos, puede analizar los errores consultando los informes de todo un grupo de entornos a la vez en lugar de los de entornos concretos.
• Evitar conflictos: al agrupar entornos, puedes asegurarte de que las rutas base de tus proxies implementados se encuentren en el mismo nombre de host.

Tipos de implementaciones admitidos

Apigee admite los siguientes tipos de implementaciones en un entorno:

Tipo	Descripción
Proxy	Desarrolla y prueba tus proxies de API en tus entornos de desarrollo de Apigee y, a continuación, despliégalos en los entornos de prueba de integración y producción de Apigee. Consulta Desplegar un proxy de APIs.
Archivar	Desarrolla y prueba tus proxies de API programables con Apigee en VS Code.

Resumen de las acciones bloqueadas con la implementación del archivo

Cuando habilites el despliegue de archivos en un entorno de Apigee, no podrás realizar las siguientes acciones en el entorno para evitar conflictos:

• En la interfaz de usuario de Apigee, no puedes ver, confirmar el estado de la implementación ni gestionar las implementaciones de archivos, tal como se describe en el artículo sobre cómo implementar un proxy de API, ni usar la interfaz de usuario de depuración, tal como se describe en el artículo sobre cómo usar la depuración. Como solución alternativa, puedes usar gcloud o la API para listar todos los despliegues de archivos en un entorno y usar la API Debug.
• No puedes crear, actualizar ni eliminar archivos de recursos ni servidores de destino con la interfaz de usuario, la API o gcloud de Apigee.
• Por el momento, no se admite la autenticación de Google con cuentas de servicio.

Nota: Puede gestionar mapas de pares clave-valor y almacenes de claves TLS en un entorno de Apigee que esté habilitado para la implementación de archivos.

Si intentas llevar a cabo alguna de las acciones que se indican más arriba, se producirá un error y aparecerá el siguiente mensaje:

FAILED_PRECONDITION

Unidades de despliegue de proxy

Las unidades de implementación de proxies cuentan los proxies y los flujos compartidos implementados en entornos por región.

Estos son los tipos de unidades de implementación:

• Las unidades de implementación de proxy estándar contabilizan el número de proxies implementados actualmente que se consideran proxies estándar.
• El recuento de unidades de implementación de proxy extensibles indica el número de proxies implementados que cumplen los requisitos para ser proxies extensibles.
• Las unidades de despliegue de flujo compartido cuentan el número de flujos compartidos desplegados.

Tu uso puede estar sujeto a la cuota de implementaciones, que es el límite de unidades de implementación que puedes usar a la vez. Consulta tus derechos (Pay-as-you-go o Suscripción 2024) para obtener más información. Para obtener información sobre los límites del sistema, consulta Unidades de implementación de proxy máximas por instancia.

Para obtener más información sobre cómo ver el uso de las unidades de implementación de proxy y los detalles de la cuota de implementaciones de tu organización, consulta Ver el uso de la implementación de proxy.

Tipos de entornos

Si tienes una suscripción de pago por uso, cuando crees un entorno, tendrás que seleccionar el tipo de entorno: Base, Intermedio o Completo. Las funciones, las características y los costes asociados al entorno dependen del tipo de entorno. Consulta más información sobre los tipos de entornos de pago por uso y los derechos de pago por uso.

En los planes de suscripción, el tipo de entorno siempre es Integral y no es necesario que sepas qué tipos de entorno hay.

Proxy de reenvío

Apigee admite el reenvío de tráfico a un URI especificado. Esta función se aplica a nivel de entorno y se puede usar para dirigir el tráfico a Internet después del procesamiento inicial en un proxy.

Las solicitudes entrantes a los proxies del proceso del entorno configurado para cualquier política incluida (consulta la compatibilidad con la función de proxy de reenvío) se reenvían mediante HTTP al nuevo URI.

Los cambios que se hagan en el ajuste de proxy de reenvío de un entorno se aplicarán inmediatamente solo a las solicitudes nuevas. Las solicitudes que ya se estén procesando se completarán con la configuración que estuviera en vigor cuando se recibieran.

Para obtener instrucciones sobre cómo configurar el proxy directo, consulta el artículo Configurar el proxy directo en un entorno.

Compatibilidad con la función de proxy de reenvío

No todas las funciones de proxy disponibles de forma general tienen la misma disponibilidad o aplicabilidad con el proxy directo.

Actualmente, Apigee no admite la autenticación básica con proxy directo, excepto en Apigee Hybrid.

En esta tabla se muestra la compatibilidad con funciones adicionales:

Función o política	¿Se admite o se aplica al proxy directo?
Puntos de conexión de destino	Sí
Comprobación del estado de HTTP	Sí
Textos destacados de servicio	Sí
Llamadas HTTP a través de JavaScript	Sí
Destinos de integración	Sí
Encadenamiento de proxies a través de bucles locales	No
Publicar mensajes	No
Cloud Logging	No
Comunicación con el sincronizador	No
Registro de mensajes mediante Syslog	No

Limitaciones del proxy directo

Actualmente, no se admite GoogleToken a través de una audiencia externa con proxy inverso.

Puntos clave

En la siguiente tabla se enumeran los puntos importantes que debes recordar sobre los entornos, las organizaciones y los grupos de entornos:

Elemento	Reglas
Organizaciones	Puede contener varios grupos de entornos Debe tener al menos un grupo de entornos
Entornos	Debe estar en al menos un grupo de entornos Puede estar en más de un grupo Compartir nombres de host con todos los demás entornos del mismo grupo Se puede usar para reenviar tráfico a un URI especificado.
Tipos de entorno	Determinar las funciones disponibles en ese entorno Determinar los precios del entorno Consulta Tipos de entorno.
Grupos de entorno	Puede tener varios nombres de host Contener uno o varios entornos Los nombres de host asignados a un grupo deben ser únicos para ese grupo (no pueden usarlos otros grupos).

Usuarios de Apigee hybrid: todos los grupos de entornos que crees con un entorno adjunto deben incluirse en todos los archivos de anulación en los que se utilice el entorno.

Ejemplos

En las siguientes secciones se muestran las formas habituales en las que se estructuran los entornos dentro de los grupos de entornos.

Un grupo de entornos y un entorno

La estructura más sencilla es un solo grupo de entornos con un solo entorno. Es habitual en organizaciones que están evaluando el producto o que aún no han configurado la infraestructura de pruebas o analíticas, ni han implementado ningún proxy en producción.

Varios entornos en un mismo grupo de entornos

Un grupo de entornos puede contener varios entornos. Por ejemplo, un solo grupo de entornos, prod-group, puede contener tres entornos: cart-prod, catalog-prod y payment-prod.

El grupo de entornos tiene un solo nombre de host, example.com. Puedes usar el nombre de host para enrutar solicitudes a un proxy implementado en cualquiera de los entornos. Ten en cuenta que los nombres de host se definen a nivel de grupo de entornos, por lo que no se dirigen a un entorno específico.

Consulta el artículo Trabajar con grupos del entorno para saber cómo crear este grupo del entorno.

Restringir el enrutamiento a un solo entorno

En el ejemplo anterior, las solicitudes se pueden enrutar a proxies de los tres entornos mediante un solo nombre de host. Si quieres restringir el acceso a los proxies en un solo entorno, por ejemplo, catalog-prod, crea otro grupo de entornos que contenga solo el entorno catalog-prod. De esta forma, un nombre de host definido para ese grupo de entornos solo podrá acceder a catalog-prod.

Por ejemplo, el nombre de host catalog.example.com, del grupo de entornos catalog-prod-group solo puede enrutar solicitudes a proxies del entorno catalog-prod.

¿Quieres crear un grupo? Abrir la consola

Para obtener más información sobre los entornos, sigue estos pasos: Seguir leyendo

Para obtener más información sobre los grupos de entornos, sigue estos pasos: Seguir leyendo

Rutas y rutas base

En una configuración sencilla, una solicitud a un proxy de API desplegado se compone de un nombre de host, una ruta base y el nombre de un recurso de API. Por ejemplo:

https://www.example.com/shopping/cart/addItem
        |_____________| |___________| |_____|
               |             |           |
            hostname      basepath     resource

Defines nombres de host en el grupo de entornos para que varios entornos puedan compartirlos. Las rutas base y los recursos de la API se definen en el proxy de API.

Nota: Los nombres del entorno y del grupo no afectan a la URL del endpoint de la API. Solo se usan para que organices y configures tus entornos, y no se muestran a los usuarios finales del proxy.

Para obtener más información sobre las rutas base y los recursos de la API, consulte el artículo Información sobre las rutas. Además, consulta la referencia de configuración de flujos y la referencia de variables de flujo para entender mejor cómo encajan estas piezas.

Nombres de host

Cuando creas un grupo de entornos, le asocias uno o varios nombres de host. Por ejemplo, puedes tener los siguientes grupos de entornos, cada uno con sus propios nombres de host:

Nombre del grupo de entornos (Entornos)	prod-group (catalog-prod cart-prod pymnt-prod)	dev-group (dev-env)	test-group (test-env)
Nombres de host	catalog.example.com payment.example.com	dev.example.com	test.example.com

Los define en el proxy cuando lo crea.

Cuando implementas un proxy en un entorno del grupo, el nombre de host, la ruta base y el nombre del recurso definen conjuntamente el endpoint de una solicitud de API a ese proxy.

Puede definir más de un nombre de host en un grupo de entornos. Todos ellos se pueden usar para llamar a cualquier proxy desplegado en cualquier entorno del grupo. Por ejemplo, catalog.example.com/proxy1 y payment.example.com/proxy1 llamarán al recurso proxy1 si los nombres de host catalog.example.com y payment.example.com se definen en el mismo grupo de entornos.

Ejemplo de enrutamiento

Por ejemplo:

• El grupo de entornos prod-group contiene los siguientes entornos:

  • catalog-prod
  • cart-prod
  • pymnt-prod

• prod-group tiene definidos los siguientes nombres de host:

  • catalog.example.com
  • payment.example.com

• Los siguientes proxies se implementan en estos entornos:

  • El proxy catalog en catalog-prod con una ruta base de /catalog
  • El proxy cart en cart-prod con una ruta base de /catalog/cart
  • El proxy payment en pymnt-prod con una ruta base de /payment

Esto crea los siguientes endpoints:

• catalog.example.com/catalog rutas al proxy de catalog en el entorno de catalog-prod.
• catalog.example.com/catalog/cart rutas al proxy de cart en el entorno de cart-prod.
• payment.example.com/payment rutas al proxy de payment en el entorno de pymnt-prod.

En el siguiente ejemplo se muestra que las solicitudes se dirigen a diferentes proxies que se han implementado en entornos del grupo, que coinciden con cualquiera de los nombres de host y la ruta base:

Nota:

Los nombres de host que defina en un grupo de entornos:

• Debe ser único en todos los grupos de entornos de una organización. No se puede usar en más de un grupo.
• No admitir comodines
• Las rutas base deben ser únicas en un grupo de entornos (dos proxies no pueden tener la misma ruta base en un grupo de entornos).

Para obtener más información, consulta Añadir nombres de host a un grupo.

Entornos compartidos y enrutamiento

Un entorno puede pertenecer a varios grupos de entornos. Si implementas un proxy en un entorno de este tipo, el proxy tendrá varias direcciones, una por cada grupo de entornos al que pertenezca el entorno. Esto es útil si un cliente tiene certificados comodín (como *.example.com) para varios partners.

Por ejemplo:

• shared-env pertenece a dos grupos de entornos:
  • partner-1 con el alias de host api.partner-1.com
  • partner-2 con el alias de host api.partner-2.com
• El proxy foo se implementa en shared-env con una ruta base /foo. Como shared-env se comparte entre los dos grupos de entornos, foo tiene dos direcciones:
  • api.partner-1.com/foo
  • api.partner-2.com/foo

Ten en cuenta que ambos nombres de host dirigen al mismo entorno. De esta forma, cada grupo de entornos tiene un nombre de dominio único. En Apigee Hybrid, este escenario puede usar mTLS con un certificado diferente para cada partner.

Acerca del ámbito del entorno

La organización proporciona el ámbito de algunas funciones de Apigee. Por ejemplo, los datos de un mapa de clave-valor (KVM) se pueden poner a disposición a nivel de organización, lo que significa que las proxies de API implementadas en cualquier entorno de esa organización pueden acceder a los mismos datos de KVM.

Del mismo modo, algunas funciones se pueden limitar a entornos o grupos de entornos de la organización. Por ejemplo, los datos analíticos de Apigee se particionan por una combinación de organización, entorno y (en última instancia) grupo de entornos.

Cuestiones importantes

Cada implementación en un entorno puede afectar al enrutamiento del tráfico de todos los grupos de entornos a los que esté asociado ese entorno. Cuando se añaden nuevas rutas base, pueden empezar a registrar tráfico completamente nuevo o un subconjunto del tráfico que ya gestiona una implementación.

Del mismo modo, cuando se eliminan las rutas base, pueden corresponder a endpoints que ya no reciben tráfico o pueden provocar que el tráfico se redirija a otro proxy. Cuando se redirige el tráfico, puede ser a un proxy del mismo entorno o, si varios entornos comparten un mismo grupo de entornos, a un proxy de otro entorno.

También se debe tener en cuenta el número total de rutas base de proxy de API añadidas a un entorno o a un grupo de entornos. Para obtener un rendimiento óptimo, Apigee recomienda no usar más de 3000 rutas base de proxy de API por entorno o grupo de entornos de Apigee. Si superas esta recomendación, puede aumentar la latencia de todos los despliegues de proxy de API nuevos y actuales.

Recursos adicionales

La siguiente información describe cómo gestionar tus entornos y grupos de entornos:

• Con la interfaz de usuario de Apigee:

  • Trabajar con entornos
  • Trabajar con grupos del entorno

• Con la API de Apigee:

  • API Environments
  • API de grupos de entornos
  • API de adjuntos de grupos de entornos