Procedure consigliate per Configurazione app di Azure

Questo articolo illustra i modelli e le procedure consigliate comuni quando si usa la Configurazione app di Azure.

Raggruppamenti chiave

Configurazione app offre due opzioni per organizzare le chiavi:

• Prefissi chiave
• Etichette

È possibile usare una o entrambe le opzioni per raggruppare le chiavi.

I prefissi delle chiavi sono le parti iniziali delle chiavi. È possibile raggruppare logicamente un set di chiavi usando lo stesso prefisso nei nomi. I prefissi possono contenere più componenti connessi da un delimitatore, ad esempio /, simile a un percorso URL, per formare uno spazio dei nomi. Tali gerarchie sono utili quando si archiviano chiavi per molte applicazioni e microservizi in un unico archivio di Configurazione app.

Un aspetto importante da tenere in considerazione è che le chiavi sono i riferimenti del codice dell'applicazione per recuperare i valori delle impostazioni corrispondenti. Le chiavi non devono essere modificate, oppure è necessario modificare il codice ogni volta che si verifica.

Le etichette sono un attributo delle chiavi. Le etichette vengono usate per creare varianti di una chiave. Ad esempio, è possibile assegnare etichette a più versioni di una chiave. Una versione potrebbe essere un'iterazione, un ambiente o altre informazioni contestuali. L'applicazione può richiedere un set completamente diverso di valori chiave specificando un'altra etichetta. Di conseguenza, tutti i riferimenti chiave rimangono invariati nel codice.

Composizioni chiave-valore

Configurazione app considera tutte le chiavi archiviate come entità indipendenti. Configurazione app non tenta di dedurre alcuna relazione tra le chiavi, né di ereditare valori chiave in base alla gerarchia. È tuttavia possibile aggregare più set di chiavi usando etichette abbinate con il raggruppamento correttamente configurato nel codice dell'applicazione.

Di seguito è descritto un esempio. Si supponga di avere un'impostazione denominata Asset1, il cui valore può variare in base all'ambiente di sviluppo. Si crea una chiave denominata "Asset1" con un'etichetta vuota e un'etichetta denominata "Sviluppo". Nella prima etichetta si inserisce il valore predefinito per Asset1 e si inserisce un valore specifico per "Development" in quest'ultimo.

Nel codice si recuperano prima i valori chiave senza etichette, e successivamente si recupera lo stesso set di valori chiave una seconda volta, con l'etichetta "Sviluppo". Quando si recuperano i valori la seconda volta, i valori precedenti delle chiavi vengono sovrascritti. Il sistema di configurazione .NET consente di "raggruppare" più set di dati di configurazione tra loro. Se una chiave è presente in più set, viene usato l'ultimo set che la contiene. Con un framework di programmazione moderno, ad esempio .NET, si ottiene gratuitamente questa capacità di raggruppamento se si usa un provider di configurazione nativo per accedere a Configurazione app. Il frammento di codice seguente illustra come implementare il raggruppamento in un'applicazione .NET:

// Augment the ConfigurationBuilder with Azure App Configuration
// Pull the connection string from an environment variable
configBuilder.AddAzureAppConfiguration(options => {
    options.Connect(configuration["connection_string"])
           .Select(KeyFilter.Any, LabelFilter.Null)
           .Select(KeyFilter.Any, "Development");
});

Un esempio completo è disponibile in Usare etichette per fornire configurazioni diverse per ambienti diversi.

Riferimenti a dati esterni

Configurazione app è progettata per archiviare tutti i dati di configurazione che normalmente si salvano nei file di configurazione o nelle variabili di ambiente. Tuttavia, alcuni tipi di dati possono essere più adatti per risiedere in altre sorgenti. Ad esempio, archiviare segreti in Key Vault, file in Archiviazione di Azure, informazioni di appartenenza nei gruppi di Microsoft Entra o elenchi di clienti in un database.

È comunque possibile sfruttare Configurazione app salvando un riferimento a dati esterni in un valore chiave. È possibile usare il tipo di contenuto per distinguere ogni origine dati. Quando l'applicazione legge un riferimento, carica i dati effettivi dall'origine a cui si fa riferimento, presupponendo che disponga dell'autorizzazione necessaria per l'origine. Se si modifica il percorso dei dati esterni, è sufficiente aggiornare il riferimento in Configurazione app, anziché aggiornare e ridistribuire l'intera applicazione.

La funzionalità di riferimento di Key Vault di Configurazione app è un esempio in questo caso. Consente di aggiornare i segreti necessari per un'applicazione in base alle esigenze, mentre i segreti sottostanti rimangono in Key Vault.

Avvio di Configurazione app

