Informationen zu Umgebungen

Eine Umgebung stellt einen isolierten Kontext oder eine "Sandbox" zum Ausführen von API-Proxys bereit. Sie können pro Organisation mehrere Umgebungen erstellen.

Der folgende Code zeigt ein Beispiel für eine Überschreibungskonfiguration, wobei mehrere Umgebungen definiert werden.

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
...

Angenommen, ein Proxy mit dem Basispfad /foo1 wird für die Umgebung test bereitgestellt. Sie könnten den Proxy so aufrufen:

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

Sobald dieser Aufruf Ingress erreicht, sendet Ingress ihn an den mit der test-Umgebung verknüpften Nachrichtenprozessor, der die Anfrage verarbeitet.

Ist foo1 auch in der prod-Umgebung bereitgestellt, können Sie eine Proxyanfrage wie diese an den Host-Alias apiprod.mydomain.net erstellen:

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

Der Aufruf wird durch Ingress an den MP weitergeleitet, der diesem Host zugeordnet ist.

Antimuster: Stellen Sie alle Ihre Proxys in einer Hybridumgebung bereit.

Best Practice: Erstellen Sie mehrere Umgebungen und stellen Sie in jeder eine begrenzte Anzahl an Proxys bereit.

Anzahl der Proxy-Deployments begrenzen

Für Hybridumgebungen bedeutet die Tatsache, dass viele Umgebungen dieselben virtuellen Hosts verwenden können, wie in Umgebungsgruppen definiert, dass Sie sich die Verwaltung Ihrer Proxybereitstellungen in den einzelnen Umgebungen genau überlegen müssen. In Hybridumgebungen wird empfohlen, mehrere Umgebungen zu erstellen und in jeder eine begrenzte Anzahl an Proxys bereitzustellen.

Wie viele Proxys sollten Sie in einer Umgebung bereitstellen? Es gibt keine feste Antwort auf diese Frage. Die folgende Tabelle enthält jedoch allgemeine Hinweise dazu, warum es sinnvoll ist, die Anzahl der in jeder Umgebung bereitgestellten Proxys zu begrenzen und was Sie bei der Verwaltung von Proxy-Bereitstellungen beachten müssen:

Zu berücksichtigendes Problem Beschreibung
Startzeit des Nachrichtenprozessors Es besteht ein direkter Zusammenhang zwischen der Zeitspanne, die für das Starten eines Nachrichtenprozessors (MP, Message Processor) erforderlich ist, und der Anzahl der auf diesem MP bereitgestellten Proxys. In Kubernetes-Umgebungen mit automatischer Skalierung kann eine Erhöhung der Startzeit zu Problemen führen. Je mehr Proxys auf einem MP bereitgestellt werden, desto länger dauert es, bis der MP bereit ist, falls er skaliert oder neu erstellt werden muss.
Skalierungsleistung Wenn Sie in einer Umgebung mehrere Proxys bereitgestellt haben und einer der Proxys viel Traffic empfängt, wird er häufig automatisch skaliert. Dies führt dazu, dass auch alle anderen Proxys in dieser Umgebung mit skaliert werden. Die Leistungseinbußen aufgrund der Skalierung mehrerer Proxys aufgrund eines einzelnen Proxy mit hohem Traffic können ein Problem darstellen.
Problemnachbarn Wenn Sie mehrere Proxys in derselben Umgebung bereitgestellt haben und ein Proxy abstürzt, werden alle Proxys in der Umgebung entfernt, während die MPs neu gestartet werden. Durch das Einschränken der Anzahl von Proxys, die in einer Umgebung bereitgestellt werden, minimieren Sie die Auswirkungen eines einzelnen Proxy-Absturzs.

Umgebungsgruppen und Virtualhosts

Mit Umgebungsgruppen können Sie Umgebungen logisch gruppieren. Umgebungen innerhalb jeder Gruppe haben die gleichen Hostnamen. Sie können Umgebungen nach Funktion, Hostnamenadresse, Region (wenn Sie eine multiregionale Hybridinstallation implementieren) oder einem beliebigen anderen Messwert gruppieren.

Da das Routing von der Kombination aus Hostnamen der Umgebung, API-Proxy-Basispfaden und -umgebungen verwaltet wird, muss jeder virtuelle Host nur den Namen der Umgebungsgruppe und alle entsprechenden Zertifikate auflisten.

Der folgende Code zeigt ein Beispiel für eine Überschreibungskonfiguration, in der mehrere Virtualhosts definiert sind. Beachten Sie, dass der Name der virtuellen Hosts die Namen der Umgebungsgruppen sein müssen.

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

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

org: hybrid-example

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
...

Zusätzliche Ressourcen