À propos des environnements et des groupes d'environnements

Cette page s'applique à Apigee et à Apigee hybrid.

Consultez la documentation d' Apigee Edge.

Cette section décrit les environnements et les groupes d'environnements.

Présentation

Un environnement Apigee est un environnement logiciel au sein d'une organisation, permettant de créer et de déployer des proxys d'API. Vous devez déployer un proxy d'API dans un environnement avant de pouvoir y accéder. Vous pouvez déployer un proxy d'API dans un seul environnement ou dans plusieurs environnements.

Chaque environnement est soumis à des limites concernant le nombre de proxys d'API, de flux partagés et d'autres ressources qui peuvent y être déployés. Ces limites varient en fonction du type d'organisation Apigee (paiement par abonnement, paiement à l'usage ou hybride) qui utilise l'environnement. Pour en savoir plus, consultez la documentation sur les limites.

Un groupe d'environnement (parfois appelé envgroup dans l'API Apigee) est le mécanisme de base permettant de définir le mode de routage des requêtes vers des environnements individuels. Vous définissez des noms d'hôte sur vos groupes d'environnement (et non sur des environnements individuels) et Apigee achemine les requêtes vers les environnements au sein d'un groupe en utilisant ces définitions de noms d'hôte.

Un environnement doit être membre d'au moins un groupe d'environnements avant de pouvoir accéder aux proxys qui sont déployés en son sein. En d'autres termes, vous devez attribuer un environnement à un groupe avant de pouvoir l'utiliser.

Le regroupement logique des environnements par groupe d'environnement offre les avantages suivants :

• Gestion centralisée des noms d'hôte : les groupes d'environnements fournissent un emplacement centralisé pour gérer les noms d'hôte.
• Insights agrégés : avec les groupes, vous pouvez analyser les erreurs en consultant les rapports d'un groupe d'environnement entier plutôt que des environnements individuels.
• Éviter les conflits : en regroupant les environnements, vous pouvez vous assurer que les chemins de base de vos proxys déployés existent sous le même nom d'hôte.

Types de déploiement acceptés

Apigee accepte les types de déploiement suivants dans un environnement :

Type	Description
Proxy	Développez et testez vos proxys d'API dans vos environnements de développement Apigee, puis déployez-les dans les environnements de test et de production d'intégration Apigee. Consultez la section Déployer un proxy d'API.
Archiver	Développez et testez vos proxys d'API programmables à l'aide d'Apigee dans VS Code.

Résumé des actions bloquées avec le déploiement d'archive

Lorsque vous activez le déploiement d'archives dans un environnement Apigee, vous ne pourrez pas effectuer les actions suivantes dans l'environnement afin d'éviter les conflits :

• Dans l'UI Apigee, vous ne pouvez pas afficher, confirmer l'état du déploiement ou gérer vos déploiements d'archive, comme décrit dans Déployer un proxy d'API, ni utiliser l'UI de débogage comme décrit dans Utiliser le débogage. Pour contourner ce problème, vous pouvez utiliser gcloud ou l'API pour répertorier tous les déploiements d'archives dans un environnement et utiliser l'API Debug.
• Vous ne pouvez pas créer, mettre à jour ou supprimer des fichiers de ressources ou des serveurs cibles à l'aide de l'UI Apigee, de l'API ni de gcloud.
• Google Authentication n'est pas compatible avec les comptes de service pour le moment.

Remarque : Vous pouvez gérer les mappages clés-valeurs (KVM) et les keystores TLS dans un environnement Apigee sur lequel le déploiement d'archives est activé.

Si vous tentez d'effectuer l'une des actions interdites répertoriées ci-dessus, l'action échoue et le message d'erreur suivant s'affiche :

FAILED_PRECONDITION

Unités de déploiement de proxy

Les unités de déploiement de proxy comptent les proxys et les flux partagés déployés dans les environnements par région.

Les types d'unités de déploiement sont les suivants :

• Les unités de déploiement de proxy de type "standard" comptent le nombre de proxys actuellement déployés qui sont considérés comme des proxys standards.
• Les unités de déploiement de proxy de type "extension" comptent le nombre de proxys actuellement déployés qui sont considérés comme des Proxys d'extension.
• Les unités de déploiement de flux partagé comptent le nombre de flux partagés qui ont été déployés.

