Analyses op cloudschaal beheren
Vandaag de dag heeft DevOps de cultuur van denken en werken verschoven, waardoor bedrijven sneller waarde realiseren door individuen en organisaties te helpen bij het ontwikkelen en onderhouden van duurzame werkpraktijken. DevOps combineert ontwikkeling en bewerkingen en wordt vaak geassocieerd met software-engineeringhulpprogramma's die ondersteuning bieden voor continue integratie (CI) en continue levering (CD) procedures. Deze hulpprogramma's en procedures omvatten broncodebeheerders (zoals Git, Apache Subversion of Team Foundation-versiebeheer) en automatische build- en leveringsmanagers (zoals Azure Pipelines of GitHub Actions).
DevOps in combinatie met waarneembaarheid is essentieel voor een flexibel en schaalbaar platform. DevOps biedt teams de mogelijkheid om broncodebeheer, CI/CD-pijplijnen, infrastructuur als code, werkstromen en automatisering te implementeren. Terwijl waarneembaarheid bedrijfseigenaren, DevOps-engineers, gegevensarchitecten, gegevenstechnici en site reliability engineers in staat stelt om problemen op een geautomatiseerde manier te detecteren, te voorspellen, te voorkomen en op te lossen en uitvaltijd te voorkomen die anders productieanalyses en AI zou onderbreken.
Broncodebeheer
Broncodebeheer zorgt ervoor dat code en configuraties behouden blijven en dat wijzigingen worden bijgehouden en geversied. De meeste broncodebeheersystemen hebben ook ingebouwde processen voor beoordeling en werken in verschillende vertakkingen van een codeopslagplaats. Momenteel is git het populairste type broncodebeheer. Dit is een gedistribueerd versiebeheersysteem waarmee personen offline kunnen werken en kunnen synchroniseren met centrale opslagplaatsen. Git-leveranciers gebruiken doorgaans ook vertakkingen en volgen de richtlijnen voor pull-aanvragen om de wijzigings- en controlestroom te ondersteunen.
Vertakkingen isoleren wijzigingen of functieontwikkelingen zonder dat dit van invloed is op ander werk dat tegelijkertijd plaatsvindt. Het gebruik van vertakkingen moet worden bevorderd om functies te ontwikkelen, fouten op te lossen en veilig te experimenteren met nieuwe ideeën. Pull-aanvragen voegen de wijzigingen van één vertakking samen in de standaardbranch en ondersteunen een gecontroleerd beoordelingsproces. Voor beveiligingsdoeleinden moet de hoofdbranch pull-aanvragen gebruiken om codebeoordelingen te garanderen.
Belangrijk
Volg deze richtlijnen voor cloudopslagplaatsen voor analyse:
- Beveilig de hoofdbranch van de opslagplaats door vertakkingen en pull-aanvragen af te dwingen om een gecontroleerd beoordelingsproces te garanderen.
- Azure DevOps- of GitHub-opslagplaatsen moeten worden gebruikt voor broncodebeheer om wijzigingen in de broncode bij te houden en meerdere teamleden tegelijkertijd code te laten ontwikkelen.
- Configuraties van toepassingscode en infrastructuur moeten worden ingecheckt in een opslagplaats.
CI/CD-pijplijnen
Met CI kunnen teams automatisch broncode testen en bouwen en snelle iteraties en feedbacklussen inschakelen om een hoge codekwaliteit op cd te garanderen. Pijplijnen zijn manieren om het CI van wijzigingen (softwarecode of infrastructuurcode) en de CD van de verpakte/gecompileerde wijzigingen te configureren. Dit wordt ook wel build en release genoemd. CD beschrijft de automatische implementatie van toepassingen in een of meer omgevingen. CD volgt meestal een CI-proces en gebruikt integratietests om de hele toepassing te valideren.
Pijplijnen kunnen meerdere fasen met verschillende taken bevatten en kunnen eenvoudige tot complexe goedkeuringsstromen hebben om naleving en validatie te garanderen. Op basis van voorkeur kunnen pijplijnen ook worden geconfigureerd met verschillende automatische triggers. Voor implementatie op ondernemingsniveau en AI moeten de productiestappen altijd vooraf door mensen worden goedgekeurd. Dit is ingebouwd in het bewerkingsmodel. CI/CD-pijplijnen moeten worden gebouwd met GitHub Actions of Azure-pijplijnen en moeten geautomatiseerde triggers zijn.
Infrastructure als code
De term code in IaC roept vaak zorgen op voor IT-medewerkers zonder achtergrond voor ontwikkelaars, maar IaC verwijst niet naar het schrijven van code op de manier waarop typische softwareontwikkelaars dit doen. Er worden echter veel van dezelfde hulpprogramma's en principes van de softwareontwikkelingsprocessen gebruikt om infrastructuur in een voorspelbare indeling te leveren.
IaC helpt de infrastructuur te worden ingericht, geconfigureerd en beheerd als onderdeel van een DevOps-pijplijn met volledige wijzigingsbeheer, controlegeschiedenis, tests, validaties en goedkeuringsprocessen, zodat taken kunnen worden gedelegeerd aan de juiste rollen voor het project zonder dat dit ten koste gaat van de beveiliging en naleving.
De twee benaderingen van IaC zijn declaratief en noodzakelijk:
Declaratief verwijst naar het opgeven van de gewenste status van de infrastructuur en het laten uitvoeren van de benodigde acties door een orchestration-engine om de gewenste status te bereiken. In Azure wordt dit gedaan met Azure Resource Manager-sjablonen. Abstractielagen van derden, zoals Terraform, zijn ook beschikbaar voor deze benadering.
De imperatieve benadering verwijst naar het uitvoeren van specifieke opdrachten in een gedefinieerde volgorde. Voor Azure kan dit worden bereikt met de opdrachtregelinterface of PowerShell, maar er zijn ook ingebouwde programmeerprogramma's voor softwareontwikkelaars, zoals .NET, Python en Java, beschikbaar als er geïntegreerde oplossingen nodig zijn.
In Azure Resource Manager-sjablonen bevindt de kerninrichting zich in de sectie resources en wordt de configuratie van de afzonderlijke resources gedefinieerd in een sectie eigenschappen. Voor een Azure Data Lake Storage Gen2 ziet de configuratie er als volgt uit:
{
"$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')]"
}
}
]
}
Belangrijk
Elke laag van analyses op cloudschaal, zoals landingszone voor gegevensbeheer, gegevenslandingszones of gegevenstoepassingen (die gegevensproducten maken), moet worden gedefinieerd met een declaratieve taal, zoals Azure Resource Manager of Terraform, worden ingecheckt in een opslagplaats en worden geïmplementeerd via CI/CD-pijplijnen. Hierdoor kunnen teams wijzigingen in de infrastructuur en configuratie van Azure-bereik bijhouden en versieren, terwijl verschillende architectuurniveaus op een flexibele manier kunnen worden geautomatiseerd. Deze richtlijnen leiden ertoe dat teams Git-opslagplaatsen gebruiken om altijd inzicht te hebben in de status van specifieke Azure-bereiken.
Werkstromen en automatisering
Teams moeten CI/CD-pijplijnen in meerdere fasen gebruiken om ervoor te zorgen dat de ontwikkelde code foutenloos is en klaar is voor productie. Sommige best practices zijn het hebben van een ontwikkelomgeving, een testomgeving en een productieomgeving. Deze fasen moeten ook worden weerspiegeld in Azure door afzonderlijke services voor elke omgeving te gebruiken.
Het platformteam is verantwoordelijk voor het leveren en onderhouden van implementatiesjablonen om snel te schalen binnen een organisatie en implementaties te vereenvoudigen voor teams die niet bekend zijn met IaC. Deze sjablonen dienen als basislijn voor nieuwe artefacten binnen het scenario en moeten in de loop van de tijd worden onderhouden om best practices en algemene standaarden binnen het bedrijf weer te geven.
Implementaties voor testen en productie mogen alleen worden beheerd via een CI/CD-pijplijn en een serviceverbinding met verhoogde machtigingen om algemene best practices af te dwingen (bijvoorbeeld Azure Resource Manager-sjablonen).
Waarschuwing
Gegevenstoepassingsteams mogen alleen leestoegang hebben tot test- en productieomgevingen, en implementaties naar deze omgevingen mogen alleen worden uitgevoerd via CI/CD-pijplijnen en serviceverbindingen met verhoogde machtigingen. Om het pad naar productie te versnellen, moeten datatoepassingsteams schrijftoegang hebben tot de ontwikkelomgeving.