Správa analýz škálování cloudu
DevOps dnes změnil kulturu toho, jak lidé myslí a pracují, a zrychlil rychlost, s jakou podniky realizují hodnotu tím, že pomáhá jednotlivcům a organizacím rozvíjet a udržovat udržitelné pracovní postupy. DevOps kombinuje vývoj a provoz a je často spojený s nástroji pro softwarové inženýrství, které podporují postupy kontinuální integrace (CI) a průběžného doručování (CD). Mezi tyto nástroje a postupy patří správci zdrojového kódu (například Git, Apache Subversion nebo Správa verzí Team Foundation) a správci automatického sestavení a doručování (například Azure Pipelines nebo GitHub Actions).
DevOps v kombinaci s pozorovatelností je klíčem k poskytování agilní a škálovatelné platformy. DevOps umožňuje týmům implementovat správu zdrojového kódu, kanály CI/CD, infrastrukturu jako kód, pracovní postupy a automatizaci. Pozorovatelnost umožňuje vlastníkům firmy, technikům DevOps, datovým architektům, datovým inženýrům a technikům spolehlivosti webů automaticky zjišťovat, predikovat, předcházet a řešit problémy a vyhnout se tak výpadkům, které by jinak narušovaly produkční analýzy a AI.
Správa zdrojového kódu
Správa zdrojového kódu zajišťuje, aby kód a konfigurace zůstaly zachovány a aby se změny sledovaly a kopírovaly verzemi. Většina systémů správy zdrojového kódu má také integrované procesy pro kontrolu a práci v různých větvích úložiště kódu. V současné době je nejpopulárnějším typem správy zdrojového kódu Git, což je distribuovaný systém správy verzí, který umožňuje jednotlivcům pracovat offline a synchronizovat se s centrálními úložišti. Dodavatelé Gitu obvykle také používají větve a řídí se pokyny k žádostem o přijetí změn, aby podpořili tok změn a kontroly.
Větve izolují změny nebo vývoj funkcí, aniž by ovlivnily další práci, která probíhá ve stejnou dobu. Používání větví by mělo být podporováno, aby bylo možné vyvíjet funkce, opravovat chyby a bezpečně experimentovat s novými nápady. Žádosti o přijetí změn sloučí změny provedené z jedné větve do výchozí větve a podporují řízený proces kontroly. Z bezpečnostních důvodů by hlavní větev měla používat žádosti o přijetí změn k zajištění kontrol kódu.
Důležité
Pro úložiště analýz v cloudovém měřítku postupujte podle těchto pokynů:
- Zabezpečte hlavní větev úložiště vynucováním větví a žádostí o přijetí změn, abyste zajistili řízené procesy kontroly.
- Úložiště Azure DevOps nebo GitHub by se měla používat ke správě zdrojového kódu, aby bylo možné sledovat změny zdrojového kódu a umožnit více členům týmu vyvíjet kód najednou.
- Konfigurace kódu aplikace a infrastruktury by se měly vrátit do úložiště.
Kanály CI/CD
CI umožňuje týmům automaticky testovat a sestavovat zdrojový kód a umožňuje rychlé iterace a smyčky zpětné vazby, které zajišťují vysokou kvalitu kódu na disku CD. Kanály jsou způsoby konfigurace CI změn (softwarového kódu nebo kódu infrastruktury) a cd zabalených/zkompilovaných změn. Označuje se také jako sestavení a vydání. Cd popisuje automatické nasazení aplikací do jednoho nebo více prostředí. CD se obvykle řídí procesem CI a používá integrační testy k ověření celé aplikace.
Kanály můžou obsahovat několik fází s různými úlohami a můžou mít jednoduché až složité toky schvalování, aby se zajistilo dodržování předpisů a ověření. V závislosti na předvolbách je možné kanály nakonfigurovat také s různými automatickými triggery. Pro nasazení na podnikové úrovni a AI by produkční kroky měly mít vždy předběžné schválení člověkem, což je součástí provozního modelu. Kanály CI/CD by se měly sestavit pomocí GitHub Actions nebo Azure Pipelines a měly by to být automatizované triggery.
Infrastruktura jako kód
Termín kód v IaC často vyvolává obavy pro pracovníky IT bez vývojářského zázemí, ale IaC neoznačuje psaní kódu způsobem, jakým to dělají běžní vývojáři softwaru. Z procesů vývoje softwaru však přijímá mnoho stejných nástrojů a principů, aby poskytovala infrastrukturu v předvídatelné podobě.
IaC pomáhá zřizovat, konfigurovat a spravovat infrastrukturu jako součást kanálu DevOps s úplnými řízeními změn, historií auditování, testy, ověřeními a schvalovacími procesy, což zajišťuje, aby úkoly bylo možné delegovat na příslušné role pro projekt, aniž by došlo k ohrožení zabezpečení a dodržování předpisů.
Dva přístupy k IaC jsou deklarativní a imperativní:
Deklarativní označuje určení požadovaného stavu infrastruktury a to, že modul orchestrace provede potřebné akce k dosažení požadovaného stavu. V Azure se to provádí pomocí šablon Azure Resource Manager. Pro tento přístup jsou k dispozici také vrstvy abstrakce třetích stran, jako je Terraform.
Imperativní přístup odkazuje na provádění konkrétních příkazů v definovaném pořadí. V Azure je toho možné dosáhnout pomocí rozhraní příkazového řádku nebo PowerShellu, ale v případě potřeby integrovaných řešení jsou k dispozici také sady pro vývojáře softwaru nativního programovacího jazyka, například .NET, Python a Java.
V šablonách Azure Resource Manager je základní zřizování v části resources (prostředky) a konfigurace jednotlivých prostředků je definovaná v oddílu vlastností. Pro Azure Data Lake Storage Gen2 vypadá konfigurace takto:
{
"$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')]"
}
}
]
}
Důležité
Každá vrstva analýzy škálování cloudu, jako je cílová zóna správy dat, cílové zóny dat nebo datové aplikace (které vytvářejí datové produkty), by měla být definována pomocí deklarativního jazyka, jako je Azure Resource Manager nebo Terraform, se změnami v úložišti a nasazená prostřednictvím kanálů CI/CD. To umožňuje týmům sledovat a měnit verze infrastruktury a konfigurace oboru Azure a zároveň podporovat agilní automatizaci různých úrovní architektury. Tyto pokyny vedou týmy k tomu, aby používaly úložiště Git, aby měly vždy přehled o stavu konkrétních oborů Azure.
Pracovní postupy a automatizace
Týmy by měly používat kanály CI/CD v několika fázích, aby zajistily, že vyvinutý kód bude bez chyb a připravený do produkčního prostředí. Mezi osvědčené postupy patří vývojové prostředí, testovací prostředí a produkční prostředí. Tyto fáze by se také měly v Azure odrážet použitím samostatných služeb pro každé prostředí.
Tým platformy zodpovídá za poskytování a údržbu šablon nasazení pro rychlé škálování v rámci organizace a za zjednodušení nasazení pro týmy, které nejsou obeznámeny s IaC. Tyto šablony slouží jako směrný plán pro nové artefakty v rámci tohoto scénáře a je potřeba je udržovat v průběhu času, aby představovaly osvědčené postupy a běžné standardy v rámci společnosti.
Nasazení pro testování a produkční prostředí by se měla spravovat pouze prostřednictvím kanálu CI/CD a připojení služby se zvýšenými oprávněními, aby se vynucovaly běžné osvědčené postupy (například šablony Azure Resource Manager).
Upozornění
Týmy datových aplikací by měly mít přístup jen pro čtení k testovacím a produkčním prostředím a nasazení do těchto prostředí by se měla spouštět pouze prostřednictvím kanálů CI/CD a připojení služeb se zvýšenými oprávněními. Aby se urychlila cesta do produkčního prostředí, týmy datových aplikací by měly mít přístup k zápisu do vývojového prostředí.