Distribuzione aziendale con l'ambiente del servizio app Azure

Questa architettura di riferimento illustra un carico di lavoro aziendale comune che usa ambiente del servizio app versione 3. Vengono inoltre descritte le procedure consigliate per rafforzare la sicurezza del carico di lavoro.

Un'implementazione di riferimento per questa architettura è disponibile in GitHub.

Architettura

Scaricare un file di Visio di questa architettura.

Flusso di lavoro

ambiente del servizio app versione 3 offre funzionalità diverse rispetto alle versioni precedenti e vantaggi rispetto a tali versioni. Per altre informazioni, vedere Differenze di funzionalità. È possibile distribuire ambiente del servizio app in due modi:

• Come ambiente del servizio app esterna con un indirizzo IP pubblico
• Come ambiente del servizio app interno con un indirizzo IP interno appartenente al servizio di bilanciamento del carico interno (ILB)

Questa architettura di riferimento distribuisce un'applicazione Web aziendale in un ambiente del servizio app interno, detta anche ambiente del servizio app ILB. Usare un ambiente del servizio app il bilanciamento del carico interno quando lo scenario richiede:

• Ospitare applicazioni Intranet con sicurezza avanzata nel cloud e accedervi tramite una VPN da sito a sito o Azure ExpressRoute.
• Fornire un livello di protezione per le app usando un web application firewall (WAF).
• l'hosting di app nel cloud non presenti nei server DNS pubblici.
• Creare app back-end isolate da Internet, che le app front-end possono integrarsi con in modo estremamente sicuro.

ambiente del servizio app deve essere sempre distribuito nella propria subnet nella rete virtuale aziendale per consentire un controllo rigoroso del traffico in ingresso e in uscita. All'interno di questa subnet, servizio app le applicazioni vengono distribuite in uno o più piani servizio app, ovvero una raccolta di risorse fisiche necessarie per eseguire l'app. A seconda della complessità e del requisito delle risorse, un piano di servizio app può essere condiviso tra più app. Questa implementazione di riferimento distribuisce un'app Web denominata Voting App, che interagisce con un'API Web privata e una funzione. Distribuisce anche un'app Web fittizia denominata App di test per illustrare le distribuzioni con più app. Ogni app servizio app è ospitata nel proprio piano di servizio app, consentendo di ridimensionare ogni app in modo indipendente, se necessario. Tutte le risorse richieste da queste app ospitate, ad esempio archiviazione e calcolo, nonché le esigenze di scalabilità sono completamente gestite dall'infrastruttura ambiente del servizio app.

L'app di voto semplice in questa implementazione consente agli utenti di visualizzare le voci esistenti, creare nuove voci e votare le voci esistenti. L'API Web viene usata per la creazione e il recupero di voci e voti. I dati stessi vengono archiviati in un database di SQL Server. Per illustrare gli aggiornamenti asincroni dei dati, l'app Web accoda i voti appena aggiunti in un'istanza di bus di servizio. La funzione raccoglie i voti in coda e aggiorna il database SQL. Azure Cosmos DB viene usato per archiviare un annuncio fittizio recuperato dall'app Web da visualizzare nel browser. L'applicazione usa cache di Azure per Redis per la gestione della cache. Viene usato un cache di Azure per Redis di livello Premium, che consente la configurazione nella stessa rete virtuale del ambiente del servizio app, nella propria subnet. In questo modo è possibile migliorare la sicurezza e l'isolamento per la cache.

Le app Web sono gli unici componenti accessibili a Internet tramite gateway applicazione. L'API e la funzione non sono accessibili da un client Internet. Il traffico in ingresso è protetto da un WAF configurato in gateway applicazione.

Componenti

I servizi seguenti sono fondamentali per bloccare il ambiente del servizio app in questa architettura:

• Azure Rete virtuale è una rete cloud di Azure privata di proprietà di un'azienda. Offre sicurezza e isolamento avanzati basati sulla rete. ambiente del servizio app è una distribuzione di servizio app in una subnet della rete virtuale di proprietà dell'organizzazione. Consente all'azienda di controllare rigorosamente lo spazio di rete e le risorse a cui accede usando i gruppi di sicurezza di rete e gli endpoint privati.

