Vous consultez la documentation Apigee Edge.
Accédez à la documentation Apigee X.
En août et septembre 2015, nous migrerons nos routeurs cloud et équilibreurs de charge Apigee Edge vers NGINX (prononcé "Engine X"). NGINX, un serveur Web Open Source, offre des performances encore meilleures et une concurrence 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 la description des étapes que nous allons suivre, ainsi que les réponses à certaines questions fréquentes.
Étape 1 : Mettez à jour le logiciel
Nous allons migrer tous les routeurs vers le nouveau routeur basé sur NGINX en utilisant notre modèle de déploiement progressif pour 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 nouvel 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 de non-production. Les équilibreurs de charge de production resteront intacts et inchangés pendant cette étape. Avant de supprimer les équilibreurs de charge existants, nous veillerons à ce 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 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'é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 : Les propriétés de la méthode HTTP "allow" du point de terminaison du proxy ne fonctionnent pas.
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" puisque nous ne touchons pas aux équilibreurs de charge existants, ce qui ne modifiera directement aucune des adresses IP diffusant 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. Lors des étapes 2 et 3, la suppression de l'équilibreur de charge et de ses adresses IP associées a des implications sur la liste d'autorisation. Par conséquent, nous coordonnerons étroitement ces étapes avec vous pour assurer une transition fluide en vous fournissant un nouvel ensemble d'adresses IP auxquelles autoriser l'accès.
Aucune modification n'est requise, en supposant que les serveurs d'origine soient les serveurs de point de terminaison cibles (serveurs appelés à partir du bundle de 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 coordonner étroitement 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 pendant nos périodes de publication existantes.