Estás viendo la documentación de Apigee Edge.
Ir a la documentación de
Apigee X. info
Durante agosto y septiembre de 2015, migraremos nuestros balanceadores de cargas y routers de Cloud de Apigee Edge a NGINX (pronunciado "Engine X"). NGINX, un servidor web de código abierto, proporciona un rendimiento aún mejor y una mayor simultaneidad que nuestros balanceadores de cargas y routers existentes.
Qué significa esto para nuestros clientes de la nube
En resumen, este cambio debería ser transparente para ti y no requiere ninguna acción de tu parte, más allá de verificar que tus sistemas funcionen según lo previsto. A continuación, se incluyen descripciones de los pasos que seguiremos, junto con respuestas a algunas preguntas frecuentes.
Paso 1: Actualización de software
Actualizaremos todos los routers al nuevo router basado en NGINX aprovechando nuestro modelo de implementación por fases para garantizar que los servicios no se vean afectados como resultado de esta actividad.
Paso 2: Quita el nivel del balanceador de cargas en los entornos que no son de producción
Con el nuevo router NGINX que controla la funcionalidad de balanceo de cargas, comenzaremos el proceso de eliminación del nivel de balanceador de cargas existente en tus entornos que no son de producción. Los balanceadores de cargas de producción permanecerán intactos y sin cambios durante este paso. Antes de quitar los balanceadores de cargas existentes, adoptaremos un enfoque exhaustivo para garantizar que el tráfico funcione según lo previsto. No es necesario que realices ninguna acción para completar este paso. Sin embargo, debes informar cualquier problema a Apigee, y trabajaremos contigo para resolverlos antes de continuar con el paso 3.
Paso 3: Quita el nivel del balanceador de cargas en los entornos de producción
Cuando se complete correctamente el paso 2, determinaremos un conjunto de períodos de mantenimiento para quitar el nivel del balanceador de cargas en los entornos de producción con el mismo enfoque que se mencionó en el paso 2 para garantizar que el tráfico de la API en el tiempo de ejecución siga funcionando según lo previsto.
Cambios en la funcionalidad del producto
Estos son algunos cambios en la funcionalidad del producto con el cambio a NGINX.
Obsoleto
Las siguientes propiedades ya no se admiten en ProxyEndpoints:
- allow.http10
- allow.http11
- allow.http.method.*
- allow.POST.without.content.length
- allow.PUT.without.content.length
Para solucionar este problema, consulta el siguiente artículo de la comunidad: Proxy Endpoint HTTP allow method properties not working.
Preguntas frecuentes
A continuación, se incluyen las respuestas a algunas preguntas frecuentes sobre la migración a NGINX.
Durante el paso 1, la respuesta es "No", ya que no modificamos los balanceadores de cargas existentes, lo que no cambiará directamente ninguna de las IPs que publican tráfico. Sin embargo, dada la naturaleza del servicio de balanceo de cargas de Amazon Web Services (AWS), se aplican las reglas de ajuste normales, lo que significa que las IPs pueden cambiar como parte de su lógica de ajuste (funcionalidad existente). Por este motivo, no recomendamos implementar configuraciones de lista de entidades permitidas de Northbound con el paquete de productos de Apigee Edge. Durante los pasos 2 y 3, la eliminación del balanceador de cargas y sus direcciones IP asociadas tiene implicaciones en la lista de entidades permitidas. Por lo tanto, nos coordinaremos estrechamente contigo durante estos pasos para garantizar una transición sin problemas. Para ello, te proporcionaremos un nuevo conjunto de direcciones IP a las que deberás permitir el acceso.
No se requieren cambios, suponiendo que los servidores de origen son los servidores del extremo de destino (servidores llamados desde el paquete de proxy). Este cambio se encuentra en el lado ascendente de Apigee o en el punto de entrada a Apigee.
No. Las entradas CNAME existentes seguirán funcionando como se espera.
Si usas SSL, el paso inicial no afectará la configuración existente de SSL. Sin embargo, deberemos coordinarnos estrechamente contigo para asegurarnos de que el protocolo SSL esté configurado correctamente en el nuevo router antes de continuar con los pasos 2 y 3.
Los pasos 2 y 3 se retrasarán hasta que se confirme la compatibilidad con SNI.
No esperamos que haya tiempo de inactividad. Los cambios se implementarán con nuestro modelo de implementación estándar durante los períodos de lanzamiento existentes.