• gateway applicazione è un servizio di bilanciamento del carico del traffico Web a livello di applicazione con l'offload TLS/SSL e WAF. È in ascolto su un indirizzo IP pubblico e instrada il traffico all'endpoint dell'applicazione nel ambiente del servizio app il bilanciamento del carico interno. Poiché si tratta di un routing a livello di applicazione, può instradare il traffico a più app all'interno dello stesso ambiente del servizio app il bilanciamento del carico interno. Per altre informazioni, vedere gateway applicazione l'hosting di più siti.

• Firewall di Azure viene usato per limitare il traffico in uscita dall'applicazione Web. Il traffico in uscita che non passa attraverso i canali dell'endpoint privato e una tabella di route richiesta da ambiente del servizio app viene indirizzata alla subnet del firewall. Per semplicità, questa architettura configura tutti gli endpoint privati nella subnet dei servizi.

• Microsoft Entra ID o Microsoft Entra ID fornisce diritti di accesso e gestione delle autorizzazioni per le risorse e i servizi di Azure. Le identità gestite assegnano identità a servizi e app, gestiti automaticamente dall'ID Microsoft Entra. Queste identità possono essere usate per eseguire l'autenticazione a qualsiasi servizio che supporti l'autenticazione di Microsoft Entra. In questo modo viene rimossa la necessità di configurare in modo esplicito le credenziali per queste app. Questa architettura assegna un'identità gestita all'app Web.

• Azure Key Vault archivia tutti i segreti e le credenziali richiesti dalle app. Usare questa opzione per archiviare i segreti direttamente nell'applicazione.

• GitHub Actions offre funzionalità di integrazione continua e distribuzione continua in questa architettura. Poiché il ambiente del servizio app si trova nella rete virtuale, una macchina virtuale viene usata come jumpbox all'interno della rete virtuale per distribuire le app nei piani di servizio app. L'azione compila le app all'esterno della rete virtuale. Per una maggiore sicurezza e connettività RDP/SSH senza problemi, è consigliabile usare Azure Bastion per il jumpbox.

Configurazione multisito

Scaricare un file di Visio di questa architettura.

Le ambiente del servizio app interne possono ospitare diverse app Web e API con endpoint HTTP. Queste applicazioni sono bloccate dalla rete Internet pubblica perché l'IP del servizio di bilanciamento del carico interno è accessibile solo dall'interno del Rete virtuale. gateway applicazione viene usato per esporre in modo selettivo queste applicazioni a Internet. ambiente del servizio app assegna un URL predefinito a ogni applicazione servizio app come <default-appName>.<app-service-environment-domain>.appserviceenvironment.net. Viene creata una zona DNS privata che esegue il mapping del nome di dominio ambiente del servizio app all'indirizzo IP del servizio di bilanciamento del carico interno ambiente del servizio app. In questo modo si evita di usare un DNS personalizzato per accedere alle app all'interno della rete virtuale.

gateway applicazione è configurato in modo che un listener sia in ascolto sulla porta HTTPS per le richieste all'indirizzo IP del gateway. Per semplicità, questa implementazione non usa una registrazione del nome DNS pubblico. È necessario modificare il file localhost nel computer in modo da puntare un URL scelto arbitrariamente all'IP gateway applicazione. Per semplicità, il listener usa un certificato autofirmato per elaborare queste richieste. gateway applicazione include pool back-end per ogni URL predefinito dell'applicazione servizio app. Una regola di routing è configurata per connettere il listener al pool back-end. Vengono create impostazioni HTTP che determinano se la connessione tra il gateway e il ambiente del servizio app verrà crittografata. Queste impostazioni vengono usate anche per eseguire l'override dell'intestazione host HTTP in ingresso con un nome host selezionato dal pool back-end. Questa implementazione usa i certificati predefiniti creati per gli URL dell'app ambiente del servizio app predefiniti, considerati attendibili dal gateway. La richiesta viene reindirizzata all'URL predefinito dell'app corrispondente. Il DNS privato collegato alla rete virtuale inoltra la richiesta all'indirizzo IP del servizio di bilanciamento del carico interno. ambiente del servizio app quindi lo inoltra al servizio app richiesto. Qualsiasi comunicazione HTTP all'interno delle app ambiente del servizio app passa attraverso il DNS privato. Si noti che le impostazioni listener, pool back-end, regola di routing e HTTP devono essere configurate nel gateway applicazione per ogni app ambiente del servizio app.