Per accedere a un archivio di Configurazione app, è possibile usare la relativa stringa di connessione, disponibile nel portale di Azure. Le stringhe di connessione vengono considerate segreti, poiché contengono informazioni sulle credenziali. Questi segreti devono essere archiviati in Azure Key Vault e il codice deve eseguire l'autenticazione in Key Vault per recuperarli.

Un'opzione migliore consiste nell'usare la funzionalità identità gestite in Microsoft Entra ID. Con le identità gestite, si necessita solo dell'URL dell'endpoint di Configurazione app per avviare l'accesso all'archivio di Configurazione app. È possibile incorporare l'URL nel codice dell'applicazione (ad esempio, nel file appsettings.json) . Per dettagli, vedere Usare le identità gestite per accedere a Configurazione app.

Accesso del servizio Azure Kubernetes a Configurazione app

Per i carichi di lavoro ospitati nel servizio Azure Kubernetes (AKS) sono disponibili le opzioni seguenti per accedere a Configurazione app di Azure. Queste opzioni si applicano anche a Kubernetes in generale.

• Installare il provider Kubernetes Configurazione app di Azure nel cluster del servizio Azure Kubernetes. Il provider Kubernetes viene eseguito come pod nel cluster. Può costruire ConfigMap e Segreti dai riferimenti chiave-valore e Key Vault nell'archivio di Configurazione app. ConfigMap e Secret sono utilizzabili come variabili di ambiente o file montati, senza la richiesta di modificare il codice dell'applicazione. Se nello stesso cluster del servizio Azure Kubernetes sono in esecuzione più applicazioni, tutte possono accedere a ConfigMap e Segreti generati, eliminando la necessità di richieste singole a Configurazione app. Il provider Kubernetes supporta anche gli aggiornamenti della configurazione dinamica. Questa è l'opzione consigliata, se possibile.

• Aggiornare l'applicazione per usare le librerie del provider di Configurazione app di Azure. Le librerie provider sono disponibili in molti framework e linguaggi, ad esempio ASP.NET, .NET, Java Spring, JavaScript/Node.js e Python. Questo approccio offre l'accesso completo alle funzionalità di Configurazione app, tra cui la configurazione dinamica e la gestione delle funzionalità. È possibile controllare in modo granulare i dati da caricare e da quale archivio di Configurazione app, per ogni applicazione.

• Integrare la distribuzione di Kubernetes con Helm. Se non si desidera aggiornare l'applicazione o aggiungere un nuovo pod al cluster del servizio Azure Kubernetes, è possibile trasferire i dati da Configurazione app al cluster Kubernetes, usando Helm tramite distribuzione. Questo approccio consente all'applicazione di continuare ad accedere alla configurazione dalle variabili e dai segreti di Kubernetes. È possibile eseguire l'aggiornamento Helm ogni volta che si vuole che l'applicazione includa nuove modifiche alla configurazione.

Accesso di Servizio app o Funzioni di Azure a Configurazione app

Usare il provider di Configurazione app o le librerie SDK per accedere a Configurazione app direttamente nell'applicazione. Questo approccio offre l'accesso completo alle funzionalità di Configurazione app, tra cui la configurazione dinamica e la gestione delle funzionalità. L'applicazione in esecuzione in Servizio app o in Funzioni di Azure può ottenere l'accesso all'archivio di Configurazione app tramite uno dei metodi seguenti:

• Abilitare l'identità gestita nel Servizio app o in Funzioni di Azure e concedere l'accesso all'archivio di Configurazione app. Per maggiori informazioni, vedere Usare le identità gestite per accedere a Configurazione app.
• Archiviare la stringa di connessione all'archivio di Configurazione app nelle impostazioni dell'Applicazione di Servizio app o Funzioni di Azure. Per una maggiore sicurezza, archiviare la stringa di connessione in Key Vault e farvi riferimento dal servizio app o da Funzioni di Azure.

È anche possibile rendere i dati di Configurazione app accessibili all'applicazione come impostazioni dell'applicazione o variabili di ambiente. Con questo approccio, non è necessario modificare il codice dell'applicazione.

• Aggiungere riferimenti ai dati di Configurazione app in Impostazioni dell'applicazione di Servizio app o Funzioni di Azure. Configurazione app offre strumenti per esportare una raccolta di valori chiave come riferimenti contemporaneamente. Per maggiori informazioni, vedere Usare i riferimenti di Configurazione app per il Servizio app e Funzioni di Azure.
• Esportare i dati di Configurazione app alle impostazioni dell'applicazione del Servizio app o di Funzioni di Azure senza selezionare l'opzione esporta-come-riferimento. Esportare nuovamente i dati ogni volta che si apportano nuove modifiche in Configurazione app, affinché l'applicazione rilevi la modifica.

Ridurre le richieste effettuate a Configurazione app