Votre utilisation peut être soumise à un quota de déploiements, qui correspond à une limite du nombre d'unités de déploiement que vous pouvez utiliser à la fois. Pour en savoir plus, consultez vos droits d'accès (Pay-as-you-go ou abonnement 2024). Pour en savoir plus sur les limites du système, consultez la section Nombre maximal d'unités de déploiement de proxy par instance.

Pour en savoir plus sur l'affichage de l'utilisation des unités de déploiement de proxy et des détails du quota de déploiements pour votre organisation, consultez la section Afficher l'utilisation des déploiements de proxy.

Types d'environnement

Pour les utilisateurs facturés à l'usage, lorsque vous créez un environnement, vous sélectionnez le type d'environnement : De base, Intermédiaire ou Complet. Les caractéristiques, les fonctionnalités et les coûts associés à l'environnement dépendent du type d'environnement. Consultez les sections Types d'environnement avec paiement à l'usage et Droits de paiement à l'usage pour en savoir plus.

Pour les abonnements, votre type d'environnement est toujours complet et vous n'avez pas besoin de connaître les types d'environnement.

Proxy de transfert

Apigee permet de transférer le trafic vers un URI spécifié. Cette fonctionnalité s'applique au niveau de l'environnement et peut être utilisée pour diriger le trafic vers Internet après le traitement initial dans un proxy.

Les requêtes entrantes vers les proxys dans le processus d'environnement configuré pour toutes les règles incluses (consultez la section Compatibilité des fonctionnalités de proxy transférées), puis le transfert via HTTP vers le nouvel URI.

Les modifications apportées au paramètre de proxy de transfert d'un environnement ne prennent effet immédiatement que pour les nouvelles requêtes. Les requêtes déjà en cours de traitement sont terminées avec le paramètre en place au moment de la réception de la requête.

Pour obtenir des instructions sur la configuration du proxy de transfert, consultez la section Configurer le proxy de transfert dans un environnement.

Compatibilité des fonctionnalités de proxy de transfert

Les fonctionnalités de proxy en disponibilité générale n'ont pas toutes la même disponibilité ou applicabilité avec un proxy de transfert.

Apigee n'est actuellement pas compatible avec l'authentification de base avec proxy de transfert, sauf dans Apigee Hybrid.

Ce tableau indique la compatibilité avec des fonctionnalités supplémentaires:

Fonctionnalité ou règle	Compatible/Applicabilité pour le proxy de transfert ?
Points de terminaison cibles	Oui
Vérification d'état http	Oui
Appels de service	Oui
Appels HTTP via JavaScript	Oui
Cibles d'intégration	Oui
Chaînage de proxys, via des rebouclages locaux	Non
Publier des messages	Non
Cloud Logging	Non
Communication avec le synchronisateur	Non
Journalisation des messages via Syslog	Non

Limites du proxy de transfert

GoogleToken via une audience externe n'est actuellement pas compatible avec le proxy de transfert.

Points essentiels

Le tableau suivant répertorie les points importants à retenir à propos des environnements, des organisations et des groupes d'environnements :

Élément	Règles
Organisations	Peuvent contenir plusieurs groupes d'environnements Doivent disposer d'au moins un groupe d'environnements
Environnements	Doivent se trouver dans au moins un groupe d'environnements Peuvent appartenir à plusieurs groupes Partagent les noms d'hôte avec tous les autres environnements du même groupe Peut être utilisé pour transférer le trafic vers un URI spécifié
Types d'environnement	Déterminer les fonctionnalités disponibles dans et avec cet environnement Déterminer la tarification de l'environnement (Consultez la page Types d'environnement.)
Groupes d'environnements	Peuvent avoir plusieurs noms d'hôte Contiennent un ou plusieurs environnements Les noms d'hôte attribués à un groupe doivent être uniques pour ce groupe (ils ne peuvent pas être utilisés par d'autres groupes)

Utilisateurs d'Apigee hybrid : vous devez inclure le groupe d’environnements que vous créez dans tous les fichiers de remplacement qui utilisent les environnements rattachés à ce groupe.

Exemples

Les sections suivantes présentent des méthodes courantes dans lesquelles les environnements sont structurés au sein des groupes d'environnements.

Un groupe d'environnements et un environnement

La structure la plus simple consiste en un groupe d'environnements unique contenant un seul environnement. Cette structure est fréquente lorsque les entreprises évaluent actuellement le produit, ou n'ont pas encore configuré d'infrastructure de test ou d'analyse, ou n'ont aucun proxy déployé en production.