Esaminare appgw.bicep e dns.bicep per informazioni su come vengono eseguite queste configurazioni per consentire più siti. L'app Web denominata testapp è un'app vuota creata per illustrare questa configurazione. Questi file JSON sono accessibili dallo script di distribuzione commands_std.azcli. Questi sono accessibili anche da commands_ha.azcli, che viene usato per una distribuzione multisito a disponibilità elevata ambiente del servizio app.

Dettagli dello scenario

app Azure Servizio è un servizio PaaS usato per ospitare un'ampia gamma di app in Azure: app Web, app per le API, funzioni e app per dispositivi mobili. ambiente del servizio app consente alle aziende di distribuire le app servizio app in una subnet nel proprio Rete virtuale di Azure, fornendo un ambiente isolato, altamente scalabile e dedicato per i carichi di lavoro cloud.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

Ambiente del servizio app

Una ambiente del servizio app interna viene distribuita nella rete virtuale aziendale, nascosta dalla rete Internet pubblica. Consente all'azienda di bloccare i servizi back-end, ad esempio API Web e funzioni, a livello di rete. È possibile accedere a qualsiasi app ambiente del servizio app con un endpoint HTTP tramite il servizio di bilanciamento del carico interno, all'interno della rete virtuale. gateway applicazione è configurato per inoltrare le richieste all'app Web tramite il servizio di bilanciamento del carico interno. L'app Web stessa passa attraverso il servizio di bilanciamento del carico interno per accedere all'API. I componenti back-end critici, ovvero l'API e la funzione, sono effettivamente inaccessibili dalla rete Internet pubblica.

I certificati predefiniti vengono creati per ogni servizio app per il nome di dominio predefinito assegnato da ambiente del servizio app. Questo certificato può rafforzare la sicurezza del traffico tra il gateway e l'app e potrebbe essere necessario in determinati scenari. Questi certificati non sono visibili tramite il browser client. Può rispondere solo ai certificati configurati in gateway applicazione.

Gateway applicazione

L'implementazione di riferimento configura gateway applicazione a livello di codice in appgw.bicep. Il file commands_std.azcli usa questa configurazione durante la distribuzione del gateway:

az deployment group create --resource-group $RGNAME --template-file templates/appgw.bicep --parameters vnetName=$VNET_NAME appgwSubnetAddressPrefix=$APPGW_PREFIX appgwApplications=@appgwApps.parameters.json
APPGW_PUBLIC_IP=$(az deployment group show -g $RGNAME -n appgw --query properties.outputs.appGwPublicIpAddress.value -o tsv)

Crittografia

Come descritto in Panoramica della terminazione TLS e di TLS end-to-end con gateway applicazione, gateway applicazione può usare Transport Layer Security (TLS)/Secure Sockets Layer (SSL) per crittografare e proteggere tutto il traffico dai Web browser. La crittografia può essere configurata nei modi seguenti:

• Crittografia terminata nel gateway. In questo caso i pool back-end sono configurati per HTTP. La crittografia si arresta nel gateway e il traffico tra il gateway e il servizio app non è crittografato. Poiché la crittografia richiede un utilizzo elevato della CPU, il traffico non crittografato nel back-end migliora le prestazioni e consente una gestione dei certificati più semplice. Ciò garantisce un livello ragionevole di sicurezza poiché il back-end è protetto in virtù della configurazione di rete.

• Crittografia end-to-end. In alcuni scenari, ad esempio requisiti di sicurezza o conformità specifici, potrebbe essere necessario crittografare il traffico tra il gateway e l'app. A tale scopo, usare la connessione HTTPS e configurare i certificati nel pool back-end.

Questa implementazione di riferimento usa certificati autofirmato per gateway applicazione. Per il codice di produzione, è necessario usare un certificato emesso da un'autorità di certificazione. Per un elenco dei tipi di certificato supportati, vedere Certificati supportati per la terminazione TLS. Leggere Configurare un gateway applicazione con terminazione TLS usando il portale di Azure per informazioni su come creare la crittografia con terminazione del gateway. Le righe di codice seguenti in appgw.bicep configurano questa operazione a livello di codice:

          httpListeners: [for item in appgwApplications: {
          name: '${appgwListenerName}${item.name}'
          properties: {
            frontendIPConfiguration: {
              id: '${appgwId}/frontendIPConfigurations/${appgwFrontendName}'
            }
            frontendPort: {
              id: '${appgwId}/frontendPorts/port_443'
            }
            protocol: 'Https'
            sslCertificate: {
              id: '${appgwId}/sslCertificates/${appgwSslCertificateName}${item.name}'
            }
            hostName: item.hostName
            requireServerNameIndication: true
          }
        }]

