Domande frequenti su Configurazione app di Azure

Configurazione app consente agli sviluppatori di gestire le impostazioni delle applicazioni e controllare la disponibilità delle funzionalità. Ha lo scopo di semplificare molte delle attività legate all'uso di dati di configurazione complessi.

Configurazione app supporta:

• Spazi dei nomi gerarchici
• Etichettatura
• Query estese
• Recupero in batch
• Operazioni di gestione specializzate
• Un'interfaccia utente di gestione delle funzionalità

Configurazione app completa Key Vault e nella maggior parte delle distribuzioni i due servizi devono essere usati affiancati.

Anche se Configurazione app offre sicurezza avanzata, il servizio migliore per archiviare i segreti delle applicazioni rimane Key Vault. Key Vault fornisce crittografia a livello di hardware, criteri di accesso granulari e operazioni di gestione come la rotazione dei certificati.

È possibile creare valori chiave di Configurazione app che fanno riferimento ai segreti archiviati in Key Vault. Per altre informazioni vedere Usare i riferimenti a Key Vault in un'app ASP.NET Core.

Sì. Configurazione app crittografa sempre tutti i dati in transito e inattivi. Tutte le comunicazioni di rete sono tramite TLS 1.2 o TLS 1.3. Configurazione app supporta la crittografia dei dati inattivi con chiavi gestite da Microsoft o chiavi gestite dal cliente.

Servizio app di Azure consente di definire le impostazioni delle app per ogni istanza di Servizio app. Queste impostazioni vengono trasmesse come variabili di ambiente al codice dell'applicazione. Se si desidera, è possibile associare un'impostazione a uno slot di distribuzione specifico. Per altre informazioni, vedere Configurare le impostazioni delle app.

Configurazione app di Azure, invece, consente di definire impostazioni che possono essere condivise tra più app. Sono incluse le app in esecuzione in Servizio app e altre piattaforme. Il codice dell'applicazione accede a queste impostazioni tramite i provider di configurazione per .NET e Java, tramite Azure SDK o direttamente tramite le API REST.

È possibile aggiungere riferimenti ai dati di Configurazione app in Impostazioni dell'applicazione di Servizio app. È anche possibile importare ed esportare le impostazioni da Servizio app a Configurazione app e viceversa. Questa funzionalità consente di configurare rapidamente un nuovo archivio di Configurazione app in base alle impostazioni di Servizio app esistenti. È anche possibile condividere la configurazione con un'app esistente che si basa sulle impostazioni di Servizio app.

È previsto un limite di 10 kB per un singolo valore chiave, inclusi attributi come etichetta, tipo di contenuto, tag e altri metadati. Non è previsto alcun limite per il numero di chiavi ed etichette, purché le dimensioni totali siano inferiori al limite di archiviazione.

Questo limite chiave-valore deve essere sufficiente per una singola impostazione nella maggior parte delle applicazioni. Se si ritiene che l'impostazione sia superiore a questo limite, è possibile considerare l'archiviazione dei dati altrove e aggiungere un riferimento a tali dati in Configurazione app.

Per un elenco completo dei limiti, vedere Sottoscrizione di Azure e limiti del servizio.

È possibile controllare chi può accedere a Configurazione app a livello di singolo archivio. Usare un archivio separato per ogni ambiente che richiede autorizzazioni diverse. Questo approccio offre il migliore isolamento di sicurezza.

Se non è necessario un isolamento di sicurezza tra ambienti, è possibile usare le etichette per distinguere tra i valori di configurazione. Un esempio completo è disponibile in Usare etichette per fornire configurazioni diverse per ambienti diversi.

Vedere le procedure consigliate.

Sono disponibili tre piani tariffari: Gratuito, Standard e Premium. Per informazioni dettagliate sui prezzi, vedere la pagina dei prezzi di Configurazione app.

Tutti i livelli di Configurazione app offrono funzionalità di base, tra cui impostazioni di configurazione, flag di funzionalità, riferimenti a Key Vault, snapshot di configurazione, operazioni di gestione di base, metriche e log.

Di seguito sono riportate alcune considerazioni per la scelta di un livello.

