Quando la nostra applicazione ASP.NET Core è in esecuzione su Azure, una best practice che dovremmo sempre adottare è quella di sfruttare Azure Key Vault come repository per i nostri dati sensibili, come stringhe di connessione, password, e quant'altro.
Abbiamo già visto in un precedente script (https://www.aspitalia.com/script/1426/Leggere-Dati-Configurazione-ASP.NET-Core-Azure-Key-Vault.aspx) come grazie a un provider presente nell'Azure SDK, possiamo fare in modo che i secret memorizzati in Key Vault vengano convogliati nella configurazione di ASP.NET Core, così che possiamo accedervi senza preoccuparci dei dettagli di utilizzo di questo servizio.
builder.Configuration.AddAzureKeyVault( new Uri($"https://{builder.Configuration["KeyVaultName"]}.vault.azure.net/"), new DefaultAzureCredential());
Il metodo AddAzureKeyVault presenta già una logica di retry così che, in caso di fallimento della chiamata, il sistema provi a rieseguirla prima di sollevare un errore e provocare il crash dell'applicazione - essendo questa logica eseguita allo startup.
Per poterne configurare i parametri di funzionamento, tuttavia, dobbiamo utilizare un overload differente, come mostrato dal codice seguente:
var options = new SecretClientOptions(); options.Retry.Mode = RetryMode.Exponential; options.Retry.MaxRetries = 5; options.Retry.Delay = TimeSpan.FromSeconds(5); var client = new SecretClient(new Uri($"https://{builder.Configuration["KeyVaultName"]}.vault.azure.net/"), new DefaultAzureCredential(), options); builder.Configuration.AddAzureKeyVault(client, new AzureKeyVaultConfigurationOptions() { ReloadInterval = TimeSpan.FromMinutes(5) });
L'esempio in alto è piuttosto comprensibile: come primo passo abbiamo configurato le nostre preferenze per i retry in un oggetto chiamato SecretClientOptions, poi l'abbiamo utilizzato per creare una nuova istanza di SecretClient, passando anche gli altri parametri necessari per interrogare Key Vault, come il suo URL e il sistema di autenticazione desiderato.
Come ultimo passo, abbiamo finalmente invocato AddAzureKeyVault passando il nostro SecretClient personalizzato, e specificando anche l'intervallo di reload tramite AzureKeyVaultConfigurationOptions. Quest'ultimo ci permetterà di effettuare il refresh automatico della configurazione se uno o più secret dovessero cambiare di valore.
Una nota finale riguarda il fatto che il retry viene attivato solo in presenza di errori considerati transitori, come Timeout, Bad Gateway, Internal Server Error, e via discorrendo.
Ciò è dovuto all'implementazione della classe ResponseClassifier, utilizzata internamente dall'SDK, per determinare quali richieste possono essere riprovate:
public virtual bool IsRetriableResponse(HttpMessage message) { switch (message.Response.Status) { case 408: // Request Timeout case 429: // Too Many Requests case 500: // Internal Server Error case 502: // Bad Gateway case 503: // Service Unavailable case 504: // Gateway Timeout return true; default: return false; } }
In un prossimo script vedremo come superare questa limitazione.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Sfruttare gli embedding e la ricerca vettoriale con Azure SQL Database
Popolare una classe a partire dal testo, con Semantic Kernel e ASP.NET Core Web API
Fissare una versione dell'agent nelle pipeline di Azure DevOps
Esporre i propri servizi applicativi con Semantic Kernel e ASP.NET Web API
Ordine e importanza per @layer in CSS
Gestione degli eventi nei Web component HTML
Escludere alcuni file da GitHub Secret Scanning
Rinnovare il token di una GitHub App durante l'esecuzione di un workflow
Generare velocemente pagine CRUD in Blazor con QuickGrid
Utilizzare Copilot con Azure Cosmos DB
Ottenere un token di accesso per una GitHub App
Scrivere selettori CSS più semplici ed efficienti con :is()