Plusieurs environnements dans un même groupe d'environnements

Un groupe d'environnements peut contenir plusieurs environnements. L'exemple ci-dessous comporte un seul groupe d'environnements, prod-group, qui contient trois environnements, cart-prod, catalog-prod et payment-prod.

Le groupe d'environnements possède un seul nom d'hôte, example.com. Vous pouvez utiliser le nom d'hôte pour acheminer les requêtes vers un proxy déployé dans n'importe quel environnement. Notez que les noms d'hôte sont définis au niveau du groupe d'environnements : ils ne gèrent pas le routage vers un environnement spécifique.

Consultez la page Utiliser des groupes d'environnements pour découvrir comment créer un tel groupe.

Limiter le routage à un seul environnement

Dans l'exemple précédent, les requêtes peuvent être acheminées vers des proxys hébergés dans les trois environnements, par le biais d'un seul nom d'hôte. Si vous souhaitez limiter l'accès aux proxys dans un seul environnement, par exemple catalog-prod, créez un autre groupe d'environnements contenant uniquement l'environnement catalog-prod. Un nom d'hôte défini pour ce groupe d'environnement ne permet alors d'accéder qu'à catalog-prod.

Dans l'exemple ci-dessous, le nom d'hôtecatalog.example.com associé au groupe d'environnementscatalog-prod-group ne peut acheminer des requêtes qu'à destination des proxys de l'environnement catalog-prod.

Prêt à créer un groupe ? Ouvrez la console

Pour en savoir plus sur les environnements : Continuer à lire

Pour en savoir plus sur les groupes d'environnements : Continuer à lire

Routage et chemins de base

Dans une configuration simple, une requête adressée à un proxy d'API déployé se compose d'un nom d'hôte, d'un chemin de base et du nom d'une ressource d'API. Par exemple :

https://www.example.com/shopping/cart/addItem
        |_____________| |___________| |_____|
               |             |           |
            hostname      basepath     resource

Vous devez définir des noms d'hôte sur le groupe d'environnement pour que plusieurs environnements puissent les partager. Les chemins de base et les ressources de l'API sont définis sur le proxy d'API.

Remarque : les noms d'environnement et de groupe n'affectent pas l'URL du point de terminaison de l'API. Ils sont destinés uniquement à organiser et configurer vos environnements, et ne sont pas exposés aux utilisateurs finaux du proxy.

Pour en savoir plus sur les chemins de base et les ressources de l'API, commencez par Comprendre les routes. En outre, consultez la documentation de référence sur la configuration des flux et la documentation de référence sur les variables de flux pour mieux comprendre le lien entre ces éléments.

Noms d'hôte

Lorsque vous créez un groupe d'environnements, vous lui associez un ou plusieurs noms d'hôte. Par exemple, vous pouvez avoir les groupes d'environnement suivants, chacun avec ses propres noms d'hôte :

Nom du groupe d'environnements (environnements)	prod-group (catalog-prod cart-prod pymnt-prod)	dev-group (dev-env)	test-group (test-env)
Noms d'hôte	catalog.example.com payment.example.com	dev.example.com	test.example.com

Vous définissez des chemins de base sur le proxy lorsque vous le créez.

Lorsque vous déployez un proxy dans un environnement du groupe, le nom d'hôte, ainsi que le chemin d'accès de base et le nom de ressource définissent ensemble le point de terminaison d'une requête API vers ce proxy.

Vous pouvez définir plusieurs noms d'hôte sur un groupe d'environnements. Ils peuvent tous être utilisés pour appeler n'importe quel proxy déployé dans n'importe quel environnement du groupe. Par exemple, catalog.example.com/proxy1 et payment.example.com/proxy1 appelleront tous deux la ressource proxy1 si les noms d'hôte catalog.example.com et payment.example.com sont définis sur le même groupe d'environnement.

Exemple de routage

Exemple :

• Le groupe d'environnement prod-group contient les environnements suivants :

  • catalog-prod
  • cart-prod
  • pymnt-prod

• Les noms d'hôte suivants sont définis dans prod-group :

  • catalog.example.com
  • payment.example.com

• Les proxys suivants sont déployés dans ces environnement :

  • Le proxy catalog sur catalog-prod avec le chemin de base /catalog
  • Le proxy cart sur cart-prod avec le chemin de base /catalog/cart
  • Le proxy payment sur pymnt-prod avec le chemin de base /payment