• Scopo: il livello gratuito è perfetto per valutare il servizio in ambienti non di produzione, consentendo di esplorare le funzionalità senza alcun costo. Il livello Standard è personalizzato per i casi d'uso di produzione a medio volume, offrendo un equilibrio tra prestazioni ed efficienza dei costi. Per esigenze di produzione di alto volume o di livello aziendale, il livello Premium offre il massimo livello di prestazioni e scalabilità, assicurando che le applicazioni vengano eseguite senza problemi anche con carichi elevati.

• Risorse per sottoscrizione: una risorsa è costituita da un singolo archivio di configurazione. Ogni sottoscrizione è limitata a un archivio di configurazione per regione nel livello gratuito. Le sottoscrizioni possono avere un numero illimitato di archivi di configurazione nei livelli Standard e Premium.

• Archiviazione per risorsa: nel livello gratuito, ogni archivio di configurazione è limitato a 10 MB di spazio di archiviazione regolare e 10 MB di archiviazione snapshot. Nel livello Standard ogni archivio di configurazione può usare fino a 1 GB di spazio di archiviazione regolare e un ulteriore 1 GB di archiviazione snapshot. Nel livello Premium ogni archivio di configurazione può usare fino a 4 GB di spazio di archiviazione regolare e 4 GB aggiuntivi di archiviazione snapshot.

• Cronologia revisioni: Configurazione app archivia una cronologia di tutte le modifiche apportate alle chiavi. Nel livello Gratuito questa cronologia viene archiviata per sette giorni. Nei livelli Standard e Premium, questa cronologia viene archiviata per 30 giorni.

• Quota richieste: gli archivi di livello gratuito sono limitati a 1000 richieste al giorno. Quando un archivio raggiunge 1000 richieste, restituisce il codice di stato HTTP 429 per tutte le richieste fino alla mezzanotte UTC.

  Gli archivi di livello standard sono limitati a 30.000 richieste all'ora. Una volta esaurita la quota oraria, le richieste aggiuntive possono restituire il codice di stato HTTP 429 che indica, fino alla fine dell'ora, che ci sono troppe richieste. Man mano che vengono inviate più richieste che superano la quota, una percentuale maggiore di esse può restituire il codice di stato 429.

  Gli archivi di livello premium non hanno limiti di quota per le richieste, garantendo che l'accesso all'archivio non venga mai bloccato.

• Velocità effettiva: gli archivi di Configurazione app in tutti i livelli presentano un limite di velocità effettiva. Le richieste che superano questa indennità ricevono una risposta con codice di stato HTTP 429. Gli archivi nel livello gratuito non hanno una velocità effettiva garantita.

  Gli archivi nel livello Standard consentono la frequenza di esecuzione† fino a 300 richieste al secondo (RPS) per le richieste di lettura e fino a 60 RPS per le richieste di scrittura.

  Gli archivi nel livello Premium consentono la frequenza di esecuzione† fino a 450 RPS per le richieste di lettura e fino a 100 RPS per le richieste di scrittura.

  † La frequenza di esecuzione viene in genere misurata come il numero medio di richieste gestite da un archivio Configurazione app senza limitazioni in un periodo specificato.

• Contratto di servizio: il livello Gratuito non ha un contratto di servizio. Il livello Standard ha un contratto di servizio con disponibilità del 99,9% e disponibilità del 99,95% con la replica geografica abilitata. Il livello Premium ha un contratto di servizio con disponibilità del 99,9% e disponibilità del 99,99% con la replica geografica abilitata.

• Funzionalità: tutti i livelli includono funzionalità, tra cui la crittografia con chiavi gestite da Microsoft, l'autenticazione tramite chiave di accesso o Microsoft Entra ID, il controllo degli accessi in base al ruolo di Azure, l'identità gestita, i tag del servizio e la ridondanza della zona di disponibilità. I livelli Standard e Premium offrono più funzionalità, tra cui il supporto del collegamento privato, la crittografia con chiavi gestite dal cliente, la protezione dell'eliminazione temporanea e la funzionalità di replica geografica.

• Costi: non è previsto alcun costo per l'uso di un archivio di livello Gratuito.

  Gli archivi di livello Standard hanno un addebito di utilizzo giornaliero, che include le prime 200.000 richieste ogni giorno. Le richieste aggiuntive a questa allocazione giornaliera comportano un addebito di eccedenza.

  Gli archivi di livello Premium hanno anche un addebito di utilizzo giornaliero e includono una replica. Le prime 800.000 richieste per l'origine e le prime 800.000 richieste per la replica ogni giorno sono incluse nell'addebito giornaliero. Le richieste che superano questa allocazione giornaliera comportano un addebito di eccedenza.