L'implementazione di riferimento illustra la crittografia end-to-end per il traffico tra gateway applicazione e le app Web nel ambiente del servizio app. Vengono usati i certificati SSL predefiniti. I pool back-end in questa implementazione sono configurati per reindirizzare il traffico HTTPS con nome host sottoposto a override dai nomi di dominio predefiniti associati alle app Web. gateway applicazione considera attendibili i certificati SSL predefiniti perché vengono rilasciati da Microsoft. Per informazioni su come vengono eseguite queste configurazioni, vedere Configurare servizio app con gateway applicazione. Il codice seguente di appgw.bicep mostra come viene configurato nell'implementazione di riferimento:

        backendHttpSettingsCollection: [for item in appgwApplications: {
        name: '${appgwHttpSettingsName}${item.name}'
        properties: {
          port: 443
          protocol: 'Https'
          cookieBasedAffinity: 'Disabled'
          pickHostNameFromBackendAddress: true
          requestTimeout: 20
          probe: {
            id: '${appgwId}/probes/${appgwHealthProbeName}${item.name}'
          }
        }
      }]

Web application firewall

Web Application Firewall (WAF) in gateway applicazione protegge le app Web da attacchi dannosi, ad esempio SQL injection. È anche integrato con Monitoraggio di Azure per monitorare gli attacchi usando un log in tempo reale. Waf deve essere abilitato nel gateway, come descritto in Creare un gateway applicazione con un Web Application Firewall usando il portale di Azure. L'implementazione di riferimento abilita WAF a livello di codice nel file appgw.bicep con il frammento di codice seguente:

        webApplicationFirewallConfiguration: {
        enabled: true
        firewallMode: 'Detection'
        ruleSetType: 'OWASP'
        ruleSetVersion: '3.0'
      }

Rete virtuale

I gruppi di sicurezza di rete possono essere associati a una o più subnet nella rete virtuale. Si tratta di regole di sicurezza che consentono o negano il flusso del traffico tra varie risorse di Azure. Questa architettura associa un gruppo di sicurezza di rete separato per ogni subnet. In questo modo è possibile ottimizzare queste regole per ogni subnet, in base ai servizi contenuti in tale subnet. Ad esempio, vedere la configurazione per "type": "Microsoft.Network/networkSecurityGroups" nel file ase.bicep per il gruppo di sicurezza di rete per la subnet ambiente del servizio app e nel file appgw.bicep per il gruppo di sicurezza di rete per la subnet gateway applicazione.

Gli endpoint privati consentono la connettività privata di sicurezza avanzata tra i client e i servizi di Azure tramite una rete privata. Forniscono un indirizzo IP accessibile privatamente per il servizio di Azure, abilitando il traffico di sicurezza avanzato verso una risorsa collegamento privato di Azure. La piattaforma convalida le connessioni di rete, consentendo solo quelle che si connettono alla risorsa collegamento privato specificata. Gli endpoint privati supportano criteri di rete come gruppi di sicurezza di rete, route definite dall'utente e gruppi di sicurezza delle applicazioni. Per migliorare la sicurezza, è necessario abilitare gli endpoint privati per qualsiasi servizio di Azure che li supporta. È quindi possibile migliorare la sicurezza per il servizio nella rete virtuale disabilitando l'accesso pubblico, bloccando in modo efficace qualsiasi accesso dalla rete Internet pubblica. Questa architettura configura gli endpoint privati per i servizi che lo supportano: bus di servizio di Azure, SQL Server, Key Vault e Azure Cosmos DB. È possibile visualizzare la configurazione in privatendpoints.bicep.

Per abilitare gli endpoint privati, è anche necessario configurare le zone DNS private. Per altre informazioni, vedere Configurazione DNS dell'endpoint privato di Azure.

Firewall

Firewall di Azure ed endpoint privati si integrano tra loro. Gli endpoint privati consentono di proteggere le risorse consentendo solo il traffico proveniente dalla rete virtuale. Firewall di Azure consente di limitare il traffico in uscita dalle applicazioni. È consigliabile consentire a tutto il traffico in uscita di passare attraverso la subnet del firewall, incluso il traffico dell'endpoint privato. In questo modo è possibile monitorare meglio il traffico in uscita. Per semplicità, questa architettura di riferimento configura tutti gli endpoint privati nella subnet dei servizi anziché nella subnet del firewall.

