Consigli 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 controllo 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 carico di lavoro a 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 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 supply chain e alla standardizzazione di strumenti e processi , è necessario avere un criterio rigoroso di distribuzione delle modifiche dell'infrastruttura (incluse le modifiche di 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, è necessario standardizzare gli strumenti e i processi di sviluppo e distribuzione IaC in una guida di stile. Le raccomandazioni per la guida di stile includono:

Preferisce strumenti dichiarativi rispetto a strumenti imperativi. Gli strumenti dichiarativi e i file associati sono una scelta 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 ottenere lo stato finale desiderato, in modo che i file possano essere molto più complessi dei 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 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 con 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 costantemente aggiornati dal provider della piattaforma, rendendoli più utili man mano che la piattaforma si evolve.

Nota

Tenere presente che i provider di servizi cloud e gli 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 di strumenti e API prima di adottarle. Allo stesso modo, 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 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 Configurazione app di Azure) 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.

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 come 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 di 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.

Strategizzare e standardizzare l'uso dei moduli. Come i parametri e le variabili, i moduli possono rendere ripetibili le distribuzioni dell'infrastruttura. Tuttavia, è opportuno considerare come usarli. Una strategia di astrazione standardizzata consente di garantire che i moduli siano creati 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.

Documentare gli standard per i passaggi manuali. Potrebbero essere necessari passaggi relativi alla distribuzione e alla gestione dell'infrastruttura specifica per l'ambiente e che richiedono un intervento manuale. Assicurarsi che questi passaggi vengano 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 abbiano 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.

Altre strategie IaC

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 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 come pacchetto monolitico è inefficiente e può introdurre più problemi, ad esempio dipendenze interrotte. 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 con 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 può 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.

Trattare il codice IaC e l'applicazione allo stesso modo. La gestione degli artefatti IaC equivale agli 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. Valutare anche la possibilità di posizionare gli asset IaC insieme agli asset del codice dell'applicazione. In questo modo è possibile assicurarsi che gli stessi processi vengano seguiti con ogni distribuzione e consentono di evitare problemi come la distribuzione inavvertitamente dell'infrastruttura prima del codice dell'applicazione necessario o viceversa.

Collaborare con altri team dell'organizzazione per la standardizzazione e la riutilizzabilità. Le organizzazioni di grandi dimensioni possono talvolta avere più team che sviluppano e supportano carichi di lavoro. La collaborazione tra i team per accettare gli standard consente di riutilizzare librerie, modelli e moduli per ottenere efficienza e coerenza negli ambienti del carico di lavoro. Allo stesso modo, gli strumenti IaC devono essere standardizzati in tutta l'organizzazione per quanto ciò sia pratico.

Applicare il principio di "sicurezza come codice" per assicurarsi che la sicurezza faccia parte della pipeline di distribuzione. Includere l'analisi della vulnerabilità e la protezione avanzata della configurazione come parte del processo di sviluppo IaC. Analizzare i repository IaC per chiavi e segreti esposti. Un vantaggio 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 la versione per la sicurezza sia effettivamente ciò che viene distribuito nell'ambiente di produzione. Per indicazioni dettagliate, vedere Raccomandazioni per la protezione di un ciclo di vita dello sviluppo.

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

Infrastruttura modificabile e 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 l'infrastruttura non modificabile. Analogamente, se si dispone di una progettazione di infrastruttura matura basata su stamp di distribuzione, l'uso dell'infrastruttura non modificabile può essere utile, perché è possibile distribuire il codice dell'applicazione e la nuova infrastruttura in modo affidabile. Al contrario, l'uso dell'infrastruttura modificabile può essere una scelta migliore se le procedure di distribuzione sicure determinano che il roll forward con le distribuzioni quando si verificano problemi di distribuzione mitigabili è l'opzione preferita. In questo caso, è probabile che l'infrastruttura venga aggiornata.

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ò renderlo una scelta scarsa. È necessario formare i membri del team e analizzare lo strumento appropriato in base al supporto degli strumenti dei provider di servizi cloud.

Maggiore sforzo di manutenzione: La manutenzione degli strumenti e della base del codice è necessaria per mantenere l'implementazione IaC corrente e sicura. 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 usando le istruzioni della riga di comando o direttamente da un portale non richiede tempo di codifica e/o elementi di test. Ridurre al minimo il tempo di distribuzione seguendo le procedure consigliate, ad esempio le revisioni del codice e le procedure di garanzia 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 (modelli arm) e Bicep sono strumenti nativi di Azure per la distribuzione dell'infrastruttura usando la sintassi dichiarativa. I modelli di Resource Manager vengono scritti in JSON, mentre Bicep è un linguaggio specifico del dominio. Entrambi possono essere facilmente integrati in pipeline di Azure o GitHub Actions pipeline CI/CD.

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 Cloud per individuare errori di configurazione in IaC.

Esempio

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

Elenco di controllo Di eccellenza operativa

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo Di eccellenza operativa