Condividi tramite

Raccomandazioni per l'uso dell'infrastruttura come codice

  • Articolo

Si applica a questa raccomandazione per l'eccellenza operativa di Azure Well-Architected Framework:

OE:05 Preparare le risorse e le relative configurazioni usando un approccio IaC (Infrastructure as Code) standardizzato. Analogamente ad altro codice, progettare IaC con stili coerenti, modularizzazione appropriata e garanzia di qualità. Preferire un approccio dichiarativo quando possibile.

Questa guida descrive le raccomandazioni per l'uso di IaC come standard per le distribuzioni dell'infrastruttura. L'uso di IaC consente di integrare le distribuzioni e la gestione dell'infrastruttura nelle procedure di sviluppo software esistenti. Fornisce una metodologia standard coerente per lo sviluppo e la distribuzione per tutti i componenti del carico di lavoro. L'uso delle distribuzioni manuali comporta il rischio di configurazioni incoerenti e progettazione potenzialmente non sicura.

Definizioni

Termine Definizione
Strumenti dichiarativi Categoria di strumenti che definiscono lo stato finale di una distribuzione e si basano sul sistema per determinare come distribuire le risorse in modo che corrispondano allo stato finale definito.
Infrastruttura non modificabile Un'infrastruttura che deve essere sostituita con una nuova infrastruttura che esegue la nuova configurazione con ogni distribuzione. Non deve essere modificata.
Strumenti imperativi Categoria di strumenti che elencano i passaggi di esecuzione che determinano lo stato finale desiderato.
Modulo Unità di astrazione per la divisione di gruppi di risorse per semplificare le distribuzioni complesse.
Infrastruttura modificabile Infrastruttura che deve essere modificata. Le distribuzioni modificano la configurazione dell'infrastruttura anziché sostituirla con una nuova infrastruttura.

Strategie di progettazione chiave

Come illustrato nelle guide alla catena di fornitura e alla standardizzazione di strumenti e processi , è necessario disporre di un criterio rigoroso di distribuzione delle modifiche dell'infrastruttura (incluse le modifiche alla configurazione) solo tramite il codice. È consigliabile distribuire IaC tramite le pipeline di integrazione continua e recapito continuo (CI/CD). L'adozione di questi criteri applica la coerenza nei processi per tutte le distribuzioni IaC, riduce al minimo il rischio di deviazione della configurazione tra gli ambienti e garantisce la coerenza dell'infrastruttura tra gli ambienti. Inoltre, è consigliabile standardizzare gli strumenti e i processi di sviluppo e distribuzione IaC in una guida di stile. Le raccomandazioni per la guida di stile includono:

Preferire gli strumenti dichiarativi rispetto a quello imperativo

Gli strumenti dichiarativi e i file associati sono una scelta complessiva migliore per la distribuzione e la gestione di IaC rispetto agli strumenti imperativi. Gli strumenti dichiarativi usano una sintassi più semplice per i file di definizione, definendo solo lo stato desiderato dell'ambiente al termine della distribuzione. Gli strumenti imperativi dipendono dalla definizione dei passaggi necessari per raggiungere lo stato finale desiderato, in modo che i file possano essere molto più complessi rispetto ai file dichiarativi. I file di definizione dichiarativa consentono anche di ridurre il debito tecnico di mantenere il codice imperativo, ad esempio gli script di distribuzione, che possono accumularsi nel tempo.

Usare strumenti nativi e standard del settore

Usare gli strumenti nativi della piattaforma cloud e altri strumenti collaudati del settore che si integrano in modo nativo nella piattaforma. La piattaforma cloud offre strumenti per semplificare e semplificare la distribuzione di IaC. Sfruttare questi strumenti e altri strumenti di terze parti che dispongono di integrazione nativa, ad esempio Terraform, anziché sviluppare soluzioni personalizzate. Gli strumenti nativi sono supportati dalla piattaforma e includono funzionalità predefinite per la maggior parte delle esigenze. Vengono continuamente aggiornati dal provider di piattaforme, rendendoli più utili man mano che la piattaforma si evolve.

