Modifica

Share via

Infrastruttura aziendale come codice con Bicep e Registro Azure Container

Registro Azure Container
Azure DevOps
Servizio Azure Kubernetes
Azure Resource Manager
Criteri di Azure

La modularizzazione della gestione dei modelli di Azure Resource Manager consente di ridurre la ripetizione, le procedure consigliate per i modelli nello sviluppo dell'infrastruttura e di avere distribuzioni standard coerenti.

Un caso d'uso di esempio per l'implementazione di questo tipo di modularizzazione è la distribuzione di macchine virtuali usando la metafora delle dimensioni della maglietta. Si supponga di aver distribuito decine o centinaia di macchine virtuali. Queste distribuzioni usano la versione 1.0.0 dei modelli e hanno una dimensione media standard di una serie precedente. Per eseguire la transizione a una nuova serie potrebbe essere necessaria una breve interruzione del servizio se sono stati semplicemente distribuiti nuovi modelli. Tuttavia, creando la versione 1.5.0 e usando la modularizzazione, è possibile distribuire una nuova infrastruttura con lo standard aggiornato mantenendo l'infrastruttura precedente in uno stato distribuibile. Se sono disponibili versioni precedenti dell'infrastruttura, i team di prodotti e applicazioni hanno una configurazione valida nota da usare durante l'aggiornamento alla nuova versione man mano che hanno tempo.

La torta di livelli dei repository: un esempio per le aziende

Quando si tratta del motivo per cui si potrebbe voler avere una preferenza forte per dove vanno i modelli, come vengono aggiornati e così via, esistono due considerazioni principali: diramazione e innersourcing.

  • Ramificazione. Questo scenario di esempio facilita i modelli di diramazione Git che supportano Gitflow e il flusso GitHub. Per altre informazioni su Gitflow, vedere Uso di git-flow per automatizzare il flusso di lavoro di diramazione git, un post di blog di Jeff Kreeftmeijer. Per altre informazioni sul flusso GitHub, vedere Flusso di GitHub nella documentazione di GitHub.

  • Innersourcing. Il secondo è l'innersourcing, che porta le pratiche collaborative dello sviluppo di software open source allo sviluppo interno. In uno scenario di questo tipo, è possibile condividere in modo più sicuro modelli e codice sorgente del modulo diversi senza dover necessariamente preoccuparsi delle autorizzazioni per i modelli di distribuzione stessi. Per altre informazioni sullo sviluppo di innersource, vedere Introduzione a innersource in GitHub.

Bicep è un linguaggio dichiarativo per la distribuzione delle risorse di Azure. Il codice riutilizzabile di Bicep può usare Registro Azure Container come registro privato per l'hosting di modelli arm con controllo delle versioni. Usando il Registro Contenitori in questo modo, l'azienda può avere un processo di integrazione continua e recapito continuo (CI/CD) per l'infrastruttura. È possibile eseguire unit test di integrazione e unit test come parte del processo di integrazione continua e il registro contenitori può ricevere moduli dopo la compilazione. I team delle app possono continuare a usare le versioni precedenti fino a quando non sono pronti per l'aggiornamento oppure possono eseguire l'aggiornamento per sfruttare i vantaggi delle funzionalità nelle versioni più recenti dei modelli.

Oltre a questo uso di Registro Container, è possibile combinare questo modello con un modello simile ai moduli verificati di Azure. L'implementazione potrebbe usare dal Registro di sistema pubblico o, preferibilmente, monitorare i repository pubblici ed eseguire il pull delle modifiche nel registro privato per un ulteriore uso. Il pull delle modifiche nel proprio registro contenitori consente di eseguire test su moduli pubblici, garantendo al tempo stesso che non vengano usate nell'ambiente di produzione fino a quando non vengono incorporate procedure di qualità e sicurezza.

Strati

