Condividi tramite

automazione

  • Articolo

Nell'infrastruttura cloud definita dal software, i team usano vari strumenti e tecniche per effettuare il provisioning, configurare e gestire l'infrastruttura. Man mano che i team si evolvono e crescono, possono passare dall'uso di portali e sforzi manuali all'uso del codice e dell'automazione per effettuare il provisioning, configurare e gestire l'infrastruttura e i servizi.

Considerazioni sull'automazione della piattaforma

  • L'implementazione della metodologia Everything as Code (EaC) consente ai team di sbloccare i vantaggi principali, creare una cultura di sviluppo avanzata e consentire a tutti i membri di ogni team di controllare come e quali risorse vengono distribuite. EaC aiuta anche i team della piattaforma ad adottare procedure di sviluppo chiave che ne migliorano l'agilità e l'efficienza. I team possono tenere traccia delle modifiche e controllare quali passare alla produzione ospitando il codice nei repository e usando i sistemi di controllo della versione per gestirli.
  • I team possono seguire il principio a 4 occhi e usare la programmazione peer o la revisione peer per garantire che le modifiche al codice non vengano mai apportate da sole. La programmazione peer e la revisione peer migliorano la qualità del codice, consentono ai team di condividere la responsabilità delle modifiche e aumentare le conoscenze del team su ciò che viene concordato e distribuito. La revisione del codice è un ottimo modo per consentire ai membri del team di apprendere nuove tecniche e metodi per la codifica e l'automazione.
  • Teams deve usare sistemi di controllo della versione come Git, insieme ai repository Git, per applicare la revisione peer. I repository Git consentono ai team di definire rami importanti e proteggerli con i criteri dei rami. È possibile usare i criteri per richiedere modifiche al codice in questi rami per soddisfare determinati criteri, ad esempio un numero minimo di approvazioni dei membri del team, prima di poter eseguire il merge in un ramo protetto.
  • Teams deve connettere la metodologia EaC e il processo di revisione delle modifiche insieme a un processo di integrazione continua e recapito continuo (CI/CD). Ogni modifica del codice deve attivare automaticamente un processo di integrazione continua che esegue distribuzioni di codice statico, convalida e test. L'integrazione continua garantisce che gli sviluppatori verifichino il codice in anticipo (spesso definiti test rapidi o di spostamento a sinistra) per gli errori che possono causare problemi futuri. A seconda della strategia di diramazione usata dal team, le modifiche apportate a qualsiasi ramo importante devono attivare la distribuzione in ambienti diversi. Dopo l'approvazione e il merge delle modifiche in main, il processo cd distribuisce tali modifiche nell'ambiente di produzione. Questo sistema di gestione del codice fornisce al team un'unica fonte di verità per ciò che viene eseguito in ogni ambiente.
  • Per garantire che la piattaforma sia completamente auto-riparazione e fornisca servizi self-service per i team del carico di lavoro, il team della piattaforma deve lavorare per automatizzare tutto (spesso definito Automazione estrema) dal provisioning, alla configurazione e alla gestione della piattaforma al provisioning delle sottoscrizioni della zona di destinazione per i team del carico di lavoro. L'automazione estrema consente al team della piattaforma di concentrarsi sul fornire valore anziché sulla distribuzione, la configurazione e la gestione della piattaforma. L'automazione estrema crea anche un ciclo di auto-miglioramento che offre al team più tempo per creare più automazione.
  • Man mano che i team della piattaforma automatizzano le attività operative e riducono l'intervento umano, devono concentrarsi su attività importanti che consentono e accelerano l'innovazione del team del carico di lavoro in Azure. A tale scopo, il team della piattaforma deve scorrere più cicli di compilazione e sviluppo man mano che vengono inseriti gli strumenti, gli script e i miglioramenti delle funzionalità della piattaforma.
  • Sono disponibili più opzioni per aiutare il team a iniziare a usare la distribuzione della zona di destinazione di Azure. Queste opzioni dipendono dalle funzionalità correnti del team e possono crescere man mano che il team si evolve. In particolare, per la distribuzione della piattaforma, è possibile scegliere tra le esperienze basate su Portale, Bicep o Terraform, a seconda della rispettiva competenza IaC e delle preferenze degli strumenti di Teams.
    • I team della piattaforma nuovi ed emergenti che stanno ancora conoscendo Infrastructure as Code (IaC) e hanno familiarità con l'uso di un portale per distribuire e gestire le risorse possono usare l'acceleratore di zona di destinazione di Azure per iniziare, che supporta ancora i team che usano un approccio ClickOps. ClickOps è il processo di provisioning, configurazione e gestione delle risorse facendo clic su portali, console di gestione e procedure guidate. Questo acceleratore consente al team di usare il portale come strumento di distribuzione iniziale e progressivamente, man mano che la maturità della progettazione della piattaforma aumenta, per usare ulteriormente l'interfaccia della riga di comando di Azure, PowerShell o IaC.
    • La soluzione AzOps consente ai team di evolvere le procedure di automazione e gestione della piattaforma da ClickOps basate su DevOps . Il team può passare dall'uso dell'accesso dell'account personale all'uso dei principi e delle procedure DevOps che si basano solo su CI/CD con AzOps e IaC. AzOps consente al team di usare la propria architettura, usare l'architettura distribuita dall'acceleratore del portale di destinazione di Azure (dopo la distribuzione iniziale basata sul portale, perché l'integrazione di AzOps non fa parte dell'esperienza del portale ALZ), integrarla con una distribuzione brownfield o usare modelli personalizzati (Bicep o ARM) per compilare e rendere operativa la piattaforma.
    • I team della piattaforma con competenze e funzionalità consolidate possono adottare un approccio codificato che segue i principi e le procedure DevOps. Il team deve basarsi principalmente sulle procedure di sviluppo IaC e moderne, passando dall'uso dell'accesso di Azure agli account personali e all'esecuzione di tutte le operazioni tramite la pipeline CI/CD. Il team deve usare acceleratori basati su IaC, ad esempio ALZ-Bicep o il modulo Terraform zone di destinazione di Azure per accelerare questa transizione.
  • Gli acceleratori basati su IaC hanno un ambito di gestione limitato. Le nuove versioni offrono maggiori funzionalità e una maggiore capacità di gestione delle risorse. Se si usa un acceleratore, il team deve considerare un approccio a più livelli che inizia con un acceleratore, quindi aggiunge un livello di automazione. Il livello di automazione offre funzionalità necessarie al team per supportare completamente i team del carico di lavoro con funzionalità della piattaforma come la distribuzione del controller di dominio per le applicazioni legacy.
  • Quando il team della piattaforma passa a un approccio DevOps, è necessario stabilire un processo per la gestione delle correzioni di emergenza. Possono usare autorizzazioni idonee di Privileged Identity Management (PIM) per richiedere l'accesso per eseguire correzioni e in seguito riportarlo al codice per limitare la deriva della configurazione oppure usare il codice per implementare una correzione rapida. Il team deve sempre registrare correzioni rapide nel backlog, in modo da poter rielaborare ogni correzione in un secondo momento e limitare il debito tecnico. Un debito tecnico troppo elevato comporta una decelerazione futura, perché alcuni codici della piattaforma non vengono esaminati completamente e non soddisfano le linee guida e i principi di codifica del team.
  • È possibile usare Criteri di Azure per aggiungere un'automazione alla piattaforma. Prendere in considerazione l'uso di IaC per distribuire e gestire criteri di Azure, spesso definiti policy-as-code (PaC). Questi criteri consentono di automatizzare attività come la raccolta di log. Molti framework PaC implementano anche un processo di esenzione, quindi pianificare i team del carico di lavoro per richiedere esenzioni dai criteri.
  • Usare "Governance guidata dai criteri" per segnalare ai team del carico di lavoro quando tentano di distribuire risorse che non soddisfano un controllo di sicurezza. Prendere in considerazione la distribuzione dei criteri con l'effetto deny per queste situazioni, che consente ai team del carico di lavoro di considerare anche Tutto come codice ed evitare la deriva della configurazione in cui il codice dichiara un elemento e i criteri hanno modificato un'impostazione in fase di distribuzione. Evitare di usare modify effetti, ad esempio se un team del carico di lavoro distribuisce un account di archiviazione con supportOnlyHttpsTraffic = false definito nel codice in cui un modify criterio cambia in true in fase di distribuzione per mantenerlo conforme. Questo comporta la deriva del codice da ciò che viene distribuito.

