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.