Il modello proposto in questo scenario di esempio è uno stack. I livelli più vicini alla parte superiore dello stack hanno distribuzioni e distribuzioni più frequenti che sono più personalizzate. Il codice Bicep offre distribuzioni coerenti. I team di sviluppo, che lavorano nei livelli per i loro contributi, si basano sui servizi e sull'infrastruttura forniti nei livelli seguenti. Nessun elemento in un livello inferiore deve basarsi sulle risorse in un livello superiore. Dal livello 0 a 3 sono libreria globale, infrastruttura globale (servizi condivisi a livello globale), piattaforma del prodotto (servizi condivisi) e applicazioni.

Diagram that shows the layers of development, ordered by development frequency.

Questo modello crea l'autonomia con l'allineamento, il che significa avere:

  • Strumenti comuni per la facilità aziendale. Ad esempio, tutti usano Git per il controllo del codice sorgente e tutti usano GitHub Actions per CI/CD. Tuttavia, non siamo troppo inconsarriti. Ad esempio, non è obbligatorio che tutti i team usino Bicep; possono usare Terraform, modelli arm e altri strumenti.

  • Possibilità di condividere le procedure consigliate. Possono assumere la forma di modelli arm, immagini dorate o frammenti di codice. Le procedure consigliate possono anche essere la documentazione di tecniche specifiche. Ad esempio, come ruotare le chiavi nell'ambiente e come testare il codice.

  • Alcuni servizi si spostano verso il basso nello stack. Ad esempio, un team di app può inizialmente sviluppare un modello per la distribuzione di un cluster Kubernetes, che verrà successivamente inserito nella piattaforma del prodotto come servizio condiviso. Questo modello diventa così utile che viene inserito nella libreria di esempi.

Livello 0 - Libreria globale

Il livello inferiore è la libreria globale, che è un repository di utili tidbit che non vengono distribuiti nell'ambiente di produzione. Dal punto di vista del controllo di accesso, l'accesso in lettura deve essere fornito a chiunque all'interno dell'azienda che lo richiede. Per modifiche, suggerimenti e così via, il Cloud Center of Excellence (CCoE) approva le richieste pull e gestisce un backlog come se fosse un altro prodotto.

Screen shot of the folder structure of layer 0, global infrastructure library, with the 'arm' folder selected.

Il livello 0 non deve contenere:

  • Modelli distribuiti nell'ambiente di produzione.
  • Segreti o configurazioni specifiche dell'ambiente.

