Creare e usare un ambiente del servizio app con bilanciamento del carico interno

  • Articolo

Importante

Questo articolo riguarda l'ambiente del servizio app v2, usato con i piani del servizio app Isolato. L'ambiente del servizio app v1 e v2 è stato ritirato il 31 agosto 2024. È disponibile una nuova versione dell'ambiente del servizio app più facile da usare, che viene eseguita in un'infrastruttura più potente. Per altre informazioni sulla nuova versione, vedere Introduzione all'ambiente del servizio app. Se al momento si usa l'ambiente del servizio app v1, seguire la procedura descritta in questo articolo per eseguire la migrazione alla nuova versione.

A partire dal 31 agosto 2024, il Contratto di servizio e i crediti di servizio non si applicano più ai carichi di lavoro dell'ambiente del servizio app v1 e v2 che continuano a essere in produzione, perché sono prodotti ritirati. È stata avviata la dismissione dell'hardware dell'ambiente del servizio app v1 e v2, il che può influire sulla disponibilità e sulle prestazioni di app e dati.

È necessario completare immediatamente la migrazione all'ambiente del servizio app v3 oppure è possibile che le app e le risorse vengano eliminate. Si tenterà con il massimo impegno di eseguire automaticamente la migrazione di qualsiasi ambiente del servizio app v1 e v2 rimanente usando la funzionalità di migrazione sul posto, ma Microsoft non dichiara né garantisce la disponibilità delle applicazioni dopo la migrazione automatica. Può essere necessario eseguire una configurazione manuale per completare la migrazione e ottimizzare la scelta di SKU del piano di servizio app in base a specifiche esigenze. Se la migrazione automatica non è fattibile, le risorse e i dati delle app associati verranno eliminati. È consigliabile agire tempestivamente per evitare uno di questi scenari estremi.

Se è necessario più tempo, è possibile usufruire di un periodo di tolleranza di 30 giorni una tantum per completare la migrazione. Per altre informazioni e per richiedere questo periodo di tolleranza, vedere la panoramica del periodo di tolleranza, quindi passare al portale di Azure e visitare il pannello Migrazione per ogni ambiente del servizio app.

Per le informazioni più aggiornate sul ritiro dell'ambiente del servizio app v1/v2, vedere l'Aggiornamento sul ritiro dall'ambiente del servizio app v1 e v2.

L'ambiente del servizio app di Azure è una distribuzione del servizio app di Azure in una subnet in una rete virtuale di Azure. È possibile distribuire un ambiente del servizio app in due modi:

  • Con un indirizzo VIP su un indirizzo IP esterno, spesso denominato ambiente del servizio app esterno.
  • Con un indirizzo VIP su un indirizzo IP interno, spesso denominato ambiente del servizio app ILB perché l'endpoint interno è un servizio di bilanciamento del carico interno (ILB).

Questo articolo illustra come creare un ambiente del servizio app ILB. Per una panoramica dell'ambiente del servizio app, vedere Introduzione agli ambienti del servizio app. Per informazioni sulla creazione di un ambiente del servizio app esterno, vedere [Creare un ambiente del servizio app esterno][MakeExternalASE].

Panoramica

È possibile distribuire un Ambiente del servizio app con un endpoint accessibile da Internet o con un indirizzo IP nella rete virtuale. Per impostare l'indirizzo IP su un indirizzo di rete virtuale, è necessario distribuire l'ambiente del servizio app con un bilanciamento del carico interno (ILB). Per la distribuzione dell'ambiente del servizio app con un bilanciamento del carico interno, è necessario fornire il nome dell'ambiente del servizio app. Il nome dell'ambiente del servizio app viene usato nel suffisso di dominio per le app nell'ambiente del servizio app. Il suffisso di dominio per l'ambiente del servizio app ILB è <nome ambiente del servizio app>.appserviceenvironment.net. Le app create in un ambiente del servizio app ILB non vengono inserite nel DNS pubblico.

Nelle versioni precedenti dell'ambiente del servizio app ILB è necessario fornire un suffisso di dominio e un certificato predefinito per le connessioni HTTPS. Il suffisso di dominio e il certificato predefinito non vengono più raccolti al momento della creazione dell'ambiente del servizio app ILB. Ora, quando si crea un ambiente del servizio app ILB, il certificato predefinito viene fornito da Microsoft e considerato attendibile dal browser. È ancora possibile impostare nomi di dominio personalizzati per le app nell'ambiente del servizio app e impostare certificati su tali nomi di dominio personalizzati.

