À propos des environnements

Un environnement fournit un contexte isolé ou un "bac à sable" pour l'exécution de proxys d'API. Dans une même organisation, vous pouvez créer plusieurs environnements.

Le code suivant illustre un exemple de configuration de remplacement où plusieurs environnements sont définis. 

namespace: my-namespace
org: my-organization
...
envs:
  - name: test
    serviceAccountPaths:
      synchronizer: "your_keypath/synchronizer-manager-service-account.json
      udca: "your_keypath/analytic-agent-service-account.json

  - name: prod
    serviceAccountPaths:
      synchronizer: "your_keypath/synchronizer-manager-service-account.json
      udca: "your_keypath/analytic-agent-service-account.json
...

Supposons qu'un proxy avec le chemin de base /foo1 soit déployé dans l'environnement test. Vous pouvez appeler le proxy ainsi : 

curl -k https://api.example.com/foo1

Lorsque cet appel atteint l'entrée, l'entrée sait qu'il doit être envoyé au processeur de messages associé à l'environnement test, qui gère la requête.

De même, si foo1 est également déployé dans l'environnement prod, vous pouvez envoyer une requête de proxy comme celle-ci, à l'alias d'hôte apiprod.mydomain.net :

curl -k https://apiprod.example.com/foo1

Et l'appel est acheminé par l'entrée vers le processeur de messages associé à cet hôte.

Antimodèle : Déployez tous vos proxys dans un environnement hybride.

Bonne pratique : Créez plusieurs environnements et déployez un nombre limité de proxys dans chacun d'eux.

Limiter le nombre de déploiements de proxy

Pour les déploiements hybrides, le fait que de nombreux environnements puissent partager les mêmes hôtes virtuels, tels que définis dans les groupes d'environnements, signifie que vous devez réfléchir attentivement à la manière dont vous gérez vos déploiements de proxys dans un environnement donné. En mode hybride, il est recommandé de créer plusieurs environnements et de déployer un nombre limité de proxys dans chacun d'eux.

Combien de proxys devez-vous déployer dans un environnement ? Il n'y a pas de réponse définie à cette question. Toutefois, le tableau suivant fournit des conseils généraux sur les raisons pour lesquelles il est judicieux de limiter le nombre de proxys déployés dans chaque environnement, ainsi que les éléments à prendre en compte lors de la gestion de déploiements de proxys :

Problème à prendre en compte Description
Délai de démarrage du processeur de messages Il existe une corrélation directe entre le temps nécessaire au démarrage d'un processeur de messages et le nombre de proxys déployés sur ce processeur de messages. Dans un environnement Kubernetes d'autoscaling, une augmentation du temps de démarrage peut poser problème. Plus le nombre de proxys déployés dans le processeur de messages est élevé, plus il faudra de temps pour que ce processeur de messages soit opérationnel s'il doit faire l'objet d'un scaling ou être recréé.
Performances de scaling Si plusieurs proxys sont déployés dans un environnement et que l'un des proxys reçoit beaucoup de trafic, de sorte qu'il réalise fréquemment un autoscaling, tous les proxys de cet environnement réalisent un scaling avec lui. L'effet sur les performances du scaling de plusieurs proxys avec un seul proxy à trafic élevé peut poser problème.
"Voisin bruyant" Si plusieurs proxys sont déployés dans le même environnement et qu'un proxy plante, alors tous les proxys de l'environnement sont affectés le temps de redémarrer le processeur de messages. En limitant le nombre de proxys déployés dans un environnement, vous minimisez l'impact d'un plantage d'un seul proxy.

Groupes d'environnements et hôtes virtuels

Les groupes d'environnements vous permettent de regrouper des environnements de manière logique. Tous les environnements d'un groupe donné partagent le même nom d'hôte. Vous pouvez regrouper les environnements par fonction, par adresse de nom d'hôte, par région (si votre installation hybride est multirégionale), ou selon toute autre métrique de votre choix.

Le routage étant géré par la combinaison des noms d'hôte de groupe d'environnements, des chemins de base de proxy d'API et des environnements, chaque hôte virtuel ne doit répertorier que le nom du groupe d'environnements et les certificats appropriés.

Le code suivant illustre un exemple de configuration de remplacement où plusieurs hôtes virtuels sont définis. Notez que le nom des hôtes virtuels doit correspondre aux noms des groupes d'environnements. 

gcp:
  region: us-central1
  projectID: hybrid-example

k8sCluster:
  name: apigee-hybrid
  region: us-central1

org: hybrid-example

contractProvider: https://us-apigee.googleapis.com # if using data residency

instanceID: "my_hybrid_example"

virtualhosts:
  - name: group-1  # the name of an environment group
    sslCertPath: ./certs/keystore.pem
    sslKeyPath: ./certs/keystore.key

virtualhosts:
  - name: group-2
    sslCertPath: ./certs/keystore.pem
    sslKeyPath: ./certs/keystore.key
...

Autres ressources