Per informazioni su come Firewall di Azure si integra con ambiente del servizio app, vedere Configurazione di Firewall di Azure con il ambiente del servizio app. Qualsiasi traffico che non attraversa gli endpoint privati e la tabella di route di rete virtuale viene monitorato e controllato dal firewall.

Microsoft Entra ID

Microsoft Entra ID fornisce funzionalità di sicurezza per autenticare le applicazioni e autorizzare l'accesso alle risorse. Questa architettura di riferimento usa due funzionalità chiave di Microsoft Entra ID: identità gestite e controllo degli accessi in base al ruolo di Azure.

Nelle applicazioni cloud, le credenziali necessarie per l'autenticazione ai servizi cloud devono essere protette. Idealmente, le credenziali non dovrebbero mai essere visualizzate nelle workstation di sviluppo o archiviate nel controllo del codice sorgente. Azure Key Vault consente di archiviare in modo sicuro le credenziali e i segreti, ma l'app deve comunque eseguire l'autenticazione in Key Vault per recuperarle. Le identità gestite per le risorse di Azure forniscono ai servizi di Azure un'identità gestita automaticamente in Microsoft Entra ID. Questa identità può essere usata per eseguire l'autenticazione a qualsiasi servizio che supporti l'autenticazione di Microsoft Entra, incluso Key Vault, senza credenziali nell'applicazione.

Il controllo degli accessi in base al ruolo di Azure gestisce l'accesso alle risorse di Azure. Tali controlli includono:

• Quale entità ha l'accesso: utente, identità gestita, entità di sicurezza.
• Quale tipo di accesso ha: proprietario, collaboratore, lettore, amministratore.
• Ambito dell'accesso: risorsa, gruppo di risorse, sottoscrizione o gruppo di gestione.

È possibile bloccare l'accesso alle applicazioni ambiente del servizio app controllando rigorosamente il ruolo richiesto e il tipo di accesso per ogni app. In questo modo, è possibile distribuire più app nello stesso ambiente del servizio app da team di sviluppo diversi. Ad esempio, il front-end potrebbe essere gestito da un team e dal back-end da un altro. Il controllo degli accessi in base al ruolo di Azure può essere usato per limitare l'accesso di ogni team alle app su cui sta lavorando. Esplorare i ruoli personalizzati di Azure per creare ruoli adatti all'organizzazione.

Insieme di credenziali delle chiavi di

Alcuni servizi supportano le identità gestite, ma usano il controllo degli accessi in base al ruolo di Azure per configurare le autorizzazioni per l'app. Ad esempio, vedere i ruoli di bus di servizio predefiniti e il controllo degli accessi in base al ruolo di Azure in Azure Cosmos DB. L'accesso proprietario alla sottoscrizione è necessario per concedere queste autorizzazioni, anche se il personale con accesso collaboratore può distribuire questi servizi. Per consentire a un team più ampio di sviluppatori di poter eseguire gli script di distribuzione, l'opzione migliore consiste nell'usare i criteri di controllo di accesso nativi del servizio:

• Per bus di servizio, si tratta di firme di accesso condiviso.
• Per Azure Cosmos DB, si tratta delle chiavi.

I stringa di connessione per questi criteri di controllo di accesso vengono quindi archiviati in Key Vault. L'insieme di credenziali stesso è accessibile tramite identità gestite, che richiedono il controllo degli accessi in base al ruolo di Azure. Impostare i criteri di accesso per questi stringa di connessione in modo appropriato. Ad esempio, di sola lettura per il back-end, di sola scrittura per il front-end e così via, invece di usare i criteri di accesso radice predefiniti.

Il codice seguente in services.bicep mostra la configurazione di Key Vault per questi servizi:

      resource keyVaultName_CosmosKey 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'CosmosKey'
      properties: {
        value: cosmosName.listKeys().primaryMasterKey 
      }
    }

      resource keyVaultName_ServiceBusListenerConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusListenerConnectionString'
      properties: {
        value: listKeys(serviceBusName_ListenerSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

      resource keyVaultName_ServiceBusSenderConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusSenderConnectionString'
      properties: {
        value: listKeys(serviceBusName_SenderSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

Questi valori stringa di connessione sono accessibili dalle app, che fanno riferimento alla coppia chiave/valore di Key Vault. Questa operazione viene eseguita nel file sites.bicep , come illustrato nel codice seguente per l'app voting:

  properties: {
    enabled: true
    hostingEnvironmentProfile: {
      id:aseId
    }
    serverFarmId: votingWebPlanName.id
    siteConfig: {
      appSettings: [
        {
          name: 'ConnectionStrings:sbConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, serviceBusSenderConnectionStringSecretName), '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:RedisConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(keyVaultName_redisSecretName.id, '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:CosmosKey'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, cosmosKeySecretName), '2022-07-01').secretUriWithVersion})'
        }
      ]
    }
  }

La funzione accede anche al listener bus di servizio stringa di connessione in modo simile.

Scalabilità

Progettare app scalabili

L'applicazione in questa architettura di riferimento è strutturata in modo che i singoli componenti possano essere ridimensionati in base all'utilizzo. Ogni app Web, API e funzione viene distribuita nel proprio piano di servizio app. È possibile monitorare ogni app per eventuali colli di bottiglia delle prestazioni e quindi aumentarla , se necessario.

Ridimensionamento automatico gateway applicazione

La scalabilità automatica può essere abilitata nel gateway di app Azure lication V2. Ciò consente gateway applicazione di aumentare o ridurre le prestazioni in base ai modelli di carico del traffico. Questa architettura di riferimento viene configurata autoscaleConfiguration nel file appgw.bicep per la scalabilità tra zero e 10 istanze aggiuntive. Per altri dettagli, vedere Ridimensionamento gateway applicazione e WAF v2.

Distribuzione

Gli script di distribuzione in questa architettura di riferimento vengono usati per distribuire ambiente del servizio app, altri servizi e le applicazioni all'interno di ambiente del servizio app. Dopo la distribuzione di queste applicazioni, le aziende potrebbero voler pianificare l'integrazione e la distribuzione continue per la manutenzione e gli aggiornamenti delle app. Questa sezione illustra alcuni dei modi comuni in cui gli sviluppatori usano per CI/CD di applicazioni ambiente del servizio app.

Le app possono essere distribuite in un ambiente del servizio app interno solo dall'interno della rete virtuale. I tre metodi seguenti vengono ampiamente usati per distribuire app ambiente del servizio app:

• Manualmente all'interno del Rete virtuale: creare una macchina virtuale all'interno della rete virtuale ambiente del servizio app con gli strumenti necessari per la distribuzione. Aprire la connessione RDP alla macchina virtuale usando una configurazione del gruppo di sicurezza di rete. Copiare gli artefatti di codice nella macchina virtuale, compilare e distribuire nella subnet ambiente del servizio app. Si tratta di un modo semplice per configurare un ambiente di sviluppo di compilazione e test iniziale. Non è tuttavia consigliabile per l'ambiente di produzione perché non è in grado di ridimensionare la velocità effettiva di distribuzione necessaria.

• Connessione da punto a sito dalla workstation locale: in questo modo è possibile estendere la rete virtuale ambiente del servizio app al computer di sviluppo e distribuirla da questa posizione. Si tratta di un altro modo per configurare un ambiente di sviluppo iniziale e non consigliato per la produzione.

• Tramite Azure Pipelines: implementa una pipeline CI/CD completa, terminando con un agente che si trova all'interno della rete virtuale. Questa soluzione è ideale per gli ambienti di produzione che richiedono una velocità effettiva elevata della distribuzione. La pipeline di compilazione rimane completamente esterna alla rete virtuale. La pipeline di distribuzione copia gli oggetti compilati nell'agente di compilazione all'interno della rete virtuale e quindi distribuisce nella subnet ambiente del servizio app. Per altre informazioni, vedere questa discussione sull'agente di compilazione self-hosted tra Pipeline e la rete virtuale ambiente del servizio app.

L'uso di Azure Pipelines è consigliato per gli ambienti di produzione. L'esecuzione di script ci/CD con l'aiuto dello schema YAML di Azure Pipelines consente di automatizzare i processi di compilazione e distribuzione. Azure-pipelines.yml implementa una pipeline CI/CD di questo tipo per l'app Web in questa implementazione di riferimento. Sono disponibili script CI/CD simili per l'APIWeb e la funzione . Leggere Usare Azure Pipelines per informazioni su come vengono usati per automatizzare CI/CD per ogni applicazione.

Alcune aziende potrebbero non voler mantenere un agente di compilazione permanente all'interno della rete virtuale. In tal caso, è possibile scegliere di creare un agente di compilazione all'interno della pipeline DevOps e di eliminarlo al termine della distribuzione. Questo aggiunge un altro passaggio in DevOps, ma riduce la complessità della gestione della macchina virtuale. È anche possibile prendere in considerazione l'uso di contenitori come agenti di compilazione, anziché come macchine virtuali. Gli agenti di compilazione possono anche essere completamente evitati distribuendo da un file compresso posizionato all'esterno della rete virtuale, in genere in un account di archiviazione. L'account di archiviazione dovrà essere accessibile dal ambiente del servizio app. La pipeline deve essere in grado di accedere all'archiviazione. Alla fine della pipeline di versione, è possibile eliminare un file compresso nell'archivio BLOB. Il ambiente del servizio app può quindi recuperarlo e distribuirlo. Tenere presenti le limitazioni seguenti di questo approccio:

• Si verifica una disconnessione tra DevOps e il processo di distribuzione effettivo, causando difficoltà nel monitoraggio e nella traccia di eventuali problemi di distribuzione.
• In un ambiente bloccato con traffico protetto, potrebbe essere necessario modificare le regole per accedere al file compresso nella risorsa di archiviazione.
• Sarà necessario installare estensioni e strumenti specifici nel ambiente del servizio app per poter eseguire la distribuzione dal file ZIP.

Per conoscere altri modi in cui le app possono essere distribuite nei piani di servizio app, leggere gli articoli servizio app incentrati sulle strategie di distribuzione.

Ottimizzazione dei costi

Usare il calcolatore dei prezzi di Azure per stimare i costi. Altre considerazioni sono descritte nella sezione Costo in Microsoft Azure Well-Architected Framework. Le prenotazioni di Azure consentono di risparmiare denaro a fronte di un impegno di acquisto di un piano di uno o tre anni per numerose risorse di Azure. Per altre informazioni, vedere l'articolo Acquistare una prenotazione.

Ecco alcuni punti da considerare per alcuni dei servizi chiave usati in questa architettura.

Ambiente del servizio app, versione 3

Sono disponibili diverse opzioni di prezzo per servizio app. Un ambiente del servizio app viene distribuito usando il piano di servizio Isolato v2. All'interno di questo piano sono disponibili più opzioni per le dimensioni della CPU, da I1v2 a I6v2. Questa implementazione di riferimento usa tre I1v2 per istanza.

Gateway applicazione

gateway applicazione prezzi offre diverse opzioni di prezzo. Questa implementazione usa lo SKU gateway applicazione Standard v2 e WAF v2, che supporta la scalabilità automatica e la ridondanza della zona. Per altre informazioni sul modello di prezzi usato per questo SKU, vedere Scaling gateway applicazione v2 and WAF v2 (Ridimensionamento gateway applicazione v2 e WAF v2 v2).

Cache Redis di Azure

cache di Azure per Redis prezzi offre le varie opzioni di prezzo per questo servizio. Questa architettura usa lo SKU Premium per il supporto della rete virtuale.

Di seguito sono riportate le pagine dei prezzi per altri servizi usati per bloccare il ambiente del servizio app:

• Prezzi del servizio Firewall di Azure

• Prezzi di Key Vault

• Prezzi di Microsoft Entra

Distribuire lo scenario

Per distribuire l'implementazione di riferimento per questa architettura, vedere il file leggimi di GitHub e seguire lo script per la distribuzione standard.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

• Dhanashri Kshirsagar | Senior Content PM

Altri contributori:

• Deep Bhattacharya | Cloud Solution Architect
• Suhas Rao | Cloud Solution Architect

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Eseguire l'app nel servizio app Azure direttamente da un pacchetto ZIP
• Schema YAML di Azure Pipelines
• Ottenere gli indirizzi di gestione dall'API
• Azure Key Vault
• Azure Pipelines

Risorse correlate

Per informazioni su come estendere questa architettura per supportare la disponibilità elevata, vedere Distribuzione di app a disponibilità elevata con ambiente servizio app s.