Con un ambiente del servizio app ILB è possibile eseguire operazioni come:

  • l'hosting sicuro nel cloud di applicazioni Intranet, a cui si accede tramite una VPN ExpressRoute o da sito a sito.
  • la protezione di app con un dispositivo WAF
  • l'hosting di app nel cloud non presenti nei server DNS pubblici.
  • la creazione di applicazioni back-end isolate da Internet con cui le app front-end possono integrarsi in modo sicuro.

Funzionalità disabilitata

Quando si usa un ambiente del servizio app con bilanciamento del carico interno, non è possibile eseguire alcune operazioni.

  • Usare l'associazione TLS/SSL basata su IP.
  • Assegnazione di indirizzi IP ad app specifiche
  • Acquisto e uso di un certificato con un'app tramite il portale di Azure. È possibile ottenere i certificati direttamente da un'autorità di certificazione e usarli con le app. Non è possibile ottenerli tramite il portale di Azure.

Creare un ambiente del servizio app con bilanciamento del carico interno

Per creare un ambiente del servizio app con servizio di bilanciamento del carico interno, vedere Creare un ambiente del servizio app usando un modello di Azure Resource Manager

Nota

Il nome dell'ambiente del servizio app non può contenere più di 36 caratteri.

Creare un'app in un ambiente del servizio app con bilanciamento del carico interno

La creazione di un'app in un ambiente del servizio app con bilanciamento del carico interno è la stessa eseguita in un ambiente del servizio app regolare.

  1. Nel portale di Azure selezionare Crea una risorsa>Web>App Web.

  2. Immettere il nome dell'app.

  3. Selezionare la sottoscrizione.

  4. Selezionare o creare un gruppo di risorse.

  5. Selezionare pubblicazione, stack di runtime e sistema operativo.

  6. Selezionare un percorso che corrisponda a un ambiente del servizio app ILB esistente.

  7. Selezionare o creare un piano di servizio app.

  8. Selezionare Rivedi e crea e quindi Crea quando si è pronti.

Funzioni, processi Web e ambiente del servizio app ILB

In un ambiente del servizio app ILB sono supportati sia i processi Web che Funzioni, ma per poterli usare dal portale è necessario avere l'accesso di rete al sito SCM. Il browser deve quindi trovarsi in un host incluso nella rete virtuale o connesso a essa. Se l'ambiente del servizio app ILB ha un nome di dominio che non termina con appserviceenvironment.net, sarà necessario impostare il browser in modo che consideri attendibile il certificato HTTPS usato dal sito SCM.

Configurazione del DNS

Sei si usa un ambiente del servizio app esterno, le app create al suo interno vengono registrate con DNS di Azure. In un ambiente del servizio app esterno per rendere le app disponibili pubblicamente non sono previsti passaggi aggiuntivi. In un ambiente del servizio app ILB, è necessario gestire il proprio DNS. È possibile farlo nel proprio server DNS o nelle zone private di DNS di Azure.

Per configurare DNS nel proprio server DNS con l'ambiente del servizio app ILB:

  1. Creare una zona per <nome dell'ambiente del servizio app>.appserviceenvironment.net
  2. creare un record A in tale zona che punti * all'indirizzo IP del servizio ILB
  3. creare un record A in tale zona che punti @ all'indirizzo IP del servizio ILB
  4. Creare una zona in <nome dell'ambiente del servizio app>.appserviceenvironment.net denominata scm
  5. creare un record A nella zona che punti * all'indirizzo IP del servizio ILB

Per configurare DNS nelle zone private di DNS di Azure:

  1. creare una zona privata di DNS di Azure denominata <nome ambiente del servizio app>.appserviceenvironment.net
  2. creare un record A in tale zona che punti * all'indirizzo IP del servizio ILB
  3. creare un record A in tale zona che punti @ all'indirizzo IP del servizio ILB
  4. Creare un record A in tale zona che punta *.scm all'indirizzo IP del servizio ILB

Le impostazioni DNS per il suffisso di dominio predefinito dell'ambiente del servizio app non limitano l'accesso alle app solo a questi nomi. In un ambiente del servizio app ILB è possibile impostare un nome di dominio personalizzato senza alcuna convalida nelle app. Se poi si vuole creare una zona denominata contoso.net, è possibile farlo e puntarla all'indirizzo IP di ILB. Il nome del dominio personalizzato funziona per le richieste di app ma non per il sito scm. Il sito scm è disponibile solo in <appname>.scm.<asename>.appserviceenvironment.net.

