Operazioni per carichi di lavoro cruciali in Azure

Analogamente a qualsiasi applicazione, la modifica si verifica nei carichi di lavoro cruciali. L'applicazione si evolverà nel tempo, le chiavi scadranno, le patch verranno rilasciate e altro ancora. Tutte le modifiche e la manutenzione devono essere applicate usando le pipeline di distribuzione. Questo articolo fornisce indicazioni operative per apportare modifiche e aggiornamenti comuni.

L'allineamento dell'organizzazione è altrettanto importante per le procedure operative. È fondamentale per il successo operativo di un carico di lavoro cruciale che le responsabilità end-to-end rientrano in un singolo team, il team DevOps.

L'esecuzione tecnica deve sfruttare le funzionalità della piattaforma nativa di Azure e l'uso di Azure Pipelines automatizzate per distribuire le modifiche all'applicazione, all'infrastruttura e alla configurazione. Anche in questo caso, le attività di manutenzione devono essere automatizzate e le attività manuali devono essere evitate.

Le sezioni seguenti descrivono gli approcci alla gestione di diversi tipi di modifica.

Automazione delle applicazioni

L'integrazione continua e la distribuzione continua (CI/CD) consentono la distribuzione e la verifica appropriate dei carichi di lavoro cruciali. CI/CD è l'approccio preferito per distribuire le modifiche in qualsiasi ambiente, sviluppo/test, produzione e altro ancora. Per i carichi di lavoro cruciali, le modifiche elencate nella sezione seguente dovrebbero comportare la distribuzione di un timbro di distribuzione completamente nuovo. Il nuovo stamp di distribuzione deve essere testato accuratamente come parte del processo di rilascio prima che il traffico venga instradato al timbro tramite una strategia di distribuzione blu/verde.

Le sezioni seguenti descrivono le modifiche che devono essere implementate, ove possibile, tramite CI/CD.

Modifiche dell'applicazione

Tutte le modifiche apportate al codice dell'applicazione devono essere distribuite tramite CI/CD. Il codice deve essere compilato, analizzato con lint e testato contro le regressioni. È consigliabile monitorare le dipendenze dell'applicazione, ad esempio l'ambiente di runtime o i pacchetti, con gli aggiornamenti distribuiti tramite CI/CD.

Modifiche all'infrastruttura

L'infrastruttura deve essere modellata e provisionata come codice. Questa procedura viene comunemente definita Infrastruttura come codice (IaC). Tutte le modifiche apportate all'IaC devono essere distribuite tramite le pipeline CI/CD. Gli aggiornamenti all'infrastruttura, ad esempio l'applicazione di patch al sistema operativo, devono essere gestiti anche tramite pipeline CI/CD.

Modifiche alla configurazione

Le modifiche alla configurazione sono una causa comune di interruzioni dell'applicazione. Per combattere queste interruzioni, la configurazione per l'applicazione o l'infrastruttura deve essere acquisita come codice. Questa procedura è nota come Configurazione come codice (CaC). Le modifiche apportate alla CaC devono essere distribuite tramite pipeline CI/CD.

Aggiornamenti di libreria/SDK

Per le applicazioni cruciali, è fondamentale aggiornare il codice sorgente e le dipendenze quando diventano disponibili nuove versioni. L'approccio consigliato consiste nell'sfruttare i vantaggi del processo di modifica della gestione della configurazione nel repository del codice sorgente. Deve essere configurato per creare automaticamente richieste pull per vari aggiornamenti delle dipendenze, ad esempio:

• Pacchetti NuGet .NET
• Pacchetti del Gestore di pacchetti Node JavaScript
• Terraform Provider

L'approccio seguente illustra l'automazione degli aggiornamenti della libreria usando dependabot in un repository GitHub.

1. Dependabot rileva gli aggiornamenti delle librerie e dell'SDK usati nel codice dell'applicazione

