Effettuare il provisioning dell'analisi su scala cloud
Processo di distribuzione della zona di destinazione per la gestione dei dati
Il team operativo della piattaforma dati è responsabile della distribuzione di una zona di destinazione per la gestione dei dati. La zona di destinazione per la gestione dei dati deve avere un proprio repository gestito dal team operativo della piattaforma dati.
Attenzione
Creare e distribuire una zona di destinazione per la gestione dei dati prima della distribuzione di qualsiasi zona di destinazione dei dati.
Processo di distribuzione della zona di destinazione dei dati
I team possono usare i modelli forniti dal team operativo della piattaforma dati per evitare di iniziare da zero per ogni asset. È consigliabile usare un modello di fork per automatizzare la distribuzione di una nuova zona di destinazione.
Ad esempio, un team operativo della zona di destinazione dei dati richiede una nuova zona di destinazione dei dati usando uno strumento di gestione IT o Power Apps. Dopo l'approvazione della richiesta, avviare il flusso di lavoro seguente usando i parametri della richiesta:
- Distribuire una nuova sottoscrizione per la nuova zona di destinazione dei dati.
- Creare una copia tramite fork del ramo principale del modello di zona di destinazione dei dati per creare un nuovo repository.
- Creare una connessione del servizio nel nuovo repository.
- Aggiornare i parametri nel nuovo repository in base ai parametri della richiesta.
- Creare una pipeline di distribuzione per distribuire i servizi, attivata dalla sincronizzazione dei parametri aggiornati.
- Notificare al team operativo della zona di destinazione dei dati che la nuova zona di destinazione è disponibile.
Il team operativo della zona di destinazione dei dati ora può modificare o aggiungere modelli di Azure Resource Manager.
Questo flusso di lavoro può essere automatizzato usando più set di servizi nella piattaforma Azure. Gestire alcuni dei passaggi, ad esempio la ridenominazione dei parametri nei file di parametri, tramite pipeline CI/CD. Altri passaggi possono essere eseguiti usando altri strumenti di orchestrazione del flusso di lavoro come App per la logica.
Il modello di fork consente ai team di aggiornare i modelli dai modelli originali usati per crearne una copia tramite fork. Inoltre, se vengono implementati miglioramenti o nuove funzionalità nei repository di modelli, i team operativi possono eseguirne il pull nel fork.
Adottare le procedure consigliate per i repository, ad esempio:
- Proteggere il ramo principale.
- Usare i rami per modifiche, aggiornamenti e miglioramenti.
- Definire i proprietari del codice che approvano le richieste pull prima di unire le modifiche nel ramo principale.
- Convalidare i rami tramite test automatizzati.
- Limitare il numero di azioni e utenti tipo nel team, ad esempio chi può attivare pipeline di compilazione e versione.
Suggerimento
Coordinare le attività tra i team per garantire che i miglioramenti o le nuove funzionalità nei modelli originali vengano replicati in tutte le istanze della zona di destinazione dei dati. I team operativi possono eseguire il pull delle modifiche dei modelli originali nel fork.
Il processo di onboarding è separato dal processo di distribuzione della zona di destinazione dei dati. Questa separazione si basa sul presupposto che la maggior parte delle organizzazioni abbia un processo standard di distribuzione della sottoscrizione di Azure come parte del modello operativo cloud. Il processo di onboarding distribuisce i componenti aziendali standard, come uno strumento di gestione dei servizi IT di terze parti. I componenti specifici della zona di destinazione dei dati vengono distribuiti successivamente.
Non sono disponibili API Git per la clonazione, l'aggiornamento, il commit e il push nella soluzione di automazione proposta. L'approccio consiste quindi nell'usare un account Automazione di Azure contenente runbook di PowerShell che:
- Configurano una zona di destinazione dei dati
- Creano una copia tramite fork del repository principale in un repository Git della piattaforma dati
- Impostano le configurazioni della subnet per la zona di destinazione dei dati
- Configurare Microsoft Entra ID
I runbook usano le funzioni Git del modulo PowerShell GitAutomation per l'uso con i repository Git. Installando questo modulo in un account Automazione di Azure, gli utenti possono eseguire operazioni di creazione, clonazione, query, push, pull e commit nei repository Git. L'immagine seguente mostra il modulo GitAutomation installato all'interno di un account Automazione di Azure:
Usare la funzione Copy-GitRepository del modulo GitAutomation per clonare il repository Git principale dall'URL specificato da URL al percorso Git della piattaforma dati specificato da DestinationPath.
Questo approccio alla distribuzione della zona di destinazione dei dati è flessibile, garantendo al tempo stesso che le azioni siano conformi ai requisiti dell'organizzazione. La gestione del ciclo di vita viene abilitata applicando nuove funzionalità o ottimizzazioni dai modelli originali.
Processo di distribuzione dell'applicazione dati
Dopo aver creato una zona di destinazione dei dati, l'onboarding può iniziare per i team dell'applicazione dati. I team operativi della piattaforma dati o della zona di destinazione dei dati concedono l'approvazione della distribuzione.
La distribuzione viene eseguita direttamente usando strumenti DevOps o chiamata tramite pipeline/flussi di lavoro esposti come API. Analogamente alla zona di destinazione dei dati, la distribuzione inizia con la copia tramite fork del repository dell'applicazione dati originale.
- L'utente effettua una richiesta per i nuovi servizi dell'applicazione dati.
- Il processo del flusso di lavoro richiede l'approvazione del team operativo della piattaforma dati o della zona di destinazione dei dati.
- Il flusso di lavoro chiama l’API Gestione dei servizi IT per creare i gruppi di risorse necessari e la creazione di una connessione del servizio Azure DevOps. Il flusso di lavoro assegna un team al progetto Azure DevOps.
- Il flusso di lavoro crea un fork del repository dell'applicazione dati originale per creare il progetto Azure DevOps di destinazione.
- Il flusso di lavoro crea un file di parametri del modello di Azure Resource Manager e pipeline.
- Il flusso di lavoro avvia quindi una pipeline di Azure per creare i requisiti di rete e un'altra pipeline di Azure per distribuire i servizi dell'applicazione dati.
- Il flusso di lavoro invia una notifica all'utente al completamento.
Suggerimento
Se non si ha esperienza con DataOps, vedere l’esercitazione pratica DataOps per il data warehouse moderno nel Centro architetture di Azure. Lo scenario dell’esercitazione descrive un ufficio fittizio di urbanistica che può usare questa soluzione di distribuzione. La soluzione di distribuzione fornisce una pipeline di dati end-to-end che segue il modello architetturale di data warehouse moderno, insieme ai processi DevOps e DataOps corrispondenti, per valutare l'uso dei parcheggi e prendere decisioni aziendali più informate.
Riepilogo
I modelli precedenti forniscono controllo, agilità, self-service e gestione del ciclo di vita dei criteri.
All'inizio del progetto, la piattaforma dati ha un progetto Azure DevOps con una o più Azure Boards. I singoli team DevOps si concentrano su:
- Un repository per la zona di destinazione per la gestione dei dati, le pipeline e una connessione del servizio all'ambiente cloud.
- Un repository di modelli per la zona di destinazione dei dati, le pipeline per distribuire un'istanza della zona di destinazione dei dati e le connessioni del servizio agli ambienti cloud.
- Un repository di modelli per i servizi di prodotti dati, le pipeline per distribuire un'istanza del prodotto dati e connessioni del servizio agli ambienti cloud. Queste connessioni vengono copiate tramite fork dalla zona di destinazione dei dati di Azure DevOps Projects.
Dopo aver distribuito le zone di destinazione dei dati, l'analisi su scala cloud prevede che:
- Ogni zona di destinazione dei dati avrà un proprio progetto Azure DevOps con una o più Azure Boards.
- Per ogni applicazione dati, il fork del progetto Azure DevOps per la zona di destinazione dei dati viene creato dopo l'approvazione della richiesta.
- Ogni applicazione dati include:
- Una connessione del servizio.
- Una pipeline registrata.
- Un team DevOps con accesso al repository e alla board di Azure.
- Un set diverso di criteri per il repository con fork.
Per controllare la distribuzione delle applicazioni dati, seguire queste procedure:
- Il team operativo della zona di destinazione dei dati possiede e protegge il ramo principale del repository.
- Solo il ramo principale viene usato per la distribuzione in ambienti di test e produzione.
- I rami di funzionalità possono essere distribuiti negli ambienti di sviluppo.
- I rami di funzionalità sono di proprietà dei team DataOps. Vengono usati per testare funzionalità nuove o modificate.
- I team DataOps possono unire rami di funzionalità in altri rami di funzionalità senza approvazione.
- I team DataOps creano una richiesta pull per unire i rami di funzionalità nel ramo principale e il team operativo della zona di destinazione dei dati fornisce l'approvazione.
- Le nuove funzionalità o i miglioramenti apportati ai modelli originali vengono uniti nel repository con fork per mantenerli aggiornati.