Domande frequenti su Configurazione app di Azure

Questo articolo contiene le risposte alle domande frequenti su Configurazione app di Azure.

Quali sono le differenze tra Configurazione e Azure Key Vault?

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.

È necessario archiviare i segreti in Configurazione app?

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 Configurazione app valori chiave 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.

Configurazione app crittografa i dati?

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 uno dei due Chiavi gestite da Microsoft o chiavi gestite dal cliente.

Quali sono le differenze tra Configurazione app e le impostazioni di Servizio app di Azure?

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 Configurazione app nelle impostazioni dell'applicazione del servizio app. È anche possibile importare ed esportare le impostazioni tra servizio app e Configurazione app. 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.

Esistono limitazioni di dimensioni per le chiavi e i valori archiviati in Configurazione app?

È previsto un limite di 10 KB per un singolo valore di chiave, inclusi attributi come etichetta, tipo di contenuto, tag e altri metadati.

Questo limite deve essere sufficiente per una singola impostazione nella maggior parte delle applicazioni. Se si rileva che l'impostazione è superiore a questo limite, è possibile archiviare i dati altrove e aggiungere un riferimento a tali dati in Configurazione app.

Per altre informazioni, vedere Limiti dei servizi e della sottoscrizione di Azure.

Come occorre archiviare le configurazioni per più ambienti (test, staging, produzione e così via)?

È 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 l'isolamento della sicurezza tra ambienti, è possibile usare le etichette per distinguere i valori di configurazione. Un esempio completo è disponibile in Usare etichette per fornire configurazioni diverse per ambienti diversi.

Quali sono i modi consigliati per usare Configurazione app?

Quanto costa Configurazione app?

Esistono due piani tariffari:

  • Livello gratuito
  • Livello Standard

Se è stato creato prima dell'introduzione del livello standard, l'archivio viene spostato automaticamente al livello gratuito al momento della disponibilità generale. È possibile scegliere di eseguire l'aggiornamento al livello standard oppure di proseguire con il livello gratuito.

Non è possibile effettuare il downgrade di un archivio dal livello standard al livello gratuito. È possibile creare un nuovo archivio nel livello gratuito e quindi importarvi i dati di configurazione.

Quale livello di Configurazione app occorre usare?

Entrambi i livelli 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.

  • Risorse per sottoscrizione: una risorsa è costituita da un singolo archivio di configurazione. Ogni sottoscrizione è limitata a un archivio di configurazione per area nel livello gratuito. Le sottoscrizioni possono avere un numero illimitato di archivi di configurazione nel livello standard.

  • Archiviazione per risorsa: nel livello gratuito, ogni archivio di configurazione è limitato a 10 MB di spazio di archiviazione normale e 10 MB di archiviazione snapshot. Nel livello standard, ogni archivio di configurazione può usare fino a 1 GB di spazio di archiviazione normale e un ulteriore 1 GB 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. Nel livello standard 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 livelli Standard sono limitati a 30.000 richieste all'ora. Quando la quota oraria viene esaurita, le richieste possono restituire il codice di stato HTTP 429 che indica un numero eccessivo di richieste fino alla fine dell'ora. Man mano che vengono inviate più richieste che superano la quota, una percentuale maggiore di esse può restituire il codice di stato 429.

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

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

  • Costo: gli archivi di livello standard hanno un prezzo di utilizzo giornaliero, che include le prime 200.000 richieste di ogni giorno. È anche previsto un costo di eccedenza per le richieste che superano l'allocazione giornaliera. Non è previsto alcun costo per l'uso di un archivio di livello gratuito.

È possibile eseguire l'aggiornamento di un archivio dal livello gratuito al livello standard? È possibile effettuare il downgrade di un archivio dal livello standard al livello gratuito?

È possibile eseguire l'aggiornamento dal livello gratuito al livello standard in qualsiasi momento.

Non è possibile effettuare il downgrade di un archivio dal livello standard al livello gratuito. È possibile creare un nuovo archivio nel livello gratuito e quindi importarvi i dati di configurazione.

Dove risiedono i dati archiviati in Configurazione app?

I dati dei clienti archiviati in Configurazione app risiedono nell'area in cui è stato creato l'archivio Configurazione app del cliente. I dati dei clienti verranno 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.

In che modo Configurazione app garantisce la disponibilità elevata dei dati?

app Azure Configurazione 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 3 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 che Configurazione app supportano la zona di disponibilità. Per altre informazioni, vedere Aree e zone di disponibilità in Azure.

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

Americhe Europa Medio Oriente Africa Asia Pacifico
Brasile meridionale Francia centrale Qatar centrale Australia orientale
Canada centrale Italia settentrionale Emirati Arabi Uniti settentrionali India centrale
Stati Uniti centrali Germania centro-occidentale Israele centrale Giappone orientale
Stati Uniti orientali Europa settentrionale Corea centrale
Stati Uniti orientali 2 Norvegia orientale Asia sud-orientale
Stati Uniti centro-meridionali Regno Unito meridionale Asia orientale
US Gov Virginia Europa occidentale Cina settentrionale 3
West US 2 Svezia centrale
Stati Uniti occidentali 3 Svizzera settentrionale
Messico centrale Polonia Centrale
Spagna centrale