Raccomandazione per la progettazione dell'automazione della piattaforma

  • Seguire un approccio Tutto come codice per la trasparenza completa e il controllo della configurazione della piattaforma, della documentazione, della distribuzione e del processo di test di Azure.
  • Usare il controllo della versione per gestire tutti i repository di codice, tra cui:
    • Infrastruttura come codice
    • Criteri come codice
    • Configurazione come codice
    • Distribuzione come codice
    • Documentazione come codice
  • Implementare il principio a 4 occhi e un processo per la programmazione peer o la revisione peer per assicurarsi che tutte le modifiche al codice vengano esaminate dal team prima di essere distribuite nell'ambiente di produzione.
  • Adottare una strategia di diramazione per il team e impostare i criteri di ramo per i rami da proteggere. Con i criteri dei rami, i team devono usare le richieste pull per apportare modifiche di tipo merge.
  • Usare l'integrazione continua e il recapito continuo (CI/CD) per automatizzare i test e la distribuzione del codice in ambienti diversi.
  • È possibile automatizzare tutto, ad esempio il provisioning, la configurazione e la gestione della piattaforma e il provisioning delle sottoscrizioni di zona di destinazione per i team del carico di lavoro.
  • Usare uno degli acceleratori disponibili che corrisponde alle funzionalità del team per iniziare a distribuire zone di destinazione di Azure.
  • Pianificare l'uso di un approccio di distribuzione a più livelli per aggiungere funzionalità non coperte da un acceleratore, ma necessarie per supportare completamente i team del carico di lavoro.
  • Stabilire un processo per l'uso del codice per implementare correzioni rapide. Registrare sempre correzioni rapide nel backlog del team, in modo che ogni correzione possa essere rielaborata in un secondo momento ed è possibile limitare il debito tecnico.
  • Usare l'infrastruttura come codice per distribuire e gestire criteri di Azure (spesso definiti criteri come codice)
  • Implementare un processo di esenzione per i criteri. Pianificare i team del carico di lavoro per richiedere esenzioni dai criteri ed essere pronti per sbloccare i team quando necessario.
  • Usare "Governance basata su criteri" per bloccare i team del carico di lavoro quando tentano di distribuire risorse che non soddisfano un controllo di sicurezza. Ciò consente di ridurre la deriva della configurazione, in cui il codice dichiara uno stato diverso da quello che finisce per essere distribuito.

Altre informazioni