Nedávno jsem se setkal s poněkud neznámým zvířetem ve světě DevOps, a to s Azure DevOps pipeline. Okamžitě jsem pocítil absenci nějakých jasných pokynů či článků na toto téma. Nevím, čím to je, ale Microsoft má jistě na čem pracovat, pokud jde o popularizaci tohoto nástroje. Dnes postavíme pipeline pro automatizované testování uvnitř cloudu Azure.

Takže úkol:
Máme software, který se buildí pomocí Azure DevOps, a skládá se z projektu na WIX. Pokud bude zájem, napíšu i o tomto nástroji. Jedná se v podstatě o více optimalizovaný způsob, jak automatizovat výrobu instalačních programů pro Windows, který nahrazuje standardní InstallShield. Takže, náš software se úspěšně sestaví a vygeneruje artefakt, jakýsi setup.exe, který nainstaluje aplikaci do systému Windows. Je třeba nainstalovat tuto aplikaci na virtualizaci podobnou produkci, zkopírovat tam automatizované testy připravené testovacím týmem, spustit je a zhodnotit výsledky, abychom určili, zda je větev dobrá nebo špatná, než provedeme merge. Všechno jako v GitLab, jenom přes j…

Jako prostředí virtualizace, kde budeme vykonávat naše testy, použijeme samozřejmě Azure DevTest Labs, nějakou entitu v předplatných Azure, která je vytvořena právě pro provozování různých testovacích věcí za přijatelnou cenu.

1. Integrace na straně cloudu

Nejprve je třeba integrovat naše DevTest Labs s Azure DevOps, k čemuž potřebujeme určitý Service Principal, který je v podstatě servisním účtem, jenž umožňuje našim pipelineům přistupovat do cloudu a vytvářet/mazat tam zdroje pro sebe.

Přejdeme do předplatného a najdeme službu Azure Active Directory.

Najdeme registrace aplikací a klikneme na Novou registraci, tím vytvoříme našeho service principal. Nebudu podrobně rozebírat, jaká nastavení vybrat při vytváření, to se může lišit u různých předplatných.

Nyní musíme našemu servisnímu řediteli udělit práva. K tomu přejdeme do předplatného, symbol s klíčem. Vybereme naše předplatné.

Pak v Access Control klikneme na Role Assignment a hledáme podle právě vytvořeného názvu tento účet. Udělíme mu roli Contributor, to bude stačit.

Následně se vrátíme k našemu Service Principal v Azure AD a otevřeme jeho vlastnosti. Později budeme potřebovat všechny ID, které tam jsou, takže si je uložíme.

Tímto naším nastavením na portálu jsme skončili a přecházíme do Azure DevOps.

2. Integrace na straně Azure DevOps

Nejprve se přihlásíme do nastavení projektu a vybereme Service Connections. Vytvoříme nový prvek typu Azure Resource Manager.

Teď potřebujeme všechny ID, které jsme si poznamenali. Klikneme na použít plnou verzi dialogu pro připojení služby. A zadáme všechny údaje, které jsme získali od Service Principal. Klikneme na ověřit a pokud je vše v pořádku, uložíme připojení. Nyní mohou naše pipeline tento přístup používat pro připojení do cloudu.

3. Vytvoření pipeline

Teď přistoupíme k tomu nejzajímavějšímu, budování samotné pipeline. Otevřeme menu Pipelines-Builds.

Setkáváme se s menu pro vytvoření nového buildu, které se pokusí automaticky vytvořit YAML soubor s vhodnou konfigurací. Slušně odmítáme a vybíráme klasickou variantu. Je pochopitelné, že Microsoft chce vše udělat uživatelsky přívětivé a umožnit co nejvíce přizpůsobit pipeline pomocí YAML, ale skromná dokumentace a praktická nefunkčnost mnoha modulů nám říká, že je zatím brzy tuto funkčnost používat.

Z rozmanitosti šablon potřebujeme jednoduchou prázdnou pipeline. Po jejím vytvoření se setkáváme s prázdným editorem, ve kterém strávíme poměrně dost času.

