Sobre ambientes e grupos de ambiente

Nesta seção, descrevemos ambientes e grupos de ambiente.

Visão geral

Um ambiente é um contexto de execução de ambiente para os proxies de API e os fluxos compartilhados em uma organização. Você precisa implantar um proxy de API em um ambiente antes de poder ser acessado. É possível implantar um proxy de API em um único ambiente ou em vários.

Cada ambiente é limitado a 50 proxies da API implantados e fluxos compartilhados (combinados).

Um grupo de ambiente (às vezes chamado de envgroup na API Apigee) é o mecanismo básico para definir a maneira como as solicitações são roteadas para ambientes individuais. Você define os nomes do host nos grupos de ambiente (não em ambientes individuais), e a Apigee encaminha as solicitações para os ambientes dentro de um grupo usando essas definições de nome de host.

Os ambientes precisam ser membros de um grupo para acessar recursos definidos neles. Em outras palavras, você precisa atribuir um ambiente a um grupo antes de usá-lo.

O agrupamento lógico de ambientes por grupo de ambiente oferece os seguintes benefícios:

• Gerenciamento centralizado de nome do host: os grupos de ambiente fornecem um local centralizado para gerenciar nomes de host.
• Insights agregados: com grupos, é possível analisar erros analisando os relatórios de um grupo inteiro de uma vez, em vez de ambientes individuais.
• Evitar conflitos: ao agrupar ambientes, você pode garantir que os caminhos base dos seus ambientes não existam no mesmo nome de host.

Pontos principais

A tabela a seguir lista pontos importantes para lembrar sobre ambientes, organizações e grupos de ambientes:

Element	Regras
Organizações	Pode conter vários grupos de ambiente É preciso ter pelo menos um grupo de ambiente
Ambientes	Precisa estar em pelo menos um grupo de ambiente Pode estar em mais de um grupo Compartilhar nomes de host com todos os outros ambientes no mesmo grupo
Grupos de ambiente	Pode ter vários nomes de host Conter um ou mais ambientes; Os nomes de host atribuídos a um grupo precisam ser exclusivos para ele. Não é possível usá-los em outros grupos.

Usuários híbridos da Apigee: todos os grupos de ambiente criados com um ambiente anexado precisam ser incluídos em todos os arquivos de substituição em que o ambiente é usado.

Para informações sobre quantos grupos de ambientes por organização e quantos ambientes por grupo de ambiente você pode ter, consulte limites.

Exemplos

As seções a seguir mostram maneiras comuns em que ambientes são estruturados dentro de grupos de ambiente.

Um grupo de ambiente e um ambiente

A estrutura mais simples é um grupo de ambiente único com um único ambiente. Isso é comum para organizações que estão avaliando o produto ou ainda não configurou a infraestrutura de teste ou análise. Além disso, não há proxies implantados na produção.

Vários ambientes em um único grupo

Uma organização pode conter vários grupos de ambiente. Por exemplo, defina os grupos de ambiente dev, test e prod em uma organização e mapeie cada um deles para um único nome de host (ou endereço IP). . Em cada grupo, pode haver um ou mais ambientes:

Grupos de ambiente alinhados com o acesso

Como é possível atribuir o mesmo ambiente a mais de um grupo, é possível organizá-los por acesso. Por exemplo, é possível tornar os ambientes de produção acessíveis em um único grupo de ambiente interno, mas limitar o acesso a alguns deles em um grupo público, que seria aberto à Internet:

Grupos de ambiente alinhados com as unidades de negócios

Com um conjunto maior e mais madura de proxies implantados ativamente, é comum alinhar grupos de ambientes a unidades de negócios. Por exemplo, você pode ter grupos de ambiente para as equipes de teste, produção e desenvolvimento:

Tudo pronto para criar um grupo? Abra o console

Para saber mais sobre ambientes: Continuar lendo

Para saber mais sobre grupos de ambiente: Continuar lendo

Roteamentos e caminhos básicos

Em uma configuração simples, uma solicitação para um proxy da API implantada é composta de um nome de host, caminho base e nome de um recurso da API. Por exemplo:

https://www.example.com/shopping/cart/addItem
        |_____________| |___________| |_____|
               |             |           |
            hostname      basepath     resource

Você define os nomes do host no grupo de ambiente para que vários ambientes possam compartilhá-los. Os caminhos de base e os recursos da API são definidos no proxy da API.

Observação: os nomes do ambiente e do grupo não afetam o URL do endpoint da API. Elas são destinadas somente para você organizar e configurar seus ambientes, e não são expostas aos usuários finais do proxy.

Para mais informações sobre caminhos base e recursos da API, leia Noções básicas sobre rotas. Além disso, confira as referências da configuração de fluxo e Variáveis de fluxo para entender melhor como essas peças se encaixam.

Nomes de host

Ao criar um grupo de ambiente, você anexa um ou mais nomes de host a esse grupo. Por exemplo, você pode ter os grupos de ambiente a seguir, cada um com os próprios nomes de host:

