Eine Umgebung stellt einen isolierten Kontext oder eine "Sandbox" zum Ausführen von API-Proxys bereit.
Sie können pro Organisation mehrere Umgebungen erstellen. Weitere Informationen finden Sie unter Umgebungen und Umgebungsgruppen.
Der folgende Code zeigt ein Beispiel für eine Konfigurations-Überschreibung, wobei mehrere Umgebungen definiert werden. Beachten Sie, dass die Umgebungen prod und test unterschiedliche Host-Aliasse haben:
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. Sie können Routingregeln erstellen, die angeben, an welche Umgebungen bestimmte API-Proxy-Basispfade weitergeleitet werden sollen. Weitere Informationen finden Sie unter Konfiguration des virtuellen Hosts.
Anzahl der Proxy-Deployments begrenzen
Bei Hybridumgebungen können sich viele Umgebungen denselben virtuellen Host teilen. Daher müssen Sie sorgfältig festlegen, wie Sie Ihre Proxybereitstellungen in einer bestimmten Umgebung verwalten. 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.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-28 (UTC)."],[[["\u003cp\u003eThis documentation version (1.2) is end-of-life and users should upgrade to a newer, supported version.\u003c/p\u003e\n"],["\u003cp\u003eEnvironments provide isolated sandboxes for running API proxies, and multiple environments can be created within a single organization.\u003c/p\u003e\n"],["\u003cp\u003eVirtual hosts map routing rules to specific environments, allowing different host aliases to route traffic to different environments like 'test' and 'prod'.\u003c/p\u003e\n"],["\u003cp\u003eBest practice dictates creating multiple environments and deploying a limited number of proxies to each to ensure better performance, scalability, and fault isolation.\u003c/p\u003e\n"],["\u003cp\u003eFactors such as message processor boot-up time, scaling performance, and the "noisy neighbor" effect should be considered when determining the number of proxies to deploy to an environment.\u003c/p\u003e\n"]]],[],null,["# About environments\n\n| You are currently viewing version 1.2 of the Apigee hybrid documentation. **This version is end of life.** You should upgrade to a newer version. For more information, see [Supported versions](/apigee/docs/hybrid/supported-platforms#supported-versions).\n\nAn *environment* provides an isolated context or \"sandbox\" for running API proxies.\nIn a single organization, you can create multiple environments. For more information,\nsee [About environments and environment groups](/apigee/docs/api-platform/fundamentals/environments-overview).\n\n\nThe following code shows an example overrides configuration where multiple environments are\ndefined. Note that environments\n**prod** and **test** have different host aliases: \n\n```actionscript-3\nnamespace: my-namespace\norg: my-organization\n...\nenvs:\n - name: test\n serviceAccountPaths:\n synchronizer: \"your_keypath/synchronizer-manager-service-account.json\n udca: \"your_keypath/analytic-agent-service-account.json\n\n - name: prod\n serviceAccountPaths:\n synchronizer: \"your_keypath/synchronizer-manager-service-account.json\n udca: \"your_keypath/analytic-agent-service-account.json\n...\n```\n- Add a `virtualhosts` property that maps its `routingRules` to the environment(s). \n\n ```\n virtualhosts:\n - name: default\n hostAliases: [\"api.example.com\"]\n sslCertPath: ./certs/fullchain.pem\n sslKeyPath: ./certs/privkey.pem\n routingRules:\n - env: test\n ``` \n\n ```\n virtualhosts:\n - name: external\n hostAliases: [\"apiprod.example.com\"]\n sslCertPath: ./certs/fullchain.pem\n sslKeyPath: ./certs/privkey.pem\n routingRules:\n - env: prod\n ```\n\n\n Suppose a proxy with the base path `/foo1` is deployed to environment\n **test**. You could call the proxy like this: \n\n ```\n curl -k https://api.example.com/foo1\n ```\n\n\n When this call hits the ingress, the ingress knows to send it to the message processor\n associated with the `test` environment, which handles the request.\n\n\n Similarly, if `foo1` is also deployed to the `prod` environment,\n you could make a proxy\n request like this, to the host alias `apiprod.mydomain.net`: \n\n ```\n curl -k https://apiprod.example.com/foo1\n ```\n\n\n And the call is routed by the ingress to the MP associated with that host.\n | **NOTE** On a request to an API proxy, the ingress compares the `Host` header of the incoming request to the list of host aliases to determine which virtual host handles the request. `curl` commands, browsers, and many other utilities automatically set the `Host` header with the domain of the request. If for any reason your app is not setting the `Host` header automatically, you must set it manually.\n\n\n **Antipattern**: Deploy all of your proxies to one hybrid environment.\n\n\n **Best practice** : Create multiple environments and deploy a limited number of proxies\n to each one. You can create routing rules that specify which environments\n to route specific API proxy basepaths to. For details, see [Virtual host configuration](/apigee/docs/hybrid/v1.2/base-path-routing).\n\n Limit the number of proxy deployments\n -------------------------------------\n\n\n For hybrid, the fact that many environments can share the same virtual host means\n that you must think carefully about how you manage your proxy deployments to any given\n environment. In hybrid, the best practice is to create multiple environments and deploy\n a limited number of proxies to each one.\n\n\n **How many proxies should you deploy to an environment?** There is not a set answer\n to this question; however, the following table provides general guidance on why it's a\n good idea to limit the number of proxies deployed to each environment and what you\n need to think about when managing proxy deployments:\n | **NOTE:** When deciding how many proxies to deploy to an environment, be sure to consider the product configuration limits described in [Limits](/apigee/docs/api-platform/reference/limits#hybrid).\n\n Enviroment configuration reference\n ----------------------------------\n\n\n For a complete list of environment configuration elements, see `envs` in the\n [Configuration property reference](/apigee/docs/hybrid/v1.2/config-prop-ref#envs).\n\n Working with environments\n -------------------------\n\n\n For more information about configuration, see the following topics:\n - [Creating new environments](/apigee/docs/hybrid/v1.2/environment-create)\n - [Deleting environments](/apigee/docs/hybrid/v1.2/environment-delete)\n - [Base path routing](/apigee/docs/hybrid/v1.2/base-path-routing)"]]
