Recentemente, am întâlnit o fiară care nu este încă foarte populară în lumea DevOps, și anume, pipe-urile Azure DevOps. Am resimțit imediat lipsa unor instrucțiuni clare sau articole pe acest subiect, nu știu din ce motiv, dar Microsoft clar că are de lucru în privința popularizării instrumentului. Astăzi, vom construi un pipeline pentru testarea automatizată în cadrul cloud-ului Azure.

Deci, sarcina:
Există un software care este construit folosind același Azure DevOps, generat dintr-un proiect pe WIX. Dacă va fi interes, voi scrie și despre acest instrument. De fapt, este o modalitate mai optimizată de a automatiza construcția instalatorilor pentru Windows, înlocuind standardul InstallShield. Deci, software-ul nostru se construiește cu succes și generează un artefact, un setup.exe, care instalează aplicația în sistemul Windows. Este necesar să instalăm această aplicație pe o mașină virtuală asemănătoare cu cea de producție, să copiem acolo teste automate, pregătite de echipa de testare, să le lansăm și să obținem rezultatele, pentru a determina dacă ramura este bună sau proastă, înainte de a face un merge. Totul ca în GitLab, numai că printr-o altă metodă.

Ca mediu de virtualizare, unde vom executa testele noastre, folosim, evident, Azure DevTest Labs, un fel de entitate în abonamentele Azure, creată exact pentru a rula tot felul de experimente de testare la un preț acceptabil.

1. Integrarea pe partea de cloud

Pentru început, va trebui să integrăm DevTest Labs cu Azure DevOps, pentru care avem nevoie de un Service Principal, practic un cont de serviciu care permite pipeline-urilor să acceseze cloud-ul și să creeze/ștergă resurse acolo pentru noi.

Mergem în abonament și găsim serviciul Azure Active Directory.

Găsim Aplicații Înregistrate și dăm clic pe New Registration, care ne va crea service principal-ul nostru. Nu voi detalia ce setări să alegem la crearea acestuia, deoarece acestea pot varia între diferite abonamente.

Acum trebuie să acordăm permisiuni directorului nostru de serviciu. Pentru asta, mergem în abonamente, pe pictograma cu cheia. Alegem abonamentul nostru.

Apoi, în Controlul Accesului, facem clic pe Atribuirea Rolului și căutăm după numele contului creat mai devreme. Acordăm rolul de Contributor, acest lucru este suficient.

Apoi, ne întoarcem la Service Principal-ul nostru din Azure AD și deschidem proprietățile acestuia. Mai târziu, ne vor fi necesare toate ID-urile care există acolo, le salvăm.

Acestea fiind spuse, setările portalului se încheie și trecem la Azure DevOps.

2. Integrarea în Azure DevOps

În primul rând, intrăm în setările proiectului și alegem Connections de Serviciu. Creăm un nou element de tip Azure Resource Manager.

Acum avem nevoie de toate ID-urile pe care le-am notat. Facem click pe folosi versiunea completă a dialogului de conexiune la serviciu. Introducem toate datele pe care le-am obținut de la Service Principal. Facem click pe verificare și, dacă totul este în regulă, salvăm conexiunea. Acum, pipeline-urile noastre pot folosi această conexiune pentru a se conecta la cloud.

3. Crearea pipeline-ului

Acum ne apucăm de partea interesantă, construirea efectivă a pipeline-ului. Deschidem meniul Pipelines-Builds

Suntem întâmpinați de meniul de creare a unui nou build, care va încerca, în mod implicit, să ne creeze un fișier YAML cu configurația potrivită. Politicos, refuzăm acest lucru și alegem opțiunea clasică. Este de înțeles dorința Microsoft de a face lucrurile cât mai prietenoase și de a permite personalizarea maximă a pipeline-urilor prin YAML, însă documentația sărăcă și pur și simplu nefuncționalitatea multor module ne spune că este încă prea devreme să folosim această funcționalitate.

Din multitudinea de șabloane, avem nevoie de un Simple Empty Pipeline. După crearea acestuia, vom fi întâmpinați de o fereastră de editare goală, în care vom petrece o perioadă considerabilă de timp.

Așadar, facem click pe + și ajungem într-un fel de magazin de module, de unde avem nevoie de următoarele componente.

Înainte de a începe configurarea task-urilor pipeline-ului, trebuie să formăm și să plasăm în proiect câteva fișiere. Acestea vor include ARM Template-ul mașinii noastre virtuale, pe care îl vom genera în Azure DevTest Labs, un script pentru a obține IP-ul mașinii după ce aceasta este creată și, opțional, scripturile testelor noastre sau ce dorim să ruleze pe gazdă.

4. Generarea ARM Template

Pentru a crea o mașină virtuală, va trebui, mai întâi, să generăm un template pentru aceasta, un fișier json pe care îl vom plasa în codul proiectului, astfel încât pipeline-ul să-l poată citi de acolo.

Ne îndreptăm spre laboratorul nostru și găsim meniul Formulelor (baze reutilizabile), facem click pe a crea una nouă.