È possibile aggiornare un archivio di Configurazione app in qualsiasi momento, ad esempio dal livello Gratuito al livello Standard o Premium o dal livello Standard al livello Premium.

Non è possibile effettuare il downgrade di un archivio di Configurazione app, ad esempio, dal livello premium al livello standard o dal livello standard al livello gratuito. Tuttavia, è possibile creare un nuovo archivio nel livello desiderato e quindi importarvi i dati di configurazione.

I dati dei clienti archiviati in Configurazione app risiedono nell'area in cui è stato creato l'archivio di Configurazione app del cliente. I dati dei clienti vengono replicati in un'altra area solo se il cliente abilita la replica geografica per tale area. Questo vale per tutte le aree disponibili. I clienti possono spostare, copiare o accedere ai dati da qualsiasi posizione a livello globale.

Configurazione app di Azure supporta la replica geografica per migliorare la resilienza alle interruzioni a livello di area.

Configurazione app di Azure supporta zone di disponibilità di Azure per proteggere l'applicazione e i dati da errori di un singolo data center. Tutte le aree abilitate per la zona di disponibilità sono costituite da almeno tre zone di disponibilità, dove ognuna è un data center fisicamente indipendente. Per la resilienza, questo supporto in Configurazione app è abilitato per tutti i clienti senza costi aggiuntivi. Di seguito sono riportate le aree per cui in Configurazione app è stato abilitato il supporto delle zone di disponibilità. Per altre informazioni, vedere Aree di Azure con supporto per la zona di disponibilità.

Di seguito sono riportate le aree per cui in Configurazione app è stato abilitato il supporto delle zone di disponibilità.

Gli archivi di Configurazione app hanno quote di richiesta diverse in base al livello. Gli archivi di livello gratuito presentano il limite di 1.000 richieste al giorno, gli archivi di livello standard 30.000 richieste all'ora e gli archivi di livello premium non hanno limiti di richiesta, garantendo accesso ininterrotto.

Gli archivi di Configurazione app presentano limiti di velocità effettiva in base al livello. Gli archivi di livello gratuito non hanno una velocità effettiva garantita. Gli archivi di livello Standard supportano la frequenza di esecuzione fino a 300 richieste al secondo (RPS) per le operazioni di lettura e fino a 60 RPS per le operazioni di scrittura. Gli archivi di livello Premium supportano la frequenza di esecuzione fino a 450 RPS per le operazioni di lettura e fino a 100 RPS per le operazioni di scrittura.

Si supponga di avere un'applicazione con 1.000 impostazioni di configurazione. L'applicazione carica tutte queste impostazioni da Configurazione app all'avvio. Successivamente, verifica la presenza di una chiave sentinel per verificare la presenza di modifiche alla configurazione ogni 30 secondi. Sia che si eseguano istanze di Kubernetes, servizio app o vm, si supponga di avere 50 istanze dell'applicazione in esecuzione contemporaneamente.

Prima di tutto, si stimano le richieste per il monitoraggio della configurazione. Ogni istanza dell'applicazione invia una richiesta per la chiave sentinel a Configurazione app ogni 30 secondi, quindi invia 120 richieste (=3600/30) in un'ora. Dato che sono presenti 50 istanze dell'applicazione, l'applicazione invia 6.000 (=120x50) richieste totali ogni ora per il monitoraggio della configurazione. Si noti che poiché le richieste di chiavi sentinel sono frequenti e per lo più invariate, la maggior parte di esse non viene conteggiato rispetto ai limiti di quota oraria dello Store† per un archivio livelli Standard.

In secondo luogo, si stimano le richieste di caricamento/ricaricamento della configurazione. L'applicazione carica tutte le impostazioni all'avvio o ogni volta che viene rilevata una modifica della chiave sentinel. Ogni richiesta a Configurazione app può recuperare fino a 100 valori chiave, quindi richiede 10 richieste (=1000/100) per caricare tutte le impostazioni. Dato che sono presenti 50 istanze dell'applicazione, si inviano 500 richieste totali (=10x50) quando l'applicazione viene riavviata o ricaricata la configurazione.

