Antimodèle : Gérer les ressources sans utiliser la gestion du contrôle du code source

Vous consultez la documentation d'Apigee et d'Apigee hybrid.
Consultez la documentation d'Apigee Edge.

Apigee 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 Apigee, les API Apigee ou les outils qui utilisent des API, et par les utilisateurs avec les 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 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 propose la fonctionnalité "Audits" qui peut être utile lors de 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 Apigee. Toutefois, si des opérations de mise à jour ou de suppression sont effectuées sur l'une des ressources Apigee, les audits ne peuvent pas vous fournir les anciennes données.

Antimodèle

Gérer les ressources Apigee (répertoriées ci-dessus) directement via l'interface utilisateur ou les API Apigee sans utiliser le système de contrôle du code source

Il existe une idée erronée qu'Apigee pourra restaurer l'état précédent des ressources après des modifications ou des suppressions. Cependant, Apigee 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 Apigee 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 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 Apigee est supprimée, il n'est pas possible de récupérer cette ressource ni son contenu d'Apigee.
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.

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 Apigee, 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 Apigee, utilisez les API Apigee 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 Apigee ou de mettre à jour des ressources 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 Apigee à l'aide d'API.

* 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.