Configurer des hôtes virtuels

REMARQUE : La configuration de virtualhosts est nouvelle dans la version 1.2.0. L'hôte virtuel name doit :

ne pas contenir plus de 128 caractères ;
ne contenir que des caractères alphanumériques minuscules ou un trait d'union - ;
commencer par un caractère alphanumérique ;
se terminer par un caractère alphanumérique.

Cet article traite de la configuration d'hôtes virtuels. Les hôtes virtuels permettent à Apigee hybrid de gérer les requêtes API adressées à plusieurs noms de domaine et d'acheminer les chemins de base du proxy vers des environnements spécifiques.

Pour spécifier vers quel environnement les chemins de base du proxy d'API doivent être acheminés, utilisez la propriété de configuration virtualhosts.routingRules[]. Pour en savoir plus sur les propriétés individuelles, consultez la section virtualhosts dans la documentation de référence sur les propriétés de configuration. Exemple :

...

virtualhosts:
  - name: vhost-one
    hostAliases: ["api.example.com"]
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    routingRules:
      - paths:
        - /orders
        - /items
        env: test1
      - paths:
        - /customers
        env: test2

envs:
  - name: test1
    serviceAccountPaths:
      synchronizer: ./sa/synchronizer.json
      udca: ./sa/udca.json
  - name: test2
    serviceAccountPaths:
      synchronizer: ./sa/synchronizer.json
      udca: ./sa/udca.json

Lorsqu'un appel d'API tel que https://api.example.com/orders arrive, la requête est envoyée au processeur de messages de l'environnement test1. De même, si une requête adressée à https://api.example.com/customers arrive, elle est acheminée vers l'environnement test2.

Ajouter un nouvel environnement

Pour ajouter un nouvel environnement, ajoutez sa configuration à la propriété envs[] et ajoutez une nouvelle entrée virtualhosts.routingRules.path, qui spécifie les chemins de base que vous souhaitez mapper au nouvel environnement. Dans l'exemple suivant, un nouvel environnement nommé test3 est ajouté, et les règles de routage (routingRules) ont été mises à jour pour acheminer deux chemins d'accès vers le nouvel environnement :

virtualhosts:
  - name: vhost-one
    hostAliases: ["api.example.com"]
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    routingRules:
      - paths:
        - /orders
        - /items
        env: test1
      - paths:
        - /v0/hello
        - /httpbin
        env: test2
      - paths:
        - /v0/inventory
        - /v0/customers
        env: test3

envs:
  - name: test1
    serviceAccountPaths:
      synchronizer: ./sa/synchronizer.json
      udca: ./sa/udca.json
  - name: test2
    serviceAccountPaths:
      synchronizer: ./sa/synchronizer.json
      udca: ./sa/udca.json
  - name: test3
    serviceAccountPaths:
      synchronizer: ./sa/synchronizer.json
      udca: ./sa/udca.json

Pour appliquer la mise à jour, il vous suffit d'appliquer le composant runtime, comme suit :

apigeectl apply -f overrides-file.yaml -c runtime

Ajouter plusieurs hôtes virtuels

La propriété virtualhosts[] est un tableau. Vous pouvez donc créer plusieurs hôtes virtuels. Chaque hôte virtuel doit contenir un ensemble unique d'alias d'hôte : deux hôtes virtuels ne peuvent pas partager le même alias d'hôte. Par exemple, le nouvel hôte virtuel dev gère le trafic envoyé au domaine api.internal.com.

virtualhosts:
  - name: vhost-one
    hostAliases: ["api.example.com"]
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    routingRules:
      - paths:
        - /orders
        - /items
        env: test1
      - paths:
        - /v0/hello
        - /httpbin
        env: test2
      - paths:
        - /v0/inventory
        - /v0/customers
        env: test3

  - name: vhost-two
    hostAliases: ["api.internal.com"]
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    routingRules:
      - paths:
        - /orders
        - /items
        env: test1
      - paths:
        - /v0/hello
        - /httpbin
        env: test2
      - paths:
        - /v0/inventory
        - /v0/customers
        env: test3

envs:
  - name: test1
    serviceAccountPaths:
      synchronizer: ./sa/synchronizer.json
      udca: ./sa/udca.json
  - name: test2
    serviceAccountPaths:
      synchronizer: ./sa/synchronizer.json
      udca: ./sa/udca.json
  - name: test3
    serviceAccountPaths:
      synchronizer: ./sa/synchronizer.json
      udca: ./sa/udca.json

Pour appliquer la mise à jour, il vous suffit d'appliquer le composant runtime, comme suit :

apigeectl apply -f overrides-file.yaml -c runtime

REMARQUE : Si vous ne faites qu'ajouter ou modifier le stanza virtualhosts, vous pouvez appliquer ces modifications à l'aide de l'option --settings :

apigeectl apply -f overrides-file.yaml --settings virtualhosts -c runtime

Si vous modifiez les hôtes virtuels et les environnements, vous devez appliquer la modification sans utiliser --settings, comme suit, pour mettre à jour entièrement le composant de l'environnement d'exécution :

apigeectl apply -f overrides-file.yaml -c runtime

Clés et certificats TLS

Lorsque vous créez un hôte virtuel, vous devez fournir une clé et un certificat TLS. La clé/le certificat permettent de communiquer de manière sécurisée avec la passerelle d'entrée.

Il vous revient de générer les paires certificat/clé TLS appropriées pour votre configuration hybride. Les articles suivants ne sont fournis qu'à titre d'exemple. Ils sont destinés principalement à l'essai ou au test d'une nouvelle installation hybride s'il est impossible d'obtenir des identifiants TLS d'une autre manière :

Consultez la page Récupérer des identifiants TLS pour obtenir un exemple d'étapes permettant de créer une paire clé/certificat TLS autorisée.
Vous pouvez utiliser une ou plusieurs paires certificat/clé autosignées à des fins de test uniquement. Consultez la page Générer des identifiants TLS autosignés.