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 ambientes.
Durante uma instalação básica, você adicionou um ambiente para testes. No entanto, é uma prática recomendada criar vários ambientes e implantar um número limitado de proxies em cada um deles.
Sobre hosts e ambientes virtuais
O Apigee híbrido usa gateways de entrada do Istio para lidar com o tráfego de API recebido. Os serviços de ambiente de execução e MART são configurados com gateways de entrada do Istio para gerenciar as conexões que estão expostas fora do cluster. Isso significa, por exemplo, que todas as solicitações HTTP e HTTPS para um proxy de API são tratadas primeiro por um gateway de entrada do Istio.
No híbrido, você cria um ou mais ambientes e atribui um alias de host a cada um. O alias de host é um nome DNS. O tráfego de entrada para esse nome de DNS é roteado pela entrada para esse ambiente. Internamente, cada ambiente é atribuído a um e apenas um processador de mensagens, que processa solicitações de proxy, aplicando políticas e direcionando o tráfego para e de serviços de destino. Portanto, o alias do host determina qual processador de mensagens recebe qualquer solicitação de entrada.
O código a seguir mostra um exemplo de configuração em que vários ambientes são definidos. Essas configurações pertencem ao seu arquivo de modificação. Observe que os ambientes dev1 e prod1 têm aliases de host diferentes:
envs: - name: dev1 hostAlias: "apitest.mydomain.net" ... - name: prod1 hostAlias: "apiprod.mydomain.net" ...
Suponha que um proxy com o caminho base /foo1
seja implantado no ambiente
dev1. Você pode chamar o proxy da seguinte maneira:
curl -k https://apitest.mydomain.net/foo1
Quando essa chamada atinge a entrada, a entrada sabe enviá-la para o processador de mensagens
associado ao ambiente dev1
, que processa a solicitação.
Da mesma forma, se foo1
também for implantado no ambiente prod1
,
será possível fazer uma solicitação
de proxy como essa para o alias de host apiprod.mydomain.net
:
curl -k https://apiprod.mydomain.net/foo1
E a chamada é roteada pela entrada para o MP associado a esse host.
Em resumo, cada ambiente que você criar precisa ter um alias de host atribuído a ele. Cada ambiente é mapeado para um e apenas um processador de mensagens, e o alias do host determina qual processador de mensagens recebe uma determinada solicitação.
Ambientes podem compartilhar o mesmo alias de host
O híbrido da Apigee permite criar vários ambientes que você pode gerenciar como quiser. Por exemplo, é possível criar vários ambientes de desenvolvimento, dev1, dev2, dev3 e assim por diante, e mapear um alias de host único para cada um. Além disso, é possível implantar vários proxies em cada ambiente.
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. A técnica para gerenciar como os híbridos encaminham as chamadas de proxy para o ambiente correto que compartilham um alias de host é chamada de roteamento do caminho base.
Por exemplo, na configuração a seguir, os ambientes dev1 e dev2 compartilham o mesmo alias de host:
envs: - name: dev1 hostAlias: "apitest.mydomain.net" ... - name: dev2 hostAlias: "apitest.mydomain.net" ...
Quando vários ambientes compartilham o mesmo alias de host, você precisa usar a técnica de configuração chamada roteamento de caminho base para mapear caminhos básicos de proxy para ambientes específicos. Consulte Roteamento de caminho base para mais informações.
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. |
Referência de configuração de ambiente
Para uma lista completa dos elementos de configuração do ambiente, consulte envs
na
Referência da propriedade de configuração.
Como trabalhar com ambientes
Para mais informações sobre a configuração, consulte os seguintes tópicos: