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 valori 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.

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 inattiva con 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 chiave, inclusi gli attributi, ad esempio 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 è maggiore di questo limite, è possibile considerare l'archiviazione dei dati altrove e aggiungere un riferimento a tali dati in Configurazione app.

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 tra 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 di Configurazione app offrono funzionalità di base, tra cui impostazioni di configurazione, flag di funzionalità, riferimenti a Key Vault, 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 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. Nel livello standard ogni archivio di configurazione può usare fino a 1 GB di spazio di archiviazione.

  • 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 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 troppe richieste fino alla fine dell'ora. Man mano che vengono inviate più richieste che sono sopra quota, una percentuale superiore di essi può restituire il codice di stato 429.

  • Contratto di servizio: il livello di servizio ha un contratto di servizio con disponibilità del 99,9%. Il livello gratuito non ha un contratto di servizio.

  • Funzionalità di sicurezza:entrambi i livelli includono funzionalità di sicurezza, tra cui la crittografia con chiavi gestite da Microsoft, l'autenticazione tramite HMAC o Azure Active Directory, il supporto di Controllo degli accessi in base al ruolo di Azure, l'identità gestita e i tag del servizio. Il livello standard offre funzionalità di sicurezza più avanzate, tra cui il supporto del collegamento privato e la crittografia con chiavi gestite dal cliente.

  • 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 il Configurazione app archivio 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?

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

Configurazione app di Azure supporta le zone di disponibilità di Azure per proteggere l'applicazione e i dati da singoli errori del data center. Tutte le aree abilitate per la 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 hanno abilitato il supporto della zona di disponibilità. Per altre informazioni, vedere Aree e zone di disponibilità in Azure.

Di seguito sono riportate le aree in cui Configurazione app ha abilitato il supporto della zona di disponibilità.

Americhe Europa Medio Oriente Africa Asia Pacifico
Brasile meridionale Francia centrale Qatar centrale Australia orientale
Canada centrale Germania centro-occidentale Emirati Arabi Uniti settentrionali India centrale
Stati Uniti centrali Europa settentrionale Giappone orientale
Stati Uniti orientali Norvegia orientale Corea centrale
Stati Uniti orientali 2 Regno Unito meridionale Asia sud-orientale
Stati Uniti centro-meridionali Europa occidentale Asia orientale
US Gov Virginia Svezia centrale Cina settentrionale 3
Stati Uniti occidentali 2 Svizzera settentrionale
Stati Uniti occidentali 3 Polonia 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†.
  • 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. Configurazione app client, ad esempio Azure SDK, librerie del provider di configurazione e attività di Azure Pipeline, 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 deve andare inosservata, se si verifica.

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 le modifiche di 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.

In primo luogo, 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, per queste richieste, solo 1.000 richieste (=500x2) useranno la quota oraria disponibile. 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 limitazione oraria. Per altre informazioni, vedere come ridurre le richieste effettuate a Configurazione app.

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 dell'eliminazione abilitata. Se la protezione dell'eliminazione è abilitata, è necessario attendere che il periodo di conservazione sia trascorso. Usare la funzione di eliminazione o impostare un periodo di conservazione più breve se spesso è necessario ricreare un archivio con lo stesso nome.

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 Key Vault riferimenti a livello di codice?

Sì. Anche se è possibile gestire flag di funzionalità e riferimenti Key Vault in Configurazione app tramite la portale di Azure o l'interfaccia della riga di comando, è 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. Il flag di funzionalità e le API di riferimento 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 renderle disponibili 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 dell'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 un'etichetta e quelle corrispondenti ai profili Spring. Le etichette più a destra accettano la priorità quando vengono trovate chiavi duplicate.

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