Distribuzione da DevOps per le applicazioni di App per la logica di Azure a tenant singolo
Si applica a: App per la logica di Azure (Standard)
Con la tendenza verso app cloud distribuite e native, le organizzazioni gestiscono componenti più distribuiti in più ambienti. Per mantenere il controllo e la coerenza, è possibile automatizzare gli ambienti e distribuire più componenti in modo più veloce e più sicuro usando strumenti e processi DevOps.
Questo articolo offre un'introduzione e una panoramica sull'esperienza di integrazione continua e distribuzione continua corrente (CI/CD) per App per la logica di Azure a tenant singolo.
Tenant singolo rispetto a multi-tenant
Nelle app per la logica di Azure multi-tenant la distribuzione delle risorse si basa sui modelli di Azure Resource Manager (modelli di Resource Manager), che combinano e gestiscono il provisioning delle risorse per le app per la logica e l'infrastruttura. In App per la logica di Azure a tenant singolo la distribuzione diventa più semplice perché è possibile separare il provisioning delle risorse tra le app e l'infrastruttura.
Quando si creano app per la logica usando il tipo di risorsa App per la logica (Standard), i flussi di lavoro sono basati sul runtime di App per la logica di Azure riprogettata. Questo runtime usa l'estendibilità Funzioni di Azure modello di estendibilità ed è ospitato come estensione nel runtime di Funzioni di Azure. Questa progettazione offre portabilità, flessibilità e prestazioni più elevate per le app per la logica e altri vantaggi ereditati dalla piattaforma di Funzioni di Azure e dall'ecosistema di Servizio app di Azure.
Ad esempio, è possibile creare un pacchetto di runtime e flussi di lavoro in contenitori riprogettati come parte dell'app per la logica. È possibile usare passaggi o attività generiche che compilano, assemblano e comprimono le risorse dell'app per la logica in artefatti pronti per la distribuzione. Per distribuire le app, copiare gli artefatti nell'ambiente host e quindi avviare le app per eseguire i flussi di lavoro. In alternativa, integrare gli artefatti nelle pipeline di distribuzione usando gli strumenti e i processi già noti e usati. Ad esempio, se lo scenario richiede contenitori, è possibile raggruppare le app per la logica e integrarle nelle pipeline esistenti.
Per configurare e distribuire le risorse dell'infrastruttura, ad esempio reti virtuali e connettività, è possibile continuare a usare i modelli di Resource Manager e effettuare separatamente il provisioning di tali risorse insieme ad altri processi e pipeline usati per tali scopi.
Usando le opzioni di compilazione e distribuzione standard, è possibile concentrarsi sullo sviluppo di app separatamente dalla distribuzione dell'infrastruttura. Di conseguenza, si ottiene un modello di progetto più generico in cui è possibile applicare molte opzioni di distribuzione simili o le stesse opzioni di distribuzione usate per un'app generica. Si può anche trarre vantaggio da un'esperienza più coerente per la creazione di pipeline di distribuzione nei progetti dell'app e per l'esecuzione dei test e delle convalida necessarie prima della pubblicazione in produzione. Indipendentemente da quale stack tecnologico si usa, è possibile distribuire app per la logica usando gli strumenti scelti.
Funzionalità di distribuzione DevOps
App per la logica di Azure a tenant singolo eredita molte funzionalità e vantaggi dalla piattaforma Funzioni di Azure e dall'ecosistema di Servizio app di Azure. Questi aggiornamenti includono un nuovo modello di distribuzione e altri modi per usare DevOps per i flussi di lavoro dell'app per la logica.
Sviluppo e test locali
Quando si usa Visual Studio Code con l'estensione App per la logica di Azure (Standard), è possibile sviluppare, compilare ed eseguire flussi di lavoro delle app per la logica basata su tenant singolo nell'ambiente di sviluppo senza dover distribuire in Azure. Se lo scenario richiede contenitori, è possibile creare e distribuire tramite App per la logica abilitate per Azure Arc.
Questa funzionalità è un miglioramento importante e offre un vantaggio significativo rispetto al modello multi-tenant, che richiede di sviluppare su una risorsa esistente ed in esecuzione in Azure.
Problemi separati
Il modello a tenant singolo offre la possibilità di separare le preoccupazioni tra l'app e l'infrastruttura sottostante. Ad esempio, è possibile sviluppare, compilare, zip e distribuire l'app separatamente come artefatto non modificabile in ambienti diversi. I flussi di lavoro dell'app per la logica in genere hanno "codice applicazione" che si aggiornano più spesso dell'infrastruttura sottostante. Separando questi livelli, è possibile concentrarsi di più sulla compilazione del flusso di lavoro dell'app per la logica e spendere meno per distribuire le risorse necessarie in più ambienti.
Struttura delle risorse dell'app per la logica
Nel modello app per la logica di Azure multi-tenant la struttura delle risorse dell'app per la logica di consumo può includere solo un singolo flusso di lavoro. A causa di questa relazione uno-a-uno, l'app per la logica e il flusso di lavoro vengono spesso considerati e a cui si fa riferimento in modo sinonimo. Tuttavia, nel modello app per la logica di Azure a tenant singolo, la struttura delle risorse dell'app per la logica Standard può includere più flussi di lavoro. Questa relazione uno-a-molti significa che nello stesso app per la logica i flussi di lavoro possono condividere e riutilizzare altre risorse. I flussi di lavoro nello stesso app per la logica e nel tenant offrono anche prestazioni migliorate a causa di questa tenancy condivisa e prossimità tra loro. Questa struttura di risorse sembra e funziona in modo analogo a Funzioni di Azure in cui un'app per le funzioni può ospitare molte funzioni.
Per altre informazioni e procedure consigliate sull'organizzazione di flussi di lavoro, prestazioni e scalabilità nell'app per la logica, vedere le indicazioni simili per Funzioni di Azure che è in genere possibile applicare alle app per la logica a tenant singolo.
Struttura del progetto dell'app per la logica
In Visual Studio Code il progetto dell'app per la logica include uno dei tipi seguenti:
- Estensione basata su bundle (Node.js), ovvero il tipo predefinito
- NuGet package-based (.NET), che è possibile convertire dal tipo predefinito
In base a questi tipi, il progetto include cartelle e file leggermente diversi. Un progetto basato su NuGet include una cartella .bin che contiene pacchetti e altri file di libreria. Un progetto basato su bundle non include la cartella .bin e altri file. Alcuni scenari richiedono un progetto basato su NuGet per l'esecuzione dell'app, ad esempio quando si desidera sviluppare ed eseguire operazioni predefinite personalizzate. Per altre informazioni sulla conversione del progetto per l'uso di NuGet, vedere Abilitare la creazione del connettore predefinito.
Per il progetto basato su bundle predefinito, il progetto ha una cartella e una struttura di file simile all'esempio seguente:
MyBundleBasedLogicAppProjectName
| .vscode
| Artifacts
|| Maps
||| MapName1
||| ...
|| Schemas
||| SchemaName1
||| ...
| WorkflowName1
|| workflow.json
|| ...
| WorkflowName2
|| workflow.json
|| ...
| workflow-designtime
| .funcignore
| connections.json
| host.json
| local.settings.json
A livello radice del progetto, è possibile trovare i file e le cartelle seguenti con altri elementi:
| NOME | File o cartella | Descrizione |
|---|---|---|
| .vscode | Cartella | Contiene file di impostazioni correlati a Visual Studio Code, ad esempio extensions.json, launch.json, settings.json e tasks.json . |
| Elementi | Cartella | Contiene elementi dell'account di integrazione definiti e usati nei flussi di lavoro che supportano scenari B2B (business-to-business). Ad esempio, la struttura di esempio include mappe e schemi per le operazioni di trasformazione e convalida XML. |
| <WorkflowName> | Cartella | Per ogni flusso di lavoro, la < cartella WorkflowName> include un file workflow.json che contiene la definizione JSON sottostante del flusso di lavoro. |
| workflow-designtime | Cartella | Contiene file di impostazioni correlate all'ambiente di sviluppo. |
| .funcignore | File | Contiene informazioni correlate agli strumenti di base installati Funzioni di Azure. |
| connections.json | File | Contiene i metadati, gli endpoint e le chiavi per le connessioni gestite e le funzioni di Azure usate dai flussi di lavoro. Importante: per usare connessioni e funzioni diverse per ogni ambiente, assicurarsi di parametrizzare questo file connections.json e aggiornare gli endpoint. |
| host.json | File | Contiene impostazioni e valori di configurazione specifici del runtime, ad esempio i limiti predefiniti per la piattaforma App per la logica di Azure a tenant singolo, le app per la logica, i flussi di lavoro, i trigger e le azioni. A livello radice del progetto dell'app per la logica, il file di metadati host.json contiene le impostazioni di configurazione e i valori predefiniti usati da tutti i flussi di lavoro nella stessa app per la logica durante l'esecuzione, sia in locale che in Azure. Nota: quando si crea l'app per la logica, Visual Studio Code crea un file host.snapshot.*.json backup nel contenitore di archiviazione. Se si elimina l'app per la logica, questo file di backup non viene eliminato. Se si crea un'altra app per la logica con lo stesso nome, viene creato un altro file di snapshot. È possibile avere solo fino a 10 snapshot per la stessa app per la logica. Se si supera questo limite, viene visualizzato l'errore seguente: Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host)) Per risolvere questo errore, eliminare i file snapshot aggiuntivi dal contenitore di archiviazione. |
| local.settings.json | File | Contiene impostazioni dell'app, stringhe di connessione e altre impostazioni usate dai flussi di lavoro durante l'esecuzione in locale. In altre parole, queste impostazioni e valori si applicano solo quando si eseguono i progetti nell'ambiente di sviluppo locale. Durante la distribuzione in Azure, i file e le impostazioni vengono ignorati e non sono inclusi nella distribuzione. Questo file archivia le impostazioni e i appSettings valori come variabili di ambiente locali usate dagli strumenti di sviluppo locali come valori. È possibile chiamare e fare riferimento a queste variabili di ambiente sia in fase di esecuzione che in fase di distribuzione usando le impostazioni e i parametridell'app. Importante: il file local.settings.json può contenere segreti, quindi assicurarsi di escludere anche questo file dal controllo del codice sorgente del progetto. |
Distribuzione di contenitori
App per la logica a tenant singolo supporta la distribuzione nei contenitori, che significa che è possibile raggruppare i flussi di lavoro dell'app per la logica ed eseguirli in cui i contenitori possono essere eseguiti. Dopo aver contenitore l'app, la distribuzione funziona principalmente come qualsiasi altro contenitore distribuito e gestito.
Per esempi che includono Azure DevOps, vedere CI/CD per contenitori.
Impostazioni e parametri dell'app
In App per la logica di Azure multi-tenant i modelli di Resource Manager rappresentano una sfida quando è necessario gestire le variabili di ambiente per le app per la logica in vari ambienti di sviluppo, test e produzione. Tutti gli elementi in un modello di Resource Manager sono definiti nella distribuzione. Se è necessario modificare solo una singola variabile, è necessario ridistribuire tutto.
In App per la logica di Azure a tenant singolo è possibile chiamare e fare riferimento alle variabili di ambiente in fase di esecuzione usando le impostazioni e i parametri dell'app, quindi non è necessario ridistribuire quanto più spesso.
Connettori gestiti e operazioni predefinite
L'ecosistema app per la logica di Azure offre centinaia di connettori gestiti da Microsoft e operazioni predefinite come parte di una raccolta in costante crescita che è possibile usare in App per la logica di Azure a tenant singolo. Il modo in cui Microsoft gestisce questi connettori e le operazioni predefinite rimangono principalmente uguali in App per la logica di Azure a tenant singolo.
Il miglioramento più significativo è che il servizio a tenant singolo rende anche disponibili connettori gestiti più diffusi come operazioni predefinite. Ad esempio, è possibile usare operazioni predefinite per bus di servizio di Azure, Hub eventi di Azure, SQL e altri. Nel frattempo, le versioni del connettore gestito sono ancora disponibili e continuano a funzionare.
Le connessioni create usando operazioni predefinite sono chiamate connessioni predefinite o connessioni provider di servizi. Le operazioni predefinite e le relative connessioni vengono eseguite localmente nello stesso processo che esegue i flussi di lavoro. Entrambi sono ospitati nel runtime di App per la logica riprogettata. Al contrario, le connessioni gestite o le connessioni API vengono create ed eseguite separatamente come risorse di Azure, che si distribuiscono usando i modelli di Resource Manager. Di conseguenza, le operazioni predefinite e le relative connessioni offrono prestazioni migliori a causa della loro prossimità ai flussi di lavoro. Questa progettazione funziona anche bene con le pipeline di distribuzione perché le connessioni del provider di servizi vengono incluse nello stesso artefatto di compilazione.
In Visual Studio Code, quando si usa la finestra di progettazione per sviluppare o apportare modifiche ai flussi di lavoro, il motore app per la logica genera automaticamente tutti i metadati di connessione necessari nel file connections.json del progetto. Le sezioni seguenti descrivono i tre tipi di connessioni che è possibile creare nei flussi di lavoro. Ogni tipo di connessione ha una struttura JSON diversa, che è importante comprendere perché gli endpoint cambiano quando si spostano tra ambienti.
Connessioni del provider di servizi
Quando si usa un'operazione predefinita per un servizio, ad esempio bus di servizio di Azure o Hub eventi di Azure in App per la logica di Azure a tenant singolo, si crea una connessione del provider di servizi eseguita nello stesso processo del flusso di lavoro. Questa infrastruttura di connessione è ospitata e gestita come parte della risorsa dell'app per la logica e le impostazioni dell'app archiviano le stringhe di connessione per qualsiasi operazione predefinita basata sul provider di servizi usata dai flussi di lavoro.
Nel progetto dell'app per la logica ogni flusso di lavoro ha un file workflow.json che contiene la definizione JSON sottostante del flusso di lavoro. Questa definizione del flusso di lavoro fa quindi riferimento alle stringhe di connessione necessarie nel file connections.json del progetto.
Nell'esempio seguente viene illustrato come viene visualizzata la connessione del provider di servizi per un'operazione del bus di servizio predefinita nel file connections.json del progetto:
"serviceProviderConnections": {
"{service-bus-connection-name}": {
"parameterValues": {
"connectionString": "@appsetting('servicebus_connectionString')"
},
"serviceProvider": {
"id": "/serviceProviders/serviceBus"
},
"displayName": "{service-bus-connection-name}"
},
<...>
}
Connessioni gestite
Quando si usa un connettore gestito per la prima volta nel flusso di lavoro, viene richiesto di creare una connessione API gestita per il servizio di destinazione o il sistema e autenticare l'identità. Questi connettori vengono gestiti dall'ecosistema di connettori condivisi in Azure. Le connessioni API esistono ed eseguono come risorse separate in Azure.
In Visual Studio Code, mentre si continua a creare e sviluppare il flusso di lavoro usando la finestra di progettazione, il motore app per la logica crea automaticamente le risorse necessarie in Azure per i connettori gestiti nel flusso di lavoro. Il motore aggiunge automaticamente queste risorse di connessione al gruppo di risorse di Azure progettato per contenere l'app per la logica.
Nell'esempio seguente viene illustrato come viene visualizzata una connessione API per il connettore del bus di servizio gestito nel file connections.json del progetto:
"managedApiConnections": {
"{service-bus-connection-name}": {
"api": {
"id": "/subscriptions/{subscription-ID}/providers/Microsoft.Web/locations/{region}/managedApis/servicebus"
},
"connection": {
"id": "/subscriptions/{subscription-ID}/resourcegroups/{resource-group-name}/providers/Microsoft.Web/connections/servicebus"
},
"connectionRuntimeUrl": "{connection-runtime-URL}",
"authentication": {
"type": "Raw",
"scheme": "Key",
"parameter": "@appsetting('servicebus_1-connectionKey')"
},
},
<...>
}
connessioni Funzioni di Azure
Per chiamare le funzioni create e ospitate in Funzioni di Azure, usare l'operazione di Funzioni di Azure predefinita. I metadati di connessione per le chiamate Funzioni di Azure sono diversi da altre connessioni predefinite. Questi metadati vengono archiviati nel file connections.json del progetto dell'app per la logica, ma è diverso:
"functionConnections": {
"{function-operation-name}": {
"function": {
"id": "/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/sites/{function-app-name}/functions/{function-name}"
},
"triggerUrl": "{function-url}",
"authentication": {
"type": "QueryString",
"name": "Code",
"value": "@appsetting('azureFunctionOperation_functionAppKey')"
},
"displayName": "{functions-connection-display-name}"
},
<...>
}
Authentication
In App per la logica a tenant singolo, il modello di hosting per i flussi di lavoro dell'app per la logica è un singolo tenant in cui i carichi di lavoro traggono vantaggio da più isolamento rispetto al modello multi-tenant. Inoltre, il runtime di App per la logica di Azure a tenant singolo è portatile, il che significa che è possibile eseguire i flussi di lavoro in altri ambienti, ad esempio in locale in Visual Studio Code. Questa progettazione richiede comunque un modo per autenticare l'identità delle app per la logica in modo che possano accedere all'ecosistema del connettore gestito in Azure. Le app necessitano anche delle autorizzazioni corrette per eseguire operazioni quando si usano connessioni gestite.
Per impostazione predefinita, ogni app per la logica basata su tenant singolo dispone di un'identità gestita assegnata dal sistema automaticamente. Questa identità differisce dalle credenziali di autenticazione o dalla stringa di connessione usata per la creazione di una connessione. In fase di esecuzione, l'app per la logica usa questa identità per autenticare le connessioni tramite i criteri di accesso di Azure. Se si disabilita questa identità, le connessioni non funzioneranno in fase di esecuzione.
Le sezioni seguenti forniscono altre informazioni sui tipi di autenticazione che è possibile usare per autenticare le connessioni gestite, in base alla posizione in cui viene eseguita l'app per la logica. Per ogni connessione gestita, il file connections.json del progetto dell'app per la logica ha un authentication oggetto che specifica il tipo di autenticazione che l'app per la logica può usare per autenticare tale connessione gestita.
Identità gestita
Per un'app per la logica ospitata ed eseguita in Azure, un'identità gestita è il tipo di autenticazione predefinito e consigliato da usare per l'autenticazione delle connessioni gestite ospitate ed eseguite in Azure. Nel file connections.json del progetto dell'app per la logica la connessione gestita ha un authentication oggetto che specifica ManagedServiceIdentity come tipo di autenticazione:
"authentication": {
"type": "ManagedServiceIdentity"
}
Notifica non elaborata
Per le app per la logica eseguite nell'ambiente di sviluppo locale con Visual Studio Code, le chiavi di autenticazione non elaborate vengono usate per autenticare le connessioni gestite ospitate ed eseguite in Azure. Queste chiavi sono progettate solo per l'uso dello sviluppo, non di produzione e hanno una scadenza di 7 giorni. Nel file connections.json del progetto dell'app per la logica, la connessione gestita ha un authentication oggetto specifica le informazioni di autenticazione seguenti:
"authentication": {
"type": "Raw",
"scheme": "Key",
"parameter": "@appsetting('connectionKey')"
}