Acerca dos ambientes e dos grupos de ambientes

Esta página aplica-se ao Apigee e ao Apigee Hybrid.

Veja a documentação do Apigee Edge.

Esta secção descreve os ambientes e os grupos de ambientes.

Vista geral

Um ambiente do Apigee é um ambiente de software, numa organização, para criar e implementar proxies de API. Tem de implementar um proxy de API num ambiente antes de poder aceder ao mesmo. Pode implementar um proxy de API num único ambiente ou em vários ambientes.

Cada ambiente está sujeito a limites no número de proxies de API, fluxos partilhados e outros recursos que podem ser implementados no mesmo. Estes limites variam consoante o tipo de organização do Apigee (subscrição, pagamento conforme a utilização ou híbrido) que usa o ambiente. Para ver informações mais detalhadas, consulte a documentação Limites.

Um grupo de ambientes (por vezes denominado envgroup na API Apigee) é o mecanismo básico para definir a forma como os pedidos são encaminhados para ambientes individuais. Define os nomes de anfitriões nos grupos de ambientes (não em ambientes individuais) e o Apigee encaminha os pedidos para os ambientes num grupo através dessas definições de nomes de anfitriões.

Um ambiente tem de ser membro de, pelo menos, um grupo de ambientes antes de poder aceder aos proxies implementados no mesmo. Por outras palavras, tem de atribuir um ambiente a um grupo antes de o poder usar.

O agrupamento lógico de ambientes por grupo de ambientes oferece as seguintes vantagens:

• Gestão centralizada de nomes de anfitriões: os grupos de ambientes oferecem um local centralizado para gerir nomes de anfitriões.
• Estatísticas agregadas: com os grupos, pode analisar erros consultando relatórios de um grupo de ambientes inteiro de uma só vez, em vez de ambientes individuais.
• Evitar conflitos: ao agrupar ambientes, pode garantir que os caminhos base dos seus proxies implementados existem no mesmo nome de anfitrião.

Tipos de implementação suportados

O Apigee suporta os seguintes tipos de implementação num ambiente:

Tipo	Descrição
Proxy	Desenvolva e teste os proxies de API nos seus ambientes de desenvolvimento do Apigee e, em seguida, implemente-os nos ambientes de teste de integração e de produção do Apigee. Consulte o artigo Implementar um proxy de API.
Arquivar	Desenvolva e teste os seus proxies de API programáveis com o Apigee no VS Code.

Resumo das ações impedidas com a implementação de arquivo

Quando ativa a implementação de arquivos num ambiente do Apigee, não pode realizar as seguintes ações no ambiente para evitar conflitos:

• Na IU do Apigee, não pode ver, confirmar o estado da implementação nem gerir as implementações de arquivo, conforme descrito em Implementar um proxy de API, nem usar a IU de depuração, conforme descrito em Usar a depuração. Como solução alternativa, pode usar o gcloud ou a API para listar todas as implementações de arquivos num ambiente e usar a API Debug.
• Não pode criar, atualizar nem eliminar ficheiros de recursos ou servidores de destino através da IU, da API ou do gcloud do Apigee.
• Neste momento, a autenticação Google através de contas de serviço não é suportada.

Nota: pode gerir mapas de chaves-valores (KVMs) e keystores TLS num ambiente do Apigee ativado para implementação de arquivos.

Se tentar realizar alguma das ações impedidas indicadas acima, a ação falha com a seguinte mensagem de erro:

FAILED_PRECONDITION

Unidades de implementação de proxy

As unidades de implementação de proxy contabilizam proxies e fluxos partilhados implementados em ambientes por região.

Seguem-se os tipos de unidades de implementação:

• As unidades de implementação de proxy padrão contabilizam o número de proxies implementados atualmente que se qualificam como proxies padrão.
• As unidades de implementação de proxy extensíveis contabilizam o número de proxies atualmente implementados que se qualificam como proxies extensíveis.
• As unidades de implementação de fluxo partilhado contabilizam o número de fluxos partilhados implementados.

