Publicar APIs internas para usuários externos

Neste cenário, uma organização consolida várias APIs internamente com a Gestão de API do Azure implementada numa Rede Virtual.

Arquitetura

Transfira um ficheiro do Visio desta arquitetura.

O diagrama anterior abrange um ciclo de vida completo de APIs internas que são consumidas pelos usuários externos.

Fluxo de dados

Os fluxos de dados são os seguintes:

1. Os desenvolvedores fazem check-in de código em um repositório GitHub conectado a um agente de pipeline de CI/CD instalado em uma VM do Azure.
2. O agente envia a compilação para o aplicativo de API hospedado no ILB ASE.
3. O Gerenciamento de API do Azure consome as APIs anteriores por meio de cabeçalhos HOST especificados na política de Gerenciamento de API.
4. O Gerenciamento de API usa o nome DNS do Ambiente do Serviço de Aplicativo para todas as APIs.
5. O Application Gateway expõe o desenvolvedor e o portal de API do API Management.
6. O DNS Privado do Azure é usado para rotear o tráfego internamente entre ASE, Gerenciamento de API e Gateway de Aplicativo.
7. Os usuários externos utilizam o portal do desenvolvedor exposto para consumir as APIs por meio do IP público do Application Gateway.

Componentes

• A Rede Virtual do Azure permite que os recursos do Azure se comuniquem com segurança entre si, com a Internet e com redes locais.
• O DNS Privado do Azure permite que os nomes de domínio sejam resolvidos em uma rede virtual sem a necessidade de adicionar uma solução DNS personalizada.
• O Gerenciamento de API do Azure ajuda as organizações a publicar APIs para desenvolvedores externos, parceiros e internos usarem seus dados e serviços.
• O Application Gateway é um balanceador de carga de tráfego da Web que ajuda você a gerenciar o tráfego para seus aplicativos Web.
• O Ambiente do Serviço de Aplicativo do Balanceador de Carga Interno é um recurso do Serviço de Aplicativo do Azure que fornece um ambiente totalmente isolado e dedicado para executar aplicativos do Serviço de Aplicativo com segurança em alta escala.
• O Azure DevOps é um serviço para gerenciar seu ciclo de vida de desenvolvimento e inclui recursos para planejamento e gerenciamento de projetos, gerenciamento de código, compilação e lançamento.
• O Application Insights é um serviço extensível de Gerenciamento de Desempenho de Aplicativos (APM) para desenvolvedores da Web em várias plataformas.
• O Azure Cosmos DB é o serviço de banco de dados multimodelo distribuído globalmente da Microsoft.

Alternativas

• Em um cenário de elevação e deslocamento do Azure implantado em uma Rede Virtual do Azure, os servidores back-end podem ser endereçados diretamente por meio de endereços IP privados.
• Se estiver usando recursos locais, a instância de Gerenciamento de API poderá retornar ao serviço interno de forma privada por meio de um gateway de VPN do Azure e uma conexão VPN IPSec (Internet Protocol Security) site a site ou ExpressRoute , criando um cenário híbrido do Azure e local.
• Provedores de DNS existentes ou de código aberto podem ser usados em vez do Serviço DNS baseado no Azure.
• As APIs internas implantadas fora do Azure ainda podem se beneficiar expondo as APIs por meio do Serviço de Gerenciamento de API.

Detalhes do cenário

Nesse cenário, uma organização hospeda várias APIs usando o Ambiente de Serviço de Aplicativo do Azure (ILB ASE) e deseja consolidar essas APIs internamente usando o Gerenciamento de API do Azure (APIM) implantado em uma Rede Virtual. A instância interna de Gerenciamento de API também pode ser exposta a usuários externos para permitir a utilização de todo o potencial das APIs. Essa exposição externa pode ser alcançada usando o Gateway de Aplicativo do Azure encaminhando solicitações para o serviço interno de Gerenciamento de API, que, por sua vez, consome as APIs implantadas no ASE.

• As APIs da Web são hospedadas pelo protocolo HTTPS seguro e usarão um Certificado TLS.
• O Application Gateway também é configurado pela porta 443 para chamadas de saída seguras e confiáveis.
• O serviço de Gerenciamento de API está configurado para usar domínios personalizados usando certificados TLS.
• Revise a configuração de rede sugerida para ambientes do Serviço de Aplicativo
• Precisa haver uma menção explícita sobre a porta 3443 que permite que o Gerenciamento de API gerencie por meio do portal do Azure ou do PowerShell.
• Aproveite as políticas dentro do APIM para adicionar um cabeçalho HOST para a API hospedada no ASE. Isso garante que o balanceador de carga do ASE encaminhará a solicitação corretamente.
• O Gerenciamento de API aceita a entrada DNS do ASE para todos os aplicativos hospedados em Ambientes do Serviço de Aplicativo. Adicione uma política APIM para definir explicitamente o cabeçalho HOST para permitir que o balanceador de carga ASE diferencie entre Aplicativos no Ambiente do Serviço de Aplicativo.
• Considere a Integração com o Azure Application Insights, que também apresenta métricas por meio do Azure Monitor para monitoramento.
• Se você usar pipelines de CI/CD para implantar APIs internas, considere criar seu próprio Agente Hospedado em uma VM dentro da Rede Virtual.