Un numero eccessivo di richieste a Configurazione app può comportare addebiti per limitazione o eccedenza. Per ridurre il numero di richieste effettuate:

• Aumentare l'intervallo di aggiornamento, soprattutto se i valori di configurazione non cambiano di frequente. Specificare un nuovo intervallo di aggiornamento usando il SetCacheExpiration metodo.

• Osservare una singola chiave sentinel, anzichè controllare le singole chiavi. Aggiornare tutte le configurazioni solo se cambia la chiave sentinel. Per un esempio, vedere Usare la configurazione dinamica in un'app ASP.NET Core.

• Usare il provider Kubernetes Configurazione app se si eseguono più carichi di lavoro in un cluster Kubernetes, ognuno dei quali esegue il pull dei dati da Configurazione app singolarmente. Il provider Kubernetes recupera i dati da Configurazione app e lo rende disponibile come ConfigMap e segreti di Kubernetes. In questo modo, i carichi di lavoro possono accedere ai dati tramite ConfigMaps e Segreti senza dover eseguire il pull dei dati da Configurazione app separatamente.

• Abilitare la replica geografica dell'archivio di Configurazione app e distribuire le richieste tra più repliche. Ad esempio, usare una replica diversa da ogni area geografica per un'applicazione distribuita a livello globale. Ogni replica di Configurazione app ha una quota di richiesta separata. Questa configurazione offre un modello per la scalabilità e la resilienza avanzata rispetto alle interruzioni temporanee e a livello di area.

Importazione dei dati di configurazione in Configurazione app

Configurazione app offre la possibilità di importarein blocco le impostazioni di configurazione dai file di configurazione correnti usando il portale di Azure o l'interfaccia della riga di comando. È anche possibile usare le stesse opzioni per esportare i valori chiave da Configurazione app, ad esempio tra gli archivi correlati. Se è stata adottata la Configurazione come codice e si gestiscono le configurazioni in GitHub o Azure DevOps, è possibile configurare l'importazione continua dei file di configurazione usando GitHub Actions o l'attività Push di Azure Pipeline.

Distribuzione in più aree in Configurazione app

Se l'applicazione viene distribuita in più aree, è consigliabile abilitare la replica geografica dell'archivio di Configurazione app. È possibile consentire all'applicazione di connettersi principalmente alla replica corrispondente all'area in cui vengono distribuite le istanze dell'applicazione e consentire il failover alle repliche in altre aree. Questa configurazione riduce al minimo la latenza tra l'applicazione e la Configurazione app, distribuisce il carico poiché ogni replica ha quote di limitazione separate e migliora la resilienza dell'applicazione in caso di interruzioni temporanee e a livello di area. Per maggiori informazioni, vedere Resilienza e Ripristino di emergenza.

Creazione di applicazioni con resilienza elevata

Le applicazioni spesso si basano sulla configurazione per iniziare, rendendo critica la disponibilità elevata di Configurazione app di Azure. Per migliorare la resilienza, le applicazioni devono sfruttare le funzionalità di affidabilità di Configurazione app e prendere in considerazione le misure seguenti in base ai requisiti specifici.

• Effettuare il provisioning nelle aree con il supporto della zona di disponibilità di Azure. Le zone di disponibilità consentono alle applicazioni di essere resilienti alle interruzioni del data center. Configurazione app offre ridondanza della zona per tutti i clienti senza costi aggiuntivi. È consigliabile creare l'archivio di Configurazione app nelle regioni con supporto per le zone di disponibilità. È possibile trovare un elenco di regioni in cui Configurazione app ha abilitato il supporto della zona di disponibilità.
• Abilitare la replica geografica e consentire all'applicazione di eseguire il failover o distribuire il carico tra le repliche. Questa configurazione offre un modello per la scalabilità e la resilienza avanzata in caso di errori temporanei e interruzioni a livello di area. Per maggiori informazioni, vedere Resilienza e Ripristino di emergenza.
• Distribuire la configurazione con procedure di distribuzione sicure. Le modifiche di configurazione non corrette o accidentali possono causare spesso tempi di inattività dell'applicazione. È consigliabile evitare di apportare modifiche di configurazione che influiscono direttamente sulla produzione, ad esempio dal portale di Azure, quando possibile. Nelle procedure di distribuzione sicura (SDP), si usa un modello di distribuzione con esposizione progressiva per ridurre al minimo il potenziale raggio di esplosione dei problemi causati dalla distribuzione. Se si adotta SDP, è possibile compilare e testare uno snapshot di configurazione prima di distribuirlo nell'ambiente di produzione. Durante la distribuzione, è possibile aggiornare le istanze dell'applicazione per selezionare progressivamente il nuovo snapshot. Se vengono rilevati problemi, è possibile eseguire il rollback della modifica ridistribuendo lo snapshot LKG (Known Good). Lo snapshot non è modificabile, e ciò garantisce la coerenza in tutte le distribuzioni. È possibile usare gli snapshot insieme alla configurazione dinamica. Usare uno snapshot per la configurazione di base e la configurazione dinamica per gli override della configurazione di emergenza e i flag di funzionalità.
• Includere la configurazione con l'applicazione. Per assicurarsi che l'applicazione abbia sempre accesso a una copia della configurazione o per evitare completamente una dipendenza di runtime da Configurazione app, è possibile eseguire il pull della configurazione da Configurazione app durante la fase di compilazione o di rilascio e includerla con l'applicazione. Per altre informazioni, vedere esempi di integrazione di Configurazione app con la pipeline CI/CD o con la distribuzione di Kubernetes.
• Usare i provider di Configurazione app. Le applicazioni svolgono un ruolo fondamentale nel raggiungere una resilienza elevata perché possono tenere conto dei problemi che si verificano durante il runtime, ad esempio problemi di rete e rispondere più rapidamente agli errori. I provider di Configurazione app offrono una gamma di funzionalità di resilienza predefinite, tra cui l'individuazione automatica delle repliche, il failover di replica, i tentativi di avvio con timeout personalizzabili, la configurazione del servizio di memorizzazione nella cache e strategie adattive per l'aggiornamento affidabile della configurazione. È consigliabile usare provider di Configurazione app per trarre vantaggio da queste funzionalità. In caso contrario, è consigliabile implementare funzionalità simili nella soluzione personalizzata per ottenere il massimo livello di resilienza.