La zona denominata .<asename>.appserviceenvironment.net è univoca a livello globale. Prima del mese di maggio 2019, i clienti potevano specificare il suffisso di dominio dell'ambiente del servizio app ILB. Se si avesse voluto usare .contoso.com per il suffisso di dominio, lo si sarebbe potuto fare includendo in tal modo il sito scm. Con tale modello si sono verificati problemi, ad esempio gestione del certificato TLS/SSL predefinito, mancanza di accesso Single Sign-On con il sito scm e il requisito di usare un certificato con caratteri jolly. Il processo di aggiornamento del certificato predefinito dell'ambiente del servizio app ILB era inoltre complicato e causava il riavvio dell'applicazione. Per risolvere questi problemi, il comportamento dell'ambiente del servizio app ILB è stato cambiato e prevede ora l'uso di un suffisso di domino basato sul nome dell'ambiente del servizio app con un suffisso di proprietà di Microsoft. La modifica del comportamento dell'ambiente del servizio app ILB influisce solo su tali ambienti creati dopo maggio 2019. Gli ambienti del servizio app ILB preesistenti continuano a gestire il certificato predefinito dell'ambiente e la rispettiva configurazione DNS.

Pubblicare con un ambiente del servizio app ILB

Per ogni app creata sono disponibili due endpoint. In un ambiente del servizio app ILB sono presenti <nome app>.<Dominio ambiente del servizio app ILB> e <nome app>.scm.<Dominio ambiente del servizio app ILB>.

Il nome del sito di gestione controllo servizi consente di passare alla console Kudu, denominata Advanced Portal (Portale avanzato) all'interno del portale di Azure. La console Kudu consente di visualizzare le variabili di ambiente, esplorare il disco, usare una console e molto altro ancora. Per altre informazioni, vedere Console Kudu per il servizio app di Azure.

I sistemi di integrazione continua basati su Internet, come GitHub e Azure DevOps, continueranno a funzionare con un ambiente del servizio app ILB se l'agente di compilazione è accessibile da Internet e si trova nella stessa rete dell'ambiente del servizio app ILB. Quindi, nel caso di Azure DevOps, se l'agente di compilazione viene creato nella stessa rete virtuale dell'ambiente del servizio app ILB (anche se la subnet è diversa), potrà eseguire il pull del codice dal GIT di Azure DevOps e distribuirlo nell'ambiente del servizio app ILB. Se non si vuole creare il proprio agente di compilazione, è necessario usare un sistema di integrazione continua che adotta un modello pull, ad esempio Dropbox.

Gli endpoint di pubblicazione per le app in un ambiente del servizio app con bilanciamento del carico interno usano il dominio con cui l'ambiente del servizio app con bilanciamento del carico interno è stato creato, che può essere visualizzato nel profilo di pubblicazione dell'app e nel pannello del portale dell'app (in Panoramica>Informazioni di base e anche in Proprietà). Se si ha un ambiente del servizio app con servizio di bilanciamento del carico interno con il suffisso di dominio <nome ambiente del servizio app>.appserviceenvironment.net e un'app denominata mytest, usare mytest.<nome ambiente del servizio app>.appserviceenvironment.net per FTP e mytest.scm.contoso.net per la distribuzione MSDeploy.

Configurare un ambiente del servizio app ILB con un dispositivo WAF

È possibile combinare un dispositivo web application firewall (WAF) con l'ambiente del servizio app ILB in modo da esporre a Internet solo le app desiderate e mantenere le altre accessibili solo dall'interno della rete virtuale. Questo consente, tra l'altro, di creare applicazioni multilivello sicure.

Per altre informazioni su come configurare l'ambiente del servizio app ILB con un dispositivo WAF, vedere Configurazione di un Web application firewall (WAF) per l'ambiente del servizio app. Questo articolo spiega come usare un'appliance virtuale Barracuda con il proprio ambiente del servizio app. Un'altra opzione consiste nell'usare il gateway applicazione Azure. Il gateway applicazione usa le regole di base OWASP per proteggere le applicazioni associate allo stesso. Per altre informazioni sul gateway applicazione, vedere Introduzione al Web application firewall di Azure.

Ambienti del servizio app creati prima del maggio 2019

Gli ambienti del servizio app con bilanciamento del carico interno creati prima del maggio 2019 richiedevano di impostare il suffisso di dominio durante la creazione dell'ambiente del servizio app. Richiedevano inoltre di caricare un certificato predefinito basato sul suffisso di dominio. In più, con un ambiente del servizio app ILB precedente, non è possibile eseguire l'accesso Single Sign-On alla console Kudu con le app che si trovano nell'ambiente. Durante la configurazione del DNS per un ambiente del servizio app ILB precedente, è necessario impostare il record A con caratteri jolly in una zona corrispondente al suffisso di dominio. Per creare o modificare l'ambiente del servizio app con servizio di bilanciamento del carico interno con il suffisso di dominio personalizzato è necessario usare i modelli di Azure Resource Manager e una versione API precedente al 2019. L'ultima versione dell'API supportata è 2018-11-01.

Operazioni preliminari