Vous consultez la documentation d'Apigee Edge.
Consultez la
documentation Apigee X. en savoir plus
En août et septembre 2015, nous allons migrer nos routeurs cloud et équilibreurs de charge Apigee Edge vers NGINX (prononcé "Moteur X"). NGINX, un serveur Web Open Source, offre des performances et une simultanéité supérieures à celles de nos équilibreurs de charge et routeurs existants.
Ce que cela implique pour nos clients cloud
En résumé, ce changement doit être transparent pour vous et ne nécessite aucune action de votre part, sauf vérifier que vos systèmes fonctionnent comme prévu. Vous trouverez ci-dessous la description des étapes que nous allons suivre, ainsi que des réponses aux questions fréquentes.
Étape 1 : Mise à jour du logiciel
Nous allons mettre à niveau tous les routeurs vers le nouveau routeur basé sur NGINX en nous appuyant sur notre modèle de déploiement par étapes afin d'éviter que cette activité n'affecte les services.
Étape 2 : Supprimez le niveau d'équilibrage de charge dans les environnements hors production
Avec le nouveau routeur NGINX qui gère 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 restent intacts au cours de cette étape. Avant la suppression des équilibreurs de charge existants, nous adopterons une approche exhaustive pour nous assurer que le trafic fonctionne comme prévu. Aucune action n'est requise de votre part pour finaliser cette étape. Cependant, vous devez signaler tous les problèmes à Apigee. Nous vous aiderons à les résoudre avant de passer à l'étape 3.
Étape 3 : Supprimer le niveau d'équilibrage de charge dans les environnements de production
Une fois l'étape 2 terminée, nous déterminerons un ensemble d'intervalles de maintenance pour supprimer le niveau d'équilibrage de charge dans les environnements de production en suivant la même approche que celle mentionnée à l'étape 2, afin de nous assurer que le trafic des 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 suite au passage à NGINX.
Obsolète
Les propriétés suivantes ne sont plus prises en charge dans ProxyEndpoints:
- allow.http10
- allow.http11
- allow.http.method.*
- allow.POST.without.content.length
- allow.PUT.without.content.length
Pour contourner ce problème, 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 à quelques questions fréquentes sur la migration NGINX.
À l'étape 1, la réponse est "Non", car nous ne touchons pas aux équilibreurs de charge existants. Cela ne modifiera donc pas directement les adresses IP qui diffusent le trafic. Cependant, étant donné la nature du service d'équilibrage de charge Amazon Web Services (AWS), des 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 de mettre en œuvre des configurations de liste d'autorisation "nord" 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 conséquences sur la liste d'autorisation. Par conséquent, nous allons collaborer étroitement avec vous au cours de ces étapes pour faciliter la transition en vous fournissant un nouvel ensemble d'adresses IP permettant d'autoriser l'accès.
Aucune modification n'est requise, en supposant que les serveurs d'origine sont les serveurs de point de terminaison cibles (serveurs appelés à partir du groupe de proxys). Cette modification se situe du côté nord 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 aucune incidence sur la configuration SSL existante. Toutefois, nous devrons nous coordonner étroitement 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.
Aucun temps d'arrêt n'est prévu. Ces modifications seront appliquées à l'aide de notre modèle de déploiement standard pendant nos périodes de publication existantes.