Së fundmi, u përballa me një kafshë që nuk është shumë e njohur në botën e DevOps, pipeline-t Azure DevOps. Menjëherë ndjeva mungesën e ndonjë udhëzimi ose artikulli të qartë mbi këtë temë, nuk e di se çfarë e shkakton këtë, por Microsoft duket se ka punë për të bërë në promovimin e këtij mjeti. Sot do të ndërtojmë një pipeline për testimin e automatizuar brenda Azure Cloud.

Pra, detyra:
Kemi një software që ndërtoshet me anë të Azure DevOps, dhe grumbullohet nga një projekt në WIX. Nëse ka interes, do të shkruaj edhe për këtë mjet. Në të vërtetë, është një mënyrë më e optimizuar për automatizimin e ndërtimit të instaluesve të Windows, duke zëvendësuar InstallShield-in standard. Pra, softi ynë ndërtrohet me sukses dhe gjeneron një artefakt, një setup.exe, që instalon aplikacionin në sistemin Windows. Është e nevojshme që të vendosim këtë aplikacion në një virtualizim të ngjashëm me prodhimin, të kopjojmë aty testet e automatizuara, të përgatitura nga ekipi i testimit, t'i ekzekutojmë dhe të marrim rezultatet, për të vlerësuar nëse dega është e mirë apo e keqe para se ta kryejmë bashkimin. E gjithë kjo si në GitLab, vetëm se përmes…

Si ambient virtualizimi, ku do të ekzekutojmë testet tona, do të përdorim, natyrisht, Azure DevTest Labs, një entitet në abonimet Azure, e cila është krijuar për të ekzekutuar çdo lloj testi me një çmim të arsyeshëm.

1. Integrimi në anën e cloud-it

Së pari, do të na nevojitet të integrojmë DevTest Labs tonë me Azure DevOps, për të cilin na nevojitet një Service Principal, në thelb një llogari shërbimi, e cila lejon pipeline-t të hyjnë në cloud dhe të krijojnë/fshijnë aty burime për vete.

Shkojmë në abonim dhe gjejmë shërbimin Azure Active Directory

Gjejmë App Registrations dhe klikojmë në New Registration, kjo do të krijojë service principal-in tonë. Nuk do ta shqyrtoj në detaje se cilat cilësime duhet të zgjidhni gjatë krijimit, kjo mund të ndryshojë në varësi të abonimeve të ndryshme.

Tani na nevojitet të japim të drejtat për drejtorin tonë të shërbimit. Për këtë, shkojmë në abonimet, ikona me çelësin. Zgjidhim abonimin tonë.

Pastaj në Access Control klikojmë Role Assignment dhe kërkojmë këtë llogari me emrin e sapokrijuar. Japim rolin Contributor, kjo është e mjaftueshme.

Pastaj kthehemi tek Service Principal ynë në Azure AD dhe hapim pronësitë e tij. Më vonë, do të na nevojiten të gjithë ID-të që ndodhen atje, i ruajmë ato.

Këtu përfundojnë përcaktimet tona të portalit dhe kalojmë në Azure DevOps.

2. Integrimi në anën e Azure DevOps

Si fillim, do të hyjmë në cilësimet e projektit dhe do të zgjedhim Shërbimet e Lidhen. Krijojmë një element të ri të tipit Azure Resource Manager.

Tani na duhen të gjitha ID-të që kemi shënuar. Klikojmë në përdorni versionin e plotë të dialogut të lidhjes së shërbimit. Dhe futim të gjitha të dhënat që kemi marrë nga Shërbimi Principal. Shtypim verifiko dhe nëse gjithçka është në rregull, ruajmë lidhjen. Tani pipeline-t tona mund ta përdorin atë për t'u lidhur me cloud.

3. Krijimi i pipeline-it

Tani fillojmë me gjënë më interesante, ndërtimin e pipeline-it përkatës. Hapim menunë Pipeline-Builds

Na pret menuja e krijimit të një build-i të ri, e cila automatikisht do të përpiqet të krijojë një skedë YAML me konfiguarionin e duhur. Ne e refuzojmë këtë me mirësjellje dhe zgjedhim variantin klasik. E kuptoj dëshirën e Microsoft për të bërë gjithçka siç duhet dhe të ofrojë mundësinë për ta personalizuar maksimalisht pipeline-in përmes YAML, por dokumentacioni i varfër dhe thjesht praktikisht mosfunksionimi i shumë moduleve na tregon se është ende herët për ta përdorur këtë funksionalitet.

