Nemrég egy nem túl népszerű, de a DevOps világában egyre elterjedtebb dologgal találkoztam, az Azure DevOps pipeline-okkal. Azonnal éreztem, hogy hiányzik valami világos útmutató vagy cikk erről a témáról, nem tudom, ez mivel magyarázható, de a Microsoftnak nyilván van mit tennie az eszköz népszerűsítése érdekében. Ma egy pipeline-t fogunk építeni az Azure felhőn belüli automatizált teszteléshez.

Tehát a feladat:
Van egy szoftverünk, amit Azure DevOps segítségével építünk, a WIX projektből készítjük el. Ha érdekel, majd írok erről az eszközről is. Valójában ez egy optimalizáltabb módszer a Windows telepítők automatizálására, amely felváltja a hagyományos InstallShield-et. Szóval a szoftverünk sikeresen épül és generál egy artefaktumot, egy setup.exe fájlt, amely telepíti az alkalmazást a Windows rendszerbe. Ezt az alkalmazást fel kell telepíteni egy produkcióhoz hasonló virtuális gépre, oda kell másolni az automatizált teszteket, amelyeket a tesztelési csapat készített, futtatni kell őket, és be kell gyűjteni az eredményeket, hogy eldönthessük, a branch jó vagy rossz, mielőtt összevonjuk. Minden, mint a GitLab-ban, csak másképp.

Virtuális környezetként, ahol a teszteket végrehajtjuk, nyilvánvalóan az Azure DevTest Labs-t fogjuk használni, egy entitás az Azure előfizetésekben, amelyet kifejezetten tesztelési környezetek futtatására hoztak létre, kedvező áron.

1. Integráció a felhőoldalon

Először integrálnunk kell a DevTest Labs-t az Azure DevOps-szal, ehhez szükségünk van egy Service Principal-ra, lényegében egy szolgáltatási fiókra, amely lehetővé teszi a pipeline-ok számára, hogy interakcióba lépjenek a felhővel és forrásokat hozzanak létre/töröljenek.

Navigáljunk az előfizetésekhez és keressük meg az Azure Active Directory szolgáltatást.

Keressük meg az App Regisztációkat, és kattintsunk az Új Regisztrációra, ez létrehozza a service principal-unkat. Részletezni nem fogom a létrehozásnál választott beállításokat, ezek különböző előfizetéseknél eltérhetnek.

Most meg kell adnunk a jogokat a szolgáltatási fiókunknak. Ehhez az előfizetésekhez navigálunk, a kulcsikonra kattintva. Válasszuk ki az előfizetésünket.

Ezután az Hozzáférés-vezérlés menüben kattintsunk a Szerepkiosztásra, és keressük meg a nemrégiben létrehozott fiókot nevén. Adjunk neki Hozzáadó szerepkört, ez elegendő lesz.

Ezután visszatérünk a Azure AD-ban található Service Principal-hoz, és megnyitjuk a tulajdonságait. Később szükségünk lesz az ott található összes ID-re, ezeket mentsük el.

Ezzel befejeződtek a portál beállításai, és áttérünk az Azure DevOps-ra.

2. Azure DevOps oldal integráció

Először is, belépünk a projekt beállításaiba, és kiválasztjuk a Szolgáltatáskapcsolatok lehetőséget. Új Azure Resource Manager típusú elemet hozunk létre.

Most szükségünk lesz az összes ID-re, amit felírtunk. Kattintunk a szolgáltatáskapcsolat párbeszédpanel teljes verziójának használatára. Beírjuk az összes adatot, amit a Szolgáltatáselvitelből kaptunk. Megnyomjuk a verify-t, és ha minden rendben van, elmentjük a kapcsolatot. Most a pipeline-jaink használhatják ezt a kapcsolatot az felhőhöz való csatlakozáshoz.

3. Pipeline létrehozása

Most nekiállunk a legérdekesebb résznek, a pipeline pontos felépítésének. Megnyitjuk a Pipelines-Builds menüt

Üdvözöl minket az új build létrehozásának menüje, ami alapértelmezetten egy YAML fájlt próbál létrehozni nekünk megfelelő konfigurációval. Udvariasan elutasítjuk ezt, és a klasszikus változatot választjuk. Megértjük a Microsoft vágyát, hogy mindent emberivé tegyen, és maximális személyre szabást biztosítson a YAML-on keresztül, de a szegényes dokumentáció és sok modul gyakorlatilag működésképtelensége azt mondja, hogy még túl korai ennek a funkciónak a használata.

