Vous consultez la documentation Apigee Edge.
Accédez à la
documentation**Apigee X**. info
Tout au long des mois d'août et de septembre 2015, nous allons migrer nos routeurs et équilibreurs de charge cloud Apigee Edge vers NGINX (prononcé "Engine X"). NGINX, un serveur Web Open Source, offre des performances encore meilleures et une simultanéité plus élevée que nos équilibreurs de charge et routeurs existants.
Qu'est-ce que cela signifie pour nos clients cloud ?
En résumé, ce changement devrait être transparent pour vous et ne nécessite aucune action de votre part, si ce n'est de vérifier que vos systèmes fonctionnent comme prévu. Vous trouverez ci-dessous une description des étapes que nous allons suivre, ainsi que des réponses à certaines questions fréquentes.
Étape 1 : Mise à jour du logiciel
Nous allons mettre à niveau tous les routeurs vers le nouveau routeur basé sur NGINX en tirant parti de notre modèle de déploiement progressif pour nous assurer que les services ne sont pas affectés par cette activité.
Étape 2 : Suppression du niveau d'équilibreur de charge dans les environnements hors production
Le nouveau routeur NGINX gérant la fonctionnalité d'équilibrage de charge, nous allons commencer par supprimer le niveau d'équilibreur de charge existant dans vos environnements hors production. Les équilibreurs de charge de production resteront intacts et inchangés au cours de cette étape. Avant de supprimer les équilibreurs de charge existants, nous allons nous assurer que le trafic fonctionne comme prévu. Aucune action n'est requise de votre part pour effectuer cette étape. Toutefois, vous devez signaler tout problème à Apigee. Nous travaillerons avec vous pour résoudre les problèmes avant de passer à l'étape 3.
Étape 3 : Suppression du niveau d'équilibreur de charge dans les environnements de production
Une fois l'étape 2 terminée, nous allons déterminer un ensemble de fenêtres de maintenance pour supprimer le niveau d'équilibreur de charge dans les environnements de production en utilisant la même approche que celle mentionnée à l'étape 2 . Cela permettra de s'assurer que le trafic de l'API d'exécution continue de fonctionner comme prévu.
Modifications apportées aux fonctionnalités du produit
Voici quelques modifications apportées aux fonctionnalités du produit lors du passage à NGINX.
Obsolète
Les propriétés suivantes ne sont plus compatibles avec les ProxyEndpoints :
- allow.http10
- allow.http11
- allow.http.method.*
- allow.POST.without.content.length
- allow.PUT.without.content.length
Pour contourner cette obsolescence, consultez l'article de la communauté suivant : Proxy Endpoint HTTP allow method properties not working (Les propriétés de la méthode d'autorisation HTTP du point de terminaison proxy ne fonctionnent pas).
Questions fréquentes
Vous trouverez ci-dessous les réponses à certaines questions fréquentes concernant la migration NGINX.
À l'étape 1, la réponse est "Non", car nous ne touchons pas aux équilibreurs de charge existants, ce qui ne modifiera directement aucune des adresses IP qui diffusent le trafic. Toutefois, étant donné la nature du service d'équilibrage de charge Amazon Web Services (AWS), les règles de scaling normales s'appliquent, ce qui signifie que les adresses IP peuvent changer dans le cadre de sa logique de scaling (fonctionnalité existante). C'est pourquoi nous vous déconseillons d'implémenter des configurations de liste d'autorisation Northbound avec la suite de produits Apigee Edge Au cours des étapes 2 et 3, la suppression de l'équilibreur de charge et de ses adresses IP associées a des implications en termes de liste d'autorisation. Par conséquent, nous allons travailler en étroite collaboration avec vous au cours de ces étapes pour assurer une transition en douceur en vous fournissant un nouvel ensemble d'adresses IP pour lesquelles autoriser l'accès.
Aucune modification n'est requise, en supposant que les serveurs d'origine sont les serveurs de point de terminaison cible (serveurs appelés à partir du bundle proxy). Cette modification concerne le côté Northbound d'Apigee ou le point d'entrée dans Apigee.
Non. Les entrées CNAME existantes continueront de fonctionner comme prévu.
Si vous utilisez SSL, l'étape initiale n'aura pas d'incidence sur la configuration SSL existante. Toutefois, nous devrons travailler en étroite collaboration avec vous pour nous assurer que SSL est correctement configuré sur le nouveau routeur avant de passer aux étapes 2 et 3.
Les étapes 2 et 3 seront retardées jusqu'à ce que la compatibilité avec SNI soit confirmée.
Nous ne prévoyons aucun temps d'arrêt. Les modifications seront implémentées à l'aide de notre modèle de déploiement standard modèle pendant nos fenêtres de publication existantes.