Nga larmia e shablloneve, na nevojitet një Pipeline i thjeshtë Empty. Pas krijimit të tij, na pret një dritare e zbrazët e redaktimit, ku do të kalojmë një kohë të konsiderueshme.

Pra, klikojmë në + dhe kalojmë në një lloj dyqani modulash, nga ku na nevojiten për listë komponentët e mëposhtëm.

Para se të fillojmë konfigurimin e detyrave të pipeline-it, duhet të formulojmë dhe vendosim në projekt disa skedarë. Këto do të jenë ARM Template për makinën tonë virtuale, të cilin do ta gjenerojmë në Azure DevTest Labs, skripti për të nxjerrë IP-në e makinë pas krijimit të saj, dhe, sipas dëshirës, skripte për testet tona ose atë që duam të ekzekutojmë në host.

4. Gjenerimi i ARM Template

Për të krijuar një virtual machine, do të duhet së pari të gjenerojmë një template për të, një skedë JSON, që do ta vendosim në kodin e projektit, për t'u lexuar nga pipeline.

Shkoi në laboratorin tonë dhe gjejmë menunë Formulat (bazat e ripërdorshme), klikojmë për të krijuar një të re.

Do të na presë një listë e gjatë imazhesh si bazë, përzgjedhja e madhësisë së makinës, gjithçka është e njëjta si kur krijojmë një makinë virtuale. Në këtë fazë nuk do të ndalemi, menjëherë do të kalojmë te pika e fundit e pronave të makinës, konkretisht artefaktet. Mund të përdorni çdo konfigurim që është e nevojshme për mjedisin tuaj. Për shembull, unë po shtoj makinën në domain dhe po i shtoj atij një llogari shërbimi si administrator, që të mund të hyjë më vonë në këtë makinë me këtë llogari. Kjo gjithçka mund të ndryshojë, por për testimin e suksesshëm të kodit na nevojitet një artefakt, mbi të cilin do të ndalemi më tepër. Që të instalohet versioni më i fundit i softuerit që po testojmë në makinën tonë, ne do të përdorim artefaktin 'Shkarko Artefaktin Azure Pipelines dhe Ekzekuto Skriptin'. Mos harroni që në fillim thashë se diku po grumbullohet ndërtimi me instaluesin e aplikacionit? Tani na nevojitet të themi makinës virtuale, ose më saktë template-it, që të shkojë dhe ta merr këtë artefakt. Dhe jo vetëm ta marrë, por ta instaloje gjithashtu, për këtë do të plotësojmë fushat e veçanta me tregimin e projektit, emrin e ndërtimit dhe çelësin sekret. Çelësi sekret, siç është në të gjitha sistemet e ngjashme, gjenerohet në llogarinë, në këtë rast në Azure DevOps dhe ruhet në Secrets në laboratorin tuaj. Këtu ka një sqarim të vogël, ne do ta ruajmë atë në Secrets, por template-it nuk do i bëjë asnjë dëm, ai do të nisë nga një përdorues tjetër në kuadër të pipeline-it, prandaj duhet ta fusim edhe një herë manualisht çelësin sekret në template.

Një artefakt tjetër që duhet patjetër të përfshihet është 'Konfiguro WinRM', na nevojitet për qasje të mëvonshme në makinë. Atje ka vetëm një parametr, hostname. Pasi që ne nuk e dimë paraprakisht, do të përfitojmë nga variabla %COMPUTERNAME%.

Pra, kemi shtuar të gjithë artefaktet e nevojshme, kalojmë te arsyeja pse jemi këtu në fillim. Marrim Template-in ARM të gjeneruar në skedarin Advanced të të njëjtit dritare krijimi formule.

Kopjojmë përmbajtjen e faqes në skedarin VMtemplate.json dhe e vendosim atë në rrënjë të projektit. Më shumë nuk na nevojitet cloud, kthehuni në pipeline.

5. Konfigurimi i pipeline-it

