Kohët e fundit hasa një “bishë” relativisht jopopullore në botën e DevOps: tubacionet e Azure DevOps. Vura re menjëherë mungesën e udhëzimeve ose artikujve të qartë mbi këtë temë. Nuk jam i sigurt pse, por Microsoft ka qartësisht punë për të bërë për ta popullarizuar mjetin. Sot, do të ndërtojmë një tubacion për testime të automatizuara brenda “cloud”-it Azure.

Pra, detyra është:
Ekziston një softuer që është ndërtuar duke përdorur të njëjtin Azure DevOps, të kompiluar nga një projekt WIX. Nëse ka interes, do të shkruaj edhe për këtë mjet. Në thelb, është një mënyrë më e automatizuar për të ndërtuar instalues ​​të Windows, duke zëvendësuar InstallShield standard. Pra, softueri ynë ndërtohet me sukses dhe gjeneron një objekt, një setup.exe, i cili instalon aplikacionin në sistem. WindowsDuhet ta instaloni këtë aplikacion në një makinë virtuale të ngjashme me prodhimin, të kopjoni testet automatike të përgatitura nga ekipi i testimit atje, t'i ekzekutoni ato dhe të mbledhni rezultatet për të përcaktuar nëse dega është e mirë apo e keqe para bashkimit. Është njësoj si në GitLab, vetëm përmes ass.

Si një mjedis virtualizimi ku do të kryejmë testet tona, padyshim që do të përdorim Azure DevTest Labs, një entitet të caktuar në abonimet Azure, i cili u krijua posaçërisht për të kryer të gjitha llojet e testimeve të pakuptimta në të për një çmim të arsyeshëm.

1. Integrimi në anën e reve

Për të filluar, duhet të integrojmë Laboratorët tanë DevTest me Azure DevOps, për të cilët na duhet një Shërbim Principal, në thelb një llogari shërbimi që lejon që tubacionet të shkojnë në cloud dhe të krijojnë/fshijnë burime atje për veten e tyre.

Shko te abonimi yt dhe gjej shërbimin Azure Active Directory.

Gjeni Regjistrimet e Aplikacioneve dhe klikoni Regjistrim i Ri. Kjo do të krijojë parimin kryesor të shërbimit tonë. Nuk do të hyj në detaje rreth cilësimeve që duhet të zgjidhni kur e krijoni, pasi ato mund të ndryshojnë në varësi të abonimit tuaj.

Tani duhet t'i japim leje drejtorit të shërbimit tonë. Për ta bërë këtë, shkoni te Abonimet, pastaj te ikona e çelësit. Zgjidhni abonimin tonë.

Më pas, te Kontrolli i Qasjes, klikoni Caktimi i Rolit dhe kërkoni për këtë llogari duke përdorur emrin që sapo krijuat. Caktoni rolin e Kontribuesit; kjo është e gjitha që ju nevojitet.

Pastaj, kthehuni te Shërbimi Principal në Azure AD dhe hapni vetitë e tij. Më vonë, do të na duhen të gjitha ID-të atje, prandaj ruajini ato.

Kjo plotëson cilësimet e portalit tonë dhe ne kalojmë te Azure DevOps.

2. Integrimi në anën e Azure DevOps

Së pari, do të shkojmë te cilësimet e projektit dhe do të zgjedhim Shërbimin e Lidhjeve. Krijojmë një artikull të ri të tipit Azure Resource Manager.

Tani do të na duhen të gjitha ID-të që kemi regjistruar. Klikoni "Përdor versionin e plotë të dialogut të lidhjes së shërbimit". Futni të gjitha të dhënat që kemi marrë nga Drejtori i Shërbimit. Klikoni "Verify" dhe nëse gjithçka është në rregull, ruani lidhjen. Tani tubacionet tona mund ta përdorin atë për t'u lidhur me cloud-in.

3. Krijimi i një tubacioni

Tani le të kalojmë te pjesa argëtuese: ndërtimi i vetë tubacionit. Hapni menynë Tubacione-Ndërtime.

Na pret një menu e re ndërtimi, e cila si parazgjedhje përpiqet të krijojë një skedar YAML me konfigurimin e duhur. Ne refuzojmë me mirësjellje dhe zgjedhim opsionin klasik. Dëshira e Microsoft-it për të qenë sa më miqësor ndaj përdoruesit dhe për të lejuar personalizimin maksimal të tubacionit përmes YAML është e kuptueshme, por dokumentacioni i pakët dhe mungesa e funksionimit të shumë moduleve sugjerojnë se është shumë herët për të përdorur këtë funksionalitet.