Potenciais casos de utilização

• Sincronize as informações de endereço do cliente internamente depois que o cliente fizer uma alteração.
• Atraia desenvolvedores para sua plataforma expondo ativos de dados exclusivos.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Fiabilidade

A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte Visão geral do pilar de confiabilidade."

Disponibilidade

Você pode implantar o serviço de Gerenciamento de API do Azure como uma implantação de várias regiões para maior disponibilidade e também para reduzir latências. Esta funcionalidade só está disponível no modo Premium. O serviço de Gerenciamento de API neste cenário específico consome APIs de Ambientes do Serviço de Aplicativo. Você também pode usar o APIM para APIs hospedadas na infraestrutura local interna.

Os Ambientes do Serviço de Aplicativo podem usar os perfis do Gerenciador de Tráfego para distribuir o tráfego hospedado nos Ambientes do Serviço de Aplicativo para maior escala e disponibilidade.

Resiliência

Embora este cenário de exemplo fale mais sobre configuração, as APIs hospedadas nos Ambientes do Serviço de Aplicativo devem ser resilientes o suficiente para lidar com erros nas solicitações, que eventualmente são gerenciadas pelo serviço de Gerenciamento de API e pelo Application Gateway. Considere os padrões de repetição e disjuntor no design da API. Para obter orientações gerais sobre como projetar soluções resilientes, consulte Projetando aplicativos resilientes para o Azure.

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.

Como o cenário de exemplo anterior é hospedado completamente em uma rede interna, o Gerenciamento de API e o ASE já estão implantados na infraestrutura segura (Azure VNet). Você pode integrar os Gateways de Aplicativo com o Microsoft Defender for Cloud para fornecer uma maneira perfeita de prevenir, detetar e responder a ameaças ao ambiente. Para obter orientações gerais sobre como criar soluções seguras, consulte a Documentação de Segurança do Azure.

Otimização de custos

A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.

O Gerenciamento de API é oferecido em quatro níveis: desenvolvedor, básico, padrão e premium. Você pode encontrar orientações detalhadas sobre a diferença nessas camadas nas diretrizes de preços do Gerenciamento de API do Azure aqui.

Os clientes podem dimensionar a Gestão de API ao adicionar e remover unidades. Cada unidade tem a capacidade estabelecida pelo respetivo escalão.

Para exibir os custos projetados e personalizar de acordo com suas necessidades de implantação, você pode modificar o número de unidades de escala e instâncias do Serviço de Aplicativo na Calculadora de Preços do Azure.

Da mesma forma, você pode encontrar as diretrizes de preços dos Ambientes do Serviço de Aplicativo.

Você pode configurar o preço do Application Gateway dependendo da camada e dos recursos necessários.

Eficiência de desempenho

Eficiência de desempenho é a capacidade da sua carga de trabalho para dimensionar para satisfazer as exigências que os utilizadores lhe colocam de forma eficiente. Para obter mais informações, consulte Visão geral do pilar de eficiência de desempenho.

Escalabilidade

Você pode expandir instâncias de Gerenciamento de API dependendo de vários fatores, como número e taxa de conexões simultâneas, tipo e número de políticas configuradas, tamanhos de solicitação e resposta e latências de back-end nas APIs. As opções de dimensionamento de instância estão disponíveis nas camadas Basic, Standard e Premium, mas estão limitadas por um limite de escala superior nas camadas Basic e Standard. As instâncias são chamadas de Unidades e podem ser dimensionadas até um máximo de duas unidades na camada Básica, quatro unidades na camada Standard e qualquer número de unidades na camada Premium. As opções de Auto Scaling também estão disponíveis para permitir o dimensionamento com base em regras.

Os Ambientes do Serviço de Aplicativo são projetados para escalar com limites baseados na camada de preço. Você pode configurar os aplicativos hospedados nos Ambientes do Serviço de Aplicativo para expandir (número de instâncias) ou aumentar (tamanho da instância), dependendo dos requisitos do aplicativo.

