Publicar APIs internas para utilizadores 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 das APIs internas que são consumidas pelos utilizadores externos.

Fluxo de dados

Os fluxos de dados são os seguintes:

1. Os programadores verificam o código num repositório do GitHub que está ligado a um agente de pipeline CI/CD instalado numa VM do Azure.
2. O agente envia a compilação para a aplicação de API alojada no ASE do ILB.
3. O Azure Gestão de API consome as APIs anteriores através de cabeçalhos HOST especificados na política de Gestão de API.
4. Gestão de API utiliza o nome DNS do Ambiente do Serviço de Aplicações para todas as APIs.
5. Gateway de Aplicação expõe o programador e o portal de API do Gestão de API.
6. O Azure DNS Privado é utilizado para encaminhar o tráfego internamente entre o ASE, Gestão de API e Gateway de Aplicação.
7. Os utilizadores externos utilizam o portal de programador exposto para consumir as APIs através do IP público do Gateway de Aplicação.

Componentes

• O Azure Rede Virtual permite que os recursos do Azure comuniquem entre si de forma segura, com a Internet e com as redes no local.
• O Azure DNS Privado permite que os nomes de domínio sejam resolvidos numa rede virtual sem ter de adicionar uma solução DNS personalizada.
• O Azure Gestão de API ajuda as organizações a publicar APIs em programadores externos, parceiros e internos para utilizarem os respetivos dados e serviços.
• Gateway de Aplicação é um balanceador de carga de tráfego Web que o ajuda a gerir o tráfego para as suas aplicações Web.
• A Ambiente do Serviço de Aplicações de Balanceador de Carga interna é uma funcionalidade Serviço de Aplicações do Azure que fornece um ambiente totalmente isolado e dedicado para executar aplicações Serviço de Aplicações em alta escala de forma segura .
• O Azure DevOps é um serviço para gerir o seu ciclo de vida de desenvolvimento e inclui funcionalidades de planeamento e gestão de projetos, gestão de códigos, compilação e lançamento.
• O Application Insights é um serviço extensível de Gestão de Desempenho de Aplicações (APM) para programadores Web em várias plataformas.
• O Azure Cosmos DB é o serviço de bases de dados multi-modelo distribuído globalmente pela Microsoft.

Alternativas

• Num cenário de lift-and-shift do Azure implementado num Rede Virtual do Azure, os servidores de back-end podem ser diretamente endereçados através de endereços IP privados.
• Se utilizar recursos no local, a instância Gestão de API pode voltar ao serviço interno em privado através de um gateway de VPN do Azure e de uma ligação VPN IPSec site a site ou do ExpressRoute, tornando um cenário híbrido do Azure e no local.
• Os fornecedores DNS existentes ou open-source podem ser utilizados em vez do Serviço DNS baseado no Azure.
• As APIs internas implementadas fora do Azure ainda podem beneficiar ao expor as APIs através do Gestão de API Service.

Detalhes do cenário

Neste cenário, uma organização aloja várias APIs com Aplicação Azure Service Environment (ASE ILB) e quer consolidar estas APIs internamente com o Azure Gestão de API (APIM) implementado dentro de um Rede Virtual. A instância de Gestão de API interna também pode ser exposta a utilizadores externos para permitir a utilização de todo o potencial das APIs. Esta exposição externa pode ser obtida com Gateway de Aplicação do Azure reencaminhar pedidos para o serviço de Gestão de API interno, que por sua vez consome as APIs implementadas no ASE.

• As APIs Web estão alojadas através do protocolo HTTPS protegido e irão utilizar um Certificado TLS.
• O Gateway de Aplicação também está configurado através da porta 443 para chamadas de saída seguras e fiáveis.
• O serviço Gestão de API está configurado para utilizar domínios personalizados com certificados TLS.
• Reveja a configuração de rede sugerida para ambientes de Serviço de Aplicações
• Tem de haver uma menção explícita sobre a porta 3443 que permita que Gestão de API faça a gestão através do portal do Azure ou do PowerShell.
• Tire partido das políticas no APIM para adicionar um cabeçalho HOST para a API alojada no ASE. Isto garante que o balanceador de carga do ASE irá reencaminhar corretamente o pedido.
• O Gestão de API aceita a entrada DNS do ASE para todas as aplicações alojadas em Ambientes Serviço de Aplicações. Adicione uma política APIM para definir explicitamente o cabeçalho HOST para permitir que o balanceador de carga do ASE diferencie entre Aplicações no Ambiente do Serviço de Aplicações.
• Considere Integrar com o Aplicação Azure Insights, que também apresenta métricas através do Azure Monitor para monitorização.
• Se utilizar pipelines CI/CD para implementar APIs Internas, considere criar o seu próprio Agente Alojado numa VM dentro do Rede Virtual.