Nome do grupo de ambiente (Ambientes)	prod-group (catalog-prod produto-produto pymnt-prod)	dev-group (dev-env)	test-group (teste-env)
Nomes de host	catalog.example.com payment.example.com	dev.example.com	test.example.com

Você define caminhos base no proxy quando cria-o.

Quando você implanta um proxy em um ambiente dentro do grupo, o nome do host mais o caminho base e o nome do recurso definem o endpoint de uma solicitação da API para esse proxy.

É possível definir mais de um nome de host em um grupo de ambiente. Todos podem ser usados para chamar qualquer proxy implantado em qualquer ambiente no grupo. Por exemplo, catalog.example.com/proxy1 e payment.example.com/proxy1 chamarão o recurso proxy1 se os nomes de host catalog.example.com e payment.example.com forem definidos no mesmo grupo de ambiente.

Para aceitar vários nomes de host em um único grupo de ambiente compartilhado por vários ambientes, a Apigee roteia as solicitações da API para diferentes proxies de maneiras diferentes.

Exemplo de roteamento

Exemplo:

• O grupo de ambiente prod-group contém os seguintes ambientes:

  • catalog-prod
  • cart-prod
  • pymnt-prod

• O prod-group tem os seguintes nomes de host definidos nele:

  • catalog.example.com
  • payment.example.com

• Os proxies a seguir são implantados nestes ambientes:

  • O proxy catalog em catalog-prod com um caminho base de /catalog
  • O proxy cart em cart-prod com um caminho base de /catalog/cart
  • O proxy payment em pymnt-prod com um caminho base de /payment

Isso cria os seguintes endpoints:

• catalog.example.com/catalog faz o roteamento para o proxy catalog no ambiente catalog-prod.
• catalog.example.com/catalog/cart faz o roteamento para o proxy cart no ambiente cart-prod.
• payment.example.com/payment faz o roteamento para o proxy payment no ambiente pymnt-prod.

O exemplo a seguir mostra que as solicitações são roteadas para diferentes proxies implantados em ambientes dentro do grupo, dependendo do nome do host e do caminho base:

Dica:

Os nomes de host definidos em um grupo de ambiente:

• Precisam ser único em todos os grupos de ambiente de uma organização; elas não podem ser usadas por mais de um grupo
• Não permitem caracteres curinga
• Os caminhos base precisam ser exclusivos dentro de um host (não é possível que dois proxies tenham o mesmo caminho base dentro de um host)

Para mais informações, consulte Como adicionar nomes de host a um grupo.

Roteamento e ambientes compartilhados

Os ambientes podem pertencer a vários grupos. No entanto, os nomes de host precisam ser exclusivos para apenas um grupo de ambiente. Portanto, o isolamento a vários grupos fornece vários endereços para proxies implantados nesse ambiente. Isso é útil quando um cliente tem certificados curinga (como *.example.com) para vários parceiros.

Exemplo:

• shared-env pertence a dois grupos de ambiente:
  • partner-1 com o alias de host api.partner-1.com
  • partner-2 com o alias de host api.partner-2.com
• O proxy foo foi implantado em shared-env com um caminho base /foo. Como shared-env é compartilhado por ambos os grupos de ambiente, foo tem dois endereços:
  • partner-1.example.com/foo
  • partner-2.example.com/foo

Nesse caso, ambos os nomes do host encaminham para o mesmo ambiente. É um caso em que uma empresa expõe nomes de host diferentes para cada parceiro, dando efetivamente a cada um um nome de domínio personalizado. Para a Apigee híbrida, este cenário pode usar mTLS com um certificado diferente para cada parceiro.

Sobre o escopo do ambiente

A organização fornece escopo para alguns recursos da Apigee. Por exemplo, os dados de um mapa de chave-valor (KVM, na sigla em inglês) são disponibilizados no nível da organização, o que significa que os proxies da API implantados em qualquer ambiente dessa organização recebem os mesmos dados do KVM.

Alguns recursos podem ser limitados a ambientes ou grupos de ambientes dentro da organização. Por exemplo, os dados de análise do Apigee são particionados por uma combinação de organização, ambiente e, mais tarde, grupo de ambiente.

Considerações

Cada implantação em um ambiente pode afetar o roteamento do tráfego para cada grupo de ambientes a que esse ambiente está anexado. Quando novos caminhos base são adicionados, eles podem começar a capturar tráfego totalmente novo ou podem começar a capturar um subconjunto de tráfego existente que já está sendo gerenciado por uma implantação atual.

Da mesma forma, quando os caminhos de base são removidos, eles podem corresponder a endpoints que não recebem mais tráfego ou podem fazer com que o tráfego existente seja redirecionado para um proxy diferente. Quando o tráfego é redirecionado, pode ser para algum proxy no mesmo ambiente ou quando vários ambientes compartilham um único grupo de ambiente, pode ser para um proxy em outro ambiente.

Outros recursos

Veja nas informações a seguir como gerenciar os ambientes e grupos de ambientes:

• Com a IU da Apigee:

  • Como trabalhar com ambientes
  • Como trabalhar com grupos de ambiente

• Com a API Apigee:

  • API Environments
  • API de grupos de ambiente
  • API Attachment Group.