Hiljuti kohtasin ma veel mitte nii populaarset loomakest DevOpsi maailmas — Azure DevOps pipeline'e. Tõsiselt puudus mingisugune arusaadav juhend või artikkel, mis seda teemat käsitleks. Ei oska öelda, millega see seotud on, kuid Microsoftil on selgelt veel palju teha selle tööriista populariseerimise osas. Täna loome pipeline'i automatiseeritud testimiseks Azure'i pilves.

Niisiis, ülesanne:
On olemas tarkvara, mida ehitatakse sama Azure DevOps'i abil, kogudes projekti WIX-ist. Kui see huvi tekitab, võin kirjutada ka selle tööriista kohta. Tegelikult on see automatiseerimise jaoks optimeeritud viis Windowsi installija kogumiseks, asendades standardse InstallShieldi. Seega, meie tarkvara ehitatakse edukalt ja genereerib artefakti, mingi setup.exe, mis installib rakenduse Windowsi süsteemi. See rakendus tuleb instalida sarnasesse virtuaalmasinasse nagu tootmisversioon, kopeerida sinna automatiseeritud testid, mis on ette valmistatud testimismeeskonna poolt, käivitada need ja võtta tulemused, et hinnata haru head või halba, enne kui neid liidetakse. Kõik nagu GitLabis, ainult läbi ... .

Kuna virtualiseerimise keskkonda, kus me meie teste teostame, kasutame selgelt Azure DevTest Labs'i, mis on teatud tüüpi teenus Azure'i tellimustes, mis on loodud erinevate testide läbiviimiseks taskukohaste hindade eest.

1. Integratsioon pilvepoolel

Kõigepealt peame integreerima meie DevTest Labs'i Azure DevOps'iga, milleks on meil vajalik Service Principal, mis on sisuliselt teenuse konto, mis võimaldab meie pipeline'idelt pilve minna ja seal ressursse luua/kustutada.

Liigume tellimusse ja leidke Azure Active Directory teenus.

Otsime üles Rakenduste registreerimised ja klikime Uuel registreerimisel, see loob meile meie service principal'i. Ma ei hakka üksikasjalikult arutama, millised seaded valida registreerimise ajal, kuna need võivad erineda erinevates tellimustes.

Nüüd peame andma õigused meie teenuse direktorile. Selleks liigume tellimustesse, võtme ikoonile. Valime meie tellimuse.

Seejärel klõpsame Access Control'l, valime Rolli määramise ja otsime just loodud nime kaudu seda kontot. Anname rolli Contributor, sellest piisab.

Seejärel tuleme tagasi meie Service Principal'i juurde Azure AD-s ja avame selle omadused. Edasi on meil vaja kõiki seal olevaid ID-sid, salvestame need.

Sellega lõppevad meie portaali seaded ja liigume Azure DevOpsisse.

2. Integratsioon Azure DevOpsi küljel

Esmalt avame projekti seaded ja valime Teenuseühendused. Loome uue Azure Resource Manager'i tüüpi elemendi.

Nüüd vajame kõiki ID-sid, mida oleme üles kirjutanud. Klõpsame nuppu "kasutada teenuseühenduse dialooge täielikult". Sisestame kõik andmed, mis saime Teenuse Põhiolekult. Vajutame "verify" ning kui kõik on korras, salvestame ühenduse. Nüüd saavad meie torud seda kasutada pilve ühendamiseks.

3. Toru loomine

Nüüd asume kõige huvitavama osa juurde, nimelt toru otse loomise. Avame valiku Pipelines-Builds

Kohale jõudes kohtame uue ehituse loomise menüüd, mis vaikimisi püüab luua sobivat YAML faili. Me keeldume sellest viisakalt ja valime klassikalise variandi. On aru saada, et Microsoft tahab teha kõik nagu inimesed ja annavad võimaluse maksimaalselt kohandada torusid läbi YAML, kuid piiratud dokumentatsioon ja lihtsalt paljude moodulite praktiline mittefunktsioneerimine ütlevad meile, et on liiga vara seda funktsionaalsust kasutada.

Paljusid malle arvesse võttes vajame lihtsalt tühja juhtmevaba toru. Pärast selle loomist tervitab meid tühi redigeerimisaken, kus veedame edasi üsna palju aega.

Nii et vajutame + ja jõuame teatud moodulite poodi, kust vajame loendi järgi järgmisi komponente.

Enne kui alustada toru tööülesannete seadistamist, peame koostama ja projekti panema mõned failid. Need on meie virtuaalmasina ARM-mall, mille genereerime Azure DevTest Labs, skript masinast IP aadressi saamiseks pärast selle loomist ning soovi korral meie testide skriptid või see, mida tahame hostis käitada.

4. ARM-malli genereerimine

Virtuaalmasina loomiseks peame esmalt genereerima templi, JSON-faili, mille paneme projekti koodi, et toru saaks sellest lugeda.

Lähme meie laborisse ja otsime menüüst Formulas (taaskasutatavad alused), klõpsame, et luua uus.