Il livello 0 deve contenere:

  • Frammenti di codice (in Python, C# e così via).
  • Criteri di Azure esempi.
  • Modelli arm, modelli Bicep o file Terraform che possono essere usati come esempi.

Un esempio di questa è un'architettura di esempio per il modo in cui l'azienda scrive una distribuzione per un'applicazione a tre livelli senza informazioni specifiche dell'ambiente. Questa architettura di esempio può includere tag, reti, gruppi di sicurezza di rete e così via. Lasciare informazioni specifiche per l'ambiente è utile, perché non tutto può essere o deve essere inserito in un modulo. Il tentativo di eseguire questa operazione può comportare un over-parameterization.

Inoltre, il livello 0 può essere collegato ad altre origini valide note del codice di esempio, ad esempio Il Registro Terraform o i moduli di risorse di Azure. Se l'organizzazione adotta codice o modello da una di queste origini, è consigliabile eseguire il pull del codice o del modello nel proprio livello 0 anziché eseguire il pull direttamente dalle origini pubbliche. Basandosi sul livello 0, è possibile scrivere test, modifiche e configurazioni di sicurezza personalizzate. Non basandosi sulle origini pubbliche, si riduce il rischio di affidarsi a un elemento che potrebbe essere eliminato in modo imprevisto.

Per essere considerato un buon codice di esempio, i modelli e i moduli devono seguire le procedure di sviluppo consigliate, inclusa la convalida dell'input per la sicurezza e per i requisiti dell'organizzazione. Per mantenere questo livello di rigore, è necessario aggiungere criteri al ramo principale per richiedere richieste pull e revisioni del codice per le modifiche proposte che comportano il flusso delle modifiche al registro contenitori principale se unito.

Il livello 0 viene inserito in Azure Pipelines o GitHub Actions per creare automaticamente elementi con controllo delle versioni in Registro Azure Container. È possibile compilare l'automazione per i messaggi di commit Git per implementare il controllo delle versioni semantiche degli artefatti. Per il corretto funzionamento, è necessario disporre di uno standard di denominazione deterministico, ad esempio <service.bicep>, per rendere l'automazione gestibile nel tempo. Con i criteri di ramo appropriati, è anche possibile aggiungere test di integrazione come prerequisito per le revisioni del codice. È possibile instrumentare questo strumento usando strumenti come Pester.

Con tali criteri e protezioni sul posto, il registro contenitori può essere la fonte di verità per tutti i moduli di infrastruttura dell'organizzazione pronti per l'uso. È consigliabile valutare la standardizzazione dei log delle modifiche, nonché gli indici degli esempi di codice disponibili, per consentire l'individuazione di questo codice. Codice sconosciuto non usato.

Livello 1 - Infrastruttura globale: servizi condivisi a livello globale

Il livello 1 è il repository per i costrutti della zona di destinazione di Azure. Mentre Microsoft fornisce modelli per la distribuzione delle zone di destinazione di Azure, è consigliabile modificare determinati componenti e fornire un file di parametri. Questo è analogo al modo in cui si esegue il pull dei repository del Registro di sistema e dei moduli pubblici nel livello 0, come descritto in precedenza.

Screen shot of the contents of the 'infrastructure' and 'policy' folders in layer 1, global infrastructure (globally shared services).

Registro Azure Container è una parte fondamentale di questa architettura. Anche se l'azienda non prevede l'uso di contenitori, è necessario distribuire Registro Container per avere esito positivo nel controllo delle versioni dei modelli Bicep. Registro Contenitori offre flessibilità e riutilizzabilità significativi per i moduli, offrendo al tempo stesso sicurezza e controllo di accesso di livello aziendale.

Il livello 1 deve contenere:

  • Assegnazioni e definizioni di criteri applicate a livello di gruppo di gestione o sottoscrizione. Questi criteri devono corrispondere ai requisiti di governance aziendale.
  • Modelli per l'infrastruttura di rete principale, ad esempio ExpressRoute, VPN, rete WAN virtuale e reti virtuali (condiviso o hub).
  • DNS.
  • Monitoraggio principale (Log Analytics).
  • Registro contenitori dell'organizzazione.

È consigliabile configurare la protezione dei rami per limitare la possibilità di eseguire il push delle modifiche nel repository. Limitare l'approvazione delle richieste pull da altri sviluppatori ai membri di CCoE o Cloud Governance. I collaboratori a questo livello sono principalmente membri di gruppi storicamente associati ai componenti di questo livello. Ad esempio, il team di rete compila i modelli per la rete, il team operativo configura il monitoraggio e così via. Tuttavia, è necessario concedere l'accesso in sola lettura a singoli utenti che lo richiedono, perché si vuole consentire agli sviluppatori di altri gruppi di suggerire modifiche alle infrastrutture principali. Possono contribuire ai miglioramenti, anche se non è possibile unire le modifiche senza approvazione e test.

Questi file devono usare i moduli nel registro contenitori per i componenti standard. Tuttavia, si avrà anche un file Bicep o una serie di file Bicep, personalizzati per l'implementazione aziendale delle zone di destinazione di Azure o di una struttura di governance simile.

Livello 2 - Piattaforma del prodotto: Servizi condivisi

È possibile considerare la piattaforma di livello 2, prodotto, come servizi condivisi per una particolare linea di prodotto o business unit. Questi componenti non sono universali nell'organizzazione, ma sono destinati a soddisfare una particolare esigenza aziendale. Si tratta di un livello appropriato per una rete virtuale che è un peer con l'hub nel livello 1, infrastruttura globale. Un insieme di credenziali delle chiavi è un altro componente di esempio per questo livello. L'insieme di credenziali delle chiavi può archiviare segreti condivisi in un account di archiviazione o in un database condiviso dalle diverse applicazioni all'interno di questa piattaforma.

Screen shot of the contents of the 'infrastructure' and 'platform-code' folders in layer 2, product platform (shared services).

Il livello 2 deve contenere:

  • Assegnazioni di criteri applicate a una sottoscrizione o a un gruppo di risorse per soddisfare i requisiti specifici del prodotto.
  • Modelli di Resource Manager per insiemi di credenziali delle chiavi, Log Analytics, un database SQL (se varie applicazioni all'interno del prodotto usano il database) e servizio Azure Kubernetes.

È necessario implementare le autorizzazioni che limitano la possibilità di eseguire il push delle modifiche nel repository. Analogamente agli altri livelli, è consigliabile usare la protezione dei rami per assicurarsi che un responsabile o un proprietario del prodotto possa approvare richieste pull da altri sviluppatori. Non esistono regole fisse sull'accesso in lettura alla piattaforma del prodotto, ma almeno agli sviluppatori di uno dei team dell'applicazione deve essere concesso l'accesso in lettura per poter suggerire le modifiche. Poiché il livello 2 potrebbe contenere un'architettura proprietaria o informazioni simili, è possibile scegliere di limitare l'accesso a quelli dell'organizzazione che usano la piattaforma. Tuttavia, se questo è il caso, è necessario assicurarsi di creare un processo di raccolta di procedure consigliate e frammenti di codice da questo repository per condividere con la libreria globale, livello 0.

Livello 3 - Applicazione

Il livello 3, il livello applicazione, include i componenti basati sulla piattaforma del prodotto. Questi componenti offrono le funzionalità richieste dall'azienda. Ad esempio, per una piattaforma di streaming, un'app può fornire la funzione di ricerca mentre un'app diversa fornisce raccomandazioni.

Screen shot of the contents of the 'app' and 'infrastructure' folders in layer 3, applications.

Il livello 3 deve contenere:

  • Codice dell'applicazione in C#, Python e così via.
  • Infrastruttura per singoli componenti (usati solo in questa applicazione): funzioni, Istanze di Azure Container, Hub eventi.

Le autorizzazioni sono limitate per la possibilità di eseguire il push delle modifiche nel repository. È consigliabile usare la protezione dei rami per consentire a un membro del team di questa applicazione di approvare una richiesta pull effettuata da un altro membro del team. I membri del team non devono essere autorizzati ad approvare le proprie modifiche. Poiché questo livello può contenere un'architettura proprietaria, una logica di business o informazioni simili, è possibile scegliere di limitare l'accesso a quelli dell'organizzazione che compilano l'applicazione. Tuttavia, se questo è il caso, è necessario creare anche un processo di raccolta di procedure consigliate e frammenti di codice da questo livello per condividere con la libreria globale, livello 0.

Commonalities tra i livelli

Anche se questo articolo descrive alcuni dettagli specifici per ogni livello, esistono anche alcune qualità per tutti i livelli da considerare.

L'infrastruttura deve funzionare come se fosse un'applicazione. Ciò significa che è necessario avere un processo di integrazione continua (CI) in cui vengono testate completamente nuove funzionalità, con unit test, smoke test e test di integrazione. È consigliabile unire solo il codice che supera questi test nel ramo di rilascio principale.

È anche necessario assicurarsi di disporre di criteri di ramo per impedire agli utenti di aggirare il processo, anche per l'esperienza. Se il processo di integrazione continua è considerato un ostacolo, significa che si è verificato un debito tecnico che deve essere gestito. Non significa che è necessario rimuovere i criteri e le protezioni.

Infine, anche se potrebbe non avere un indice di tutti i repository e il codice all'interno di essi, l'organizzazione deve sviluppare un processo per i singoli utenti per richiedere l'accesso ai repository. Alcune regole potrebbero essere completamente automatizzate. Ad esempio, è possibile implementare una regola che concede l'accesso in lettura, senza revisione, a un collaboratore del team del prodotto per qualsiasi applicazione nel prodotto. Tali regole possono essere spesso implementate con l'appartenenza basata sui gruppi e le assegnazioni di ruolo basate su gruppi negli ambienti. La configurazione di questo tipo di accesso dovrebbe aiutare a facilitare l'approvvigionamento interno e le conoscenze dell'organizzazione.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Altri contributori:

Passaggi successivi