Hantera analys i molnskala
Idag har DevOps ändrat kulturen i hur människor tänker och arbetar, vilket påskyndar den takt med vilken företag inser värde genom att hjälpa individer och organisationer att utveckla och upprätthålla hållbara arbetsmetoder. DevOps kombinerar utveckling och drift och är ofta associerat med programvaruutvecklingsverktyg som stöder kontinuerlig integrering (CI) och metoder för kontinuerlig leverans (CD). Dessa verktyg och metoder omfattar källkodshanterare (till exempel Git, Apache Subversion eller Team Foundation Version Control) och automatiska bygg- och leveranshanterare (till exempel Azure Pipelines eller GitHub Actions).
DevOps i kombination med observerbarhet är nyckeln till att tillhandahålla en flexibel och skalbar plattform. DevOps ger team möjlighet att implementera källkontroll, CI/CD-pipelines, infrastruktur som kod, arbetsflöden och automatisering. Med observerbarhet kan företagsägare, DevOps-tekniker, dataarkitekter, datatekniker och platstillförlitlighetstekniker identifiera, förutsäga, förebygga och lösa problem på ett automatiserat sätt och undvika att eliminera driftstopp som annars skulle bryta produktionsanalys och AI.
Källkontroll
Källkontroll säkerställer att kod och konfigurationer bevaras och att ändringar spåras och versionshanteras. De flesta källkontrollsystem har också inbyggda processer för granskning och arbete i olika grenar på en kodlagringsplats. För närvarande är den mest populära källkontrolltypen Git, som är ett system för distribuerad versionskontroll som gör att enskilda användare kan arbeta offline och synkronisera till centrala lagringsplatser. Git-leverantörer använder vanligtvis även grenar och följer vägledningen för pull-begäranden för att stödja ändrings- och granskningsflödet.
Grenar isolerar ändringar eller funktionsutvecklingar utan att påverka annat arbete som sker samtidigt. Användningen av grenar bör främjas för att utveckla funktioner, åtgärda buggar och på ett säkert sätt experimentera med nya idéer. Pull-begäranden sammanfogar de ändringar som gjorts från en gren till standardgrenen, och de stöder en kontrollerad granskningsprocess. Av säkerhetsskäl bör huvudgrenen använda pull-begäranden för att säkerställa kodgranskningar.
Viktigt
Följ dessa riktlinjer för analyslagringsplatser i molnskala:
- Skydda lagringsplatsens huvudgren genom att framtvinga grenar och pull-begäranden för att säkerställa en kontrollerad granskningsprocess.
- Azure DevOps- eller GitHub-lagringsplatser bör användas för källkontroll för att spåra ändringar i källkoden och tillåta flera teammedlemmar att utveckla kod samtidigt.
- Programkod och infrastrukturkonfigurationer bör checkas in på en lagringsplats.
CI/CD-pipelines
CI gör det möjligt för team att automatiskt testa och skapa källkod och möjliggör snabba iterationer och feedbackslingor för att säkerställa hög kodkvalitet i CD. Pipelines är sätt att konfigurera CI för ändringar (programvarukod eller infrastrukturkod) och CD för de paketerade/kompilerade ändringarna. Detta kallas även build och release. CD beskriver den automatiska distributionen av program till en eller flera miljöer. CD följer vanligtvis en CI-process och använder integreringstester för att verifiera hela programmet.
Pipelines kan innehålla flera steg med olika uppgifter och kan ha enkla till komplexa godkännandeflöden för att säkerställa efterlevnad och validering. Baserat på inställningar kan pipelines också konfigureras med olika automatiska utlösare. För distribution i företagsskala och AI bör produktionsstegen alltid ha mänskligt förhandsgodkännande och detta är inbyggt i driftsmodellen. CI/CD-pipelines bör skapas med GitHub Actions eller Azure Pipelines, och de bör vara automatiserade utlösare.
Infrastruktur som kod
Termen kod i IaC väcker ofta oro för IT-personal utan utvecklarbakgrund, men IaC refererar inte till att skriva kod på det sätt som vanliga programvaruutvecklare gör det på. Den använder dock många av samma verktyg och principer från programutvecklingsprocesserna för att leverera infrastruktur i ett förutsägbart format.
IaC hjälper infrastrukturen att etableras, konfigureras och hanteras som en del av en DevOps-pipeline med fullständiga ändringskontroller, granskningshistorik, tester, verifieringar och godkännandeprocesser, vilket säkerställer att uppgifter kan delegeras till lämpliga roller för projektet utan att äventyra säkerhet och efterlevnad.
De två metoderna för IaC är deklarativa och imperativa:
Deklarativ syftar på att ange det önskade tillståndet för infrastrukturen och låta en orkestreringsmotor utföra de åtgärder som krävs för att uppnå önskat tillstånd. I Azure görs detta med Azure Resource Manager mallar. Abstraktionslager från tredje part som Terraform är också tillgängliga för den här metoden.
Den imperativa metoden syftar på att köra specifika kommandon i en definierad ordning. För Azure kan detta uppnås med kommandoradsgränssnittet eller PowerShell, men utvecklarpaket för internt programmeringsspråk, till exempel .NET, Python och Java, är också tillgängliga om integrerade lösningar krävs.
I Azure Resource Manager mallar finns kärnetablering i avsnittet resurser och konfigurationen av de enskilda resurserna definieras i ett egenskapsavsnitt. För en Azure Data Lake Storage Gen2 ser konfigurationen ut så här:
{
"$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')]"
}
}
]
}
Viktigt
Varje lager av analys i molnskala, till exempel landningszon för datahantering, datalandningszoner eller dataprogram (som skapar dataprodukter), bör definieras med ett deklarativt språk som Azure Resource Manager eller Terraform, checkas in på en lagringsplats och distribueras via CI/CD-pipelines. På så sätt kan team spåra och versionsändringar i infrastrukturen och konfigurationen av Azure-omfånget samtidigt som olika arkitekturnivåer kan automatiseras på ett flexibelt sätt. Den här vägledningen gör att teamen använder Git-lagringsplatser för att alltid ha insyn i tillståndet för specifika Azure-omfång.
Arbetsflöden och automatisering
Teams bör använda CI/CD-pipelines i flera steg för att säkerställa att den utvecklade koden är utan fel och redo för produktion. Några metodtips är att ha en utvecklingsmiljö, en testmiljö och en produktionsmiljö. Dessa faser bör också återspeglas i Azure med hjälp av separata tjänster för varje miljö.
Plattformsteamet ansvarar för att tillhandahålla och underhålla distributionsmallar för snabb skalning inom en organisation och förenkla distributioner för team som inte är bekanta med IaC. Dessa mallar fungerar som baslinje för nya artefakter i scenariot och måste underhållas över tid för att representera bästa praxis och vanliga standarder inom företaget.
Distributioner för testning och produktion bör endast hanteras via en CI/CD-pipeline och en tjänstanslutning med förhöjd behörighet för att framtvinga vanliga metodtips (till exempel Azure Resource Manager-mallar).
Varning
Dataprogramteam bör endast ha läsåtkomst till test- och produktionsmiljöer, och distributioner till dessa miljöer bör endast köras via CI/CD-pipelines och tjänstanslutningar med förhöjd behörighet. För att påskynda sökvägen till produktion bör dataprogramteamen ha skrivåtkomst till utvecklingsmiljön.