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 enrutadores de la nube 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 enrutadores 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, excepto la verificación de que tus sistemas funcionan como se espera. A continuación, se describen los pasos que tomaremos, junto con las respuestas a algunas preguntas frecuentes.
Paso 1: Actualización de software
Actualizaremos todos los enrutadores al nuevo enrutador basado en NGINX aprovechando nuestro modelo de implementación por etapas para garantizar que los servicios no se vean afectados como resultado de esta actividad.
Paso 2: Quita el nivel del balanceador de cargas en entornos que no son de producción
Con el nuevo enrutador NGINX que controla la funcionalidad de balanceo de cargas, comenzaremos el proceso de quitar el nivel del balanceador de cargas existente primero 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 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 balanceador de cargas en los entornos de producción con el mismo enfoque mencionado en el paso 2 para garantizar que el tráfico de la API en tiempo de ejecución continúe funcionando como se espera.
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 son compatibles con ProxyEndpoints:
- allow.http10
- allow.http11
- allow.http.method.*
- allow.POST.without.content.length
- allow.PUT.without.content.length
Para solucionar esta obsolescencia, 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 de NGINX.
Durante el paso 1, la respuesta es "No", ya que no estamos tocando los balanceadores de cargas existentes, que no cambiarán 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 reglas de ajuste de escala normales, lo que significa que las IPs pueden cambiar como parte de su lógica de ajuste de escala (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, existen implicaciones de la lista de entidades permitidas con la eliminación del balanceador de cargas y sus direcciones IP asociadas. Como resultado, coordinaremos de cerca contigo durante estos pasos para garantizar una transición sin problemas proporcionando un nuevo conjunto de direcciones IP para permitir el acceso.
No se requieren cambios, suponiendo que los servidores de origen sean los servidores del extremo de destino (servidores llamados desde el paquete de proxy). Este cambio se encuentra en el lado Northbound 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 de SSL existente. Sin embargo, deberemos coordinar de cerca contigo para garantizar que SSL esté configurado correctamente en el nuevo enrutador 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 ningún tiempo de inactividad. Los cambios se implementarán con nuestro modelo de implementación estándar model durante nuestras ventanas de lanzamiento existentes.