Le të fillojmë me gjënë më të rëndësishme dhe interesante, krijimin e një virtual machine; për këtë ne bëmë të gjitha këto integrime dhe template. Në pikën Azure RM Subscription ne zgjedhim lidhjen tonë të shërbimit, të cilën e kemi konfiguruar në pikën 2. Më pas duhet të shfaqet ambienti laboratorik i disponueshëm për ne. Pastaj zgjedhim json-in që kemi gjeneruar dhe përcaktojmë disa variabla të domosdoshëm. Mund të vendosni login dhe fjalëkalimin për makinë ose drejtpërdrejt ose si variabla, por në të vërtetë nuk jam i sigurt që kjo funksionon, gjithçka që kam shkruar nuk më lejoi të hyja në makinë me këto kredenciale; e rëndësishme është të caktoni një emër për makinën, në mënyrë që të jetë gjithmonë unik. Për këtë unë përdor variablën e ambientit të ndërtimit.

Më pas, ne konfigurojmë edhe një moment të rëndësishëm. Pasi makina të ngrejë, ne na nevojitet një mënyrë për të ditur parametrat e saj, dhe më mirë se kaq, t'i përcjellim ata në pipeline. Për këtë, krijojmë një skenar, për shembull GetLabVMParams.ps1 dhe e vendosim atë gjithashtu në projekt. Tekstin e skenarit e kam marrë nga faqja e Microsoft, por pak e kam rregulluar për ambientin tim, pasi ai merrte PublicIP dhe FQDN të makinës. Asnjë nga dyja nuk është e pranishme, por kam PrivateIP, i cili nuk është aq e lehtë për t'u marrë, ndaj kam shtuar një pjesë të kodit.

Param( [string] $labVmId)

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

# Merr emrin e grupit të burimeve të laboratorit VM
$labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName

# Merr emrin e laboratorit VM
$labVmName = (Get-AzureRmResource -Id $labVmId).Name

# Merr adresën IP publike të laboratorit VM
# $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress

# Merr FQDN të laboratorit VM
# $labVMFqdn = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).DnsSettings.Fqdn

# Merr adresën IP private të laboratorit 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

# Cakto një variabël labVmRgName për të ruajtur emrin e grupit të burimeve të laboratori VM
Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName"

# Cakto një variabël labVMIpAddress për të ruajtur adresën IP të laboratorit VM
Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress"

# Cakto një variabël labVMFqdn për të ruajtur emrin e FQDN të laboratorit VM
Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn"

Write-Output $labVMIpAddress

Set-Item wsman:localhostclienttrustedhosts * -Force

Nga e gjithë informacioni që skenari lexon, na nevojitet vetëm variabla labVMIpAddress. Kjo është e nevojshme për mua, ndoshta ju nevojiten edhe disa gjëra të tjera, ndaj unë nuk fshiva asgjë dhe thjesht komentuam të papërshtatshmet.

Po ashtu, do të shpjegoj rreshtin e fundit të skenarit, ai i lejon makinës tonë të ndërtimit qasje në çdo host përmes WinRM.

Në këtë fazë, ne fillojmë skriptin tonë të mrekullueshëm. Ai do të kërkojë të njëjtin lidhje me cloud-in, një ndryshues hyrës me ID-në e makinës, e cila do të jetë e njohur nga hapi i mëparshëm. Si? Këtu duhet të përmendim një gjë të mrekullueshme, siç janë Variablat e Daljes. Çdo hap mund të ketë një listë variablash që kalohen më tej, hapave të tjerë të pipeline-it. Prandaj, për skriptin tonë të shkëlqyer, variabli do të jetë labVMIpAddress, mos e harroni ta tregoni këtë.

Më pas bëj disa gjëra mjaft të thjeshta, të cilat gjithashtu mund të ndryshojnë nga rasti në rast. Ekzekutoj një skript të largët me krijimin e një ndarje, në të cilën më pas do të ngarkoj skriptet e mia.

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

Nga emri i detyrave është e qartë se më pas kopjojmë një skript mostër në makinë dhe me një hap tjetër e ekzekutojmë atë. Si adresë të makinës së largët, do të na ndihmojë variabli ynë $(labVMIpAddress). Më pas përdorim detyrën "atëruaj artefaktin nga ndarja" dhe kopjojmë rezultatet e ekzekutimit të skriptit në mjedisin tonë të ndërtimit, pastaj me një detyrë standarde ruajmë këto skedarë në artefaktin e ndërtimit. Pasi makina nuk na nevojitet më, në përfundim, e eliminojmë atë. Sfidë kryesore, siç duket nga volumi i artikullit, është të integrohen me cloud-in dhe të krijohet kontakti me virtualen që keni krijuar, pastaj mund të argëtoheni sa të doni.

Ky është artikulli im i parë, prandaj mos gjykoni shumë ashpër, vlerësimet janë të mirëpritura.

Burimi: habr.com