Sobre ambientes e grupos de ambiente

Esta página se aplica à Apigee e à Apigee híbrida.

Confira a documentação da Apigee Edge.

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

Visão geral

Um ambiente de Apigee é um ambiente de software, dentro de uma organização, para criar e implantar proxies da API. 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 está sujeito a limites de número de proxies de API, fluxos compartilhados e outros recursos que podem ser implantados nele. Esses limites variam de acordo com o tipo de organização da Apigee (assinatura, pagamento por uso ou híbrida) que usa o ambiente. Para obter mais detalhes, consulte a documentação Limites.

Um grupo de ambiente, também 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.

Um ambiente precisa ser membro de pelo menos um grupo para acessar os proxies implantados nele. 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, é possível garantir que os caminhos básicos dos proxies implantados existam no mesmo nome de host.

Tipos de implantação compatíveis

A Apigee é compatível com os seguintes tipos de implantação em um ambiente:

Tipo	Descrição
Proxy	Desenvolva e teste seus proxies de API nos ambientes de desenvolvimento da Apigee. Depois, implante-os nos ambientes de teste e produção de integração da Apigee. Consulte Como implantar um proxy de API.
Arquivar	Desenvolva e teste seus proxies de API programáveis usando a Apigee no VS Code.

Resumo de ações bloqueadas com a implantação de arquivos

Ao ativar a implantação de arquivos em um ambiente Apigee, você não vai poder executar as seguintes ações no ambiente para evitar conflitos:

• Na IU da Apigee, vocênão pode ver, confirmar o status da implantação ou gerenciar as implantações do arquivo, conforme descrito Como implantar um proxy de API ou use a IU de depuração conforme descrito em Como usar o Debug. Como solução alternativa, você pode usar o gcloud ou a API para listar todas as implantações de arquivo em um ambiente e usar a API Debug.
• Não é possível criar, atualizar ou excluir arquivos de recursos ou servidores de destino usando a IU, API ou gcloud da Apigee.
• No momento, não há suporte para a Autenticação do Google usando contas de serviço.

Observação:: é possível gerenciar mapas de chave-valor (KVMs, na sigla em inglês) e keystores de TLS em um ambiente Apigee ativado para a implantação de arquivos.

Se você tentar realizar uma das ações acima, a ação falhará e será exibida a seguinte mensagem de erro:

FAILED_PRECONDITION

Unidades de implantação de proxy

As unidades de implantação de proxy contam proxies e fluxos compartilhados implantados em ambientes por região.

Estes são os tipos de unidade de implantação:

• As unidades de implantação de proxy padrão contam o número de proxies implantados atualmente que se qualificam como proxies padrão.
• Unidades de implantação de proxy extensíveis contam o número de proxies implantados atualmente que se qualificam como proxies extensíveis.
• As unidades de implantação de fluxo compartilhado contam o número de fluxos compartilhados implantados.

O uso pode estar sujeito à cota de implantações, que é um limite de quantas unidades de implantação podem ser usadas por vez. Consulte seus direitos de Pay-as-you-go ou Assinatura 2024 para mais detalhes.

Para mais informações sobre como visualizar o uso da unidade de implantação do proxy e os detalhes da cota de implantações da sua organização, consulte Visualizar o uso da implantação do proxy.

Tipos de ambientes

Para usuários de pagamento por uso, ao criar um ambiente, você selecionará o tipo de ambiente: Base, Intermediário ou Abrangente. Os recursos, as funcionalidades e os custos associados ao ambiente dependem do tipo de ambiente. Consulte Tipos de ambiente de pagamento por uso e Direitos de pagamento por utilização para mais informações.

Nos planos de assinatura, o tipo de ambiente é sempre abrangente, e você não precisa conhecer os tipos de ambiente.

Proxy de encaminhamento

A Apigee oferece suporte ao encaminhamento de tráfego para um URI especificado. Esse recurso se aplica no nível do ambiente e pode ser usado para direcionar o tráfego para a Internet após o processamento inicial em um proxy.