Sono previsti limiti al numero di richieste effettuate a Configurazione app?

Per gli archivi di configurazione nel livello gratuito è previsto un limite di 1000 richieste al giorno. Gli archivi di configurazione nel livello Standard possono riscontrare limitazioni temporanee quando la frequenza delle richieste supera 30.000 richieste all'ora.

Quando un archivio raggiunge il limite nel livello standard, può restituire il codice di stato HTTP 429 per alcune richieste effettuate fino alla fine dell'ora. L'intestazione retry-after-ms nella risposta indica un tempo di attesa suggerito (in millisecondi) che è necessario attendere prima di riprovare la richiesta.

Se nell'applicazione si verificano regolarmente risposte con codice di stato HTTP 429, è consigliabile riprogettare l'applicazione in modo da ridurre il numero di richieste effettuate. Per altre informazioni, vedere come ridurre le richieste effettuate a Configurazione app.

L'applicazione riceve risposte con codice di stato HTTP 429. Perché?

Si riceverà una risposta con codice di stato HTTP 429 nelle circostanze seguenti:

  • Superamento del limite di richieste giornaliere per un archivio nel livello gratuito.
  • Superamento del limite di richieste orarie per un archivio nel livello standard.
  • Limitazione momentanea a causa di un elevato burst di richieste†.
  • Limitazione momentanea a causa di un utilizzo eccessivo della larghezza di banda†.
  • Tentativo di creare o modificare una chiave 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.

†A archivio di configurazione può riscontrare una limitazione momentanea se riceve un elevato burst di richieste o trasferisce un volume eccessivo di dati. Configurazione app client, ad esempio Azure SDK, librerie del provider di configurazione e attività di Azure Pipelines, riprovare automaticamente alle richieste limitate. Per tutte le applicazioni che usano uno di questi client o un client personalizzato che ritenta le richieste limitate, questa limitazione momentanea dovrebbe non essere nota, in caso di verificarsi.

Ricerca per categorie stimare il numero di richieste che l'applicazione può inviare a Configurazione app?

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. Indipendentemente dal fatto che sia in esecuzione in Kubernetes, servizio app o nelle macchine virtuali, 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 invierà una richiesta per la chiave sentinel a Configurazione app ogni 30 secondi, quindi invierà 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 verrà conteggiato rispetto ai limiti di quota oraria dell'archivio†.

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 richiederà 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 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) useranno la quota oraria disponibile. Aggiornare i numeri in questo esempio in modo che corrispondano alla configurazione specifica e progettare di conseguenza in modo da disporre di un buffer sufficiente rispetto al limite di limitazione oraria. Per altre informazioni, vedere come ridurre le richieste effettuate a Configurazione app.

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

Perché non è possibile creare un archivio di Configurazione app con lo stesso nome di quello appena eliminato?

Tutti gli archivi Configurazione app nel livello standard hanno abilitato automaticamente la funzionalità di eliminazione temporanea. Quando viene eliminato un livello standard Configurazione app store, il relativo nome viene riservato per il periodo di conservazione. Per ricreare un archivio con lo stesso nome prima della scadenza del periodo di conservazione, è necessario eliminare prima di tutto l'archivio eliminato temporaneamente, purché l'archivio non abbia la protezione di ripulitura abilitata. Se la protezione dall'eliminazione è 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 l'eliminazione 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.

Come è possibile ripristinare un archivio di Configurazione app eliminato per errore?

Tutti gli archivi Configurazione app nel livello standard 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 Configurazione app eliminato erroneamente.

È possibile creare e aggiornare flag di funzionalità o riferimenti a Key Vault a livello di codice?

Sì. Anche se è possibile gestire flag di funzionalità e riferimenti a Key Vault in Configurazione app tramite l'interfaccia della riga di comando o portale di Azure, è anche possibile crearli e aggiornarli a livello di codice usando Configurazione app SDK. 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 dei 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 .

Come usare i profili Java Spring in Configurazione app?

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 caricherà 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.

Chiave Etichetta Valore
/application/config.message dev Hello from dev
/application/config.message prod Ciao da prod

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 del provider Spring caricherà 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.

Come abilitare la gestione delle funzionalità nelle applicazioni Blazor o come servizi con ambito nelle applicazioni .NET?

A partire dalla versione 3.1.0, la Microsoft.FeatureManagement libreria 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 AddFeatureManagement chiamata 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 modello singletonIHttpContextAccessor. Tuttavia, questo modello non funziona per le applicazioni server Blazor in cui devono essere usati i servizi con ambito. In questo caso, è consigliabile AddScopedFeatureManagement usare il metodo .

Come è possibile ricevere annunci su nuove versioni e altre informazioni correlate a Configurazione app?

Eseguire la sottoscrizione al repository di annunci GitHub.

Come è possibile segnalare un problema o fornire un suggerimento?

È possibile contattarci direttamente su GitHub.

Passaggi successivi