Takže klikneme na + a dostaneme se do jakéhosi obchodu s moduly, odkud potřebujeme dle seznamu následující komponenty.

Než přistoupíme k konfiguraci úkolů pipeline, musíme vytvořit a uložit do projektu několik souborů. To bude ARM Template naší virtuální stroje, který vygenerujeme v Azure DevTest Labs, skript pro získání IP adresy stroje po jeho vytvoření a, pokud si přejete, skripty našich testů nebo toho, co chceme spouštět na hostiteli.

4. Generování ARM Template

Abychom vytvořili virtuální stroj, nejprve musíme vygenerovat pro něj šablonu, JSON soubor, který umístíme do kódu projektu, aby si ho pipeline mohla přečíst.

Jdeme do naší laboratoře a najdeme menu Formulas (znovu použitelné základy), klikneme na vytvořit nové.

Setkáme se s dlouhým seznamem imagí jako základ, výběrem velikosti stroje, to vše je stejné jako při vytváření virtuálního stroje. Na tomto kroku se nezastavíme, hned přejdeme k poslednímu bodu vlastností stroje, a to k artefaktům. Můžete použít jakékoli konfigurace, které jsou potřebné pro vaše prostředí. Například já přidávám stroj do doména A přidávám na něj servisní účet jako administrátora, aby mohl pipeline později vstoupit na tento stroj pod tímto účtem. To vše se může lišit, ale pro úspěšné testování kódu potřebujeme jeden artefakt, na kterém se podrobněji zastavíme. Aby se na náš stroj nainstalovala poslední verze testovaného softwaru, použijeme artefakt „Stáhnout artefakt Azure Pipelines a spustit skript“. Pamatujte, že jsem na začátku říkal, že se někde sestavuje build s instalátorem aplikace? Teď potřebujeme říct virtuálnímu stroji, přesněji šabloně, aby šla a vzala tento artefakt. A nejen ho vzala, ale ještě ho nainstalovala, k čemuž vyplníme speciální pole s uvedením projektu, názvu buildu a tajného klíče. Tajný klíč, jako ve všech systémech tohoto typu, se generuje v účtu, v tomto případě v Azure DevOps a ukládá se do Secrets ve vaší laboratoři. Je tu malá poznámka, v Secrets ho sice uložíme, ale šabloně to bude jedno, bude se spouštět už od jiného uživatele v rámci pipeline, takže tajný klíč budeme muset ještě jednou ručně vložit do šablony.

Další artefakt, který je nutné zahrnout, je „Nakonfigurovat WinRM“, který budeme potřebovat pro následný přístup k zařízení. Je tam pouze jeden parametr, hostname. Protože jej předem neznáme, použijeme proměnnou %COMPUTERNAME%.

Takže jsme přidali všechny potřebné artefakty, nyní přecházíme k tomu, proč jsme sem vlastně přišli. Vytáhneme vygenerovanou ARM šablonu na kartě Pokročilé ve stejném okně pro vytvoření vzorce.

Zkopírujeme obsah stránky do souboru VMtemplate.json a umístíme ho do kořene projektu. Další cloud již nepotřebujeme, vracíme se do pipeline.

5. Konfigurace pipeline

Začneme s tím nejdůležitějším a nejzajímavějším, vytvořením virtuálního stroje, kvůli tomu jsme prováděli všechny tyto integrace a šablony. V bodě Azure RM Subscription vybíráme naše Service connection, které jsme nakonfigurovali v bodě 2. Poté by se měla objevit dostupná laboratoř. Následně vybereme json, který jsme vygenerovali, a definujeme některé povinné proměnné. Přihlašovací jméno a heslo k zařízení lze zadat buď přímo, nebo jako proměnné, ale nejsem si úplně jistý, že to funguje, co bych tam nenapsal, nikdy se mi nepodařilo se do zařízení přihlásit s těmito údaji; hlavní je zadat název stroje, aby byl co nejunikátnější. K tomu používám proměnnou prostředí buildu.

