Hiljuti kohtasin DevOpsi maailmas veel mitte väga populaarset loomade rühma, Azure DevOps'i torujuhtmeid. Jõudsin kiiresti järeldusele, et mul puuduvad selged juhised või artiklid selle teema kohta; ma ei tea, millega see seotud on, kuid Microsoftil on selgelt midagi, millega tegeleda, et tööriista populariseerida. Täna ehitame torujuhtme automatiseeritud testimiseks Azure'i pilves.

Seega, ülesanne:
On olemas tarkvara, mida ehitatakse Azure DevOps'i abil, kogudes WIX projektist. Kui see huvi pakub, kirjutan ka sellest tööriistast. Tegelikult on see optimeeritud meetod Windowsi installijate ehitamiseks, asendades standardse InstallShield'i. Nii et meie tarkvara ehitatakse edukalt ja genereerib artefakti, teatud setup.exe, mis installib rakenduse Windowsi süsteemi. See rakendus tuleb paigaldada sarnasesse virtuaalmasinasse nagu tootmisversioon, kopeerida sinna automatiseeritud testid, mille on ette valmistanud testimismeeskond, käivitada need ja hankida tulemused, et otsustada, kas haru on hea või halb, enne kui liidame. Kõik käib nagu GitLab'is, ainult läbi ju....

Kuna virtuaaliseerimiskeskkonda, kus me testid käivitame, kasutame ilmselt Azure DevTest Labs, mis on teatud üksus Azure'i tellimustes, mille eesmärk on testida igasuguseid katseasi mõõdukate hindadega.

1. Integreerimine pilves

Alustuseks on meil vaja integreerida meie DevTest Labs Azure DevOps'iga, milleks on meil vajalik mõni Service Principal, põhjalikult öeldes teenuse konto, mis võimaldab torujuhtmete minna pilve ja luua/pooleldada seal ressursse enda jaoks.

Läheme tellimusse ja leiame Azure Active Directory teenuse

Leiame Rakenduse registreerimised ja klõpsame Uuel registreerimisel, see loob meie teenuse põhiteenuse. Ei hakka üksikasjalikult arutama, milliseid seadeid valida registreerimise ajal, need võivad erinevates tellimustes erineda.

Nüüd peame andma oma teenuse direktorile õigused. Selleks läheme tellimustele, võtmega ikoon. Valime meie tellimuse.

Seejärel klõpsame Access Control'is Rolli määramine ja otsime loodud nime järgi seda kontot. Anname rolli Contributor, seda on piisavalt.

Seejärel naaseme meie Service Principal'i juurde Azure AD-s ja avame tema atribuudid. Hiljem vajame kõiki seal olevaid ID-sid, salvestame need.

Sellega saavad meie portaali seaded läbi ja viime end Azure DevOps'i.

2. Azure DevOps'i integreerimine

Esiteks siseneme projekti seadistustesse ja valime Teenuseühendused. Loome uue Azure Resource Manageri tüüpi elemendi.

Nüüd vajame kõiki ID-sid, mis me üles kirjutasime. Klõpsame 'kasuta teenuseühenduse dialooge täisversioonis'. Sisestame kõik andmed, mis saime Teenuse Peavalitsuselt. Klõpsame ülevaatamisel ja kui kõik on korras, salvestame ühenduse. Nüüd saavad meie torud seda kasutada pilve ühendamiseks.

3. Toru loomine

Nüüd viime ellu kõige huvitavama osa, toru otse loomise. Avame menüü Torud - Ehitus.

Meid tervitab uue ehituse loomise menüü, mis üritab vaikimisi luua sobiva konfiguratsiooni YAML faili. Me keeldume viisakalt sellest ja valime klassikalise variandi. Microsofti soov muuta kõik inimlikuks ja anda võimalus maksimaalselt kohandada torne YAML kaudu on arusaadav, kuid napid dokumentatsioon ja lihtsalt praktiline mittevõime paljude moodulite puhul ütlevad meile, et praegu on veel vara selle funktsionaalsusega tutvuda.

Laiast mallivalikust vajame lihtsat Tühja Toru. Pärast selle loomist tervitab meid tühi redigeerimisaken, kus me veedame edaspidi üsna palju aega.

Seega klõpsame + ja jõuame mingisse moodulite poodi, kust vajame järgmist loetelu komponente.

Enne kui hakkame toru ülesannete konfigureerimisega tegelema, peame vormima ja projekti paigutama mitmeid faile. Need on meie virtuaalmasina ARM malli, mille genereerime Azure DevTest Labsis, skript IP aadressi hankimiseks pärast masina loomist ja soovi korral meie testide skript või see, mida soovime hostis käivitada.

4. ARM malli genereerimine

Virtuaalmasina loomiseks peame kõigepealt genereerima selle jaoks mall, json faili, mille me paneme projekti koodisse, et toru saaks sellest lugeda.

Suundume oma laborisse ja leiame menüü Valemid (uuesti kasutatavad alused), klõpsame uue loomisel.