Potenciais casos de utilização

• Sincronize as informações do endereço do cliente internamente depois de o cliente fazer uma alteração.
• Atraia programadores para a sua plataforma ao expor recursos de dados exclusivos.

Considerações

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

Fiabilidade

A fiabilidade garante que a sua aplicação pode cumprir os compromissos que assumiu com os seus clientes. Para obter mais informações, veja Descrição geral do pilar de fiabilidade."

Disponibilidade

Pode implementar o serviço Gestão de API do Azure como uma implementação de Várias Regiões para uma maior disponibilidade e também para reduzir as latências. Esta funcionalidade só está disponível no modo Premium. O serviço Gestão de API neste cenário específico consome APIs de Ambientes Serviço de Aplicações. Também pode utilizar a APIM para APIs alojadas na infraestrutura interna no local.

Serviço de Aplicações Ambientes poderia utilizar perfis do Gestor de Tráfego para distribuir o tráfego alojado em Ambientes Serviço de Aplicações para maior escala e disponibilidade.

Resiliência

Embora este cenário de exemplo fale mais sobre a configuração, as APIs alojadas no Serviço de Aplicações Ambientes devem ser suficientemente resilientes para lidar com erros nos pedidos, que são eventualmente geridos pelo serviço Gestão de API e Gateway de Aplicação. Considere repetir e padrões de disjuntor automático na estrutura da API. Para obter orientações gerais sobre a conceção de soluções resilientes, veja Estruturar aplicações resilientes para o Azure.

Segurança

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

Uma vez que o cenário de exemplo anterior está completamente alojado numa rede interna, Gestão de API e ASE já estão implementados na infraestrutura protegida (VNet do Azure). Pode integrar os Gateways de Aplicação com Microsoft Defender para a Cloud para fornecer uma forma totalmente integrada de prevenir, detetar e responder a ameaças ao ambiente. Para obter orientações gerais sobre a conceção de soluções seguras, veja a Documentação de Segurança do Azure.

Otimização de custos

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

Gestão de API é oferecido em quatro escalões: programador, básico, standard e premium. Pode encontrar orientações detalhadas sobre a diferença nestes escalões na documentação de orientação sobre preços do Azure Gestão de API aqui.

Os clientes podem dimensionar Gestão de API ao adicionar e remover unidades. Cada unidade tem capacidade que depende do escalão.

Para ver os custos projetados e personalizar as suas necessidades de implementação, pode modificar o número de unidades de escala e Serviço de Aplicações instâncias na Calculadora de Preços do Azure.

Da mesma forma, pode encontrar a documentação de orientação de preços Serviço de Aplicações Ambientes.

Pode configurar Gateway de Aplicação preços consoante o escalão e os 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, veja Descrição geral do pilar Eficiência do desempenho.

Escalabilidade

Pode aumentar horizontalmente Gestão de API instâncias consoante vários fatores, como número e taxa de ligações simultâneas, o tipo e o número de políticas configuradas, tamanhos de pedidos e respostas e latências de back-end nas APIs. As opções de escalamento horizontal de instâncias estão disponíveis em Escalões Básico, Standard e Premium, mas estão vinculadas por um limite de dimensionamento superior nos escalões Básico e Standard. As instâncias são denominadas Unidades e podem ser aumentadas verticalmente para um máximo de duas unidades no escalão Básico, quatro unidades no escalão Standard e qualquer número de unidades no escalão Premium. As opções de Dimensionamento Automático também estão disponíveis para ativar o aumento horizontal com base nas regras.

Serviço de Aplicações Ambientes foram concebidos para dimensionamento com limites com base no escalão de preço. Pode configurar as aplicações alojadas no Serviço de Aplicações Ambientes para aumentar horizontalmente (número de instâncias) ou aumentar verticalmente (tamanho da instância) consoante os requisitos da aplicação.

Gateway de Aplicação do Azure dimensionamento automático está disponível como parte do SKU com redundância entre zonas em todas as regiões globais do Azure. Veja a funcionalidade de pré-visualização pública relativa ao dimensionamento automático do Gateway de Aplicação.

