Virtuelle Hosts konfigurieren

HINWEIS: Die virtualhosts-Konfiguration ist neu in der Version 1.2.0. Der virtuelle Host name muss folgende Bedingungen erfüllen:

Er darf nicht mehr als 253 Zeichen enthalten.
Er darf nur kleingeschriebene, alphanumerische Zeichen und einen Bindestrich - enthalten.
Er muss mit einem alphanumerischen Zeichen beginnen.
Er muss mit einem alphanumerischen Zeichen enden.

In diesem Thema wird die Konfiguration des virtuellen Hosts erläutert. Mit virtuellen Hosts kann Apigee Hybrid API-Anfragen an mehrere Domainnamen verarbeiten und Proxy-Basispfade an bestimmte Umgebungen weiterleiten.

Mit dem Konfigurationsattribut virtualhosts.routingRules[] können Sie festlegen, an welche umgebungsspezifischen API-Proxys Basispfade weitergeleitet werden soll. Weitere Informationen zu den einzelnen Attributen finden Sie in der Referenz zu Konfigurationsattributen unter virtualhosts. Beispiele:

...

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

Wenn ein API-Aufruf wie https://api.example.com/orders eingeht, wird die Anfrage an den Nachrichtenprozessor der test1-Umgebung gesendet. Analog dazu wird eine Anfrage an https://api.example.com/customers an die Umgebung test2 weitergeleitet.

Neue Umgebung hinzufügen

Wenn Sie eine neue Umgebung hinzufügen möchten, fügen Sie deren Konfiguration zum Attribut envs[] hinzu und fügen Sie dann einen neuen virtualhosts.routingRules.path-Eintrag hinzu, der angibt, welche Basispfade der neuen Umgebung zugeordnet werden sollen. Im folgenden Beispiel wird eine neue Umgebung mit dem Namen test3 hinzugefügt. routingRules wurde aktualisiert, um zwei Pfade zur neuen Umgebung zu weiterzuleiten:

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

Um das Update anzuwenden, müssen Sie nur die runtime-Komponente anwenden:

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

Mehrere virtuelle Hosts hinzufügen

Das Attribut virtualhosts[] ist ein Array, das Sie erstellen können. Jeder virtuelle Host muss einen eindeutigen Satz von Hostaliassen enthalten: Zwei virtuelle Hosts können nicht denselben Hostalias teilen. Zum Beispiel verarbeitet der neue virtuelle Host dev den an die Domain api.internal.com gesendeten Traffic.

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

Um das Update anzuwenden, müssen Sie nur die runtime-Komponente anwenden:

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

HINWEIS: Wenn Sie nur die virtualhosts-Stanza hinzufügen oder ändern, müssen Sie nichts mit dem Flag --settings tun:

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

Wenn Sie Virtualhosts und Umgebungen ändern, müssen Sie die Änderungen ohne --settings so anwenden, um die Laufzeitkomponente vollständig zu aktualisieren:

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

TLS-Schlüssel und -Zertifikate

Wenn Sie einen neuen virtuellen Host erstellen, müssen Sie auch einen TLS-Schlüssel und ein Zertifikat bereitstellen. Schlüssel und Zertifikat werden zur sicheren Kommunikation mit dem Ingress-Gateway verwendet.

Sie entscheiden selbst, wie Sie geeignete TLS-Zertifikat-/Schlüsselpaare für Ihre Hybridkonfiguration generieren. Die folgenden Themen werden nur als Beispiele bereitgestellt. Sie dienen hauptsächlich zum Ausprobieren oder Testen einer neuen Hybridinstallation, wenn es nicht möglich ist, TLS-Anmeldedaten abzurufen.

Unter TLS-Anmeldedaten abrufen finden Sie eine Reihe von Beispielschritten für die Erstellung eines autorisierten TLS-Zertifikat-/Schlüsselpaars.
Sie können selbst signierte Zertifikate/Schlüsselpaare nur zu Testzwecken verwenden. Weitere Informationen finden Sie unter Selbstsignierte TLS-Anmeldedaten generieren.