A sokféle sablon közül egy egyszerű Üres Pipeline-ra lesz szükségünk. A létrehozása után egy üres szerkesztőablak vár minket, amiben később elég sok időt fogunk eltölteni.

Tehát, rákattintunk a + gombra, és egyfajta modulboltba kerülünk, ahonnan a következő összetevőket szükségünk lesz a listában.

Mielőtt nekilátnánk a pipeline feladatainak konfigurálásához, először néhány fájlt kell létrehoznunk és betennünk a projektbe. Ezek lesznek az ARM Template a virtuális gépünkhöz, amit az Azure DevTest Labs-ban generálunk, a gép IP-jének kinyerésére szolgáló szkript, miután létrejött, és opcionálisan a tesztjeink vagy annak a szkriptek, amit a hoszton szeretnénk futtatni.

4. ARM Template generálás

Ahhoz, hogy létrehozzunk egy virtuális gépet, először is szükségünk lesz egy sablon generálására, egy JSON fájlra, amit berakunk a projekt kódjába, hogy a pipeline azt onnét el tudja olvasni.

Elmegyünk a laborunkba, és megtaláljuk a Formulas (újrahasználható alapok) menüt, rákattintunk az új létrehozására.

Üdvözöl minket egy hosszú lista az alapként szolgáló imádziókról, a gép méretének kiválasztása, minden ugyanaz, mint virtuális gép létrehozásakor. Ezen a ponton nem állunk meg, egyből áttérünk a gép jellemzőinek utolsó pontjára, nevezetesen az artefaktumokra. Bármilyen konfigurációt használhat, amely szükséges a környezetéhez. Például, gépet adok hozzá a domain És hozzáadom a szolgáltatási fiókot adminisztrátorként, hogy a pipeline később be tudjon lépni erre a gépre ezzel a fiókkal. Ez mind változhat, de a kód sikeres teszteléséhez szükségünk van egy olyan artefaktra, amelyen részletesebben megérkezünk. Azért, hogy a legfrissebb verzióját a tesztelt szoftvernek telepíthessük a gépünkre, az "Download Azure Pipelines Artifact and Run Script" artefaktumot fogjuk használni. Emlékeztek, az elején mondtam, hogy valahol a telepítő buildje összegyűlik? Most azt kell mondanunk a virtuális gépnek, pontosabban a sablonnak, hogy menjen és hozza el ezt az artefaktumot. És nem csupán elhozza, hanem telepíti is, ezért speciális mezőket töltünk ki a projektnév, a build neve és a titkos kulcs megadásával. A titkos kulcs, mint minden hasonló rendszerben, a fiókban generálódik, jelen esetben az Azure DevOps-ban és a Secrets-ben tároljuk az Ön laborjában. Itt van egy apró megjegyzés, a Secrets-be el fogjuk menteni, de a sablon számára ez semmit nem jelent, mert már más felhasználóként fog működni a pipeline keretein belül, ezért a titkos kulcsot manuálisan kell újra bevinni a sablonba.

Egy másik artefakt, amelyet kötelezően be kell vonni, az a „Configure WinRM”, szükségünk lesz rá a géphez való későbbi hozzáféréshez. Csak egy paraméter van, a hostname. Mivel ezt előre nem ismerjük, a %COMPUTERNAME% változót fogjuk használni.

Tehát hozzáadtuk az összes szükséges artefaktot, most térjünk át arra, amiért idejöttünk. Elővesszük az ARM Template-t, amelyet az Advanced fül alatt találunk, ugyanabban az ablakban, ahol a formulát létrehozzuk.

Másoljuk az oldal tartalmát a VMtemplate.json fájlba, és helyezzük el a projekt gyökerében. További felhőre nincs szükségünk, visszatérünk a pipeline-hoz.

5. A pipeline konfigurálása