Nga shumëllojshmëria e shablloneve në dispozicion, do të na duhet një tubacion i thjeshtë bosh. Pasi ta krijojmë, do të na presë një dritare redaktimi bosh, ku do të kalojmë një sasi të konsiderueshme kohe.

Pra, klikojmë te + dhe arrijmë në një dyqan të caktuar modulesh, nga ku do të na duhen komponentët e mëposhtëm në listë.

Para se të fillojmë konfigurimin e detyrave të tubacionit, duhet të krijojmë dhe shtojmë disa skedarë në projekt. Këto do të përfshijnë Shabllonin ARM të makinës sonë virtuale, të cilin do ta gjenerojmë në Azure DevTest Labs, një skript për marrjen e adresës IP të makinës pasi të jetë krijuar dhe, opsionalisht, skripte për testet tona ose çdo gjë tjetër që duam të ekzekutojmë në host.

4. Gjenerimi i shabllonit ARM

Për të krijuar një makinë virtuale, së pari do të duhet të gjenerojmë një shabllon për të, një skedar json, të cilin do ta vendosim në kodin e projektit në mënyrë që tubacioni të mund ta lexojë atë që andej.

Shkojmë në laboratorin tonë dhe gjejmë menunë Formulat (bazat e ripërdorshme), klikojmë Krijo të re.

Do të na presë një listë e gjatë imazhesh si bazë, një zgjedhje e madhësisë së makinës dhe i njëjti proces si kur krijohet një makinë virtuale. Nuk do të ndalemi në këtë hap; do të kalojmë direkt te elementi i fundit në vetitë e makinës, domethënë, artefaktet. Mund të përdorni çdo konfigurim të kërkuar për mjedisin tuaj. Për shembull, po shtoj një makinë në domeni Unë shtoj një llogari shërbimi si administrator në mënyrë që tubacioni të mund të hyjë në këtë makinë nën këtë llogari. E gjitha kjo mund të ndryshojë, por për të testuar me sukses kodin, na duhet një objekt, të cilin do ta diskutojmë më në detaje. Për t'u siguruar që versioni më i fundit i softuerit që po testojmë është instaluar në makinën tonë, do të përdorim objektin "Shkarko Artifaktin e Azure Pipelines dhe Ekzekuto Skriptin". A e mbani mend në fillim kur përmenda se një ndërtim me instaluesin e aplikacionit është kompiluar diku? Tani duhet t'i themi makinës virtuale, ose më saktë, shabllonit, të shkojë dhe ta marrë këtë objekt. Dhe jo vetëm ta marrë, por edhe ta instalojë, për të cilin plotësojmë fusha të veçanta që specifikojnë projektin, emrin e ndërtimit dhe çelësin sekret. Çelësi sekret, si në të gjitha sistemet e ngjashme, gjenerohet në llogari - në këtë rast, në Azure DevOps - dhe ruhet në Secrets në laboratorin tuaj. Ka një paralajmërim të vogël këtu: do ta ruajmë në Secrets, por shablloni nuk do të interesohet. Do të lançohet nga një përdorues tjetër brenda tubacionit, kështu që do të na duhet ta fusim manualisht përsëri çelësin sekret në shabllon.

Një tjetër objekt që duhet të aktivizohet është "Configure WinRM"; do të na duhet për qasje të mëvonshme në makinë. Ai ka vetëm një parametër: hostname. Meqenëse nuk e dimë paraprakisht, do të përdorim variablin %COMPUTERNAME%.

Pra, kemi shtuar të gjitha objektet e nevojshme, le të kalojmë te pika kryesore e këtij postimi. Hapni shabllonin ARM të gjeneruar në skedën "Të avancuara" të së njëjtës dritare të krijimit të formulës.

Kopjoni përmbajtjen e faqes në skedarin VMtemplate.json dhe vendoseni atë në rrënjën e projektit. Nuk kemi më nevojë për cloud-in, kështu që le të kthehemi te tubacioni.

5. Konfigurimi i tubacionit

