Apigee hybrid est une plate-forme de développement et de gestion de proxys d'API dotée d'un modèle de déploiement hybride. Le modèle hybride comprend un plan de gestion hébergé par Apigee dans le cloud, et un plan d'exécution que vous installez et gérez sur l'une des plates-formes Kubernetes compatibles.
Gérez toutes vos API au même endroit |
Apigee hybrid vous permet de gérer les API internes et externes avec Google Cloud. Cette gestion unifiée des API offre à vos développeurs, partenaires et clients une expérience homogène sur les programmes d'API. |
Garantissez la sécurité et la conformité |
Si les questions de sécurité et de conformité vous imposent de déployer vos applications sur site, une passerelle hybride pensée pour les entreprises vous donne la possibilité d'héberger et de gérer le plan d'exécution Apigee hybrid sur site. Vous gérez et contrôlez l'exécution, ce qui vous permet de vous appuyer sur vos infrastructures de sécurité, de gouvernance et de conformité existantes. |
Accompagnez votre stratégie multicloud |
La recherche de l'équilibre entre coûts et performances peut vous orienter vers une stratégie hybride. Que vous n'en soyez qu'à l'étude des différents fournisseurs cloud ou que vous ayez déjà arrêté votre choix sur ce type de stratégie, votre plate-forme de gestion d'API doit vous apporter la flexibilité dont vous avez besoin. Hébergez et gérez des passerelles hybrid pensées pour les entreprises dans votre centre de données, sur Google Cloud ou les deux. |
|
Pour en savoir plus sur Apigee hybrid :
|
Pour installer Apigee hybrid :
|
Programmes d'API dans un monde hybride
Apigee hybrid est constitué d'un plan de gestion géré par Google et d'un plan d'exécution que vous installez sur une plate-forme Kubernetes compatible. Les deux plans utilisent les services Google Cloud Platform, comme le montre l'image suivante :
Comme vous pouvez le voir, l'architecture hybride est constituée des composants principaux suivants :
- Plan de gestion géré par Apigee : Ensemble de services hébergés dans le cloud et gérés par Google. Ces services incluent l'interface utilisateur, l'API de gestion et l'analyse.
Plan d'exécution géré par le client : Ensemble de services d'exécution conteneurisés que vous configurez et gérez dans votre propre cluster Kubernetes. Tout le trafic des API transite et est traité dans le plan d'exécution.
Vous gérez l'exécution en conteneurs sur votre cluster Kubernetes, et gagnez en flexibilité à l'aide des déploiements par étapes, de l'autoscaling et des autres avantages opérationnels des conteneurs.
- Google Cloud est une suite de services cloud hébergés par Google.
Concernant l'architecture hybride, il est important de savoir que tout le trafic des API est traité dans les limites de votre réseau et est sous votre contrôle, tandis que des services de gestion tels que l'interface utilisateur et API Analytics s'exécutent dans le cloud et sont gérés par Google. Pour en savoir plus, consultez la section Où vos données sont-elles stockées ?
La vidéo suivante présente en détail l'architecture hybride :
À propos du plan d'exécution
Le plan d'exécution est un ensemble de services d'exécution conteneurisés que vous configurez et gérez dans votre propre cluster Kubernetes s'exécutant sur une plate-forme Kubernetes compatible. Tout le trafic des API transite et est traité dans le plan d'exécution. Le plan d'exécution comprend les principaux composants suivants :
Le plan d'exécution s'exécute dans un cluster Kubernetes s'exécutant sur une plate-forme Kubernetes compatible que vous gérez.
L'image suivante montre les services principaux qui s'exécutent sur le plan d'exécution :
Pour obtenir des informations générales sur les composants d'exécution, reportez-vous aux sections suivantes. Consultez également la section Présentation de la configuration des services d'exécution.
Les sections suivantes décrivent plus en détail chacun des services du plan d'exécution principal.
Processeur de messages
Les processeurs de messages hybrides (MP) permettent de traiter les requêtes API et d'exécuter des règles sur le plan d'exécution. Les MP chargent tous les proxys, ressources, serveurs cibles, certificats et keystores déployés à partir du stockage local. Vous configurez un contrôleur d'entrée Istio pour exposer les MP aux requêtes provenant de l'extérieur du cluster.
Synchronisateur
Le synchronisateur extrait les données de configuration concernant un environnement d'API depuis le plan de gestion et les propage à travers le plan d'exécution. Ces données téléchargées sont également appelées contrat et sont stockées dans le système de fichiers local.
Le synchronisateur interroge périodiquement le serveur de gestion pour détecter les modifications et télécharge une nouvelle configuration chaque fois que des modifications sont détectées. Les données de configuration sont extraites et stockées localement sous forme de fichier JSON dans le système de fichiers local, où les processeurs de messages peuvent y accéder.
Les données de configuration téléchargées permettent au plan d'exécution de fonctionner indépendamment du plan de gestion. Dans le contrat, les processeurs de messages du plan d'exécution utilisent les données stockées localement comme configuration. Si la connexion entre le plan de gestion et d'exécution est interrompue, les services du plan d'exécution continuent de fonctionner.
Les données de configuration téléchargées par le synchronisateur incluent :
- Groupes de proxys et déploiements de flux partagés
- Hooks de flux
- Informations sur l'environnement
- Ressources d'API partagées
- Définitions des serveurs cibles
- Paramètres TLS
- Noms de mappage de clés-valeurs (KVM)
- Masques de données
Datastore Cassandra
Apache Cassandra est le datastore d'exécution qui assure la persistance des données sur le plan d'exécution.
Cassandra est un système de données distribué qui assure la persistance des données sur le plan d'exécution. Vous déployez la base de données Cassandra en tant que pool de nœuds StatefulSet sur votre cluster Kubernetes. La localisation de ces entités à proximité des services de traitement de l'environnement d'exécution permet de répondre aux exigences de sécurité et de haute évolutivité.
La base de données Cassandra stocke des informations sur les entités suivantes :
- Système de gestion des clés (KMS)
- Mappage clé-valeur (KVM)
- Cache de réponse
- OAuth
- Quotas
API Management pour les données d'exécution (MART)
Les données appartenant à votre organisation et accessibles lors des appels d'API d'exécution sont stockées par Cassandra dans le plan d'exécution.
Ces données incluent :
- Configurations d'application
- Données du système de gestion des clés (KMS)
- Cache
- Mappages clé-valeur (KVM)
- Produits d'API
- Applications développeur
Pour accéder aux données et les mettre à jour, par exemple pour ajouter un nouveau KVM ou pour supprimer un environnement, vous pouvez utiliser l'interface utilisateur Apigee hybrid ou les API Apigee. Le serveur MART (API Management pour les données d'exécution) traite les appels d'API par rapport au datastore d'exécution.
Cette section décrit le rôle joué par MART lorsque vous appelez les API Apigee pour accéder au datastore d'exécution.
| Qu'est-ce que MART ? | Pour appeler une API Apigee, vous envoyez une requête authentifiée au serveur de gestion (MS) sur le plan de gestion. Le serveur de gestion authentifie et autorise la requête, puis la transfère à MART sur le plan d'exécution. À cette requête est associé un jeton que le serveur de gestion a généré à l'aide d'un compte de service préconfiguré. MART reçoit la requête, l'authentifie et l'autorise, puis procède à une validation entreprise de celle-ci. (Par exemple, si l'application fait partie d'un produit d'API, MART garantit qu'il s'agit d'une requête valide.) Après avoir vérifié qu'une requête est valide, MART procède à son traitement. Cassandra stocke les données d'exécution traitées par MART (il s'agit après tout d'un datastore d'exécution). MART peut lire des données à partir de Cassandra ou les mettre à jour en fonction du type de requête. Comme la plupart des services hybrides, MART n'a pas d'état : il ne conserve pas son propre état au moment de l'exécution. |
| Qu'est-ce que MART n'est pas | Le plan de gestion communique avec MART via l'agent Apigee Connect, qui utilise un compte de service doté du rôle Agent Apigee Connect (le compte de service MART dans la plupart des installations). Vous n'appelez pas directement MART. De plus, MART ne reçoit pas les requêtes de proxy d'API. Ces appels sont gérés par le contrôleur d'entrée de l'environnement d'exécution et acheminés vers les processeurs de messages de votre cluster. |
Il est important de mentionner que MART et les processeurs de messages ont accès au même datastore d'exécution (Cassandra), ce qui leur permet de partager les données concernant KMS, KVM et les caches.
L'image suivante illustre le flux d'un appel d'API Apigee :
UDCA
Universal Data Collection Agent (UDCA) est un service s'exécutant dans le pod de collecte de données du plan d'exécution. Il extrait les données d'analyse, de débogage et d'état de déploiement, puis les envoie à l'UAP.
Pour en savoir plus, consultez la page Collecte de données de débogage, d'analyse et d'état du déploiement.
À propos du plan de gestion
Le plan de gestion s'exécute sur Google Cloud. Il inclut des services administratifs tels que :
- L'interface utilisateur Apigee hybrid fournit une interface utilisateur permettant aux développeurs de créer et de déployer des proxys d'API, de configurer des règles, de créer des produits d'API et de créer des applications développeur. Les administrateurs peuvent utiliser l'interface utilisateur Apigee hybrid pour surveiller l'état du déploiement.
- Les API Apigee fournissent une interface de programmation pour gérer votre organisation et vos environnements.
- La plate-forme d'analyse unifiée (UAP) reçoit et traite les données d'analyse et d'état de déploiement à partir du plan d'exécution.
L'image suivante montre les principaux services qui s'exécutent sur le plan de gestion :
À propos des services Google Cloud
Le tableau suivant décrit les principaux services Google Cloud sur lesquels s'appuie hybrid :
| Service Google Cloud | Description |
|---|---|
| Identité | L'authentification des comptes utilisateur s'appuie sur les comptes Google Cloud. L'autorisation s'appuie sur les comptes de service Google Cloud. |
| Rôles | La gestion des accès pour Apigee hybrid utilise le moteur de rôles IAM de Google, et est compatible avec les rôles par défaut d'Apigee. |
| Hiérarchie des ressources | Les ressources sont organisées dans des projets Google Cloud (associés à des organisations Apigee). |
| Suite Google Cloud Operations | Fournit des analyses de données de journalisation et de métriques. |
Types d'utilisateurs
Apigee a identifié les principaux types d'utilisateurs de la solution hybride suivants :
| Rôle | Responsabilités et tâches courantes | Domaines d'intérêt |
|---|---|---|
| Administrateurs système/opérateurs |
|
|
| Développeurs |
|
|
Avantages
Apigee hybrid présente les avantages suivants :
- Agilité accrue
- Étant donné que la solution hybride est fournie et exécutée en conteneurs, vous pouvez effectuer des déploiements par étapes, de l'autoscaling et d'autres avantages opérationnels d'un système conteneurisé.
- Latence réduite
- Toutes les communications avec le plan de gestion hybride sont asynchrones et ne se font pas dans le cadre du traitement des requêtes API de clients.
- Adoption accrue des API
- Bien qu'il soit possible de traiter des API internes à l'aide d'Apigee, la latence réduite et l'efficacité que vous pouvez obtenir avec une solution hybride font du traitement des API internes à l'aide de cette solution une option intéressante. Cette efficacité est obtenue en partie parce que votre passerelle API s'exécute sur site, à proximité de vos services de backend. En outre, si vous utilisez Apigee, vous pouvez augmenter votre adoption d'Apigee en traitant les API internes à l'aide d'une solution hybride.
- Meilleur contrôle
- De nombreuses entreprises adoptent une stratégie hybride. Pour les grandes entreprises, il est essentiel de pouvoir gérer les environnements d'exécution d'API déployés dans des centres de données privés. Actuellement, le plan d'exécution d'hybrid peut être déployé sur Google Cloud ou dans votre propre centre de données.
Étape suivante
Consultez la page L'essentiel sur la présentation du processus d'installation de la solution hybride.