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.

Descripción general

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

Cada entorno está sujeto a límites en la cantidad de proxies de API, flujos compartidos y otros recursos que se pueden implementar en él. Estos límites varían según el tipo de organización de Apigee (suscripción, pago por uso o híbrida) que use el entorno. Para obtener información más detallada, consulta la documentación sobre límites.

Un grupo de entornos (a veces llamado envgroup en la API de Apigee) es el mecanismo básico para definir la forma en que se enrutan las solicitudes a entornos individuales. Defines nombres de host en tus grupos de entornos (no en entornos individuales), y Apigee enruta las solicitudes a los entornos dentro de un grupo mediante esas definiciones de nombre de host.

Un entorno debe ser miembro de al menos un grupo de entornos para que puedas acceder a los proxies implementados dentro de él. En otras palabras, debes asignar un entorno a un grupo para poder usarlo.

La agrupación lógica de entornos por grupo de entornos proporciona los siguientes beneficios:

• Administración centralizada de los nombres de host: Los grupos de entornos proporcionan un lugar centralizado para administrar los nombres de host.
• Estadísticas globales: Con los grupos, puedes analizar los errores si observas los informes de un grupo de entorno completo a la vez en lugar de entornos individuales.
• Prevención de conflictos: Cuando agrupas entornos, puedes asegurarte de que las rutas base de tus proxies implementados existan con el mismo nombre de host.

Tipos de implementación admitidos

Apigee admite los siguientes tipos de implementación en un entorno:

Tipo	Descripción
Proxy	Desarrolla y prueba tus proxies de API en tus entornos de desarrollo de Apigee y, luego, impleméntalos en los entornos de producción y de prueba de integración de Apigee. Consulta Implementa un proxy de API.
Archive	Desarrolla y prueba tus proxies de API programables con Apigee en VS Code.

Resumen de las acciones que se evitaron con la implementación del archivo

Cuando habilites la implementación de archivos en un entorno de Apigee, se evitará que realices las siguientes acciones dentro del entorno para evitar conflictos:

• En la IU de Apigee, puedes hacer lo siguiente:no se puede ver, confirmar el estado de implementación o administrar tus implementaciones de archivo, como se describeImplementa un proxy de API o usa la IU de depuración como se describe enUsa la depuración. Como solución alternativa, puedes usar gcloud o la API para enumerar todas las implementaciones de archivo en un entorno y usar la API de depuración.
• No puedes crear, actualizar ni borrar archivos de recursos ni servidores de destino con la IU, la API o gcloud de Apigee.
• En este momento, no se admite la autenticación de Google mediante cuentas de servicio.

Nota: Puedes administrar mapas de clave-valor (KVM) y almacenes de claves TLS en un entorno de Apigee habilitado para la implementación de archivos.

Si intentas realizar alguna de las acciones que se evitaron antes mencionadas, la acción fallará y mostrará el siguiente mensaje de error:

FAILED_PRECONDITION

Unidades de implementación del proxy

Las unidades de implementación de proxy cuentan proxies y 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 cuentan la cantidad de proxies implementados actualmente que califican como proxies estándar.
• Las unidades de implementación de proxy extensibles cuentan la cantidad de proxies implementados actualmente que califican como proxies extensibles.
• Las unidades de implementación de flujo compartido cuentan la cantidad de implementaciones de flujo compartido.

El uso puede estar sujeto a la cuota de implementaciones, que es un límite para la cantidad 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 detalles. Para obtener información sobre los límites del sistema, consulta Unidades máximas de implementación de proxy 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 Visualiza el uso de la implementación de proxy.

Tipos de entorno

Para los usuarios de pago por uso, cuando crees un entorno, seleccionarás el tipo de entorno: Base, Intermedio o Integral. Las características, la funcionalidad y los costos asociados con el entorno dependen del tipo de entorno. Consulta Tipos de entorno de pago por uso y Derechos de pago por uso para obtener más información.

Para los planes de suscripción, tu tipo de entorno siempre es integral y no es necesario que conozcas los tipos de entorno.

Proxy de reenvío

Apigee admite el reenvío de tráfico a un URI especificado. Esta característica se aplica a nivel del 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 en el proceso de entorno configurado para cualquier política incluida (consulta Compatibilidad con funciones de proxy de reenvío) y, luego, reenvía mediante HTTP al URI nuevo.

Los cambios en la configuración del proxy de reenvío de un entorno se aplican solo de inmediato para las solicitudes nuevas. Las solicitudes que ya se procesan se completan con la configuración que se implementó cuando se recibió la solicitud.

Si deseas obtener instrucciones para configurar el proxy de reenvío, consulta Configura los proxies de reenvío 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 proxies de reenvío.

Por el momento, Apigee no admite la autenticación básica con proxy de reenvío, excepto en Apigee Hybrid.

En esta tabla, se muestra la compatibilidad con funciones adicionales:

Función o política	¿Compatible o aplicable para proxies de reenvío?
Extremos de destino	Sí
Verificación de estado HTTP	Sí
Service Callouts	Sí
Llamadas HTTP mediante JavaScript	Sí
Destinos de integración	Sí
Encadenamiento de proxy, mediante bucles locales	No
Publica mensajes	No
Cloud Logging	No
Comunicación con el sincronizador	No
Registro de mensajes mediante Syslog	No

Limitaciones de los proxies de reenvío

Actualmente, no se admite GoogleToken a través de un público externo con proxies de reenvío.

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 Debes tener al menos un grupo de entorno
Entornos	Debe estar en al menos un grupo de entorno Puede estar en más de un grupo Comparte los nombres de host con todos los otros entornos del mismo grupo Se puede usar para reenviar tráfico a un URI específico
Tipos de entorno	Determina la funcionalidad disponible en ese entorno y con él Determina los precios del entorno (consulta Tipos de entorno).
Grupos de entornos	Puede tener varios nombres de host Contiene uno o más entornos Los nombres de host asignados a un grupo deben ser únicos para ese grupo (no pueden usarse para otros grupos)