Nota

Tenere presente che come provider di servizi cloud e sviluppatori di terze parti aggiornano gli strumenti e le API, è possibile correre il rischio di problemi imprevisti quando si usa la versione più recente nel carico di lavoro. Assicurarsi di testare accuratamente le nuove versioni degli strumenti e delle API prima di adottarle. Analogamente, evitare di usare il flag "latest" quando si chiama uno strumento o un'API nel codice di distribuzione. È consigliabile chiamare la versione valida nota più recente per il carico di lavoro.

Usare lo strumento corretto per l'attività

Usare gli strumenti appropriati per attività e tipi di infrastruttura specifici. Più attività, oltre alle distribuzioni, sono coinvolte in un ciclo di vita dell'infrastruttura. La configurazione deve essere applicata e gestita, ad esempio e lo strumento usato per creare script per le distribuzioni, ad esempio Bicep, potrebbe non essere lo strumento migliore per ogni operazione di gestione.

Analogamente, l'applicazione della configurazione dello stato desiderata (DSC) per diversi tipi di infrastruttura potrebbe richiedere strumenti diversi. Ad esempio, sono disponibili strumenti specifici come Ansible per la gestione di DSC per le macchine virtuali, mentre Flux è uno strumento valido per la gestione di DSC nei cluster Kubernetes. I servizi PaaS (Platform as a Service) possono fornire strumenti diversi per la gestione della configurazione (ad esempio app Azure Configurazione) che possono essere gestiti tramite IaC. I servizi SaaS (Software as a Service) potrebbero essere più limitati perché sono più strettamente controllati dalla piattaforma.

Considerare tutte le attività e i tipi di infrastruttura che rientrano nell'ambito delle procedure IaC e standardizzare gli strumenti che eseguono i processi necessari e possono essere integrati nelle procedure di sviluppo e gestione.

Supportare più ambienti

Gli script e i modelli devono essere sufficientemente flessibili per distribuire facilmente un'ampia gamma di ambienti. Usare parametri, variabili e file di configurazione per distribuire un set standard di risorse che può essere modificato per distribuire qualsiasi ambiente nello stack di promozione del codice. Impostazioni astratte, ad esempio dimensioni delle risorse, conteggio, nome, percorsi in cui eseguire la distribuzione e alcune impostazioni di configurazione. Prestare attenzione a non astrarre troppo, tuttavia. Esistono impostazioni che possono essere astratte con un parametro o una variabile che potrebbero non cambiare effettivamente nel corso del ciclo di vita del carico di lavoro o che potrebbero cambiare raramente. Non dovrebbero essere astratte.

Nota

Evitare di usare asset IaC diversi per ambienti diversi. Non è consigliabile avere file Terraform diversi per ambienti di produzione e test, ad esempio. Tutti gli ambienti devono usare un solo file. È possibile modificare il file per la distribuzione in ambienti diversi in base alle esigenze.

Usare il giusto equilibrio durante l'incapsulamento delle funzionalità

Strategizzare e standardizzare l'uso dei moduli. Come i parametri e le variabili, i moduli possono rendere ripetibili le distribuzioni dell'infrastruttura. Tuttavia, è opportuno pensare a come usarli. Una strategia di astrazione standardizzata consente di garantire che i moduli siano compilati per soddisfare obiettivi specifici e concordati. Usare i moduli per incapsulare configurazioni o combinazioni complesse di risorse. Evitare moduli se si usa solo la configurazione predefinita della risorsa. Inoltre, è opportuno sviluppare nuovi moduli. Usare moduli open source gestiti quando appropriato, ad esempio scenari senza distinzione tra maiuscole e minuscole.

Passaggi manuali del documento