Le të fillojmë me pjesën më të rëndësishme dhe interesante: krijimin e një makine virtuale. Kjo është arsyeja pse krijuam të gjitha këto integrime dhe shabllone. Në seksionin Abonimi Azure RM, zgjedhim lidhjen tonë të Shërbimit, të cilën e konfiguruam në hapin 2. Më pas duhet të shfaqet mjedisi i disponueshëm i laboratorit. Pastaj, zgjedhim skedarin JSON që gjeneruam dhe përcaktojmë disa variabla të kërkuara. Hyrja dhe fjalëkalimi i makinës mund të vendosen ose direkt ose duke përdorur variabla, por nuk jam aspak i sigurt nëse kjo funksionon. Pavarësisht se çfarë shkrova, nuk munda të hyja në makinë duke përdorur këto kredenciale. Gjëja kryesore është të caktoni emrin e makinës në mënyrë që, nëse është e mundur, të jetë gjithmonë unik. Për këtë, unë përdor një variabël mjedisi ndërtimi.

Më pas, konfigurojmë një detaj tjetër të rëndësishëm. Pasi makina të niset, duhet të dimë disi parametrat e saj - ose akoma më mirë, tubacioni duhet t'i dijë ato. Për ta bërë këtë, krijojmë një skript, për shembull, GetLabVMParams.ps1, dhe e shtojmë në projekt. E mora tekstin e skriptit nga faqja e internetit e Microsoft, por e modifikova pak për mjedisin tim, pasi ai mori PublicIP dhe FQDN të makinës. Unë nuk kam asnjërën, por kam një PrivateIP, të cilën nuk është e lehtë ta marrësh, kështu që shtova pak më shumë.

Param( [string] $labVmId)

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

# Get lab VM resource group name
$labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName

# Get the lab VM Name
$labVmName = (Get-AzureRmResource -Id $labVmId).Name

# Get lab VM public IP address
# $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress

# Get lab VM FQDN
# $labVMFqdn = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).DnsSettings.Fqdn

# Get lab VM private IP address
$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

# Set a variable labVmRgName to store the lab VM resource group name
Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName"

# Set a variable labVMIpAddress to store the lab VM Ip address
Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress"

# Set a variable labVMFqdn to store the lab VM FQDN name
Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn"

Write-Output $labVMIpAddress

Set-Item wsman:localhostclienttrustedhosts * -Force

Nga të gjitha gjërat që lexon skripti, na duhet vetëm variabla labVMIpAddress. Epo, kjo është vetëm për mua; ndoshta do t'ju duhet diçka tjetër, kështu që nuk fshiva asgjë dhe thjesht komentova pjesët e panevojshme.

Do të shpjegoj gjithashtu rreshtin e fundit të skriptit; ai i lejon makinës sonë të ndërtimit qasje në çdo host nëpërmjet WinRM.

Hapi tjetër është të nisim skriptin tonë të mrekullueshëm. Do të kërkojë të njëjtën lidhje në cloud dhe një variabël hyrëse me ID-në e makinës, e cila do të njihet tashmë nga hapi i mëparshëm. Si? Ja ku duhet të përmendim diçka të mrekullueshme: Variablat e Daljes. Çdo hap mund të ketë një listë variablash që kalohen në hapat pasues në proces. Për super skriptin tonë, kjo variabël do të jetë labVMIpAddress; mos harroni ta specifikoni atë.

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

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

Siç sugjerojnë emrat e detyrave, ne kopjojmë një skript shembull në makinë dhe e ekzekutojmë atë në një hap tjetër. Do të përdorim variablin tonë $(labVMIpAddress) si adresën e makinës në distancë. Më pas, përdorim detyrën "merr artifaktin nga ndarja" dhe kopjojmë rezultatet e skriptit në mjedisin tonë të ndërtimit. Pastaj, duke përdorur të njëjtën detyrë standarde, i ruajmë këto skedarë në artifaktin e ndërtimit. Pasi të mos na duhet më makina, hapi i fundit është ta çaktivizojmë atë. Vështirësia kryesore, siç mund ta shihni nga gjatësia e këtij artikulli, është integrimi me cloud-in dhe vendosja e kontaktit me makinën virtuale që keni krijuar. Pas kësaj, mund të argëtoheni sa të dëshironi.

Ky është artikulli im i parë, ndaj mos më gjykoni shumë ashpër, komentet janë të mirëseardhura.

Burimi: www.habr.com