2. Dependabot aggiorna il codice dell'applicazione in un ramo e crea una pull request (PR) con tali modifiche contro il ramo principale. La PR contiene tutte le informazioni pertinenti ed è pronta per la revisione finale.

   

3. Al termine della revisione e del test del codice, la pull request può essere fusa nel ramo principale.

Per le dipendenze che dependabot non è in grado di monitorare, assicurati di avere processi in atto per rilevare nuove versioni.

Rinnovo di chiavi, segreti e certificati

La rotazione (rinnovo) delle chiavi e dei segreti deve essere una procedura standard in qualsiasi carico di lavoro. Potrebbe essere necessario modificare i segreti in caso di breve preavviso dopo essere stati esposti o regolarmente come una buona procedura di sicurezza.

Poiché i segreti scaduti o non validi possono causare interruzioni dell'applicazione (vedere Analisi errori), è importante disporre di un processo chiaramente definito e collaudato. Per Azure Mission-Critical, i francobolli sono previsti solo per alcune settimane. Per questo motivo, la rotazione dei segreti delle risorse stamp non è un problema. Se i segreti in un timbro scadono, l'applicazione nel suo complesso continuerà a funzionare.

La gestione dei segreti per accedere a risorse globali di lunga durata, tuttavia, è fondamentale. Un esempio rilevante è rappresentato dalle chiavi API di Azure Cosmos DB. Se le chiavi API di Azure Cosmos DB scadono, tutti i francobolli vengono interessati simultaneamente e causano un'interruzione completa dell'applicazione.

L'approccio seguente è un approccio testato e documentato di importanza critica di Azure per la rotazione delle chiavi di Azure Cosmos DB senza causare tempi di inattività per i servizi in esecuzione nel servizio Azure Kubernetes.

1. Aggiorna i timbri con la chiave secondaria. Per impostazione predefinita, la chiave API primaria per Azure Cosmos DB viene archiviata come segreto in Azure Key Vault in ogni istanza. Creare un Pull Request che aggiorni il modello di codice IaC utilizzando la chiave API secondaria di Azure Cosmos DB. Devi eseguire questa modifica tramite la normale procedura di revisione e aggiornamento della pull request per poter essere distribuita come nuova versione o come hotfix.

2. (facoltativo) Se l'aggiornamento è stato distribuito come hotfix a una versione esistente, i pod rileveranno automaticamente il nuovo segreto da Azure Key Vault dopo alcuni minuti. Tuttavia, il codice client di Azure Cosmos DB attualmente non viene reinizializzato con una chiave modificata. Per risolvere questo problema, riavviare manualmente tutti i pod usando i comandi seguenti nei cluster:

   kubectl rollout restart deployment/CatalogService-deploy -n workload
   kubectl rollout restart deployment/BackgroundProcessor-deploy -n workload
   kubectl rollout restart deployment/healthservice-deploy -n workload
   

3. I pod appena distribuiti o riavviati ora usano la chiave API secondaria per la connessione ad Azure Cosmos DB.

4. Una volta riavviati tutti i pod di tutti i stamp di distribuzione o viene effettuata una nuova distribuzione di uno stamp, rigenerare la chiave API primaria per Azure Cosmos DB. Usare il modello di comando seguente:

   az cosmosdb keys regenerate --key-kind primary --name MyCosmosDBDatabaseAccount --resource-group MyResourceGroup
   

5. Modificare il modello IaC per usare la chiave API primaria per le distribuzioni future. In alternativa, è possibile continuare a usare la chiave secondaria e tornare alla chiave API primaria quando è il momento di rinnovare il database secondario.

Avvisi

Gli avvisi sono fondamentali per comprendere se e quando si verificano problemi con l'ambiente. Le modifiche apportate agli avvisi e/o ai gruppi di azioni devono essere implementate tramite pipeline CI/CD. Per altre informazioni sugli avvisi, vedere Modellazione dell'integrità e osservabilità dei carichi di lavoro cruciali in Azure.