Documentare gli standard per i passaggi manuali. Potrebbero essere necessari passaggi correlati alla distribuzione e alla gestione dell'infrastruttura specifica per l'ambiente e che richiedono un intervento manuale. Assicurarsi che questi passaggi siano ridotti al minimo il più possibile e documentati in modo chiaro. Nella guida di stile e nelle procedure operative standard, standardizzare i passaggi manuali per garantire che le attività vengano eseguite in modo sicuro e coerente.

Standard del documento per gestire le risorse orfane. A seconda degli strumenti usati per la gestione della configurazione e delle relative limitazioni, potrebbero verificarsi momenti in cui una determinata risorsa non è più necessaria per il carico di lavoro e gli strumenti IaC non possono rimuovere automaticamente la risorsa. Si supponga, ad esempio, di passare da macchine virtuali a un servizio PaaS per alcune funzioni e che gli strumenti IaC non dispongano della logica per rimuovere le risorse ritirati. Queste risorse possono diventare orfane se il team del carico di lavoro non ricorda di eliminarle manualmente. Per gestire questi scenari, standardizzare una strategia per analizzare le risorse orfane ed eliminarle. È anche necessario considerare come assicurarsi che i modelli siano aggiornati. Ricercare le limitazioni degli strumenti IaC per capire cosa potrebbe essere necessario pianificare in queste situazioni.

Prendere in considerazione le raccomandazioni seguenti che si applicano all'uso di IaC per il carico di lavoro.

Usare un approccio a più livelli per le pipeline IaC

Usare un approccio a più livelli per allineare le pipeline IaC all'interno dello stack del carico di lavoro. La separazione delle pipeline IaC in livelli consente di gestire ambienti complessi. La distribuzione di decine o centinaia di risorse in un unico pacchetto monolitico è inefficiente e può introdurre più problemi, come l’interruzione di alcune dipendenze. L'uso di più pipeline allineate a livelli costituiti da risorse i cui cicli di vita di distribuzione o fattori come la funzionalità corrispondono strettamente semplifica la gestione delle distribuzioni IaC.

L'infrastruttura di base, ad esempio le risorse di rete, richiede raramente modifiche più complesse rispetto agli aggiornamenti della configurazione, quindi tali risorse devono creare una pipeline IaC a basso tocco . È possibile che siano presenti una o più pipeline IaC con tocco medio e elevato per le risorse, a seconda della complessità del carico di lavoro. Usando uno stack di applicazioni basato su Kubernetes come esempio, un livello medio-tocco potrebbe essere costituito da cluster, risorse di archiviazione e servizi di database. I livelli ad alto tocco sono costituiti dai contenitori dell'applicazione che vengono aggiornati molto frequentemente in modalità di recapito continuo.

Gestire il codice dell'applicazione e IaC allo stesso modo

La gestione analoga degli artefatti IaC e degli artefatti del codice dell'applicazione consente di applicare lo stesso rigore per la gestione del codice in tutte le pipeline. Inoltre, le procedure di sviluppo e distribuzione IaC devono rispecchiare le procedure dell'applicazione. Gli standard per il controllo della versione, la diramazione, la promozione del codice e la qualità devono essere tutti identici. Prendere in considerazione anche la collocazione degli asset IaC insieme agli asset di codice dell'applicazione. In questo modo si garantisce che gli stessi processi vengano seguiti con ogni distribuzione e consenta di evitare problemi come la distribuzione accidentale dell'infrastruttura prima del codice dell'applicazione necessario o viceversa.

Usare standard e risorse centralizzati

Collaborare con altri team dell'organizzazione per standardizzazione e riutilizzabilità. Le organizzazioni di grandi dimensioni possono talvolta avere più team che sviluppano e supportano carichi di lavoro. La collaborazione tra i team per concordare gli standard consente di riutilizzare librerie, modelli e moduli per ottenere efficienza e coerenza tra gli ambienti del carico di lavoro. Analogamente, gli strumenti IaC devono essere standardizzati in tutta l'organizzazione, nella misura in cui questa operazione è pratica.

Applicare la sicurezza nel codice IaC

