Um ambiente fornece um contexto isolado ou "sandbox" para executar proxies de API.
Em uma única organização, é possível criar vários ambientes. Para mais informações,
consulte Sobre ambientes e grupos de ambiente.
O código a seguir mostra um exemplo de configuração em que vários ambientes são
definidos. Observe que os ambientes
prod e test têm aliases de host diferentes:
Suponha que um proxy com o caminho base /foo1 esteja implantado no ambiente test. Você pode chamar o proxy da seguinte maneira:
curl -k https://api.example.com/foo1
Quando essa chamada atinge a entrada, a entrada sabe enviá-la para o processador de mensagens
associado ao ambiente test, que processa a solicitação.
Da mesma forma, se foo1 também for implantado no ambiente prod,
será possível fazer uma solicitação
de proxy como essa para o alias de host apiprod.mydomain.net:
curl -k https://apiprod.example.com/foo1
E a chamada é roteada pela entrada para o MP associado a esse host.
Antipadrão: implante todos os proxies em um ambiente híbrido.
Prática recomendada: crie vários ambientes e implante um número limitado de proxies
em cada um. É possível criar regras de roteamento que especificam para quais ambientes
rotear caminhos de base de proxy de API específicos. Para detalhes, consulte Configuração do host virtual.
Limitar o número de implantações de proxy
Para híbridos, o fato de que muitos ambientes podem compartilhar o mesmo host virtual significa
que você precisa pensar cuidadosamente sobre como gerenciar as implantações de proxy em qualquer
ambiente. No híbrido, a prática recomendada é criar vários ambientes e implantar
um número limitado de proxies para cada um.
Quantos proxies você precisa implantar em um ambiente? Não há uma resposta definida
para essa pergunta: No entanto, a tabela a seguir fornece orientações gerais sobre por que é uma
boa ideia limitar o número de proxies implantados em cada ambiente e o que você
precisa considerar ao gerenciar implantações de proxy:
Problema a ser considerado
Descrição
Tempo de inicialização do processador de mensagens
Há uma correlação direta entre o tempo que um processador de mensagens (MP, na sigla em inglês)
leva para inicializar e o número de proxies implantados nesse MP. Em um ambiente de escalonamento automático
do Kubernetes, um aumento no tempo de inicialização pode ser um problema. Quanto mais proxies
implantados no MP, mais tempo levará para que esse MP apareça se precisar
ser escalonado ou recriado.
Como escalonar o desempenho
Se você tiver vários proxies implantados em um ambiente e um deles receber
muito tráfego para que seja escalonado automaticamente, todos os proxies nesse
ambiente serão escalonados com ele. O efeito de desempenho no escalonamento de vários
proxies com um único proxy de alto tráfego pode ser um problema.
Vizinho barulhento
Se você tiver vários proxies implantados no mesmo ambiente e um proxy
falhar, todos os proxies no ambiente serão desativados enquanto os
MPs são reiniciados. Ao limitar o número de proxies implantados em um ambiente, você
minimiza o impacto de um único proxy falhar.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)"]]