Infine, lo metteremo insieme. Supponendo di aver aggiornato la chiave sentinel due volte entro un'ora, l'archivio di Configurazione app riceverà quindi 7.000 (=6.000+500x2) richieste totali per quell'ora. Si noti che su queste richieste, solo circa 1.000 richieste (=500x2) usano la quota oraria disponibile per un archivio di livelli Standard. Aggiornare i numeri in questo esempio in modo che corrispondano alla configurazione e alla progettazione specifiche in modo da disporre di un buffer sufficiente rispetto al limite di quota oraria.

† Archivi di livello gratuito non hanno richieste ripetute frequenti escluse dal limite giornaliero.

L'applicazione può ricevere una risposta 429 con codice di stato HTTP nelle circostanze indicate di seguito.

• Superamento della quota di richieste giornaliere per un archivio di livello gratuito.
• Superamento della quota di richieste orarie per un archivio di livello standard.
• Superamento del limite di velocità effettiva per un archivio di qualsiasi livello.
• Superamento del limite di larghezza di banda per un archivio di qualsiasi livello.
• Tentativo di creare o modificare una chiave-valore quando viene superata la quota di archiviazione.

Per trovare il motivo specifico per cui la richiesta ha avuto esito negativo, controllare il corpo della risposta 429. Inoltre è possibile raccogliere i log per l'archivio di Configurazione app di Azure in Monitoraggio di Azure e configurare gli avvisi per la metrica Richiesta utilizzo quota.

La ricezione di un codice di stato HTTP momentaneo 429 in genere non causa alcun danno, perché i client di Configurazione app gestiscono questi normalmente. Tuttavia, se l'applicazione riscontra regolarmente risposte con codice di stato HTTP 429, prendere in considerazione le opzioni seguenti:

• Aggiornare l'archivio al livello Premium: questo livello non ha limiti di quota per le richieste e ha aumentato la quota di archiviazione e una maggiore quantità di velocità effettiva.
• Utilizzare i provider di Configurazione app: i provider hanno funzionalità predefinite di ripetizione e memorizzazione insieme a molte altre funzionalità di resilienza. Assicurarsi di eseguire l'aggiornamento alla versione più recente del provider per tutti i miglioramenti più recenti.
• Utilizzare SDK di Configurazione app, se l'applicazione deve inviare richieste di scrittura. Anche se gli SDK potrebbero non essere altrettanto ricchi di funzionalità come provider, riprovano automaticamente nelle risposte del codice di stato HTTP 429 e in altri errori temporanei.
• Includere la logica di ripetizione nei client personalizzati, se non è possibile usare provider di Configurazione app o SDK. L'intestazione retry-after-ms nella risposta indica un tempo di attesa suggerito (in millisecondi) che è necessario attendere prima di riprovare la richiesta.
• Distribuire le richieste tra più istanze client: consente di ottenere la velocità effettiva massima dall'archivio di Configurazione app.
• Ridurre le richieste effettuate a Configurazione app: seguire le indicazioni per ridurre al minimo il numero di richieste.
• Migliorare la resilienza dell'applicazione: prendere in considerazione l'integrazione della replica geografica per consentire il failover e il bilanciamento del carico. Controllare le procedure consigliate per la creazione di applicazioni altamente resilienti.

Tutti gli archivi di Configurazione app nei livelli Standard e Premium hanno abilitato automaticamente la funzionalità di eliminazione temporanea. Quando un archivio di Configurazione app di livello Standard o Premium viene eliminato, il nome viene riservato per il periodo di conservazione. Per ricreare un archivio con lo stesso nome prima della scadenza del periodo di conservazione, è necessario ripulire prima di tutto l'archivio con elementi eliminati temporaneamente, purché l'archivio non abbia la protezione di ripulitura abilitata. Se la protezione dalla ripulitura è abilitata, è necessario attendere che il periodo di conservazione sia trascorso. Usare la funzione di ripulitura o impostare un periodo di conservazione più breve se spesso è necessario ricreare un archivio con lo stesso nome. I flussi di lavoro che richiedono la ricreazione di un archivio con lo stesso nome devono consentire un'ora tra l'eliminazione di un archivio di configurazione e l'esecuzione della creazione successiva. Questa raccomandazione è disponibile perché una volta richiesta la ripulitura effettiva delle risorse dell'archivio di configurazione viene eseguita in modo asincrono, richiedendo un po ' di tempo aggiuntivo per finalizzare. Per evitare la necessità di attendere, è consigliabile usare nomi univoci per i flussi di lavoro che creano archivi di configurazione temporanei.

