Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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 chiave consentono di raggruppare le chiavi correlate usando un prefisso comune nei nomi. I prefissi possono includere più segmenti separati da delimitatori, ad /
esempio o :
, formando uno spazio dei nomi gerarchico. Questo approccio è utile quando si archiviano chiavi di configurazione per più applicazioni o microservizi all'interno di un singolo archivio di Configurazione app.
È importante ricordare che le chiavi fanno riferimento direttamente al codice dell'applicazione per recuperare i valori corrispondenti. Pertanto, le chiavi devono rimanere stabili per evitare modifiche al codice. Se necessario, è possibile usare il provider di Configurazione app per tagliare i prefissi chiave in fase di esecuzione.
Le etichette consentono di creare varianti di una chiave, ad esempio versioni diverse o impostazioni specifiche dell'ambiente. Assegnando etichette, è possibile mantenere più valori per la stessa chiave. L'applicazione può quindi recuperare diversi set di valori chiave specificando l'etichetta appropriata, consentendo ai riferimenti di chiave nel codice di rimanere coerenti.
Composizioni chiave-valore
Configurazione app considera ogni chiave archiviata all'interno di essa come entità indipendente. Non deduce relazioni tra chiavi o eredita valori in base alla gerarchia delle chiavi. Tuttavia, è possibile aggregare più set di chiavi in modo efficace usando etichette combinate con lo stack di configurazione nell'applicazione.
Si consideri un esempio in cui si dispone di un'impostazione di configurazione denominata TestApp:MySetting, il cui valore varia a seconda dell'ambiente. È possibile creare due chiavi con lo stesso nome, ma assegnare etichette diverse, una senza etichetta (impostazione predefinita) e un'altra etichettata Sviluppo. La chiave senza etichetta contiene il valore predefinito, mentre la chiave etichettata contiene il valore specifico dell'ambiente.
Nel codice dell'applicazione si caricano prima i valori chiave predefiniti (senza etichetta), quindi si caricano i valori chiave-valore specifici dell'ambiente usando l'etichetta Sviluppo . Quando si carica il secondo set, tutte le chiavi corrispondenti sovrascrivono i valori caricati in precedenza. Questo approccio consente di "impilare" più set di configurazione, con l'ultimo valore caricato che ha la precedenza. I provider di configurazione delle app attraverso i linguaggi e le piattaforme supportati offrono questa capacità di stacking.
L'esempio seguente illustra come implementare la composizione chiave-valore in un'applicazione .NET:
configBuilder.AddAzureAppConfiguration(options => {
options.Connect(new Uri("<your-app-config-endpoint>"), new DefaultAzureCredential())
// Load all keys that start with `TestApp:` and compose with two different labels
.Select(keyFilter: "TestApp:*", labelFilter: LabelFilter.Null)
.Select(keyFilter: "TestApp:*", labelFilter: "Development");
});
Un esempio completo è disponibile in Usare etichette per fornire configurazioni diverse per ambienti diversi.
Aggiornamento della configurazione
Configurazione app di Azure supporta l'aggiornamento della configurazione dinamica senza richiedere un riavvio dell'applicazione. I «provider di configurazione delle app» possono monitorare le modifiche di configurazione usando due approcci:
Monitoraggio di tutte le chiavi selezionate
In questo approccio, il provider monitora tutte le chiavi selezionate. Se viene rilevata una modifica in uno dei valori chiave selezionati, l'intera configurazione viene ricaricata. Questo approccio garantisce aggiornamenti immediati senza richiedere modifiche chiave aggiuntive.
configBuilder.AddAzureAppConfiguration(options =>
{
options.Connect(new Uri("<your-app-config-endpoint>"), new DefaultAzureCredential())
// Load all keys that start with `TestApp:` and have no label
.Select(keyFilter: "TestApp:*", labelFilter: LabelFilter.Null)
.ConfigureRefresh(refreshOptions =>
{
// Trigger full configuration refresh when any selected key changes.
refreshOptions.RegisterAll();
});
});
Monitoraggio di una chiave sentinella
In alternativa, è possibile monitorare una singola chiave, spesso definita chiave sentinel. Questo approccio è utile quando si aggiornano più valori chiave. Aggiornando la chiave sentinel solo dopo il completamento di tutte le altre modifiche di configurazione, assicurarsi che l'applicazione ricarica la configurazione una sola volta, mantenendo la coerenza.
configBuilder.AddAzureAppConfiguration(options =>
{
options.Connect(new Uri("<your-app-config-endpoint>"), new DefaultAzureCredential())
// Load all keys that start with `TestApp:` and have no label
.Select(keyFilter: "TestApp:*", labelFilter: LabelFilter.Null)
.ConfigureRefresh(refreshOptions =>
{
// Trigger full configuration refresh only if the `SentinelKey` changes.
refreshOptions.Register("SentinelKey", refreshAll: true);
});
});
Entrambi gli approcci sono disponibili tramite provider di Configurazione app in linguaggi e piattaforme supportati.
Per ridurre il rischio di incoerenze di configurazione, usare gli snapshot di configurazione per garantire l'integrità della configurazione.
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 di Azure, è possibile eseguire l'autenticazione usando una stringa di connessione o un ID Microsoft Entra. Anche se le stringhe di connessione sono facilmente disponibili nel portale di Azure, contengono informazioni sulle credenziali e devono essere considerate come segreti. Se si sceglie questo approccio, archiviare la stringa di connessione in modo sicuro in Azure Key Vault e assicurarsi che l'applicazione esegua l'autenticazione in Key Vault per recuperarla.
Un approccio più sicuro e consigliato consiste nell'usare l'autenticazione microsoft Entra ID. Se l'applicazione è ospitata in Azure, ad esempio nel servizio Azure Kubernetes, nel servizio app o in Funzioni di Azure, è possibile usare le identità gestite fornite dall'ID Microsoft Entra. Le identità gestite eliminano la necessità di gestire i segreti in modo esplicito. Con questo metodo, l'applicazione richiede solo l'URL dell'endpoint di Configurazione app, che può essere incorporato in modo sicuro nel codice dell'applicazione o nei file di configurazione.
Per maggiori informazioni, 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 vuoi aggiornare l'applicazione o aggiungere un nuovo pod al cluster AKS, hai la possibilità di trasferire i dati da Configurazione dell'applicazione al cluster Kubernetes usando Helm mediante 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 frequentemente. Specificare un nuovo intervallo di aggiornamento usando il
SetRefreshInterval
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 si adotta Configuration 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à di importazione 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 altre 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 usare 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 altre 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. È anche possibile fare riferimento al codice di esempio per la configurazione di applicazioni 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 dall'archivio 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 l'importazione di configurazione app Azure, un'attività della pipeline di Azure, nelle pipeline di compilazione o versione per la sincronizzazione dei dati.
- Per altri utenti, è possibile importare i 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.