Editar

Partilhar via


Publicar APIs internas para usuários externos

Azure API Management
Azure Application Gateway
Azure DevOps
Azure Monitor
Azure Virtual Network

Nesse cenário, uma organização consolida várias APIs internamente usando o Gerenciamento de API do Azure implantado em 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.

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 App Service Environment.
  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 do Gerenciamento de API e o portal da API.
  6. O DNS Privado do Azure é usado para rotear o tráfego internamente entre o Ambiente do Serviço de Aplicativo, o Gerenciamento de API e o 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 do Serviço de Aplicativo do Azure (Ambiente do Serviço de Aplicativo ILB) 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 obtida usando o Gateway de Aplicativo do Azure encaminhando solicitações para o serviço de Gerenciamento de API interno, que, por sua vez, consome as APIs implantadas no Ambiente do Serviço de Aplicativo.

  • As APIs da Web são hospedadas pelo 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.
  • 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.
  • Use políticas dentro do APIM para adicionar um cabeçalho HOST para a API hospedada no Ambiente do Serviço de Aplicativo. Isso garante que o balanceador de carga do Ambiente do Serviço de Aplicativo encaminhará corretamente a solicitação.
  • O Gerenciamento de API aceita a entrada DNS do Ambiente do Serviço de Aplicativo 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 do Ambiente do Serviço de Aplicativo 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 Hosted Agent 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 Ambiente do Serviço de Aplicativo já estão implantados na infraestrutura segura (Rede Virtual do Azure). 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.

Nota

Você pode usar a camada de desenvolvedor para avaliar os recursos de gerenciamento de API. Você não deve usar a camada de desenvolvedor para produçã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

Implementar no Azure

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

  1. Rede virtual com as seguintes configurações:

    • Nome: ase-internal-vnet
    • Espaço de endereço para rede virtual: 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 ILB App Service Environment: 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 o Ambiente do Serviço de Aplicativo como local

  5. Um aplicativo de API (Serviço 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 à rede virtual: noderestapidb
    • Criar entradas DNS na zona DNS privada do Azure 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 de rede virtual
  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 do Ambiente do Serviço de Aplicativo usando o Nome DNS do Ambiente do Serviço de Aplicativo adicionado 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 gateway de aplicativo para acessar o serviço de API: apim-gateway na porta 80. Adicione certificados TLS ao gateway de aplicativo 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 e portal.contoso.org com o nome DNS público do api.contoso.org 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.

Nota

Não é uma boa prática usar a mesma URL para pontos de extremidade internos e externos para os serviços APIM.

Contribuidores

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

Autor principal:

Outros contribuidores:

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

Próximos passos

Migrar um aplicativo Web usando o Gerenciamento de API do Azure