Dále nastavujeme ještě jeden důležitý moment. Po vzletu stroje potřebujeme nějak vědět jeho parametry, a lépe, aby to věděl náš pipeline. K tomu vytvoříme skript, například GetLabVMParams.ps1, a uložíme ho tamtéž, do projektu. Text skriptu jsem převzal z webu Microsoft, ale trochu jsem ho upravil pro své prostředí, protože bral PublicIP a FQDN zařízení. Ani jedno z toho nemám, ale mám PrivateIP, který není snadné získat, proto jsem přidal další část.

Param( [string] $labVmId)

$labVmComputeId = (Get-AzureRmResource -Id $labVmId).Properties.ComputeId

# Získání názvu resource group laboratoře VM
$labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName

# Získání názvu laboratoře VM
$labVmName = (Get-AzureRmResource -Id $labVmId).Name

# Získání veřejné IP adresy laboratoře VM
# $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress

# Získání FQDN laboratoře VM
# $labVMFqdn = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).DnsSettings.Fqdn

# Získání soukromé IP adresy laboratoře VM
$VmNetworkdetails= (((Get-AzureRmVM -ResourceGroupName $labVmRgName -Name $labVmName).NetworkProfile).NetworkInterfaces).Id
$nicname = $VmNetworkdetails.substring($VmNetworkdetails.LastIndexOf("/" ) + 1)
$labVMnetwork = (Get-AzureRmNetworkInterface -Name $nicname -ResourceGroupName $labVmRgName)|Select-Object -ExpandProperty IPConfigurations 
$labVMIpAddress = $labVMnetwork.PrivateIpAddress

# Nastavení proměnné labVmRgName pro uložení názvu resource group laboratoře VM
Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName"

# Nastavení proměnné labVMIpAddress pro uložení IP adresy laboratoře VM
Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress"

# Nastavení proměnné labVMFqdn pro uložení názvu FQDN laboratoře VM
Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn"

Write-Output $labVMIpAddress

Set-Item wsman:localhostclienttrustedhosts * -Force

Z celého, co skript čte, potřebujeme pouze proměnnou labVMIpAddress. Tedy to potřebuji já, možná budete potřebovat ještě něco jiného, proto jsem nic neodstraňoval a pouze zakomentoval to nadbytečné.

Také vysvětlím poslední řádek skriptu, ten umožňuje naší buildovací mašině přístup k jakémukoli hostiteli přes WinRM.

Dalším krokem je spuštění našeho skvělého skriptu. Bude potřebovat stejné připojení k cloudu a vstupní proměnnou s ID stroje, které bude již známo z předchozího kroku. Jak? Je třeba zmínit úžasnou věc, nazvanou Output Variables. Každý krok může mít seznam proměnných, které se předávají dalším krokům pipeline. Pro náš super skript tedy bude takovou proměnnou labVMIpAddress, nezapomeňte ji uvést.

Dále dělám poměrně jednoduché věci, které se navíc mohou lišit od případu k případu. Spouštím vzdálený skript pro vytvoření sdílení, do kterého budu následně nahrávat své skripty.

New-Item "C:test" –type directory
New-SMBShare –Name "test" –Path "C:test"  –FullAccess everyone

Z názvu úloh je jasné, že dále kopírujeme nějaký sample script na stroj a dalším krokem jej spouštíme. Jako adresu vzdáleného stroje využijeme naši proměnnou $(labVMIpAddress). Dále použijeme úlohu „získat artefakt ze sdílení“ a kopírujeme výsledky provedení skriptu do našeho build prostředí, poté stejnou standardní úlohou tyto soubory ukládáme do artefaktu buildu. Jakmile stroj již není potřeba, na závěr jej ukončíme. Hlavní složitost, jak je vidět z objemu článku, spočívá v integraci s cloudem a navázání kontaktu s virtuálním strojem, který jste vytvořili, poté už se můžete bavit, jak dlouho chcete.

Tohle je můj první článek, tak prosím nehodnoťte příliš přísně, připomínky jsou vítány.

Zdroj: habr.com