O dimensionamento automático do Gateway de Aplicativo do Azure está disponível como parte da SKU redundante de Zona em todas as regiões globais do Azure. Consulte o recurso de visualização pública sobre o Dimensionamento automático do gateway de aplicativo.

Implementar este cenário

Pré-requisitos e pressupostos

1. Você precisa comprar um nome de domínio personalizado.
2. Você precisa de um certificado TLS (usamos um certificado curinga do Serviço de Certificados do Azure) para usar um para todos os nossos domínios personalizados. Você também pode obter um certificado autoassinado para cenários de Teste de Desenvolvimento.
3. Essa implantação específica usa o contoso.org de nome de domínio e um certificado TLS curinga para o domínio.
4. A implantação usa os nomes de recursos e espaços de endereço mencionados na seção Implantação. Você pode configurar os nomes de recursos e espaços de endereço.

Implantação e montagem das peças

Você precisa configurar ainda mais os componentes implantados usando o modelo anterior do Gerenciador de Recursos da seguinte maneira:

1. VNet com as seguintes configurações:

   • Nome: ase-internal-vnet
   • Espaço de endereço para VNet: 10.0.0.0/16
   • Quatro sub-redes
     • backendSubnet para o serviço DNS: 10.0.0.0/24
     • apimsubnet para o Serviço de Gerenciamento de API Interno: 10.0.1.0/28
     • asesubnet para o ILB ASE: 10.0.2.0/24
     • VMSubnet para VMs de teste e VM de agente hospedado de DevOps interno: 10.0.3.0/24

2. Serviço DNS privado (Pré-visualização pública), uma vez que a adição de um serviço DNS requer que a rede virtual esteja vazia.

   • Consulte as diretrizes de implantação para obter mais informações

3. Ambiente do Serviço de Aplicativo com opção ILB (Balanceador de Carga Interno): aseinternal (DNS: aseinternal.contoso.org). Quando a implantação estiver concluída, carregue o certificado curinga para o ILB

4. Plano do Serviço de Aplicativo com ASE como local

5. Um aplicativo de API (Serviços de aplicativo para simplificar) - srasprest (URL: https://srasprest.contoso.org) - ASP.NET API da Web baseada em MVC (Model-View-Controller). Após a implantação, configure:

   • Aplicativo Web para usar o certificado TLS
   • Application Insights para os aplicativos anteriores: api-insights
   • Crie um serviço do Azure Cosmos DB para APIs Web hospedadas internamente na VNet: noderestapidb
   • Criar entradas DNS na zona DNS privada criada
   • Você pode usar os Pipelines do Azure para configurar os agentes em Máquinas Virtuais para implantar o código do Aplicativo Web na Rede interna
   • Para testar o aplicativo de API internamente, crie uma VM de teste na sub-rede VNet

6. Criar serviço de Gerenciamento de API: apim-internal

7. Configure o serviço para se conectar à rede virtual interna na sub-rede: apimsubnet. Após a conclusão da implantação, execute as seguintes etapas adicionais:

   • Configurar domínios personalizados para Serviços APIM usando TLS
     • Portal API (api.contoso.org)
     • Portal de desenvolvimento (portal.contoso.org)
     • Na seção APIs, configure os aplicativos ASE usando o nome DNS adicionado do ASE Política para cabeçalho HOST para o aplicativo Web
     • Use a VM de teste criada anteriormente para testar o serviço de Gerenciamento de API interno na Rede Virtual

   Nota

   Testar as APIs do APIM a partir do portal do Azure não funcionará, porque api.contoso.org não pode ser resolvido publicamente.*

8. Configure o Application Gateway para acessar o serviço de API: apim-gateway na porta 80. Adicione certificados TLS ao Application Gateway e às sondas de integridade e configurações HTTP correspondentes. Configure também as Regras e Ouvintes para usar o certificado TLS.

Quando as etapas anteriores forem concluídas com êxito, configure as entradas DNS nas entradas CNAME do registrador da Web de api.contoso.org e portal.contoso.org com o nome DNS público do Application Gateway: ase-appgtwy.westus.cloudapp.azure.com. Verifique se você consegue acessar o Portal de Desenvolvimento a partir de Público e se pode testar as APIs de serviços APIM usando o portal do Azure.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelo seguinte colaborador.

Autor principal:

• Srikant Sarwa - Brasil | Engenheiro de Clientes Sênior

Outros contribuidores:

• Shawn Kupfer - Brasil | Redator Técnico

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

• Tutorial: Importar e publicar a primeira API
• Tutorial: criar e publicar um produto
• Tutorial: publicar várias versões da sua API

Recursos relacionados

Migrar um aplicativo Web usando o Gerenciamento de API do Azure