Publicar APIs internas para usuários externos

Gerenciamento de API
Gateway de Aplicativo
Azure DevOps
Monitor
Rede Virtual

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

Diagrama de arquitetura que mostra o ciclo de vida completo das APIs internas que são consumidas pelos usuários externos.

Baixe um Arquivo Visio dessa arquitetura.

O diagrama anterior aborda 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 marcar em código para um repositório GitHub conectado a um agente de pipeline de CI/CD instalado em uma VM do Azure.
  2. O agente envia por push o build para o aplicativo de API hospedado no ASE ILB.
  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. Gerenciamento de API usa o nome DNS do Ambiente do Serviço de Aplicativo para todas as APIs.
  5. Gateway de Aplicativo expõe o desenvolvedor e o portal de API do Gerenciamento de API.
  6. O DNS privado do Azure é usado para rotear o tráfego internamente entre ASE, Gerenciamento de API e Gateway de Aplicativo.
  7. Usuários externos utilizam o portal do desenvolvedor exposto para consumir as APIs por meio 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.
  • Gateway de Aplicativo é 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 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 (Ambiente de Serviço Aplicativo Azure) e deseja consolidar essas APIs internamente usando o Azure Gerenciamento de API (APIM) implantado dentro de um 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 Gateway de Aplicativo do Azure solicitações de encaminhamento 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 APIM para definir explicitamente o cabeçalho HOST para permitir que o balanceador de carga do ASE diferencie entre aplicativos sob o 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ê usar pipelines de CI/CD para implantar APIs internas, considere criar seu próprio Agente Hospedado em uma VM dentro do 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 serviço Gerenciamento de API do Azure como uma implantação de várias regiões para maior disponibilidade e também para reduzir as 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. Você também pode usar o APIM para APIs hospedadas na infraestrutura local interna.

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

Embora este cenário de exemplo fale mais sobre a configuração, as APIs hospedadas no Serviço de Aplicativo Environments devem ser resilientes o suficiente para lidar com erros nas solicitações, que eventualmente são gerenciadas pelo serviço Gerenciamento de API e 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, Gerenciamento de API e ASE já estão implantados na infraestrutura protegida (VNet do Azure). Você pode integrar os Gateways de Aplicativo ao Microsoft Defender para Nuvem para fornecer uma maneira perfeita de prevenir, detectar e responder a ameaças ao ambiente. Para obter diretrizes gerais sobre como criar soluções seguras, confira a 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.

Observação

Você pode usar a camada Desenvolvedor para avaliação dos recursos de Gerenciamento de API. Você não deve usar a camada Desenvolvedor para produção.

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, você pode encontrar as diretrizes de preços dos Ambientes de Serviço de Aplicativo.

Você pode configurar Gateway de Aplicativo preços 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 horizontalmente Gerenciamento de API instâncias dependendo de vários fatores, como número e taxa de conexões simultâneas, o tipo e o número de políticas configuradas, tamanhos de solicitação e resposta e latências de back-end nas APIs. As opções de instância de expansão estão disponíveis nas Camadas Básica, Standard e Premium, mas estão associadas a um limite de escala superior nas camadas Basic e Standard. 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.

Serviço de Aplicativo Ambientes são projetados para escala com limites com base no tipo de preço. Você pode configurar os aplicativos hospedados nos Ambientes Serviço de Aplicativo para escalar horizontalmente (número de instâncias) ou escalar verticalmente (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 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 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 os 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

Implantar no Azure

Você precisa configurar ainda mais os componentes implantados usando o modelo de Resource Manager anterior 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.

  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 para os aplicativos anteriores: api-insights
    • Crie um serviço do Azure Cosmos DB para APIs Web hospedadas internas na VNet: noderestapidb
    • Criar entradas de DNS na zona de DNS privado criadas
    • Você pode usar o Azure Pipelines para configurar os agentes no 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 da VNet
  6. Criar Gerenciamento de API serviço: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 seguintes etapas adicionais:

    • 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 anteriormente para testar o serviço de Gerenciamento de API interno no Rede Virtual

    Observação

    Testar as APIs apim do portal do Azure não funcionará, pois api.contoso.org não é capaz de ser resolvido publicamente.*

  8. Configure o Gateway de Aplicativo (WAF V1) para acessar o serviço de API: apim-gateway na Porta 80. Adicione certificados TLS ao Gateway de Aplicativo e às investigações de integridade e às 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 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ê consegue acessar o Portal de Desenvolvimento do Public e se consegue testar as APIs de serviços APIM usando o portal do Azure.

Observação

Não é uma boa prática usar a mesma URL para pontos de extremidade internos e externos para os serviços APIM (embora nesta demonstração, ambas as URLs sejam as mesmas). Se você optar por ter URLs diferentes para pontos de extremidade internos e externos, poderá usar Gateway de Aplicativo WAF v2, que dá suporte ao redirecionamento http e muito mais.

Colaboradores

Esse artigo é mantido pela Microsoft. Foi originalmente escrito pelo contribuidor a seguir.

Autor principal:

Outros colaboradores:

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

Próximas etapas

Migrar um aplicativo Web usando o Azure Gerenciamento de API