Les points de terminaison suivants sont ainsi créés :

• catalog.example.com/catalog redirige vers le proxy catalog dans l'environnement catalog-prod.
• catalog.example.com/catalog/cart redirige vers le proxy cart dans l'environnement cart-prod.
• payment.example.com/payment redirige vers le proxy payment dans l'environnement pymnt-prod.

L'exemple suivant montre que les requêtes sont acheminées vers différents proxys déployés dans les environnements du groupe, en correspondance avec l'un des noms d'hôte et le chemin de base :

Astuce :

Les noms d'hôte que vous définissez sur un groupe d'environnements :

• Doivent être uniques dans tous les groupes d'environnements d'une organisation et ne peuvent donc pas être utilisés par plusieurs groupes
• N'acceptent pas les caractères génériques
• Les chemins de base doivent être uniques au sein d'un groupe d'environnements (deux proxys ne peuvent pas avoir le même chemin de base dans un groupe d'environnements)

Pour en savoir plus, consultez la section Ajouter des noms d'hôte à un groupe.

Environnements partagés et routage

Un environnement peut appartenir à plusieurs groupes d'environnements. Si vous déployez un proxy dans un tel environnement, le proxy dispose de plusieurs adresses, une pour chaque groupe d'environnements auquel l'environnement appartient. Cela est utile si un client dispose de certificats génériques (comme *.example.com) pour plusieurs partenaires.

Exemple :

• shared-env appartient à deux groupes d'environnements :
  • partner-1 avec l'alias d'hôte api.partner-1.com
  • partner-2 avec l'alias d'hôte api.partner-2.com
• Le proxy foo est déployé sur shared-env avec le chemin de base /foo. Comme shared-env est partagé par les deux groupes d'environnement, foo comporte deux adresses :
  • api.partner-1.com/foo
  • api.partner-2.com/foo

Notez que les deux noms d'hôte redirigent vers le même environnement. Chaque groupe d'environnement possède ainsi un nom de domaine unique. Pour Apigee hybrid, ce scénario peut utiliser mTLS avec un certificat différent pour chaque partenaire.

À propos du champ d'application de l'environnement

L'organisation fournit des champ d'application pour certaines fonctionnalités d'Apigee. Par exemple, les données de mappage clé-valeur (KVM) peuvent être rendues disponibles au niveau de l'organisation, ce qui signifie que les proxys d'API déployés dans n'importe quel environnement de cette organisation peuvent accéder aux mêmes données KVM.

De même, certaines fonctionnalités peuvent être limitées à des environnements ou des groupes d'environnements au sein de l'organisation. Par exemple, les données d'analyse Apigee sont partitionnées en fonction d'une combinaison d'organisation, d'environnement et (à terme) de groupe d'environnements.

Remarques

Chaque déploiement dans un environnement peut affecter le routage du trafic pour chaque groupe d'environnement auquel il est associé. Lorsque de nouveaux chemins de base sont ajoutés, ils peuvent commencer à capturer du trafic entièrement nouveau ou commencer à capturer un sous-ensemble du trafic existant déjà géré par un déploiement existant.

De même, lorsque les chemins de base sont supprimés, ils peuvent correspondre à des points de terminaison qui ne reçoivent plus aucun trafic, ou entraîner une redirection du trafic existant vers un proxy différent. Lorsque le trafic est redirigé, ce peut être vers un proxy situé dans le même environnement, ou lorsque plusieurs environnements partagent un même groupe d'environnement, ce peut être vers un proxy dans un environnement différent.

Le nombre total de chemins de base de proxy d'API ajoutés à un environnement ou à un groupe d'environnements, doit également être pris en compte. Pour des performances optimales, Apigee recommande de ne pas utiliser plus de 3 000 chemins de base de proxy d'API par environnement ou groupe d'environnements Apigee. Le fait de passer outre cette recommandation risque d'entraîner une latence accrue pour tous les déploiements de proxy d'API, tant sur les nouveaux déploiements que sur les déploiements existants.

Autres ressources

Les informations suivantes décrivent comment gérer vos environnements et groupes d'environnement :

• Avec l'interface utilisateur Apigee :

  • Utiliser des environnements
  • Utiliser des groupes d'environnements

• Avec l'API Apigee :

  • API Environnements
  • API Groupes d'environnements
  • API Rattachement de groupe d'environnements