Solicitações de entrada para proxies no processo de ambiente configurado para todas as políticas incluídas (consulte Suporte ao recurso de proxy de encaminhamento) e, em seguida, encaminham usando HTTP para o novo URI.

As alterações feitas na configuração de proxy de encaminhamento de um ambiente entram em vigor imediatamente apenas para novas solicitações. Solicitações já em processamento com a configuração que estava em vigor quando a solicitação foi recebida.

Para instruções sobre o proxy de encaminhamento, consulte Configurar o proxy de encaminhamento em um ambiente.

Compatibilidade com o recurso de proxy de encaminhamento

Nem todos os recursos de proxy com disponibilidade geral têm a mesma disponibilidade ou aplicabilidade com o proxy de encaminhamento.

No momento, a Apigee não oferece suporte à autenticação básica com proxy de encaminhamento, exceto na Apigee híbrida.

Esta tabela mostra suporte para outras funcionalidades:

Recurso ou política	Compatível/aplicável com proxy de encaminhamento?
Endpoints de destino	Sim
Verificação de integridade de HTTP	Sim
Chamadas de serviço	Sim
Chamadas HTTP via JavaScript	Sim
Destinos de integração	Sim
Encadeamento de proxy usando loopbacks locais	Não
Como publicar mensagens	Não
Cloud Logging	Não
Comunicação com o sincronizador	Não
Registro de mensagens via Syslog	Não

Limitações do proxy de encaminhamento

No momento, o GoogleToken não é compatível com um público-alvo externo usando proxy de encaminhamento.

Pontos principais

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

Elemento	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 Pode ser usado para encaminhar tráfego para um URI especificado
Tipos de ambientes	Determinar a funcionalidade disponível nesse ambiente e com relação a ele Determinar os preços do ambiente (Consulte Tipos de ambiente.)
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.

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 de ambiente

Um grupo de ambientes pode conter vários ambientes. No exemplo abaixo, há um único grupo de ambiente, prod-group, que contém três ambientes: prod-group, prod-group e prod-group.

O grupo de ambientes tem um único nome do host, example.com. É possível usar o nome do host para rotear solicitações para um proxy implantado em qualquer um dos ambientes. Observe que os nomes de host são definidos no nível do grupo de ambientes: eles não são roteados para um ambiente específico.

Consulte Como trabalhar com grupos de ambiente para saber como criar esse grupo.

Como restringir o roteamento a um único ambiente

No exemplo anterior, as solicitações podem ser roteadas para proxies nos três ambientes por um único nome do host. Se você quiser restringir o acesso a proxies em um único ambiente, como catalog-prod, crie outro grupo de ambiente que contenha apenas o ambiente catalog-prod. Em seguida, um nome do host definido para esse grupo de ambiente só pode acessar catalog-prod.

No exemplo abaixo, o nome do host catalog.example.com, para o grupo de ambiente catalog-prod-group, só pode encaminhar solicitações para proxies no ambiente catalog-prod.

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

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, correspondendo a qualquer um dos nomes de host e ao 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 grupo de ambiente. Não é possível que dois proxies tenham o mesmo caminho base em um grupo de ambiente

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

Roteamento e ambientes compartilhados

Um ambiente pode pertencer a vários grupos de ambientes. Se você implantar um proxy nesse ambiente, o proxy terá vários endereços, um para cada grupo de ambiente a que o ambiente pertencer. 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:
  • api.partner-1.com/foo
  • api.partner-2.com/foo

Observe que os dois nomes do host encaminham para o mesmo ambiente. Isso dá a cada grupo de ambiente um nome de domínio exclusivo. 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 um proxy no mesmo ambiente ou quando vários ambientes compartilham um único grupo de ambiente, pode ser para um proxy em outro ambiente.

O número total de caminhos de base do proxy de API adicionados a um ambiente ou grupo de ambientes também precisa ser considerado. Para um desempenho ideal, a Apigee recomenda usar no máximo 3.000 caminhos de base de proxy de API por ambiente ou grupo de ambientes da Apigee. Exceder essa recomendação pode resultar no aumento da latência em todas as implantações de proxy de API novas e atuais.

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.