Self hosted Agent pool használata Azure DevOps-ban

Minden cégnek más és más elvárása van az egyes környezetekkel és szolgáltatásokkal kapcsolatban. Egyesek lazábbak, nagyon szabadon kezelik azok hálózati dolgait, míg mások sokkal szigorúbban. Azt, hogy melyik a jobb választás, nem az én tisztem eldönteni, de az igények kiszolgálása igen :) Ebben a Postban azt mutatom meg, hogyan lehet Azure DevOps számára olyan build/deploy gépeket létrehozni, melyek egy nagyobb és zárt, biztonságos hálózatban is képesek működni. Az alapvető probléma, amivel meg kell bírkózni, hogy nincs csak úgy internet elérése az egyes gépeknek, ezeknek először be kell “kapcsolódni” a hálózati vérkeringésbe és csak azt érik el, amit a hálózat/tűzfalas csapat megenged nekik, mint az enterprise-scale landing zones (ESLZ) világában úgy általában szokás.

Előfeltételek

Környezet létrehozásához a következőkre van szükség:

• Service Principal (SP)
• Jogosultság
• Azure DevOps regisztráció
• Azure előfizetés amibe van pár $
• Ingyenes DevOps esetén, ha még MSDN se áll rendelkezésre, lehet igényelni ingyenes Parallel job-ot (legalul leírom, hogyan)
• Vnet, melyhez kapcsolódhatunk, illetve amin keresztül internetelérésünk van.

Hálózat

ESLZ környezetben a hálózati infrastruktúrához nem biztos, hogy van hozzáférésünk olyan szinten, ami szükséges a hálózati erőforrások létrehozásához is. Ebben a szcenárióban nem is fogunk létrehozni Vnet-et, ezt már létrehozta nekünk valaki egy valamilyen módon leadott igény alapján. Ehhez hozzá is kapcsolt egy user defined routing (UDR)-t, tehát minden olyan eszköznek, amit hozzákapcsolunk ehhez a Vnethez, lesz egy értelmezhető belső hálózati kapcsolata és internet hozzáférése, ami elengedhetetlen ehhez az Azure DevOps szolgáltatáshoz. Tehát van egy előfizetésünk, amiben valami hasonló van:

Tűzfal/proxy

Van pár URL és IP, amit el kell tudnia érnie a Build környezetnek, ezt a listát itt megtalálod a Linux agent host-hoz Link

Virtual Machine Scale Sets

Virtual Machine Scale Sets (VMSS) létrehozása nem sokban különbözik egy sima VM létrehozásától, de azért egy két alapvető különség van… Az alap “az vmss create” parancs használata esetén sok olyan erőforrást létrehozni, ami szabadabb környezetben hasznos, de a mi esetünkben akár hibát is eredményezhet, hiszen a Puplic IP például, amit alapesetben létrehozna, gyakran le van tiltva az Azure Policy-val.
Minimál VMSS létrehozásához itt van egy egyszerű cli parancs, de ehhez azért kell némi információt megadni. Mivel már vnet-et és a subnetet is megkaptuk, így azokra csak hivatkoznunk kell, szóval a változók értékét ki kell cserélni a kapott nevekre:

az login

#Ha több előfizetéshez van jogosultsága a felhasználónknak
az account list
az account set --subscription "Előfizetés_neve"

#----------------------------------------------------------
$vmssname = "vmssagentspool"
$rg = "DevOpsAgentPool"
$vnet = "devops-vmss"
$subnet = "default"

az vmss create --name $vmssname --resource-group $rg --image UbuntuLTS --vm-sku Standard_D2ads_v5 --storage-sku Standard_LRS --authentication-type SSH --instance-count 0 --disable-overprovision --upgrade-policy-mode manual --single-placement-group false --platform-fault-domain-count 1 --generate-ssh-keys --ephemeral-os-disk true --os-disk-caching readonly --vnet-name $vnet --subnet $subnet --public-ip-address "" --load-balancer ""

A parancs sikeres lefuttatása után valami hasonló látvány fogad minket.

Ephemeral disk-et akarok használni, így ezek fontos lépések (maga a parancs még “fejlesztés alatt” van, szóval warning-ot fog kiírni, így éles környezetben nem ajánlott)
--ephemeral-os-disk true --os-disk-caching readonly Itt jelzem, hogy azt akarom használni, ha normál lemezt akarunk, akkor ezt a két paramétert el kell távolítani.
--vm-sku Standard_D2ads_v5 Ephemeral diskhez megfelelő méretű Temp disk kell, mert azt használja, mint OS disk.

Ezzel annyi előnyünk van, hogy

• Nem kell Disk-ért külön fizetnünk, hiszen a compute árában benne van a temp disk is
• Sokkal gyorsabban jönnek létre a gépek

A következő lépésben létre kell hoznunk egy olyan SP-t, amely hozzáfér ehhez a VMSS-hez, hogy átvehesse az irányítást az Azure DevOps felette.

Service connection létrehozása

Ezt már egy előző postban leírtam, hogy hogyan is kell létrehozni, mely itt található.

Agent hozzáadása

Organizáció vagy projekt szinten is hozzá tudjuk rendelni az agent-eket, de kiindulva abból, hogy sok kicsi projektem van, így nekem elgendő egy Agent Pool, amely viszont képes skálázódni.

Ezzel a Scale-set felett átvette a vezetést az Azure DevOps és el is tudjuk kezdeni annak használatát. Küldjünk is ki egy hello word-öt :)

Teszt

Default pipeline mintát veszek alapul, csak a pool-t cserélem ki alatta.

Arra a névre írom át a pool-t, ahogy felvettem Azure DevOps-ban
Portálon látom, hogy hoz is létre magának instance-ot
Build status pedig visszaigazol, hogy minden sikeresen lefutott

Diagnostics alatt ellenőrizhatjük, hogy az egyes Pool Agent-ek hogyan jönnek létre, majd megadott idő után hogyan törli azokat.