Implementar este cenário

Pré-requisitos e pressupostos

1. Tem de comprar um nome de domínio personalizado.
2. Precisa de um certificado TLS (utilizámos um certificado universal do Azure Certificates Service) para utilizar um para todos os nossos domínios personalizados. Também pode obter um certificado autoassinado para cenários de Dev Test.
3. Esta implementação específica utiliza o nome de domínio contoso.org e um certificado TLS de caráter universal para o domínio.
4. A implementação utiliza os nomes de recursos e os espaços de endereços mencionados na secção Implementação. Pode configurar os nomes de recursos e os espaços de endereços.

Implementação e colocação das peças em conjunto

Tem de configurar ainda mais os componentes implementados com o modelo de Resource Manager anterior da seguinte forma:

1. VNet com as seguintes configurações:

   • Nome: ase-internal-vnet
   • Espaço de endereços da VNet: 10.0.0.0/16
   • Quatro Sub-redes
     • backendSubnet para o Serviço DNS: 10.0.0.0/24
     • apimsubnetpara Serviço de Gestão de API Interno: 10.0.1.0/28
     • asesubnet para ASE de ILB: 10.0.2.0/24
     • VMSubnet para VMs de Teste e VM do Agente Alojado de DevOps Interno: 10.0.3.0/24

2. DNS Privado serviço (Pré-visualização Pública) uma vez que adicionar um serviço DNS requer que a VNet esteja vazia.

   • Veja as diretrizes de implementação para obter mais informações

3. Ambiente do Serviço de Aplicações com a opção aseinternal Balanceador de Carga Interno (ILB): (DNS: aseinternal.contoso.org). Assim que a Implementação estiver concluída, carregue o certificado wild-card para o ILB

4. Serviço de Aplicações Plano com o ASE como localização

5. Uma Aplicação API (Serviços aplicacionais para simplicidade) – srasprest (URL: https://srasprest.contoso.org) – ASP.NET API Web baseada em MVC. Após a implementação, configure:

   • Aplicação Web para utilizar o certificado TLS
   • Application Insights para as aplicações anteriores: api-insights
   • Crie um serviço do Azure Cosmos DB para APIs Web alojadas internamente na VNet: noderestapidb
   • Criar entradas DNS na zona de DNS Privado criada
   • Pode utilizar os Pipelines do Azure para configurar os agentes no Máquinas Virtuais para implementar o código da Aplicação Web na Rede interna
   • Para testar a Aplicação API internamente, crie uma VM de teste na sub-rede da VNet

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

7. Configure o serviço para ligar à VNet interna na Sub-rede: apimsubnet. Após a conclusão da implementação, execute os seguintes passos adicionais:

   • Configurar domínios personalizados para Serviços APIM com O TLS
     • Portal da API (api.contoso.org)
     • Portal de Desenvolvimento (portal.contoso.org)
     • Na secção APIs, configure as Aplicações ASE com o nome DNS do ASE adicionado Política para Cabeçalho ANFITRIÃO para a aplicação Web
     • Utilize a VM de teste criada anterior para testar o serviço de Gestão de API interno no Rede Virtual

   Nota

   Testar as APIs da APIM a partir do portal do Azure não funcionará, porque api.contoso.org não é possível resolver publicamente.*

8. Configure o Gateway de Aplicação (WAF V1) para aceder ao serviço de API: apim-gateway na Porta 80. Adicione certificados TLS ao Gateway de Aplicação e às sondas de estado de funcionamento correspondentes e às definições de http. Configure também as Regras e os Serviços de Escuta para utilizar o certificado TLS.

Assim que os passos anteriores forem concluídos com êxito, configure as entradas DNS nas entradas CNAME da entidade de registo Web de api.contoso.org e portal.contoso.org com o nome DNS público do Gateway de Aplicação: ase-appgtwy.westus.cloudapp.azure.com. Verifique se consegue aceder ao Portal de Programador a partir de Público e se consegue testar as APIs de serviços da APIM com o portal do Azure.

Contribuidores

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

Autor principal:

• Srikant Sarwa | Engenheiro De Clientes Sénior

Outros contribuidores:

• Shawn Kupfer | Escritor Técnico

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

Passos seguintes

• 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 uma aplicação Web com o Azure Gestão de API