Distribuzione da DevOps per le applicazioni di App per la logica di Azure a tenant singolo
Si applica: 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ù rapido e sicuro usando strumenti e processi DevOps.
Questo articolo offre un'introduzione e una panoramica dell'esperienza di integrazione continua e distribuzione continua (CI/CD) corrente per App per la logica di Azure a tenant singolo.
Tenant singolo e multi-tenant
Nella App per la logica di Azure multi-tenant la distribuzione delle risorse si basa sui modelli di Azure Resource Manager (modelli arm), che combinano e gestiscono il provisioning delle risorse sia per le app per la logica che per 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 tenant singolo riprogettato. Questo runtime usa l'estendibilità del modello di estendibilità Funzioni di Azure ed è ospitato come estensione nel runtime di Funzioni di Azure. Questa progettazione offre portabilità, flessibilità e prestazioni maggiori per le app per la logica, oltre ad altre funzionalità e vantaggi ereditati dalla piattaforma Funzioni di Azure e dall'ecosistema di servizi app Azure.
Ad esempio, è possibile creare un pacchetto del runtime e dei flussi di lavoro in contenitori riprogettati come parte dell'app per la logica. È possibile usare passaggi o attività generici 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 inserire in contenitori 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 usate per un'app generica. È anche possibile usufruire di un'esperienza più coerente per la creazione di pipeline di distribuzione nei progetti di app e per l'esecuzione dei test e delle convalide necessarie prima della pubblicazione nell'ambiente di produzione. Indipendentemente da quale stack di tecnologie si usa, è possibile distribuire app per la logica usando gli strumenti scelti.
Funzionalità di distribuzione DevOps
Il App per la logica di Azure a tenant singolo eredita molte funzionalità e vantaggi dalla piattaforma Funzioni di Azure e dall'ecosistema di servizi app Azure. Questi aggiornamenti includono un modello di distribuzione completamente nuovo e altri modi per usare DevOps per i flussi di lavoro dell'app per la logica.
Sviluppo e test in locale
Quando si usa Visual Studio Code con l'estensione App per la logica di Azure (Standard), è possibile sviluppare, compilare ed eseguire flussi di lavoro di app per la logica basati su tenant singolo nell'ambiente di sviluppo senza dover eseguire la distribuzione 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 notevole vantaggio rispetto al modello multi-tenant, che richiede lo sviluppo rispetto a 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, comprimere e distribuire l'app separatamente come artefatto non modificabile in ambienti diversi. I flussi di lavoro delle app per la logica in genere hanno "codice dell'applicazione" che si aggiorna più spesso dell'infrastruttura sottostante. Separando questi livelli, è possibile concentrarsi maggiormente sulla creazione del flusso di lavoro dell'app per la logica e sulla spesa minore per distribuire le risorse necessarie in più ambienti.
Struttura delle risorse dell'app per la logica
Nel modello di App per la logica di Azure multi-tenant la struttura delle risorse dell'app per la logica a consumo può includere solo un singolo flusso di lavoro. A causa di questa relazione uno-a-uno, sia l'app per la logica che il flusso di lavoro vengono spesso considerati e a cui viene fatto riferimento come sinonimo. Tuttavia, nel modello di 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 nella stessa app per la logica i flussi di lavoro possono condividere e riutilizzare altre risorse. I flussi di lavoro nella stessa app per la logica e nello stesso tenant offrono anche prestazioni migliorate a causa di questa tenancy condivisa e della vicinanza tra loro. Questa struttura di risorse è simile 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 ai App per la logica di Azure a tenant singolo.
Struttura del progetto dell'app per la logica
In Visual Studio Code il progetto di app per la logica ha uno dei tipi seguenti:
- Basato su bundle di estensioni (Node.js), ovvero il tipo predefinito
- Basato su pacchetti NuGet (.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 l'esecuzione di un progetto basato su NuGet per l'app, ad esempio quando si vogliono sviluppare ed eseguire operazioni predefinite personalizzate. Per altre informazioni sulla conversione del progetto per l'uso di NuGet, vedere Abilitare la creazione di connettori predefiniti.
Per il progetto predefinito basato su bundle, 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 file extensions.json, launch.json, settings.jsone tasks.json. |
| Elementi | Cartella | Contiene elementi dell'account di integrazione definiti e usati nei flussi di lavoro che supportano scenari business-to-business (B2B). 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. |
| fase di progettazione del flusso di lavoro | Cartella | Contiene i file di impostazioni correlati all'ambiente di sviluppo. |
| .funcignore | file | Contiene informazioni correlate all' Azure Functions Core Tools. |
| connections.json | file | Contiene i metadati, gli endpoint e le chiavi per tutte 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 che tutti i flussi di lavoro nella stessa app per la logica usano durante l'esecuzione, sia in locale sia in Azure. Nota: quando si crea l'app per la logica, Visual Studio Code crea un file di backup host.snapshot.*.json 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 fino a 10 snapshot per la stessa app per la logica. Se si supera questo limite, verrà 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 di 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, il file e le impostazioni vengono ignorati e non sono inclusi nella distribuzione. Questo file archivia le impostazioni e i valori come variabili di ambiente locali usati dagli strumenti di sviluppo locali come valori di appSettings. È possibile chiamare e fare riferimento a queste variabili di ambiente sia in fase di runtime che in fase di distribuzione usando le impostazioni e i parametri dell’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
L'App per la logica di Azure a tenant singolo supporta la distribuzione in contenitori, il che significa che è possibile inserire in contenitori i flussi di lavoro dell'app per la logica ed eseguirli dove possono essere eseguiti i contenitori. Dopo aver in contenitori 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
Nei App per la logica di Azure multi-tenant i modelli arm 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 in fase di 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 con frequenza.
Connettori gestiti e operazioni predefinite
L'ecosistema di App per la logica di Azure offre centinaia di connettori gestiti da Microsoft e operazioni predefinite come parte di una raccolta in continua 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 per lo più uguali in App per la logica di Azure a tenant singolo.
Il miglioramento più significativo è che il servizio a tenant singolo rende disponibili anche 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 tramite operazioni predefinite sono denominate connessioni predefinite o connessioni del 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 riprogettata di App per la logica. Al contrario, le connessioni gestite o le connessioni API vengono create ed eseguite separatamente come risorse di Azure, distribuite usando i modelli di Resource Manager. Di conseguenza, le operazioni predefinite e le relative connessioni offrono prestazioni migliori grazie alla vicinanza ai flussi di lavoro. Questa progettazione funziona anche bene con le pipeline di distribuzione perché le connessioni del provider di servizi vengono inserite 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 di App per la logica genera automaticamente tutti i metadati di connessione necessari nel file di 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 passa da un ambiente all'altro.
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 archivia le stringa di connessione per qualsiasi operazione predefinita basata sul provider di servizi usata dai flussi di lavoro.
Importante
Quando si dispone di informazioni riservate, ad esempio stringa di connessione che includono nomi utente e password, assicurarsi di usare il flusso di autenticazione più sicuro disponibile. Ad esempio, Microsoft consiglia di autenticare l'accesso alle risorse di Azure con un'identità gestita quando è disponibile il supporto e assegnare un ruolo con il privilegio minimo richiesto.
Se questa funzionalità non è disponibile, assicurarsi di proteggere stringa di connessione tramite altre misure, ad esempio Azure Key Vault, che è possibile usare con le impostazioni dell'app. È quindi possibile fare riferimento direttamente a stringhe sicure, ad esempio stringa di connessione e chiavi. Analogamente ai modelli arm, in cui è possibile definire le variabili di ambiente in fase di distribuzione, è possibile definire le impostazioni dell'app all'interno della definizione del flusso di lavoro dell'app per la logica. È quindi possibile acquisire valori di infrastruttura generati dinamicamente, ad esempio endpoint di connessione, stringhe di archiviazione e altro ancora. Per altre informazioni, vedere Tipi di applicazione per Microsoft Identity Platform.
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 stringa di connessione necessarie nel file di connections.json del progetto.
Nell'esempio seguente viene illustrato come viene visualizzata la connessione del provider di servizi per un'operazione di 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 o il sistema di destinazione e autenticare l'identità. Questi connettori vengono gestiti dall'ecosistema di connettori condivisi in Azure. Le connessioni API esistono ed vengono eseguite 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 di 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.
L'esempio seguente mostra come viene visualizzata una connessione API per il connettore bus di servizio gestito nel file di 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 di connections.json del progetto dell'app per la logica, ma hanno un aspetto 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}"
},
<...>
}
Autenticazione
Nell'App per la logica di Azure 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 un maggiore isolamento rispetto al modello multi-tenant. Inoltre, il runtime di App per la logica di Azure a tenant singolo è portabile, il che significa che è possibile eseguire i flussi di lavoro in altri ambienti, ad esempio localmente in Visual Studio Code. Tuttavia, questa progettazione richiede un modo per autenticare l'identità delle app per la logica in modo da poter accedere all'ecosistema di connettori gestiti 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 ha un'identità gestita assegnata automaticamente dal sistema. Questa identità è diversa dalle credenziali di autenticazione o stringa di connessione usate 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 di 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 la 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 autenticare le connessioni gestite ospitate ed eseguite in Azure. Nel file di 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"
}
Raw
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 lo sviluppo, non per la produzione e hanno una scadenza di 7 giorni. Nel file di connections.json del progetto dell'app per la logica, la connessione gestita ha un authentication oggetto che specifica le informazioni di autenticazione seguenti:
"authentication": {
"type": "Raw",
"scheme": "Key",
"parameter": "@appsetting('connectionKey')"
}