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 * -ForceNga 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 everyoneNga 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