Vom întâlni o listă lungă de imagini ca bază, alegerea dimensiunii mașinii, toate aceleași ca și la crearea unei mașini virtuale. În acest stadiu, nu ne vom opri, vom trece direct la ultimul punct de proprietăți ale mașinii, și anume artefactele. Puteți utiliza orice configurații necesare pentru mediu. domeniu și adaug un cont de serviciu ca administrator, astfel încât pipeline-ul să poată accesa ulterior această mașină sub acest cont. Acestea pot varia, dar pentru a testa cu succes codul, avem nevoie de un artefact, pe care ne vom concentra mai în detaliu. Pentru ca pe mașina noastră să fie instalată cea mai recentă versiune a software-ului pe care îl testăm, vom folosi artefactul „Download Azure Pipelines Artifact and Run Script”. Îmi amintesc că la început am spus că undeva se face un build cu instalatorul aplicației? Acum trebuie să spunem mașinii virtuale, mai exact șablonului, să meargă și să preia acest artefact. Și nu doar să-l preia, ci și să-l instaleze, pentru care completăm câmpurile speciale cu specificațiile proiectului, numele build-ului și cheia secretă. Cheia secretă, ca și în toate sistemele de acest tip, este generată în cont, în acest caz în Azure DevOps și este salvată în Secrets în laboratorul vostru. Aici există o mică specificație, în Secrets o vom salva, dar șablonul nu va fi afectat de aceasta, va rula deja sub un alt utilizator în cadrul pipeline-ului, așa că va trebui să introducem din nou manual cheia secretă în șablon.

Un alt artefact care trebuie inclus obligatoriu este „Configure WinRM”, care ne va fi necesar pentru accesul ulterior la mașină. Acesta are un singur parametru, hostname. Cum nu îl știm dinainte, vom folosi variabila %COMPUTERNAME%.

Așadar, am adăugat toate artefactele necesare, trecem la motivul pentru care am venit aici. Extragem șablonul ARM generat din fila Advanced a aceleași feronii de creare a formulei.

Copiem conținutul paginii în fișierul VMtemplate.json și îl plasăm în rădăcina proiectului. Nu mai avem nevoie de cloud, ne întoarcem în pipeline.

5. Configurarea pipeline-ului

Să începem cu cel mai important și interesant aspect, crearea unei mașini virtuale. De aceea am realizat toate aceste integrații și șabloane. La punctul Abonament Azure RM, alegem conexiunea de serviciu pe care am configurat-o la punctul 2. Apoi, ar trebui să apară mediul de laborator disponibil. Apoi, selectăm JSON-ul pe care l-am generat și definim anumite variabile obligatorii. Numele de utilizator și parola pentru mașină pot fi setate fie direct, fie ca variabile, dar nu sunt sigur că funcționează; oricum, nu am reușit să accesez mașina ulterior cu aceste acreditive. Este esențial să dăm un nume unic mașinii, așa că folosesc variabila de mediu a construcției.

Apoi, configurăm încă un aspect foarte important. După ce mașina va fi operațională, trebuie să știm cumva parametrii acesteia, iar acest lucru ar trebui să fie clar mai degrabă pentru pipeline decât pentru noi. Pentru aceasta, creăm un script, de exemplu, GetLabVMParams.ps1 și îl plasăm acolo, în proiect. Textul scriptului l-am preluat de pe site-ul Microsoft, dar l-am ajustat puțin pentru mediul meu, deoarece acesta prelua PublicIP și FQDN-ul mașinii. Nu am niciuna dintre acestea, dar am PrivateIP, pe care nu este chiar simplu să-l obții, așa că am adăugat un fragment.

Param( [string] $labVmId)

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

# Obține numele grupului de resurse pentru laboratoarele VM
$labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName

# Obține numele laboratoarei VM
$labVmName = (Get-AzureRmResource -Id $labVmId).Name

# Obține adresa IP publică a laboratoarelor VM
# $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress

# Obține FQDN-ul laboratoarelor VM
# $labVMFqdn = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).DnsSettings.Fqdn

# Obține adresa IP privată a laboratoarelor 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

# Setează o variabilă labVmRgName pentru a stoca numele grupului de resurse al laboratorului VM
Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName"

# Setează o variabilă labVMIpAddress pentru a stoca adresa IP a laboratoarelor VM
Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress"

# Setează o variabilă labVMFqdn pentru a stoca numele FQDN al laboratoarelor VM
Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn"

Write-Output $labVMIpAddress

Set-Item wsman:localhostclienttrustedhosts * -Force

Din tot ceea ce citește scriptul, avem nevoie doar de variabila labVMIpAddress. Acesta este cazul meu; poate că aveți nevoie și de alte informații, așa că nu am șters nimic, ci doar am comentat elementele inutile.

De asemenea, voi explica ultima linie a scriptului; aceasta permite mașinii noastre de construcție să acceseze orice gazdă prin WinRM.

În etapa următoare, lansăm minunatul nostru script. Acesta va necesita aceeași conexiune cu cloudul, variabila de intrare cu ID-ul mașinii, care va fi deja cunoscut din pasul anterior. Cum? Aici trebuie să menționez un lucru minunat, numit variabile de ieșire. Fiecare pas poate avea o listă de variabile care sunt transmise mai departe, pașilor următori din pipeline. Prin urmare, pentru super scriptul nostru, o astfel de variabilă va fi labVMIpAddress, nu uitați să o specificați.

Apoi, fac lucruri destul de simple, care, în plus, pot varia de la un caz la altul. Execuți scriptul remote pentru a crea un share, în care voi încărca ulterior scripturile mele.

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

Din denumirea task-urilor, este clar că următorul pas este să copiem un certain sample script pe mașină și, într-o etapă ulterioară, să-l executăm. Ca adresă a mașinii remote, ne va fi utilă variabila noastră $(labVMIpAddress). Apoi, folosim task-ul „preia artefacte din share” și copiăm rezultatele execuției scriptului în mediul nostru de build, apoi cu aceeași task standard salvăm aceste fișiere în artefactul build-ului. După ce mașina nu ne mai este necesară, în ultima etapă, o eliminăm. Principală dificultate, așa cum se vede și din volumul articolului, este integrarea cu cloudul și stabilirea contactului cu mașina virtuală pe care ați creat-o, apoi totul devine distractiv cât doriți.

Aceasta este prima mea articolă, așa că nu fiți prea duri, sugestiile sunt binevenite.

Sursa: habr.com