Raccomandazioni per l'uso dell'infrastruttura come codice

  • Articolo

Si applica a questo elenco di controllo di Eccellenza operativa di Azure Well-Architected Framework:

OE:05 Preparare le risorse e le relative configurazioni usando un approccio di infrastruttura standardizzata come codice (IaC). Come altri codici, progettare IaC con stili coerenti, modularizzazione appropriata e garanzia di qualità. Preferire un approccio dichiarativo quando possibile.

Questa guida descrive i consigli 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 coerente e standard per lo sviluppo e la distribuzione per tutti i componenti del carico di lavoro. L'uso delle distribuzioni manuali mette il carico di lavoro a rischio di configurazioni incoerenti e di progettazione potenzialmente insicure.

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 destinata a essere sostituita con una nuova infrastruttura che esegue la nuova configurazione con ogni distribuzione. Non deve essere modificato sul posto.
Strumenti imperativi Categoria di strumenti che elencano i passaggi di esecuzione che comportano lo stato finale desiderato.
Modulo Unità di astrazione per dividere i 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 agli strumenti e ai processi di standardizzazione della catena di fornitura, è necessario disporre di criteri rigorosi per distribuire le modifiche dell'infrastruttura (incluse le modifiche di configurazione) solo tramite il codice. È necessario 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 deriva della configurazione negli ambienti e garantisce la coerenza dell'infrastruttura negli ambienti. È inoltre necessario standardizzare gli strumenti di sviluppo e distribuzione IaC in una guida allo stile. Le raccomandazioni per la guida di stile includono:

Preferire gli strumenti dichiarativi sugli 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 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 gli strumenti nativi della piattaforma cloud e altri strumenti comprovati dal 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 aggiornati continuamente dal provider di piattaforme, rendendoli più utili quando 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 eseguire il rischio di problemi imprevisti quando si usa la versione più recente nel carico di lavoro. Assicurarsi di testare accuratamente nuove versioni di strumenti e API prima di adottarle. Analogamente, evitare di usare il flag "più recente" quando si chiama uno strumento o un'API nel codice di distribuzione. È consigliabile chiamare la versione più recente valida 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 le distribuzioni di script, 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 ottimale per la gestione di DSC nei cluster Kubernetes. I servizi PaaS (Platform as a Service) possono fornire diversi strumenti per la gestione della configurazione (ad esempio Configurazione app di Azure) che possono essere gestiti tramite IaC. I servizi Software as a service (SaaS) potrebbero essere più limitati perché sono più strettamente controllati dalla piattaforma.

Si considerino tutte le attività e i tipi di infrastruttura che si trovano nell'ambito delle procedure IaC e standardizzare sugli strumenti che devono eseguire i processi necessari e possono essere integrati nelle procedure di sviluppo e gestione.

Gli script e i modelli devono essere abbastanza 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 promozioni del codice. Impostazioni astratte come dimensioni delle risorse, conteggio, nome, posizioni da distribuire in 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 astratti.

Nota

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

Strategizzare e standardizzare l'uso dei moduli. Come parametri e variabili, i moduli possono rendere ripetibili le distribuzioni dell'infrastruttura. Tuttavia, è consigliabile 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 complesse o combinazioni di risorse. Evitare moduli se si usa solo la configurazione predefinita della risorsa. Inoltre, essere giudizioso nello sviluppo di nuovi moduli. Usare i moduli open source gestiti quando appropriato, ad esempio scenari non dissensibili.

Standard del documento 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 chiaramente documentati. 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 dal carico di lavoro e gli strumenti IaC non possono rimuovere automaticamente la risorsa. Ad esempio, si supponga di passare da macchine virtuali a un servizio PaaS per alcune funzioni e lo strumento IaC non ha logica per rimuovere le risorse ritirati. Queste risorse possono diventare orfane se il team del carico di lavoro non ricorda di eliminarli 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. Cercare le limitazioni dello strumento IaC per comprendere cosa potrebbe essere necessario pianificare in queste situazioni.

Altre strategie IaC

Prendere in considerazione i consigli seguenti che si applicano all'uso di IaC per il carico di lavoro:

Usare un approccio a 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 rende più semplice la gestione delle distribuzioni IaC.

L'infrastruttura principale, ad esempio le risorse di rete, richiede raramente modifiche più complesse rispetto agli aggiornamenti della configurazione, pertanto tali risorse devono creare una pipeline IaC con tocco basso . È 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. L'uso di uno stack di applicazioni basato su Kubernetes come esempio può essere costituito da un livello di tocco medio composto da cluster, risorse di archiviazione e servizi di database. I livelli a tocco elevato sono costituiti dai contenitori dell'applicazione che vengono aggiornati molto spesso in modalità di recapito continua.

Trattare il codice IaC e dell'applicazione lo stesso. 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 eseguire il mirroring delle procedure dell'applicazione. Gli standard per il controllo della versione, il ramo, la promozione del codice e la qualità devono essere tutti identici. Valutare anche la possibilità di collocare gli asset IaC insieme agli asset di codice dell'applicazione. In questo modo si garantisce che gli stessi processi vengano seguiti con ogni distribuzione e consentono di evitare problemi come la distribuzione accidentale dell'infrastruttura prima del codice dell'applicazione necessario o viceversa.

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 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. Un vantaggio dell'uso di IaC è che i membri del team incentrati sulla sicurezza possono esaminare il codice prima della distribuzione per garantire che la configurazione approvata per il rilascio dalla sicurezza sia effettivamente ciò che viene distribuito 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 le distribuzioni, gli aggiornamenti della 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 e 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 roll forward con le distribuzioni quando si verificano problemi di distribuzione non affidabili è 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 corretto in base al supporto degli strumenti dei provider di servizi cloud.

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

Maggiore tempo per le modifiche alla configurazione: La distribuzione dell'infrastruttura tramite 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 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 (modelli arm) e Bicep sono strumenti nativi di Azure per la distribuzione dell'infrastruttura usando la sintassi dichiarativa. I modelli arm sono 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 configurazioni errate in IaC.

Allineamento dell'organizzazione

Cloud Adoption Framework fornisce indicazioni per i team centrali su come standardizzare l'infrastruttura come codice nei team del carico di lavoro dell'organizzazione.

Per altre informazioni, vedere Infrastruttura come codice nel Cloud Adoption Framework.

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 forniti Resource Manager, Bicep o Terraform.

Elenco di controllo per l'eccellenza operativa

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'eccellenza operativa