Applicare il principio di "sicurezza come codice" per assicurarsi che la sicurezza faccia parte della pipeline di distribuzione. Includere l'analisi delle vulnerabilità e la protezione avanzata della configurazione come parte del processo di sviluppo IaC. Analizzare i repository IaC per individuare chiavi e segreti esposti. Uno dei vantaggi dell'uso di IaC è che i membri del team incentrato sulla sicurezza possono esaminare il codice prima della distribuzione per assicurarsi che la configurazione approvata per il rilascio in base alla sicurezza sia effettivamente quella distribuita nell'ambiente di produzione. Per indicazioni dettagliate, vedere Raccomandazioni per la protezione di un ciclo di vita di sviluppo.

Testare le attività di routine e non di routine. Testare distribuzioni, aggiornamenti della configurazione e processi di ripristino, inclusi i processi di rollback della distribuzione.

Adottare un modello di distribuzione non modificabile

La scelta tra la distribuzione di un'infrastruttura modificabile rispetto all'infrastruttura non modificabile dipende da alcuni fattori. Se il carico di lavoro è business critical, è consigliabile usare un'infrastruttura non modificabile. Analogamente, se si dispone di una progettazione di infrastruttura matura basata su indicatori di distribuzione, l'uso di un'infrastruttura non modificabile può avere senso, perché è possibile distribuire il codice dell'applicazione e la nuova infrastruttura in modo affidabile. Viceversa, l'uso di un'infrastruttura modificabile può essere una scelta migliore se le procedure di distribuzione sicure determinano che il rollforward con le distribuzioni quando si verificano problemi di distribuzione errate è l'opzione preferita. In questo caso, è probabile che si aggiorni l'infrastruttura sul posto.

Considerazioni

Maggiore specializzazione: in alcuni casi, l'introduzione di nuove lingue nel team del carico di lavoro include una curva di apprendimento e il blocco del fornitore può fare una scelta scarsa. È necessario formare i membri del team e analizzare lo strumento corretto in base al supporto degli strumenti dei provider di servizi cloud.

Maggiore impegno di manutenzione: la manutenzione della codebase e degli strumenti è necessaria per mantenere aggiornata e sicura l'implementazione IaC. Tenere traccia del debito tecnico e promuovere una cultura in cui la riduzione del debito viene ricompensata.

Maggiore tempo per le modifiche alla configurazione: la distribuzione dell'infrastruttura tramite istruzioni della riga di comando o direttamente da un portale non richiede tempi di codifica e/o artefatti di test. Ridurre al minimo il tempo di distribuzione seguendo le procedure consigliate, ad esempio le revisioni del codice e le procedure di controllo della qualità.

Maggiore complessità della modularizzazione: l'uso di più moduli e parametrizzazione aumenta il tempo necessario per eseguire il debug e documentare il sistema e aggiunge un livello di astrazione. Bilanciare l'uso della modularizzazione per ridurre la complessità ed evitare l'over engineering.

Facilitazione di Azure

I modelli di Azure Resource Manager e Bicep sono strumenti nativi di Azure per la distribuzione dell'infrastruttura usando la sintassi dichiarativa. I modelli arm vengono scritti in JSON, mentre Bicep è un linguaggio specifico del dominio. Entrambi possono essere facilmente integrati nelle pipeline di Azure o nelle pipeline CI/CD di GitHub Actions .

Terraform è un altro strumento IaC dichiarativo completamente supportato in Azure. Può essere usato per distribuire e gestire l'infrastruttura e può essere integrato nella pipeline CI/CD.

È possibile usare Microsoft Defender per il cloud per individuare errori di configurazione in IaC.

Esempio

Vedere l'architettura dell'acceleratore di zona di destinazione di Desktop virtuale Azure e l'implementazione di riferimento associata per un esempio di implementazione di Desktop virtuale che può essere distribuita tramite file di Resource Manager, Bicep o Terraform forniti.

Elenco di controllo per l'eccellenza operativa

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'eccellenza operativa