Meid ootab pikk nimekiri imajidest, masinate suuruse valik ja kõik sama, nagu virtuaalmasina loomise puhul. Sel hetkel ei peatu me, vaid liigume kohe viimase punkti juurde masina omadustest, st artefaktide juurde. Võite kasutada kõiki konfigureerimise võimalusi, mis teie keskkonna jaoks vajalikud. Näiteks lisan masina domeeni ja lisame sellele teenuse konto administraatorina, et pipeline saaks sellele masinale selle konto kaudu ligi. See kõik võib varieeruda, aga koodide edukaks testimiseks vajame ühte artefakti, millele jääme detailsemalt pidama. Selleks, et meie masinasse installitaks testitava tarkvara viimane versioon, kasutame artefakti "Download Azure Pipelines Artifact and Run Script". Kas mäletate, et ma mainisin alguses, et kuskil koostatakse rakenduse installija? Praegu peame ütlema virtuaalmasinale, või täpsemalt templi, et see minema läheks ja selle artefakti välja tooks. Ja mitte lihtsalt saaks, vaid ka installiks, mille jaoks täidame spetsiaalsed väljad projekti, buildi nime ja salajase võtme näitamisega. Salajane võtme, nagu kõikides sarnastes süsteemides, genereeritakse kontol, antud juhul Azure DevOpsis, ja salvestatakse teie laboris Secretsisse. Siin on üks väike täpsustus: me salvestame selle Secretsisse, kuid templile ei ole sellest mingit kasu, kuna see käivitub juba teise kasutaja alt pipeline'i raames, seega peame salajase võtme veel kord käsitsi templisse sisestama.

Veel üks artefakt, mida kindlasti lisada, on «Configure WinRM», kuna meil on seda vaja masinale hilisemaks ligipääsuks. Seal on vaid üks parameeter, hostname. Kuna me ei tea seda ette, kasutame muutuja %COMPUTERNAME%.

Nii et oleme lisanud kõik vajalikud artefaktid ja liigume edasi põhjuseni, miks me siin oleme. Saame genereeritud ARM malelõike Advanced vahekaardilt samas aknas, kus formuleerime.

Kopeerime lehe sisu faili VMtemplate.json ja paneme selle projekti juurkausta. Pilv ei ole meile enam vajalik, naaseme tagasi voolu.

5. Voogude konfigureerimine

Alustame kõige olulisemast ja huvitavamast, virtuaalmasina loomisest, milleks me kõik need integreerimised ja mallid tegime. Azure RM Subscription punktis valime meie teenuseühenduse, mille me konfigureerisime punktis 2. Järgmisena peaks ilmuma meie jaoks saadaval laboratorikeskkond. Siis valime JSON-faili, mille me genereerisime, ja määratleme mõned kohustuslikud muutujad. Masina kasutajanime ja parooli saab määrata kas otse või muutujate kaudu, kuid ma ei ole kindel, kas see toimib; mida iganes ma sinna ei kirjutanud, masinasse sisenemine nende andmetega ei õnnestunud. Peamine on määrata masina nimi, et see oleks võimalusel alati ainulaadne. Selle jaoks kasutan ma buildi keskkonnavaru.

Seejärel seadistame veel ühe olulise aspekti. Kui masin tõuseb, peame me kuidagi teadma selle parameetreid, parem oleks, kui see teaks kanali jaoks. Selleks loome skripti, näiteks GetLabVMParams.ps1 ja paneme selle projekti. Skripti tekst on võetud Microsofti veebisaidilt, kuid muutsin seda veidi oma keskkonna jaoks, kuna see hankis masinast PublicIP ja FQDN. Mul ei ole kumbagi, kuid on olemas PrivateIP, mille hankimine ei ole nii lihtne, seetõttu lisasin skripti osa.

Param( [string] $labVmId)

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

# Hankige labori VM-i ressursirühma nimi
$labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName

# Hankige labori VM-i nimi
$labVmName = (Get-AzureRmResource -Id $labVmId).Name

# Hankige labori VM-i avalik IP-aadress
# $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress

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

# Hankige labori VM-i sise IP-aadress
$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

# Muutujate labVmRgName seadmine, et salvestada labori VM-i ressursirühma nimi
Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName"

# Muutujate labVMIpAddress seadmine, et salvestada labori VM-i IP-aadress
Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress"

# Muutujate labVMFqdn seadmine, et salvestada labori VM-i FQDN nimi
Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn"

Write-Output $labVMIpAddress

Set-Item wsman:localhostclienttrustedhosts * -Force

Kõigest, mida skript näeb, vajame ainult muutuja labVMIpAddress. Küll aga võite vajada veel midagi, seega ma ei kustutanud midagi, vaid lihtsalt kommenteerisin üleliigse välja.

Selgitan ka viimast rida skriptis; see lubab meie ehituskeskkonnal juurde pääseda igale hostile WinRM-i kaudu.

Järgmise sammuna käivitame meie suurepärase skripti. Selleks on vajalik sama ühendus pilvega, sisendmuutuja masina ID-ga, mis on selleks ajaks juba teada eelmisest sammust. Kuidas? Siin on oluline mainida sellist imelist asja nagu väljundmuutujad. Iga sammul võivad olla loetelu muutujatest, mis edastatakse edasi järgmistele pipelini sammudele. Seega meie super skripti jaoks on selline muutuja labVMIpAddress, ärge unustage seda märkida.

Edasi teen ma üsna lihtsaid asju, mis võivad varieeruda juhtumist juhtumisse. Käivitan kaugskripti jagamise loomisega, kuhu hakkan hiljem oma skripte üles laadima.

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

Tööde pealkirjast on selge, et edasi liikumiseks kopeerime mõne skripti masinasse ja täidame selle seejärel järgmisel etapil. Kaugmasina aadressina on meil kasulik meie muutuja $(labVMIpAddress). Järgmisena kasutame ülesannet 'artiifakti toomine jagamisest' ja kopeerime skripti täitmise tulemused enda ehituskeskkonda, seejärel salvestame need failid ehituse artefakti tavalise ülesandega. Kui masinat enam ei vajata, lõpetame selle viimase etapina. Peamine keerukus, nagu näha artikli mahust, on integreeruda pilve ja luua kontakt loodud virtuaalmasinaga, edasi võib juba meelelahutusele pühenduda nii palju kui soovite.

See on minu esimene artikkel, seetõttu ärge tehke liiga karmilt, kommentaarid on teretulnud.

Allikas: habr.com