Automazione

Molte piattaforme e servizi in esecuzione in Azure offrono automazione per le attività operative comuni. Questa automazione include la scalabilità automatica e la gestione automatizzata di chiavi e certificati.

Ridimensionamento

Come parte della progettazione dell'applicazione, è necessario determinare i requisiti di scala che definiscono un'unità di scala per il timbro nel suo complesso. I singoli servizi all'interno dell'infrastruttura devono essere in grado di aumentare le risorse per soddisfare la domanda di picco o ridurle per risparmiare denaro o risorse.

I servizi che non dispongono di risorse sufficienti possono presentare effetti collaterali diversi, incluso l'elenco seguente:

• Un numero insufficiente di pod che elaborano messaggi da una coda, un articolo, o una partizione si traduce in un numero sempre maggiore di messaggi non elaborati. Questo risultato viene talvolta definito profondità della coda crescente.
• Le risorse insufficienti in un nodo del servizio Azure Kubernetes possono causare la mancata esecuzione dei pod.
• Il risultato seguente genera richieste limitate:
  • Numero insufficiente di Request Units (RUs) per Azure Cosmos DB
  • Unità di elaborazione insufficienti per hub eventi Premium o unità di throughput (UT) per standard
  • Unità di messaggistica insufficienti (MU) per il livello Premium del Bus di Servizio

Sfruttare le seguenti funzionalità di scalabilità automatica dei servizi, ove possibile, per assicurarsi di disporre di risorse sufficienti per soddisfare la domanda:

• scalabilità automatica orizzontale dei pod consente di aumentare o diminuire il numero di pod che eseguono carichi di lavoro, a seconda della richiesta.
• Il autoscaler del cluster AKS consente di aumentare o diminuire il numero di nodi nel cluster, a seconda della domanda.
• È possibile aumentare automaticamente le unità di throughput degli Event Hubs di Azure nella classe standard
• È possibile Aggiornare automaticamente le unità di messaggistica di un namespace del Service Bus di Azure

Gestione di chiavi, segreti e certificati

Usare le identità gestite, dove possibile, per evitare di dover gestire chiavi API o segreti, ad esempio password.

Quando si usano chiavi, segreti o certificati, usare le funzionalità della piattaforma nativa di Azure quando possibile. Queste funzionalità a livello di piattaforma includono gli esempi seguenti:

• Frontdoor di Azure offre funzionalità predefinite per la gestione e il rinnovo dei certificati TLS.
• Azure Key Vault supporta la rotazione automatica delle chiavi.

Operazioni manuali

Esistono attività operative che richiedono un intervento manuale. Questi processi devono essere testati.

Messaggi non recapitabili

I messaggi che non possono essere elaborati devono essere indirizzati a una coda dei messaggi morti con un'allerta configurata per tale coda. Questi messaggi richiedono in genere un intervento manuale per comprendere e attenuare il problema. Dovresti costruire la capacità di visualizzare, aggiornare e riprodurre messaggi non consegnati.

Ripristino di Azure Cosmos DB

Quando i dati di Azure Cosmos DB vengono eliminati involontariamente, aggiornati o danneggiati, è necessario eseguire un ripristino da un backup periodico. Il ripristino da un backup temporizzato può essere eseguito solo tramite una richiesta di supporto. Questo processo deve essere documentato e testato periodicamente.

Aumenti delle quote

Le sottoscrizioni di Azure hanno limiti di quota. Le distribuzioni possono non riuscire quando vengono raggiunti questi limiti. Alcune quote sono regolabili. Per le quote regolabili, è possibile richiedere un aumento dalla pagina Quote personali nel portale di Azure. Per le quote non modificabili è necessario inviare una richiesta di supporto. Il team di supporto di Azure collabora con l'utente per trovare una soluzione.

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autore principale:

• Allen Sudbring | Sviluppatore di contenuti senior

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi