Publicar APIs internas para usuários externos

Neste cenário, uma organização consolida várias APIs internamente usando o Gerenciamento de API do Azure implantado dentro de uma Rede Virtual.

Arquitetura

Baixe um Arquivo Visio dessa arquitetura.

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

Fluxo de dados

O fluxo de dados é o seguinte:

1. Os desenvolvedores verificam o código em um repositório de GitHub conectado ao 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 Gateway de Aplicativo expõe o desenvolvimento do Gerenciamento de API e o portal da API.
6. O DNS privado do Azure é usado para rotear o tráfego internamente entre o ASE, o Gerenciamento de API e o Gateway de Aplicativo.
7. Os usuários externos utilizam o portal do desenvolvedor exposto para consumir as APIs através do IP público do Gateway de Aplicativo.

Componentes

• A Rede Virtual do Microsoft Azure permite que os recursos do Azure se comuniquem com segurança entre si, com a Internet e com redes locais.
• O Azure DNS privado permite que os nomes de domínio sejam resolvidos em uma rede virtual sem a necessidade de adicionar uma solução de DNS personalizada.
• O Gerenciamento de API do Azure ajuda as organizações a publicar APIs para parceiros externos e desenvolvedores internos para usar seus dados e serviços.
• O Gateway de Aplicativo é um balanceador de carga do 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 a executar com segurança os aplicativos do Serviço de Aplicativo em maior 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 APM (Gerenciamento de Desempenho de Aplicativos) extensível para desenvolvedores da Web em várias plataformas.
• O Azure Cosmos DB é o serviço de banco de dados de vários modelos distribuído globalmente da Microsoft.

Alternativas

• Em um cenário de comparação de precisão e deslocamento do Azure implantado em uma rede virtual do Azure, os servidores de back-end podem ser diretamente endereçados 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 modo privado por meio de um Gateway de VPN do Azure e da conexão VPN IPSec de site a site ou do ExpressRoute criando um cenário híbrido Azure e local.
• Provedores DNS existentes ou de software livre 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 ILB ASE (Ambientes de Serviço de Aplicativo) e gostaria de consolidar essas APIs internamente usando o APIM (Gerenciamento de API do Azure) implantado dentro de uma rede virtual. A instância interna do Gerenciamento de API também pode ser exposta a usuários externos para permitir a utilização do potencial total das APIs. Essa exposição externa pode ser obtida usando uma solicitação de encaminhamento de Gateway de Aplicativo do Azure para o serviço de Gerenciamento de API interno, que, por sua vez, consome as APIs implantadas no ASE.

• As APIs da Web são hospedadas sobre o protocolo HTTPS seguro e usarão um certificado TLS.
• O Gateway de Aplicativo 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.
• Examinar a configuração de rede sugerida para Ambiente do Serviço de Aplicativo
• Deve haver uma menção explícita sobre a porta 3443, permitindo que o Gerenciamento de API seja gerenciado por meio do portal do Azure ou do PowerShell.
• Aproveite as políticas no APIM para adicionar um cabeçalho de HOST para a API hospedada no ASE. Isso garante que o balanceador de carga do ASE encaminhará corretamente a solicitação.
• O Gerenciamento de API aceita a entrada DNS do ASE para todos os aplicativos hospedados em Ambientes do Serviço do Aplicativo. Adicione uma política de APIM para definir explicitamente o cabeçalho do host para permitir que o balanceador de carga do ASE diferencie os aplicativos no Ambiente do Serviço de Aplicativo.
• Considere a Integração com o Azure Application Insights, que também exibe as métricas para monitoramento por meio do Azure Monitor.
• Se você usa pipelines de CI/CD para implantar APIs internas, considere criar seu próprio agente hospedado em uma VM dentro da Rede Virtual.

Possíveis casos de uso

• 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 de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Confiabilidade

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

Disponibilidade

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

Os Ambiente do Serviço de Aplicativo podem usar perfis de Gerenciador de Tráfego para distribuir o tráfego hospedado em Ambiente do Serviço de Aplicativo do Azure para maior escala e disponibilidade.

Resiliência

Mas este cenário de exemplo, embora se comunique mais sobre a 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 Gateway de Aplicativo. Considere os padrões de Repetição e Disjuntor no design da API. Para obter diretrizes gerais sobre como criar soluções resilientes, confira Projetando aplicativos resilientes para o Azure.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira 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 (VNet do Azure). Você pode integrar Gateways de Aplicativo com o Microsoft Defender para Nuvem para fornecer uma maneira simples de prevenir, detectar e responder a ameaças ao ambiente. Confira orientações gerais sobre como criar soluções seguras na Documentação de Segurança do Azure.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

