In questo scenario, un'organizzazione ha ospitato più API usando applicazione Azure Service Environment (AMBIENTE del servizio di bilanciamento del carico interno) e vuole consolidare queste API internamente, usando Azure Gestione API (APIM) distribuito all'interno di un Rete virtuale. L'istanza interna di Gestione API potrebbe anche essere esposta agli utenti esterni per consentire l'utilizzo del potenziale completo delle API. Questa esposizione esterna può essere ottenuta usando gateway applicazione di Azure l'inoltro delle richieste al servizio Gestione API interno, che a sua volta utilizza le API distribuite nell'ambiente del servizio app.
Potenziali casi d'uso
- Sincronizzare le informazioni sull'indirizzo del cliente internamente dopo una modifica apportata dal cliente.
- Attirare gli sviluppatori alla piattaforma esponendo asset di dati univoci.
Architettura
Scaricare un file di Visio di questa architettura.
Lo scenario precedente illustra un ciclo di vita completo delle API interne utilizzate dagli utenti esterni.
Flusso di dati
Il flusso di dati è il seguente:
- Gli sviluppatori archiviano il codice in un repository GitHub connesso a un agente della pipeline CI/CD installato in una macchina virtuale di Azure.
- L'agente esegue il push della compilazione nell'applicazione API ospitata nell'ambiente del servizio app con bilanciamento del carico interno.
- Azure Gestione API usa le API precedenti tramite intestazioni HOST specificate nei criteri di Gestione API.
- Gestione API usa il nome DNS del ambiente del servizio app per tutte le API.
- gateway applicazione espone lo sviluppatore e il portale API di Gestione API.
- Azure DNS privato viene usato per instradare il traffico internamente tra ambiente del servizio app, Gestione API e gateway applicazione.
- Gli utenti esterni usano il portale per sviluppatori esposto per usare le API tramite l'indirizzo IP pubblico di gateway applicazione.
Componenti
- La rete virtuale di Azure consente alle risorse di Azure di comunicare in modo sicuro tra loro, con Internet e con le reti locali.
- DNS privato di Azure consente di risolvere i nomi di dominio in una rete virtuale senza dover aggiungere una soluzione DNS personalizzata.
- Gestione API di Azure consente alle organizzazioni di pubblicare API per consentire a sviluppatori esterni, partner e interni di usare i rispettivi dati e servizi.
- Il gateway applicazione è un servizio di bilanciamento del carico del traffico Web che consente di gestire il traffico verso le applicazioni Web.
- L'ambiente del servizio app del servizio di bilanciamento del carico interno è una funzionalità del servizio app di Azure che fornisce un ambiente completamente isolato e dedicato per l'esecuzione sicura di app del servizio app di Azure su larga scala.
- Azure DevOps è un servizio per gestire il ciclo di vita dello sviluppo e include funzionalità per la pianificazione e la gestione dei progetti, la gestione del codice, la compilazione e il rilascio.
- Application Insights è un servizio estendibile di gestione delle prestazioni delle applicazioni per sviluppatori Web su più piattaforme,
- Azure Cosmos DB è il servizio di database di Microsoft multimodello distribuito a livello globale.
Alternativi
- In uno scenario in modalità lift-and-shift di Azure distribuito in una rete virtuale di Azure i server back-end potrebbero essere gestiti direttamente tramite indirizzi IP privati.
- Se si usano risorse locali l'istanza di Gestione API potrebbe raggiungere il servizio interno privatamente tramite un gateway VPN di Azure e una connessione VPN IPSec da sito a sito o tramite ExpressRoute creando uno scenario locale e di Azure ibrido.
- È possibile usare provider DNS open source o esistenti invece del servizio DNS basato su Azure.
- Le API interne distribuite all'esterno di Azure possono comunque trarre vantaggio dall'esposizione delle API tramite il servizio Gestione API.
Considerazioni
- Le API Web sono ospitate tramite il protocollo HTTPS protetto e usano un certificato TLS.
- Il gateway applicazione viene configurato anche sulla porta 443 per garantire chiamate in uscita protette e affidabili.
- Il servizio Gestione API è configurato per l'uso di domini personalizzati tramite certificati TLS.
- Esaminare la configurazione di rete consigliata per Ambienti del servizio app
- È necessario menzionare in modo esplicito la porta 3443 consentendo a Gestione API di gestire tramite il portale di Azure o PowerShell.
- Sfruttare i criteri all'interno di Gestione API di Azure per aggiungere un'intestazione HOST per l'API ospitata nell'ambiente del servizio app. In questo modo il servizio di bilanciamento del carico dell'ambiente del servizio app inoltrerà correttamente la richiesta.
- Gestione API accetta la voce DNS dell'ambiente del servizio app per tutte le app ospitate in Ambienti del servizio app. Aggiungere un criterio di Gestione API per impostare in modo esplicito l'intestazione HOST per consentire al servizio di bilanciamento del carico dell'ambiente del servizio app di distinguere tra le app nel ambiente del servizio app.
- Considerare l'integrazione con Azure Application Insights, che espone le metriche tramite Monitoraggio di Azure per il monitoraggio.
- Se si usano pipeline CI/CD per la distribuzione di API interne, è consigliabile creare un proprio agente ospitato in una macchina virtuale all'interno del Rete virtuale.
Disponibilità
Il servizio Gestione API di Azure può essere distribuito come distribuzione tra più aree per garantire una maggiore disponibilità nonché per ridurre le latenze. Questa funzionalità è disponibile solo in modalità Premium. Il servizio Gestione API in questo scenario specifico utilizza le API di Ambienti del servizio app. È anche possibile usare Gestione API di Azure per le API ospitate nell'infrastruttura locale interna.
Ambienti del servizio app può usare i profili di Gestione traffico per distribuire il traffico ospitato in Ambienti del servizio app per una maggiore scalabilità e disponibilità.
Scalabilità
È possibile ridurre il numero di istanze di Gestione API in base a diversi fattori, tra cui numero e velocità delle connessioni simultanee, tipologia e numero dei criteri configurati, dimensioni di richieste e risposte e latenze back-end nelle API. Le opzioni per l'aumento del numero di istanze sono disponibili nei livelli Basic, Standard e Premium, ma sono vincolate da un limite di scalabilità superiore nei livelli inferiori a quello Premium. Le istanze vengono definite unità ed è possibile aumentarne il numero fino a un massimo di due nel livello Basic, quattro nel livello Standard e qualsiasi numero nel livello Premium. Sono disponibili anche opzioni di Dimensionamento automatico per consentire l'aumento del numero di istanze in base a regole.
Ambienti del servizio app è progettato per la scalabilità e prevede limiti basati sul piano tariffario. Le app ospitate in Ambienti del servizio app possono essere configurate per l'aumento del numero di istanze o delle dimensioni dell'istanza a seconda dei requisiti dell'applicazione.
Il dimensionamento automatico del gateway applicazione di Azure è incluso nello SKU con ridondanza della zona in tutte le aree di Azure globali. Vedere la funzionalità di anteprima pubblica per informazioni sul dimensionamento automatico del gateway applicazione.
Sicurezza
Dal momento che lo scenario di esempio precedente è ospitato completamente in una rete interna, Gestione API e l'ambiente del servizio app sono già distribuiti nell'infrastruttura protetta (rete virtuale di Azure). È possibile integrare i gateway applicazione con Microsoft Defender for Cloud come semplice soluzione per prevenire e rilevare le minacce all'ambiente e rispondervi. Per indicazioni di carattere generale sulla progettazione di soluzioni sicure, vedere la documentazione sulla sicurezza di Azure.
Resilienza
Questo scenario di esempio è tuttavia incentrato maggiormente sulla configurazione. Le API ospitate in Ambienti del servizio app devono essere sufficientemente resilienti da gestire gli errori presenti nelle richieste, che alla fine vengono gestite dal servizio Gestione API e dal gateway applicazione. Prendere in considerazione i modelli di ripetizione dei tentativi e Interruttore nella progettazione dell'API. Per indicazioni generali sulla progettazione di soluzioni resilienti, vedere Progettazione di applicazioni resilienti per Azure.
Ottimizzazione dei costi
Gestione API è disponibile in quattro livelli: Developer, Basic, Standard e Premium. È possibile trovare indicazioni dettagliate sulla differenza tra questi livelli nella guida ai prezzi di Gestione API di Azure.
I clienti possono sfruttare la scalabilità di Gestione API aggiungendo o rimuovendo unità. La capacità di ogni unità dipende dal livello.
Nota
Il livello Developer è utilizzabile per la valutazione delle funzionalità di Gestione API. Il livello Developer non deve essere usato per la produzione.
Per visualizzare i costi previsti ed eseguire la personalizzazione in base alle specifiche esigenze di distribuzione, è possibile modificare il numero di unità di scala e di istanze del servizio app nel calcolatore dei prezzi di Azure.
Analogamente, le indicazioni relative ai prezzi di Ambienti del servizio app sono disponibili qui.
È possibile configurare qui i prezzi del gateway applicazione a seconda del livello e delle risorse necessarie.
Distribuire lo scenario
Prerequisiti e presupposti
- Sarà necessario acquistare un nome di dominio personalizzato.
- Un certificato TLS (ne è stato usato uno basato su caratteri jolly del servizio Certificati di Azure) per usarne uno per tutti i domini personalizzati. È anche possibile ottenere un certificato autofirmato per gli scenari di sviluppo/test.
- Per questa specifica distribuzione viene usato il nome di dominio contoso.org e un certificato TLS basato su caratteri jolly per il dominio.
- La distribuzione usa i nomi di risorse e gli spazi degli indirizzi menzionati nella sezione relativa alla distribuzione, che possono essere configurati.
Distribuzione e combinazione dei componenti
I componenti distribuiti con il modello di Resource Manager devono essere ulteriormente configurati come indicato di seguito.
Rete virtuale con le configurazioni seguenti:
- Nome:
ase-internal-vnet
- Spazio indirizzi per la rete virtuale: 10.0.0.0/16
- Quattro subnet
backendSubnet
per il servizio DNS: 10.0.0.0/24apimsubnet
per il servizio Gestione API interno: 10.0.1.0/28asesubnet
per l'ambiente del servizio app ILB: 10.0.2.0/24- Subnet di macchina virtuale per macchine virtuale di test e macchina virtuale dell'agente ospitato DevOps interna: 10.0.3.0/24
- Nome:
Servizio DNS privato (anteprima pubblica) dal momento che se si aggiunge un servizio DNS, la rete virtuale deve essere vuota.
- Per altre informazioni, vedere le indicazioni per la distribuzione
Ambiente del servizio app con opzione per il servizio di bilanciamento del carico interno (ILB):
aseinternal
(DNS:aseinternal.contoso.org
). Al termine della distribuzione, caricare il certificato basato su caratteri jolly per il servizio di bilanciamento del carico internoPiano di servizio app la cui località è l'ambiente del servizio app
Un'app per le API (Servizi app per semplicità):
srasprest
(URL:https://srasprest.contoso.org
) - API Web basata su MVC ASP.NET. Dopo la distribuzione configurare:- App Web per l'uso del certificato TLS
- Applicazione Insights per le app precedenti: api-insights
- Creare un servizio Azure Cosmos DB per le API Web ospitate interne alla rete virtuale:
noderestapidb
- Creare voci DNS nella zona DNS privato creata
- È possibile usare Azure Pipelines per configurare gli agenti nelle macchine virtuali e distribuire il codice per l'app Web nella rete interna
- Per testare l'app per le API internamente, creare una macchina virtuale di test all'interno della subnet della rete virtuale
Creare il servizio Gestione API:
apim-internal
Configurare il servizio per la connessione alla rete virtuale interna nella subnet:
apimsubnet
. Al termine della distribuzione, eseguire questi passaggi aggiuntivi:- Configurare domini personalizzati per i servizi di Gestione API di Azure tramite TLS
- Portale API (api.contoso.org)
- Portale per sviluppatori (portal.contoso.org)
- Nella sezione delle API configurare le app dell'ambiente del servizio app usando il criterio del nome DNS dell'ambiente del servizio app aggiunto per l'intestazione HOST relativa all'app Web
- Usare la macchina virtuale di test creata in precedenza per testare il servizio Gestione API interno nella rete virtuale
Nota
Il test delle API di Gestione API di Azure dal portale di Azure non funzionerà comunque perché api.contoso.org non può essere risolto pubblicamente.*
- Configurare domini personalizzati per i servizi di Gestione API di Azure tramite TLS
Configurare il gateway applicazione (WAF V1) per accedere al servizio API apim-gateway sulla porta 80. Aggiungere i certificati TLS al gateway app, nonché i probe di integrità e le impostazioni HTTP corrispondenti. Configurare anche le regole e i listener per l'uso del certificato TLS.
Dopo aver completato i passaggi precedenti, configurare le voci DNS nelle voci CNAME GoDaddy di api.contoso.org e portal.contoso.org con il nome DNS pubblico del gateway app ase-appgtwy.westus.cloudapp.azure.com
e verificare se è possibile raggiungere il portale per sviluppatori dal livello Pubblico e testare le API dei servizi di Gestione API di Azure usando portale di Azure.
È consigliabile non usare lo stesso URL per gli endpoint interni ed esterni per i servizi di Gestione API (attualmente nella demo precedente entrambi gli URL sono uguali). Se si preferisce avere URL diversi per gli endpoint interni ed esterni, è possibile usare WAF v2 del gateway applicazione, che supporta il reindirizzamento HTTP e molto altro ancora.
Passaggi successivi
- Esercitazione: Importare e pubblicare la prima API
- Esercitazione: Creare e pubblicare un prodotto
- Esercitazione: Pubblicare più versioni dell'API
Risorse correlate
Vedere lo scenario correlato in Eseguire la migrazione di un'app Web con Gestione API di Azure