Meid tervitab pikk loend piltidest aluseks, masina suuruse valik, kõik on sama nagu virtuaalmasina loomisel. Sellel etapil me ei peatu, vaid liigume kohe masina omaduste viimase punkti juurde, nimelt artefaktide juurde. Saate kasutada igasuguseid konfiguratsioone, mis on vajalikud teie keskkonna jaoks. Näiteks lisan masina domeen ja lisame teenusekonto administraatorina, et pipeline saaks sellele masinale selle konto kaudu juurde pääseda. See kõik võib varieeruda, kuid koodi edukaks testimiseks vajame ühte artefakti, millele peatume üksikasjalikumalt. Selleks et meie masinale installitaks viimase versiooni katsetatavast tarkvarast, kasutame artefakti „Laadi Azure Pipelines'i artefakt ja käivita skript“. Kas mäletate, et rääkisin alguses, et kuskil kogutakse rakenduse installer? Praegu peame virtuaalmasinale, täpsemalt templi jaoks, ütlema, et ta läheks ja tooks selle artefakti. Ja mitte lihtsalt tooma, vaid ka installima, milleks täidame spetsiaalsed väljad projekti, ehituse nime ja salajase võtmega. Salajane võti, nagu kõikides sarnastes süsteemides, genereeritakse kontol, antud juhul Azure DevOpsis, ja salvestatakse teie laboris Secrets sektsiooni. Siin on väike täpsustus, me salvestame selle Secrets'i, kuid templile ei ole sellest kasu, sest see käivitatakse teise kasutaja alla pipeline'i raames, seega tuleb salajane võti veel kord käsitsi templisse sisestada.

Veel üks artefakt, mis tuleb kindlasti lisada, on „Configure WinRM“, me vajame seda edasisteks juurdepääsuks masinale. Seal on vaid üks parameeter, hostname. Kuna me seda ette ei tea, kasutame muutujat %COMPUTERNAME%.

Nii oleme lisanud kõik vajalikud artefaktid, liigume edasi selle juurde, miks me siia üldse tulime. Tõstame genereeritud ARM-malli esile Advanced vahekaart samas akna loomise formuli.

Kopeerime lehe sisu faili VMtemplate.json ja paneme selle projekti juurde. Rohkem pole me pilves, naaseme pipeline'i.

5. Pipeline'i konfigureerimine

Alustame kõige olulisemast ja huvitavamast, virtuaalmasina loomisest, mille jaoks oleme teinud kõik need integreerimised ja mallid. Azure RM tellimuse jaotises valime meie teenuseühenduse, mille oleme konfigureerinud punktis 2. Järgmiseks peaks ilmuma meie jaoks saadaval olev laborikeskkond. Siis valime json-faili, mille me genereerisime, ja määratleme mõned kohustuslikud muutujad. Saame masinasse sisenemiseks kasutajanime ja parooli määrata kas otse või muutujate kaudu, kuid ma ei ole üldse kindel, et see töötab; olen proovinud erinevaid variatsioone ja ei saanud masinasse sisse logida. Peamine on määrata masina nimi, veendudes, et see oleks võimalikult ainulaadne. Selle jaoks kasutan ehituse keskkonna muutujat.

Seejärel seadistame veel ühe olulise hetke. Pärast seda, kui masin on tööle läinud, peame kuidagi teadma selle parameetreid, või veel parem, et teadlik oleks meie CI/CD torustik. Selleks loome skripti, näiteks GetLabVMParams.ps1, ja paneme selle projektikausta. Skripti tekst on toodud Microsofti veebisaidilt, kuid olen seda veidi kohandanud oma keskkonna jaoks, kuna see võttis endale PublicIP ja FQDN väärtused. Mul ei ole ei ühtki, vaid on olemas PrivateIP, mille hankimine pole sugugi lihtne, seega lisasin mõned read.

Param( [string] $labVmId)

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

# Saame labori VM-i ressursside grupi nime
$labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName

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

# Saame labori VM-i avaliku IP-aadressi
# $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress

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

# Saame labori VM-i privaatse IP-aadressi
$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

# Seame muutujale labVmRgName labori VM-i ressursside grupi nime salvestamiseks
Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName"

# Seame muutujale labVMIpAddress labori VM-i IP-aadressi salvestamiseks
Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress"

# Seame muutujale labVMFqdn labori VM-i FQDN nime salvestamiseks
Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn"

Write-Output $labVMIpAddress

Set-Item wsman:localhostclienttrustedhosts * -Force

Kogu skriptist on meil vaja vaid muutujat labVMIpAddress. Üks asi, mis võib teile veel vajalik olla, seega ei kustutanud ma midagi, vaid kommenteerisin lihtsalt üleliigse välja.

Selgitan ka skripti viimaset rida, see lubab meie ehitusmasinal juurdepääsu igale hostile läbi WinRM.

Järgmise etapina käivitame meie imelise skripti. Selleks on vajalik sama ühendus pilvega, sisendmuutuja masina ID-ga, mis on selleks ajaks juba teada eelmisest sammust. Kuidas? Siin tuleb mainida sellist imelise asja nagu väljundmuutujad. Iga sammu juures võib olla nimekiri muutujatest, mis edastatakse edasi järgmistele etappidele torustikus. Seega meie super skripti jaoks on selline muutuja labVMIpAddress, ärge unustage seda märkida.

Edasi teen ma üsna lihtsaid asju, mis võivad samuti varieeruda juhtumist juhtumisse. Käivitan kaugskripti jagamise loomisega, kuhu seejärel laen oma skripte.

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

Nime järgi on selge, et edasi me kopeerime mingi näidis skripti masinasse ja ühes etapis ka käivitame selle. Kaugmasina aadressina tuleb kasuks meie muutuja $(labVMIpAddress). Edasi kasutame ülesannet "korja artefakt jagamisest" ja kopeerime skripti käitamise tulemused oma ehituskeskkonda, seejärel salvestame sarnase standardse ülesande abil need failid ehituse artefakti. Pärast seda, kui masinat enam ei vajata, tapame selle viimase etapina. Peamine raskus, nagu artikli mahust näha, on integreeruda pilvega ja luua kontakt loodud virtuaalmasinaga, edasi on juba võimalik lõbutseda nii palju kui soovite.

See on minu esimene artikkel, nii et ärge olge liiga ranged, kommentaarid on teretulnud.

Allikas: habr.com