A sua utilização pode estar sujeita à quota de implementações, que é um limite do número de unidades de implementação que pode usar em simultâneo. Consulte os seus direitos (Pay-as-you-go ou Subscrição 2024) para ver detalhes. Para informações sobre os limites do sistema, consulte o artigo Número máximo de unidades de implementação de proxy por instância.

Para mais informações sobre como ver a utilização da unidade de implementação de proxy e os detalhes da quota de implementações da sua organização, consulte o artigo Veja a utilização da implementação de proxy.

Tipos de ambientes

Para utilizadores de pagamento conforme o uso, quando cria um ambiente, seleciona o tipo de ambiente: Base, Intermédio ou Abrangente. As funcionalidades, a funcionalidade e os custos associados ao ambiente dependem do tipo de ambiente. Consulte os tipos de ambientes de pagamento conforme o uso e os direitos de pagamento conforme o uso para mais informações.

Para os planos de subscrição, o tipo de ambiente é sempre abrangente e não precisa de saber mais sobre os tipos de ambiente.

Encaminhamento por proxy

O Apigee suporta o encaminhamento de tráfego para um URI especificado. Esta funcionalidade aplica-se ao nível do ambiente e pode ser usada para direcionar o tráfego para a Internet após o processamento inicial num proxy.

Os pedidos recebidos para proxies no processo do ambiente configurado para quaisquer políticas incluídas (consulte Suporte de funcionalidades de encaminhamento de proxy) e, em seguida, encaminham-se através de HTTP para o novo URI.

As alterações feitas à definição de proxy de encaminhamento de um ambiente entram em vigor imediatamente apenas para novos pedidos. Os pedidos já em processamento são concluídos com a definição que estava em vigor quando o pedido foi recebido.

Para ver instruções sobre como configurar o encaminhamento por proxy, consulte o artigo Configurar o encaminhamento por proxy num ambiente.

Suporte da funcionalidade de proxy de encaminhamento

Nem todas as funcionalidades de proxy geralmente disponíveis têm a mesma disponibilidade ou aplicabilidade com o encaminhamento de proxy.

Atualmente, o Apigee não suporta a autenticação básica com encaminhamento por proxy, exceto no Apigee Hybrid.

Esta tabela mostra o suporte para funcionalidades adicionais:

Funcionalidade ou política	Suportado/aplicável para encaminhamento de proxy?
Pontos finais de destino	Sim
Verificação de funcionamento de HTTP	Sim
Textos destacados de serviços	Sim
Chamadas HTTP através de JavaScript	Sim
Alvos de integração	Sim
Encadeamento de proxies através de loopbacks locais	Não
Publicar mensagens	Não
Cloud Logging	Não
Comunicação com o sincronizador	Não
Registo de mensagens através do Syslog	Não

Limitações de proxy de encaminhamento

Atualmente, o GoogleToken através de um público-alvo externo não é suportado com o encaminhamento por proxy.

Pontos-chave

A tabela seguinte apresenta pontos importantes a ter em atenção acerca dos ambientes, das organizações e dos grupos de ambientes:

Elemento	Regras
Organizações	Pode conter vários grupos de ambientes Tem de ter, pelo menos, um grupo de ambientes
Ambientes	Tem de estar em, pelo menos, um grupo de ambientes Pode estar em mais do que um grupo Partilhe nomes de anfitriões com todos os outros ambientes no mesmo grupo Pode ser usado para encaminhar tráfego para um URI especificado
Tipos de ambiente	Determinar a funcionalidade disponível nesse ambiente Determine os preços para o ambiente (Consulte Tipos de ambiente.)
Grupos de ambientes	Pode ter vários nomes de anfitrião Contêm um ou mais ambientes Os nomes de anfitrião atribuídos a um grupo têm de ser exclusivos desse grupo (não podem ser usados por outros grupos)

