Vous consultez la documentation d'Apigee Edge.
Accédez à la documentation sur Apigee X. info
Apigee Edge fournit de nombreux types de ressources différents, chacun ayant un objectif différent. Certaines ressources ne peuvent être configurées (c'est-à-dire, créées, mises à jour ou supprimées) que via l'interface utilisateur Edge, les API de gestion ou les outils qui utilisent des API de gestion, et par les utilisateurs disposant des rôles et autorisations préalables requises. Par exemple, seuls les administrateurs d'organisation appartenant à une organisation spécifique peuvent configurer ces ressources. Cela signifie que ces ressources ne peuvent pas être configurées par les utilisateurs finaux via des portails de développeur, ni par aucun autre moyen. Voici notamment ce que vous y trouverez :
- Proxys d'API
- Flux partagés
- Produits d'API
- Caches
- KVM
- Keystores et truststores
- Hôtes virtuels
- Serveurs cibles
- Fichiers de ressources
Bien que ces ressources aient un accès limité, si des modifications y sont apportées, même par les utilisateurs autorisés, les données historiques sont simplement remplacées par les nouvelles données. Cela est dû au fait que ces ressources ne sont stockées dans Apigee Edge que conformément à leur état actuel. Les principales exceptions à cette règle sont les proxys d'API et les flux partagés.
Proxys d'API et flux partagés sous contrôle de révision
Les proxys d'API et les flux partagés sont gérés (en d'autres termes, créés, mis à jour et déployés) par le biais de révisions. Les révisions sont numérotées de manière séquentielle, ce qui vous permet d'ajouter de nouvelles modifications et de les enregistrer en tant que nouvelle révision ou d'annuler une modification en déployant une révision précédente du proxy d'API/flux partagé. À tout moment, il ne peut y avoir qu'une seule révision d'un proxy d'API/flux partagé déployé dans un environnement, à moins que les révisions n'aient un chemin de base différent.
Bien que les proxys d'API et les flux partagés soient gérés par le biais de révisions, si des modifications sont apportées à une révision existante, il n'existe aucun moyen d'effectuer un rollback, car les anciennes modifications sont simplement écrasées.
Audits et historique
Apigee Edge fournit les fonctionnalités Audits et API, Produit et historique de l'organisation qui peuvent être utiles pour résoudre des scénarios de dépannage. Ces fonctionnalités vous permettent de voir qui a effectué des opérations spécifiques (créer, lire, mettre à jour, supprimer, déployer et annuler le déploiement) et quand les opérations ont été effectuées sur les ressources Edge. Toutefois, si des opérations de mise à jour ou de suppression sont effectuées sur l'une des ressources Edge, les audits ne peuvent pas vous fournir les anciennes données.
Antimodèle
Gérer les ressources Edge (répertoriées ci-dessus) directement via l'interface utilisateur Edge ou les API de gestion sans utiliser le système de contrôle du code source
Il existe une idée erronée qu'Apigee Edge pourra restaurer l'état précédent des ressources après des modifications ou des suppressions. Cependant, Edge Cloud ne permet pas de restaurer les ressources à leur état précédent. Par conséquent, il incombe à l'utilisateur de s'assurer que toutes les données relatives aux ressources Edge sont gérées via la gestion du contrôle du code source. Ainsi, les anciennes données peuvent être restaurées rapidement en cas de suppression accidentelle ou lorsque des modifications nécessitent la réalisation d'un rollback. Cela est particulièrement important pour les environnements de production dans lesquels ces données sont requises pour le trafic d'exécution.
Nous allons expliquer ce cas avec quelques exemples et ainsi que le type d'impact pouvant être causé si les données ne sont pas gérées via un système de contrôle du code source et sont modifiées ou supprimées accidentellement ou non:
Exemple 1 : Suppression ou modification de proxy d'API
Lorsqu'un proxy d'API est supprimé ou qu'une modification est déployée sur une révision existante, le code précédent ne peut pas être récupéré. Si le proxy d'API contient du code Java, JavaScript, Node.js ou Python qui n'est pas géré dans un système de gestion de contrôle du code source (SCM) en dehors d'Apigee, un grand nombre de tâches et d'efforts de développement peuvent être perdus.
Exemple 2 : Déterminer des proxys d'API à l'aide d'hôtes virtuels spécifiques
Un certificat installé sur un hôte virtuel arrive à expiration et il doit être mis à jour. Il peut être difficile de déterminer quels proxys d'API utilisent cet hôte virtuel à des fins de test s'il existe de nombreux proxys d'API. Si les proxys d'API sont gérés dans un système SCM en dehors d'Apigee, il serait facile de rechercher dans le dépôt.
Exemple 3 : Suppression de keystore/truststore
Si un keystore/truststore utilisé par une configuration d'hôte virtuel ou de serveur cible est supprimé, il ne pourra être restauré que si les détails de configuration du keystore/truststore (y compris les certificats et/ou les clés privées) sont stockés dans un dépôt source.
Impact
- Si l'une des ressources Edge est supprimée, il n'est pas possible de récupérer cette ressource ni son contenu d'Apigee Edge.
- Les requêtes d'API peuvent échouer avec des erreurs inattendues entraînant une panne jusqu'à ce que la ressource soit rétablie à son état précédent.
- Il est difficile de rechercher des interdépendances entre les proxy d'API et les autres ressources dans Apigee Edge.
Bonne pratique
- Utilisez n'importe quel SCM standard associé à un pipeline d'intégration et de déploiement continu (CI/CD) pour gérer les proxys d'API et les flux partagés.
- Utilisez n'importe quel SCM standard pour gérer les autres ressources Edge, y compris les produits d'API, les caches, les KVM, les serveurs cibles, les hôtes virtuels et les keystores.
- S'il existe déjà des ressources Edge, utilisez les API de gestion pour obtenir les détails de leur configuration en tant que charge utile JSON/XML et les stocker dans la gestion du contrôle du code source.
- Gérez les nouvelles mises à jour de ces ressources dans la gestion du contrôle du code source.
- Si vous avez besoin de créer des ressources Edge ou de mettre à jour des ressources Edge existantes, utilisez la charge utile JSON/XML appropriée stockée dans la gestion du contrôle du code source et mettez à jour la configuration dans Edge à l'aide d'API de gestion.
* Les KVM chiffrées ne peuvent pas être exportées en texte brut à partir de l'API. Il incombe à l'utilisateur de conserver une enregistrement des valeurs placées dans les KVM chiffrées.