Gestire l'analisi su scala cloud
Oggi DevOps ha spostato la cultura del modo in cui le persone pensano e lavorano, accelerando il tasso in cui le aziende realizzano valore aiutando persone e organizzazioni a sviluppare e mantenere pratiche di lavoro sostenibili. DevOps combina sviluppo e operazioni ed è spesso associato a strumenti di ingegneria del software che supportano le procedure di integrazione continua (CI) e distribuzione continua (CD). Questi strumenti e procedure includono strumenti di gestione del codice sorgente (come Git, Apache Subversion o controllo della versione di Team Foundation) e strumenti di gestione di compilazione e recapito automatici (come Azure Pipelines o GitHub Actions).
DevOps combinato con osservabilità è fondamentale per fornire una piattaforma agile e scalabile. DevOps consente ai team di implementare il controllo del codice sorgente, le pipeline CI/CD, l'infrastruttura come codice, flussi di lavoro e automazione. Mentre l'osservabilità consente ai proprietari aziendali, ai tecnici DevOps, agli architetti dei dati, ai data engineer e agli ingegneri dell'affidabilità del sito di rilevare, prevedere, prevenire e risolvere i problemi in modo automatizzato ed evitare di eliminare tempi di inattività che altrimenti interromperebbero l'analisi di produzione e l'intelligenza artificiale.
Controllo del codice sorgente
Il controllo del codice sorgente garantisce che il codice e le configurazioni siano persistenti e che le modifiche siano tracciate e sia incluso il controllo della versione. La maggior parte dei sistemi di controllo del codice sorgente include anche processi predefiniti per la revisione e l'uso in rami diversi di un repository di codice. Attualmente, il tipo di controllo del codice sorgente più diffuso è Git, un sistema di controllo della versione distribuito che consente agli utenti di lavorare offline e di eseguire la sincronizzazione con i repository centrali. Anche i fornitori Git in genere usano i rami e seguono le linee guida per le richieste pull per supportare il flusso di modifica e revisione.
I rami isolano le modifiche o gli sviluppi delle funzionalità senza influire su altre operazioni che si verificano contemporaneamente. L'uso dei rami deve essere promosso per sviluppare funzionalità, correggere bug e sperimentare in modo sicuro nuove idee. Le richieste pull uniscono le modifiche apportate da un ramo nel ramo predefinito e supportano un processo di revisione controllato. Per motivi di sicurezza, il ramo principale deve usare le richieste pull per garantire le revisioni del codice.
Importante
Seguire queste linee guida per i repository di analisi su scala cloud:
- Proteggere il ramo principale del repository applicando rami e richieste pull per garantire un processo di revisione controllato.
- I repository Azure DevOps o GitHub devono essere usati per il controllo del codice sorgente per tenere traccia delle modifiche apportate al codice sorgente e consentire a più membri del team di sviluppare codice contemporaneamente.
- Il codice dell'applicazione e le configurazioni dell'infrastruttura devono essere archiviati in un repository.
Pipeline CI/CD
L’integrazione continua consente ai team di testare e compilare automaticamente il codice sorgente e consente iterazioni rapide e cicli di feedback per garantire un'elevata qualità del codice in distribuzione continua. Le pipeline sono un modo per configurare l’integrazione continua delle modifiche (codice software o codice di infrastruttura) e la distribuzione continua delle modifiche compilate/inserite in pacchetti. Questa operazione viene definita anche compilazione e rilascio. La distribuzione continua descrive la distribuzione automatica delle applicazioni in uno o più ambienti. La distribuzione continua in genere segue un processo di integrazione continua e usa i test di integrazione per convalidare l'intera applicazione.
Le pipeline possono contenere più fasi con varie attività e possono avere flussi di approvazione semplici o complessi per garantire la conformità e la convalida. In base alle preferenze, le pipeline possono anche essere configurate con vari trigger automatici. Per la distribuzione su scala aziendale e di intelligenza artificiale, i passaggi di produzione devono sempre avere una pre-approvazione umana, che è integrata nel modello operativo. Le pipeline CI/CD devono essere compilate con GitHub Actions o Azure Pipelines e devono essere trigger automatizzati.
Infrastructure as code
Il termine codice in IaC spesso genera preoccupazioni per il personale IT senza uno sfondo per sviluppatori, ma IaC non fa riferimento alla scrittura del codice nel modo in cui gli sviluppatori di software tipici lo fanno. Tuttavia, adotta molti degli stessi strumenti e principi dei processi di sviluppo software per fornire l'infrastruttura in un formato prevedibile.
IaC consente di eseguire il provisioning, la configurazione e la gestione dell'infrastruttura come parte di una pipeline di DevOps con controlli delle modifiche completi, cronologia di controllo, test, convalide e processi di approvazione, garantendo che le attività possano essere delegate ai ruoli appropriati per il progetto senza compromettere sicurezza e conformità.
I due approcci alla IaC sono dichiarativo e imperativo:
L’approccio dichiarativo si riferisce alla specifica dello stato desiderato dell'infrastruttura e all'esecuzione da parte di un motore di orchestrazione delle azioni necessarie per ottenere lo stato desiderato. In Azure queste operazioni vengono eseguite con i modelli Azure Resource Manager. Per questo approccio sono disponibili anche livelli di astrazione di terze parti come Terraform.
L'approccio imperativo si riferisce all'esecuzione di comandi specifici in un ordine definito. Per Azure, questa operazione può essere eseguita con l'interfaccia della riga di comando o PowerShell, ma se sono necessarie soluzioni integrate sono disponibili anche kit per lo sviluppo di software del linguaggio di programmazione nativo, ad esempio .NET, Python e Java.
Nei modelli Azure Resource Manager, il provisioning di base si trova nella sezione delle risorse e la configurazione delle singole risorse è definita in una sezioneproprietà. Per Azure Data Lake Storage Gen2, la configurazione è simile alla seguente:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources": [
{
"type": "Microsoft.MachineLearningServices/workspaces/datastores",
"name": "[concat(parameters('workspaceName'), '/', parameters('datastoreName'))]",
"apiVersion": "2020-05-01-preview",
"location": "[parameters('location')]",
"properties": {
"DataStoreType": "adls-gen2",
"SkipValidation": "[parameters('skipValidation')]",
"ClientId": "[parameters('clientId')]",
"ClientSecret": "[parameters('clientSecret')]",
"FileSystem": "[parameters('fileSystem')]",
"AccountName": "[parameters('accountName')]",
"TenantId": "[parameters('tenantId')]",
"ResourceUrl": "[parameters('resourceUrl')]",
"AuthorityUrl": "[parameters('authorityUrl')]"
}
}
]
}
Importante
Ogni livello di analisi su scala cloud, ad esempio zona di destinazione dei dati, zone di destinazione dei dati o applicazioni dati (che creano prodotti dati), deve essere definito con un linguaggio dichiarativo come Azure Resource Manager o Terraform, controllato in un repository e distribuito tramite pipeline CI/CD. Ciò consente ai team di tenere traccia e controllare la versione delle modifiche apportate all'infrastruttura e alla configurazione dell'ambito di Azure, supportando allo stesso tempo livelli di architettura diversi da automatizzare in modo agile. Queste linee guida indicano ai team di usare i repository Git per avere sempre visibilità sullo stato di ambiti di Azure specifici.
Flussi di lavoro e automazione
I team devono usare le pipeline CI/CD in più fasi per garantire che il codice sviluppato sia privo di errori e pronto per la produzione. Alcune procedure consigliate prevedono di avere un ambiente di sviluppo, un ambiente di test e un ambiente di produzione. Queste fasi devono essere riflesse anche in Azure usando servizi separati per ogni ambiente.
Il team della piattaforma è responsabile della fornitura e della gestione dei modelli di distribuzione per una rapida scalabilità all'interno di un'organizzazione e la semplificazione delle distribuzioni per i team che non hanno familiarità con IaC. Questi modelli fungono da baseline per i nuovi artefatti all'interno dello scenario e devono essere mantenuti nel tempo per rappresentare le procedure consigliate e gli standard comuni all'interno dell'azienda.
Le distribuzioni per il test e la produzione devono essere gestite solo tramite una pipeline CI/CD e una connessione ai servizi con autorizzazioni elevate per applicare le procedure consigliate comuni (ad esempio i modelli Azure Resource Manager).
Attenzione
I team dell'applicazione dati devono avere accesso in lettura solo agli ambienti di test e di produzione e le distribuzioni in questi ambienti devono essere eseguiti solo tramite pipeline CI/CD e connessioni al servizio con autorizzazioni elevate. Per accelerare il percorso di produzione, i team dell'applicazione dati devono avere accesso in scrittura all'ambiente di sviluppo.