Utilizadores do Apigee hybrid: todos os grupos de ambientes que criar com um ambiente anexado têm de ser incluídos em todos os ficheiros de substituição onde o ambiente é usado.

Exemplos

As secções seguintes mostram formas comuns de estruturar os ambientes nos grupos de ambientes.

Um grupo de ambientes e um ambiente

A estrutura mais simples é um único grupo de ambientes com um único ambiente. Isto é comum para organizações que estão atualmente a avaliar o produto ou ainda não configuraram infraestrutura de testes ou de estatísticas, nem têm proxies implementados em produção.

Vários ambientes num único grupo de ambientes

Um grupo de ambientes pode conter vários ambientes. Por exemplo, um único grupo de ambientes, prod-group, pode conter três ambientes, cart-prod, catalog-prod e payment-prod.

O grupo de ambientes tem um único nome de anfitrião, example.com. Pode usar o nome do anfitrião para encaminhar pedidos para um proxy implementado em qualquer um dos ambientes. Tenha em atenção que os nomes de anfitriões são definidos ao nível do grupo de ambientes: não são encaminhados para um ambiente específico.

Consulte o artigo Trabalhar com grupos de ambientes para saber como criar este grupo de ambientes.

Restringir o encaminhamento a um único ambiente

No exemplo anterior, os pedidos podem ser encaminhados para proxies em todos os três ambientes por um único nome de anfitrião. Se quiser restringir o acesso a proxies num único ambiente, por exemplo, catalog-prod, crie outro grupo de ambientes que contenha apenas o ambiente catalog-prod. Em seguida, um nome de anfitrião definido para esse grupo de ambientes só pode aceder a catalog-prod.

Por exemplo, o nome do anfitrião catalog.example.com, para o grupo de ambientes catalog-prod-group, só pode encaminhar pedidos para proxies no ambiente catalog-prod.

Quer criar um grupo? Abra a consola

Para saber mais sobre os ambientes: Continuar a ler

Para saber mais sobre os grupos de ambientes: Continuar a ler

Encaminhamento e caminhos base

Numa configuração simples, um pedido a um proxy de API implementado é composto por um nome de anfitrião, um caminho base e o nome de um recurso de API; por exemplo:

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

Define os nomes de anfitrião no grupo de ambientes para que vários ambientes os possam partilhar. Os caminhos base e os recursos da API são definidos no proxy de API.

Nota: os nomes do ambiente e do grupo não afetam o URL do ponto final da API. Destinam-se apenas a si para organizar e configurar os seus ambientes e não são expostos aos utilizadores finais do proxy.

Para mais informações sobre caminhos base e recursos da API, comece por ler o artigo Compreender as rotas. Além disso, consulte a referência de configuração do fluxo e a referência de variáveis do fluxo para compreender melhor como estas partes se encaixam.

Nomes de anfitriões

Quando cria um grupo de ambientes, associa um ou mais nomes de anfitrião a esse grupo. Por exemplo, pode ter os seguintes grupos de ambientes, cada um com os seus próprios nomes de anfitriões:

Nome do grupo de ambientes (Environments)	prod-group (catalog-prod cart-prod pymnt-prod)	dev-group (dev-env)	test-group (test-env)
Nomes de anfitriões	catalog.example.com payment.example.com	dev.example.com	test.example.com

Define caminhos base no proxy quando o cria.

Quando implementa um proxy num ambiente dentro do grupo, o nome do anfitrião, o caminho base e o nome do recurso definem em conjunto o ponto final de um pedido de API a esse proxy.

Pode definir mais do que um nome de anfitrião num grupo de ambientes. Podem ser usados para chamar qualquer proxy implementado em qualquer ambiente no grupo. Por exemplo, catalog.example.com/proxy1 e payment.example.com/proxy1 chamam o recurso proxy1 se os nomes de anfitrião catalog.example.com e payment.example.com estiverem definidos no mesmo grupo de ambientes.

