Vous consultez la documentation d'Apigee Edge.
Accédez à la documentation sur Apigee X. info
En août et septembre 2015, nous migrons nos routeurs cloud et équilibreurs de charge Apigee Edge vers NGINX (prononcé "Engine X"). NGINX, un serveur Web open source, offre des performances et une concurrence encore meilleures que nos équilibreurs de charge et nos 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écessiter aucune action de votre part, si ce n'est que 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 migrer tous les routeurs vers le nouveau routeur basé sur NGINX en utilisant notre modèle de déploiement par étapes afin de nous assurer que les services ne sont pas affectés par cette activité.
Étape 2 : Supprimez le niveau de l'équilibreur de charge dans les environnements hors production
Le nouveau routeur NGINX assurant la fonctionnalité d'équilibrage de charge, nous commencerons par supprimer le niveau d'équilibreur de charge existant dans vos environnements hors production. Les équilibreurs de charge de production restent intacts et inchangés pendant cette étape. Avant de supprimer les équilibreurs de charge existants, nous allons adopter une approche exhaustive pour nous assurer que le trafic fonctionne comme prévu. Aucune action de votre part n'est requise pour effectuer cette étape. Toutefois, vous devez signaler tout problème à Apigee. Nous vous aiderons à le résoudre avant de passer à l'étape 3.
Étape 3 : Supprimer le niveau de l'équilibreur de charge dans les environnements de production
Une fois l'étape 2 terminée, nous déterminerons un ensemble de périodes de maintenance pour supprimer le niveau d'équilibrage de charge dans l'environnement de production à l'aide de la même approche mentionnée à l'étape 2 afin de nous 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 avec le passage à NGINX.
Obsolète
Les propriétés suivantes ne sont plus compatibles avec ProxyEndpoints:
- allow.http10
- allow.http11
- allow.http.method.*
- allow.POST.without.content.length
- allow.PUT.without.content.length
Pour contourner cette suppression, consultez l'article de la communauté suivant: https://community.apigee.com/questions/16134/proxy-endpoint-http-allow-method-properties-not-wo.html.
Questions fréquentes
Vous trouverez ci-dessous les réponses à certaines questions fréquentes sur la migration vers NGINX.
Lors de l'étape 1, la réponse est "Non", car nous ne touchons pas aux équilibreurs de charge existants, ce qui ne modifiera pas directement l'une des adresses IP qui servent le trafic. Toutefois, compte tenu de la nature du service d'équilibrage de charge Amazon Web Services (AWS), des règles de mise à l'échelle normales s'appliquent, ce qui signifie que les adresses IP peuvent changer dans le cadre de sa logique de mise à l'échelle (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. Lors des étapes 2 et 3, la suppression de l'équilibreur de charge et de ses adresses IP associées a des conséquences sur la liste d'autorisation. Par conséquent, nous allons travailler en étroite collaboration avec vous pendant ces étapes pour assurer une transition fluide en 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 de proxy). Cette modification se trouve du côté Northbound d'Apigee ou du 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 aucun impact sur la configuration SSL existante. Toutefois, nous devrons travailler en étroite collaboration avec vous pour nous assurer que le protocole 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é 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 lors de nos périodes de publication existantes.