Usuarios híbridos de Apigee: Cada grupo de entornos que crees con un entorno adjunto debe incluirse en todos los archivos de anulación en los que se use el entorno.

Ejemplos

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

Un entorno y un grupo de entornos

La estructura más simple es un solo grupo de entorno con un solo entorno. Esto es común para las organizaciones que están evaluando el producto o que aún no configuraron infraestructura de pruebas o estadísticas, ni tienen proxies implementados en producción.

Varios entornos en un solo grupo de entorno

Un grupo de entornos puede contener varios entornos. En el siguiente ejemplo, hay un solo grupo de entorno, prod-group, que contiene tres entornos, cart-prod y catalog- prod y payments-prod.

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

Consulta Trabaja con grupos de entornos para obtener información sobre cómo crear este grupo de entornos.

Restringe el enrutamiento a un solo entorno

En el ejemplo anterior, las solicitudes se pueden enrutar a proxies en los tres entornos con un solo nombre de host. Si deseas 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. Luego, un nombre de host definido para ese grupo de entornos solo puede acceder a catalog-prod.

En el siguiente ejemplo, el nombre de hostcatalog.example.com , para el grupo de entornos catalog-prod-group, solo puede enrutar solicitudes a proxies en el entorno catalog-prod.

¿Estás listo para crear un grupo? Abrir Console

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

Para obtener más información sobre los grupos de entornos, haz lo siguiente: Sigue leyendo

Enrutamiento y rutas de acceso base

En una configuración simple, una solicitud a un proxy de API implementado está compuesta por un nombre de host, una ruta base y un nombre de recurso de API. Por ejemplo:

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

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

Nota: Los nombres de entorno y grupo no afectan la URL del extremo de la API. Solo están destinados para organizar y configurar tus entornos, y no están expuestos a los usuarios finales del proxy.

Para obtener más información sobre las rutas base y los recursos de API, consulta Comprende las rutas. Además, consulta la referencia de configuración del flujo y la referencia de variables de flujo para comprender mejor cómo se ajustan estas piezas.

Nombres de host

Cuando creas un grupo de entorno, adjuntas uno o más nombres de host a ese grupo. Por ejemplo, puedes tener los siguientes grupos de entornos, cada uno con sus propios nombres de host:

Nombre del grupo de entorno (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

Las rutas de acceso base se definen en el proxy cuando lo creas.

Cuando implementas un proxy en un entorno dentro del grupo, el nombre de host más la ruta base y el nombre del recurso definen el extremo de una solicitud a la API para ese proxy.

Puedes definir más de un nombre de host en un grupo de entorno. Todos se pueden usar para llamar a cualquier proxy implementado 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 entorno prod-group contiene los siguientes entornos:

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

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

  • 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 extremos:

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

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

Sugerencia:

Los nombres de host que defines en un grupo de entorno:

• Deben ser únicos en todos los grupos de entornos de una organización no pueden usarse en más de un grupo
• No admite comodines
• Las rutas base deben ser únicas dentro de un grupo de entornos (no puede haber dos proxies con la misma ruta base dentro de un grupo de entornos)

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

Entornos compartidos y enrutamiento

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

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 de /foo. Debido a que shared-env se comparte en ambos 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 se enrutan al mismo entorno. Esto le da a cada grupo de entorno un nombre de dominio único. En el caso de Apigee Hybrid, esta situación puede usar mTLS con un certificado diferente para cada socio.

Acerca de los permisos del entorno

La organización proporciona alcance para algunas de las funciones de Apigee. Por ejemplo, los datos del mapa de clave-valor (KVM) pueden estar disponibles a nivel de la organización, lo que significa que los proxies de API implementados en cualquier entorno dentro de esa organización pueden acceder a los mismos datos de KVM.

De manera similar, algunas capacidades pueden tener alcance para entornos o grupos de entornos dentro de la organización. Por ejemplo, los datos de estadísticas de Apigee se particionan mediante una combinación de organización, entorno y (finalmente) grupo de entorno.

Consideraciones

Cada implementación en un entorno tiene el potencial de afectar el enrutamiento de tráfico para cada grupo de entorno al que se adjunta ese entorno. Cuando se agregan nuevas rutas base, pueden comenzar a capturar el tráfico completamente nuevo o a capturar un subconjunto del tráfico existente que una implementación existente ya controla.

Del mismo modo, cuando se quitan rutas de acceso base, pueden corresponder a extremos que ya no reciben tráfico o pueden hacer que el tráfico existente se redireccione a un proxy diferente. Cuando el tráfico se redirige, puede ser a un proxy en el mismo entorno o, cuando varios entornos comparten un solo grupo de entorno, puede ser a un proxy en un entorno diferente.

También se debe considerar la cantidad total de rutas de acceso de proxy de API que se agregaron a un entorno o grupo de entornos. Para obtener un rendimiento óptimo, Apigee recomienda usar no más de 3,000 rutas de acceso de proxy de API por entorno o grupo de entornos de Apigee. Superar esta recomendación puede aumentar la latencia de todas las implementaciones de proxy de APIs nuevas y existentes.

Recursos adicionales

En la siguiente información, se describe cómo administrar tus entornos y grupos de entornos:

• Con la IU de Apigee:

  • Trabaja con entornos
  • Trabaja con grupos de entornos

• Con la API de Apigee:

  • API de entornos
  • API de grupos de entornos
  • API de adjunto del grupos de entorno