O Gerenciamento de API é fornecido em quatro camadas: desenvolvedor, básica, standard e premium. Você pode encontrar orientações detalhadas sobre a diferença dos níveis aqui nas diretrizes de preços de Gerenciamento de API do Azure.

Os clientes podem escalonar o Gerenciamento de API adicionando e removendo unidades. Cada unidade tem capacidades que dependem de sua camada.

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

Da mesma forma, as diretrizes de preços dos Ambientes do Serviço de Aplicativo são fornecidas aqui

Você pode configurar os preços do Gateway de Aplicativo dependendo da camada e dos recursos necessários.

Eficiência de desempenho

A eficiência do desempenho é a capacidade de dimensionar sua carga de trabalho para atender às demandas colocadas por usuários de maneira eficiente. Para saber mais, confira Visão geral do pilar de eficiência de desempenho.

Escalabilidade

Você pode escalar 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 expansão de instância estão disponíveis nas camadas Básica, Standard e Premium, mas estão associadas a um limite de escala superior em camadas Básico e Padrão. As instâncias são conhecidas como unidades e podem ser escaladas horizontalmente para até um máximo de duas unidades na camada Básica, quatro unidades na camada Standard e qualquer número de unidades na camada de Premium. As opções de escala automática também estão disponíveis para habilitar o escalar horizontalmente com base em regras.

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

A escala automática do Gateway de Aplicativo Azure está disponível como parte do SKU com redundância de zona em todas as regiões globais do Azure. Consulte o recurso de visualização pública sobre o escala automática do gateway de aplicativo.

Implantar este cenário

Pré-requisitos e suposições

1. Você precisa adquirir 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 adquirir um certificado autoassinado para cenários de teste de desenvolvimento.
3. Essa implantação específica usa o nome de domínio contoso.org 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 os espaços de endereço.

Implantação e colocação das peças juntas

Você precisa configurar ainda mais os componentes implantados usando o modelo anterior do Resource Manager da seguinte maneira:

1. VNet com as seguintes configurações:

   • Nome: ase-internal-vnet
   • Espaço de endereço para a VNet: 10.0.0.0/16
   • Quatro sub-redes
     • backendSubnet para 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 ILB ASE: 10.0.2.0/24
     • VMSubnet para VMs de teste e VM de agente hospedado DevOps interno: 10.0.3.0/24

2. O serviço de DNS privado (visualização pública) desde a adição de um serviço DNS requer que a VNet esteja vazia.

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

3. Ambiente do Serviço de Aplicativo com opção de ILB (Load Balancer interno): aseinternal (DNS: aseinternal.contoso.org). Depois que a implantação for 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 aplicativos para simplificação) - srasprest (URL: https://srasprest.contoso.org ) – ASP.NET API da web baseada em MVC. Após a implantação, configure:

   • Aplicativo Web para usar o certificado TLS
   • Application Insights aos aplicativos acima: api-insights
   • Criar um serviço de Azure Cosmos DB para APIs web hospedadas internamente na VNet: noderestapidb
   • Criar entradas de DNS na zona de DNS privado criadas
   • É possível fazer uso de Azure Pipelines para configurar os agentes em máquinas virtuais para implantar o código para o aplicativo Web na rede interna
   • Para testar o Aplicativo de API internamente, crie uma VM de teste na sub-rede da VNet

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

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

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

   Observação

   O teste das APIs do APIM no portal do Azure não funcionará, pois api.contoso.org não poderá ser resolvido publicamente.*

8. Configure o Gateway de Aplicativo (WAF V1) para acessar o serviço de API: apim-gateway na Porta 80. Adicione os certificados TLS ao Gateway de Aplicativo e investigação de Integridade e configurações Http correspondentes. Configure também as Regras e Ouvintes para usar o certificado TLS.

Depois que 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 Gateway de Aplicativo: ase-appgtwy.westus.cloudapp.azure.com. Verifique se você é capaz de acessar o Portal de Desenvolvimento a partir do Público e se você é capaz de testar as APIs de serviços APIM usando o portal do Azure.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi escrito originalmente pelos colaboradores a seguir.

Autor principal:

• Srikant Sarwa | Engenheiro de Clientes Sênior

Outros colaboradores:

• Shawn Kupfer | Redator Técnico

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

Próximas etapas

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

Recursos relacionados

Migrar um aplicativo Web com o Gerenciamento de API do Azure