Applicazioni client in Configurazione app

Quando si usa Configurazione app nelle applicazioni client, assicurarsi di considerare due fattori principali. Prima di tutto, se si usa la stringa di connessione in un'applicazione client, si rischia di esporre la chiave di accesso dell'archivio di Configurazione app al pubblico. In secondo luogo, la scalabilità tipica di un'applicazione client potrebbe causare richieste eccessive all'archivio di Configurazione app, causando addebiti per eccedenza o limitazioni. Per maggiori informazioni sulla limitazione, vedere le domande frequenti.

Per risolvere questi problemi, è consigliabile usare un servizio proxy tra le applicazioni client e l'archivio di Configurazione app. Il servizio proxy può eseguire l'autenticazione sicura con l'archivio di Configurazione app, senza problemi di sicurezza per la perdita di informazioni di autenticazione. È possibile compilare un servizio proxy usando una delle librerie del provider di Configurazione app, in modo da poter sfruttare le funzionalità dei servizi di memorizzazione nella cache e di aggiornamento predefiniti, per ottimizzare il volume delle richieste inviate a Configurazione app. Per altre informazioni sull'uso dei provider di Configurazione app, vedere gli articoli in Guide introduttive ed Esercitazioni. Il servizio proxy gestisce la configurazione dalla relativa cache alle applicazioni client in modo tale da evitare i due potenziali problemi descritti in questa sezione.

Applicazioni multi tenant in Configurazione app

Un'applicazione multi tenant è basata su un'architettura in cui un'istanza condivisa dell'applicazione serve più clienti o tenant. Ad esempio, si potrebbe avere un servizio di posta elettronica che offre agli utenti account separati ed esperienze personalizzate. L'applicazione gestisce in genere configurazioni diverse per ogni tenant. Ecco alcune considerazioni sull'architettura per usare Configurazione app in un'applicazione multi tenant.

Configurazione come Codice

La configurazione come codice è una pratica di gestione dei file di configurazione nel sistema di controllo del codice sorgente, ad esempio un archivio Git. Offre vantaggi come la tracciabilità e il processo di approvazione per eventuali modifiche alla configurazione. Se si adotta la configurazione come codice, Configurazione app include strumenti che consentono di gestire i dati di configurazione nei file e di distribuirli come parte del processo di compilazione, rilascio o CI/CD. In questo modo, le applicazioni possono accedere ai dati più recenti dagli archivi di Configurazione app.

• Per GitHub, è possibile importare file di configurazione dall’archivio GitHub nell'archivio di Configurazione app usando GitHub Actions
• Per Azure DevOps, è possibile includere Push Configurazione app di Azure, un'attività della pipeline di Azure, nelle pipeline di compilazione o di rilascio per la sincronizzazione dei dati.
• È anche possibile importare file di configurazione in Configurazione app usando l'interfaccia della riga di comando di Azure come parte del sistema CI/CD. Per maggiori informazioni, vedere az appconfig kv import.

Questo modello consente di includere passaggi di convalida e test prima di eseguire il commit dei dati in Configurazione app. Se si usano più archivi di Configurazione app, è anche possibile eseguire il push dei dati di configurazione in modo incrementale o contemporaneamente.

Passaggi successivi

• Chiavi e valori