Antimodèle: gérer les ressources Edge sans utiliser la gestion du contrôle des sources

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

Apigee Edge fournit de nombreux types de ressources différents, et chacun d'eux a un objectif différent. Certaines ressources ne peuvent être configurées (c'est-à-dire créées, mises à jour et/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. 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 qu'en fonction de 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 d'audits et d'historique des API, des produits et de l'organisation qui peuvent être utiles dans les scénarios de dépannage. Ces fonctionnalités vous permettent d'afficher des informations telles que la personne ayant effectué des opérations spécifiques (création, lecture, mise à jour, suppression, déploiement et annulation du déploiement) et le moment où 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

Gestion des 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

On croit à tort qu'Apigee Edge pourra restaurer l'état précédent des ressources après des modifications ou des suppressions. Toutefois, Edge Cloud ne permet pas de restaurer les ressources à leur état précédent. Par conséquent, il est de la responsabilité de l'utilisateur de s'assurer que toutes les données liées aux ressources Edge sont gérées via la gestion du contrôle du code source, de sorte que les anciennes données puissent être restaurées rapidement en cas de suppression accidentelle ou de rollback d'une modification. 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 du contrôle des sources (SCM) en dehors d'Apigee, une grande partie du travail de développement et de l'effort pourrait être perdue.

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 la ressource et son contenu depuis Apigee Edge.
  • Les requêtes API peuvent échouer et générer des erreurs inattendues entraînant une interruption de service jusqu'à ce que la ressource retrouve son état précédent.
  • Il est difficile de rechercher des interdépendances entre les proxys d'API et d'autres ressources dans Apigee Edge.

Bonnes pratiques

  • Utilisez n'importe quelle SCM standard associée à un pipeline d'intégration et de déploiement continus (CICD) pour gérer les proxys d'API et les flux partagés.
  • Utilisez n'importe quelle SCM standard pour gérer les autres ressources en périphérie, y compris les produits d'API, les caches, les KVM, les serveurs cibles, les hôtes virtuels et les keystores.
    • S'il existe des ressources Edge existantes, utilisez les API de gestion pour obtenir les détails de configuration les concernant sous forme de charge utile JSON/XML et stockez-les dans la gestion du contrôle du code source.
    • Gérez toute nouvelle mise à jour de ces ressources dans la gestion du contrôle du code source.
    • Si vous devez créer des ressources Edge ou mettre à jour des ressources Edge existantes, utilisez la charge utile JSON/XML appropriée stockée dans la gestion du contrôle des sources et mettez à jour la configuration dans Edge à l'aide des 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.

Documentation complémentaire