Exemplo de encaminhamento

Por exemplo:

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

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

• O prod-group tem os seguintes nomes de anfitriões definidos:

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

• Os seguintes proxies são implementados 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

Isto cria os seguintes pontos finais:

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

O exemplo seguinte mostra que os pedidos são encaminhados para diferentes proxies implementados em ambientes dentro do grupo, correspondendo a qualquer um dos nomes de anfitrião e ao caminho base:

Sugestão:

Os nomes de anfitrião que define num grupo de ambientes:

• Tem de ser único em todos os grupos de ambientes numa organização; não pode ser usado por mais do que um grupo
• Não suportam carateres universais
• Os caminhos base têm de ser exclusivos num grupo de ambientes (não podem existir dois proxies com o mesmo caminho base num grupo de ambientes)

Para mais informações, consulte a secção Adicionar nomes de anfitriões a um grupo.

Ambientes partilhados e encaminhamento

Um ambiente pode pertencer a vários grupos de ambientes. Se implementar um proxy num ambiente deste tipo, o proxy tem várias moradas, uma para cada grupo de ambientes ao qual o ambiente pertence. Isto é útil se um cliente tiver certificados universais (como *.example.com) para vários parceiros.

Por exemplo:

• shared-env pertence a dois grupos de ambientes:
  • partner-1 com o alias do anfitrião api.partner-1.com
  • partner-2 com o alias do anfitrião api.partner-2.com
• O proxy foo é implementado em shared-env com um caminho base /foo. Como shared-env é partilhado por ambos os grupos de ambientes, foo tem duas moradas:
  • api.partner-1.com/foo
  • api.partner-2.com/foo

Tenha em atenção que ambos os nomes de anfitrião são encaminhados para o mesmo ambiente. Isto atribui a cada grupo de ambientes um nome de domínio único. Para o Apigee hybrid, este cenário pode usar mTLS com um certificado diferente para cada parceiro.

Acerca do âmbito do ambiente

A organização fornece âmbito para algumas capacidades do Apigee. Por exemplo, os dados de mapa de chave-valor (KVM) podem ser disponibilizados ao nível da organização, o que significa que os proxies de API implementados em qualquer ambiente nessa organização podem aceder aos mesmos dados de KVM.

Da mesma forma, algumas capacidades podem ser limitadas a ambientes ou grupos de ambientes na organização. Por exemplo, os dados de estatísticas do Apigee são particionados por uma combinação de organização, ambiente e (eventualmente) grupo de ambientes.

Considerações

Cada implementação num ambiente tem o potencial de afetar o encaminhamento do tráfego para todos os grupos de ambientes aos quais esse ambiente está anexado. Quando são adicionados novos caminhos base, estes podem começar a captar tráfego totalmente novo ou podem começar a captar um subconjunto do tráfego existente já processado por uma implementação existente.

Da mesma forma, quando os caminhos base são removidos, podem corresponder a pontos finais que já não recebem tráfego ou podem fazer com que o tráfego existente seja reencaminhado para um proxy diferente. Quando o tráfego é reencaminhado, pode ser para um proxy no mesmo ambiente ou, quando vários ambientes partilham um único grupo de ambientes, pode ser para um proxy num ambiente diferente.

Também deve ter em consideração o número total de caminhos base de proxy de API adicionados a um ambiente ou a um grupo de ambientes. Para um desempenho ideal, a Apigee recomenda que não use mais de 3000 basepaths de proxy de API por ambiente do Apigee ou grupo de ambientes. Exceder esta recomendação pode resultar num aumento da latência para todas as implementações de proxy de API novas e existentes.

Recursos adicionais

As informações seguintes descrevem como gerir os seus ambientes e grupos de ambientes:

• Com a IU do Apigee:

  • Trabalhar com ambientes
  • Trabalhar com grupos de ambientes

• Com a API Apigee:

  • API Environments
  • API Environment groups
  • API de associação de grupos de ambientes