Tutti gli archivi di Configurazione app nei livelli Standard e Premium supportano la funzionalità di eliminazione temporanea, che non può essere disabilitata. È possibile ripristinare un archivio eliminato entro il periodo di conservazione. Seguire queste istruzioni per ripristinare un archivio di Configurazione app eliminato erroneamente.

Sì. Anche se è possibile gestire flag di funzionalità e riferimenti a Key Vault in Configurazione app tramite il portale di Azure o l'interfaccia della riga di comando, è anche possibile crearli e aggiornarli a livello di codice usando gli SDK di Configurazione app. Pertanto, è possibile scrivere il portale di gestione personalizzato o gestirli in CI/CD a livello di codice. I flag di funzionalità e le API di riferimento di Key Vault sono disponibili negli SDK di tutti i linguaggi supportati. Vedere i collegamenti di esempio per esempi in ogni lingua supportata.

La valutazione e l'utilizzo di flag di funzionalità nell'applicazione richiedono il provider di Configurazione app e le librerie di gestione delle funzionalità, disponibili in .NET e Java Spring. Per altre informazioni, vedere la sezione Gestione delle funzionalità in Guide introduttive ed Esercitazioni.

I profili Spring consentono di separare parti dell'applicazione, inclusa la configurazione, e renderla disponibile solo in determinati ambienti o quando vengono usate librerie specifiche.

È consigliabile impostare l'etichetta dei valori chiave in modo che corrispondano ai profili Spring. Per impostazione predefinita, la libreria del provider Configurazione app Spring carica i valori chiave con le etichette corrispondenti ai profili Spring attivi correnti () se${spring.profiles.active} il filtro dell'etichetta non è impostato in modo esplicito. Se non è impostato alcun profilo Spring attivo, verranno caricati i valori chiave con "nessuna etichetta".

Ad esempio, con i profili dev e prod, si creano i valori chiave di conseguenza con le etichette seguenti.

Quando il profilo Spring è impostato su dev, il valore di config.message sarà Hello from dev. Quando il profilo Spring è impostato su prod, il valore di config.message sarà Hello from prod.

Questo comportamento predefinito può essere sottoposto a override impostando il filtro etichetta nel file bootstrap. La libreria dei provider Spring carica i valori chiave con le etichette specificate indipendentemente dal profilo Spring attivo.

spring.cloud.azure.appconfiguration.stores[0].selects[0].label-filter: my-label

Per selezionare altre etichette e i profili Spring, è possibile usare un filtro di etichetta come ',${spring.profiles.active}', che selezionerà tutte le chiavi senza etichetta e quelle corrispondenti ai profili Spring. Le etichette più a destra hanno la priorità quando vengono trovate chiavi duplicate.

A partire dalla versione 3.1.0, la libreria Microsoft.FeatureManagement consente l'esecuzione di servizi di gestione delle funzionalità, inclusi i filtri delle funzionalità, come servizi con ambito nelle applicazioni .NET basate su inserimento delle dipendenze. Per sfruttare questa funzionalità, è sufficiente sostituire la chiamataAddFeatureManagement nel codice con AddScopedFeatureManagement, come illustrato nel frammento di codice seguente:

services.AddScopedFeatureManagement();

I filtri delle funzionalità possono valutare un flag di funzionalità in base alle proprietà di una richiesta HTTP. Questa operazione viene in genere eseguita controllando l'oggetto HttpContext tramite il IHttpContextAccessormodello singleton. Tuttavia, questo modello non funziona per le applicazioni server Blazor in cui devono essere usati i servizi con ambito. In questo caso, è consigliabile usare il metodo AddScopedFeatureManagement.

Eseguire la sottoscrizione al repository di annunci GitHub.

È possibile contattarci direttamente su GitHub.

• Informazioni su Configurazione app di Azure