Kezdjük a legfontosabb és legérdekesebb dologgal, a virtuális gép létrehozásával. E miatt készítettük el az összes integrációt és sablont. Az Azure RM Subscription részben kiválasztjuk a Service connection-t, amelyet a 2. pontban konfiguráltunk. Ezután meg kell jelennie a rendelkezésünkre álló laboratóriumi környezetnek. Majd kiválasztjuk a generált json-t, és meghatározunk néhány kötelező változót. A géphez való bejelentkezési név és jelszó megadható közvetlenül vagy változókként, de nem vagyok biztos benne, hogy ez működik, mert amit csak írtam, azzal nem tudtam bejutni a gépre. A legfontosabb, hogy a gép neve mindig lehetőleg egyedi legyen. Ehhez a build környezeti változót használom.

Ezután beállítunk még egy lényeges dolgot. Miután a gép elindul, tudnunk kell az adatait, de a legjobb, ha nem nekünk, hanem a pipeline-nak. Ehhez készítünk egy scriptet, például GetLabVMParams.ps1, és elhelyezzük a projektben. A script szövegét a Microsoft webhelyéről vettem, de kicsit módosítottam a saját környezetemhez, mert az a PublicIP-t és a gép FQDN-ját vette. Ebből egyik sincs nálam, de van PrivateIP, amit nem olyan könnyű megszerezni, így írtam egy kiegészítést.

Param( [string] $labVmId)

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

# Szerezzük meg a laboratóriumi VM erőforráscsoport nevét
$labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName

# Szerezzük meg a laboratóriumi VM nevét
$labVmName = (Get-AzureRmResource -Id $labVmId).Name

# Szerezzük meg a laboratóriumi VM nyilvános IP címét
# $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress

# Szerezzük meg a laboratóriumi VM FQDN-ját
# $labVMFqdn = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).DnsSettings.Fqdn

# Szerezzük meg a laboratóriumi VM privát IP címét
$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

# Beállítunk egy változót labVmRgName, hogy tároljuk a laboratóriumi VM erőforráscsoport nevét
Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName"

# Beállítunk egy változót labVMIpAddress, hogy tároljuk a laboratóriumi VM IP címét
Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress"

# Beállítunk egy változót labVMFqdn, hogy tároljuk a laboratóriumi VM FQDN nevét
Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn"

Write-Output $labVMIpAddress

Set-Item wsman:localhostclienttrustedhosts * -Force

A scriptből csak a labVMIpAddress változóra van szükségünk. Talán nektek másra is szükségetek lesz, így nem töröltem semmit, csak kommenteltem ki a felesleges részeket.

A script utolsó sorát is megmagyarázom, ez lehetővé teszi a build gépünk számára, hogy hozzáférjen bármilyen hosthoz WinRM-en keresztül.

A következő lépésben elindítjuk csodás skriptünket. Ehhez szükség lesz ugyanarra a felhőkapcsolatra, valamint a gép ID-jára, amelyről már tudomást szereztünk az előző lépésben. Hogyan? Itt említenünk kell egy nagyszerű dolgot, az Output Változókat. Minden lépésnek lehet egy listája a változókról, amelyeket továbbítanak a pipeline következő lépéseihez. Tehát a mi szuper skriptünkhöz a labVMIpAddress változó lesz a szükséges, ne felejtsd el megadni.

Ezután egyszerű dolgokat fogok csinálni, amelyek esettől függően változhatnak. Távoli skriptet hajtok végre, amely létrehozza a megosztást, ahová később fel fogom tölteni a saját skriptjeimet.

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

A feladatok nevéből világosan látszik, hogy most másolunk egy mintaskriptet a gépre, majd egy új lépésben végrehajtjuk. A távoli gép címeként a $(labVMIpAddress) változónkra van szükség. Ezután a „készítsd el az artefaktumot a megosztásból” feladatot használjuk, és a skript végrehajtásának eredményeit lemásoljuk a build környezetünkhöz, majd egy standard feladattal elmentjük ezeket a fájlokat a build artefaktumába. Miután a gépre már nincs szükségünk, az utolsó lépésben leállítjuk. A fő nehézség, ahogyan a cikk terjedelméből is látszik, hogy integrálódjunk a felhőbe, és kapcsolatba lépjünk a virtuális géppel, amit létrehoztál, onnantól kezdve már szórakozhatsz, amennyit csak akarsz.

Ez az első cikkem, ne ítéljetek el, várom a megjegyzéseket.

Forrás: habr.com