Estás viendo la documentación de Apigee Edge.
Ve a la
documentación de Apigee X. info
Durante agosto y septiembre de 2015, migraremos nuestros routers y balanceadores de cargas 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 debe ser transparente para ti y no requiere que realices ninguna acción, excepto verificar que tus sistemas funcionen según lo esperado. 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 quitar primero el 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 como se espera. 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
Una vez que se complete correctamente el paso 2, determinaremos un conjunto de ventanas de mantenimiento para quitar el nivel del equilibrador 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 del entorno de ejecución siga funcionando como se espera.
Cambios en la funcionalidad de los productos
Estos son algunos cambios en la funcionalidad del producto con el cambio a NGINX.
Obsoleto
Las siguientes propiedades ya no son compatibles con 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: https://community.apigee.com/questions/16134/proxy-endpoint-http-allow-method-properties-not-wo.html.
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 estamos modificando los balanceadores de cargas existentes, lo que no cambiará directamente ninguna de las IPs que entregan tráfico. Sin embargo, debido a la naturaleza del servicio de balanceo de cargas de Amazon Web Services (AWS), se aplican las reglas de escalamiento normales, lo que significa que las IPs pueden cambiar como parte de su lógica de escalamiento (funcionalidad existente). Por este motivo, no recomendamos implementar configuraciones de listas de entidades permitidas orientadas al norte con el paquete de productos de Apigee Edge. Durante los pasos 2 y 3, hay implicaciones de la lista de entidades permitidas con la eliminación del balanceador de cargas y sus direcciones IP asociadas. Como resultado, 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 se les permitirá el acceso.
No se requieren cambios, siempre que los servidores de origen sean los servidores de extremos de destino (servidores a los que se llama 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 de CNAME existentes seguirán funcionando como se espera.
Si usas SSL, el paso inicial no afectará la configuración de SSL existente. Sin embargo, tendremos que coordinarnos contigo para asegurarnos de que la SSL esté configurada correctamente en el router nuevo 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 nuestras ventanas de lanzamiento existentes.