Наскоро се сблъсках с не много популярна все още звер в света на DevOps, Azure DevOps пайплайни. Веднага усетих липсата на каквито и да било ясни инструкции или статии по темата, не знам с какво е свързано, но Microsoft определено има да работи в посока популяризиране на инструмента. Днес ще изградим пайплайн за автоматизирано тестване в облака Azure.

И така, задачата:
Имаме софтуер, който билдим с помощта на същия Azure DevOps, събрани от проект на WIX. Ако проявите интерес, ще напиша и за този инструмент. По същество това е по-оптимизиран за автоматизация начин за изграждане на инсталатори за Windows, който заменя стандартния InstallShield. И така, нашият софтуер успешно се компилира и генерира артефакт, някакъв setup.exe, който инсталира приложението в Windows системата. Необходимо е това приложение да бъде инсталирано в виртуална машина, която е подобна на продукционната, да копираме там автоматизирани тестове, подготвени от тестовия екип, да ги стартираме и да вземем резултатите, за да преценим дали клонът е добър или лош, преди да извършим сливането. Всичко както в GitLab, само че по...

Като среда за виртуализация, в която ще изпълняваме нашите тестове, очевидно използваме Azure DevTest Labs, нещо като субстанция в Azure абонаментите, която е създадена именно за да върти всякакви тестови неща на приемливи цени.

1. Интеграция на облачната страна

Първо, трябва да интегрираме нашето DevTest Labs с Azure DevOps, за което ни е необходим Service Principal, всъщност сервисна учетна запись, която позволява на пайплайните да комуникират с облака и да създават/изтриват ресурси за себе си.

Отиваме в абонамента и намираме услугата Azure Active Directory.

Намираме App Registrations и щракаме на New Registration, това ще ни създаде нашия service principal. Няма да разглеждам подробно какви настройки да изберем при създаването, това може да се различава за различни абонаменти.

Сега трябва да дадем права на нашия сервисен директор. За целта отиваме в абонаментите, значката с ключа. Избираме нашия абонамент.

След това в Access Control натискаме Role Assignment и търсим по създаденото току-що име на тази учетна запис. Даваме ролята Contributor, това е достатъчно.

След това се връщаме към нашия Service Principal в Azure AD и отваряме неговите свойства. По-късно ще ни трябват всички ID, които се намират там, запазваме ги.

С това приключваме с настройките в портала и преминаваме към Azure DevOps.

2. Интеграция на страната на Azure DevOps

Първо, отиваме в настройките на проекта и избираме Service Connections. Създаваме нов елемент от типа Azure Resource Manager.

Сега ще ни трябват всички ID, които записахме. Кликваме на use the full version of the service connection dialog. Въвеждаме всички данни, получени от Service Principal. Натискаме verify и ако всичко е наред, запазваме връзката. Сега нашите пайплайни могат да го използват за свързване с облака.

3. Създаване на пайплайн

Сега пристъпваме към най-интересното, изграждането на самия пайплайн. Отваряме менюто Pipelines-Builds

Срещаме меню за създаване на нов билд, което по подразбиране ще се опита да създаде YAML файл с подходяща конфигурация. Ние учтиво отказваме и избираме класическия вариант. Разбираме желанията на Microsoft да направи всичко както трябва и да даде възможност за максимална персонализация на пайплайните през YAML, но оскъдната документация и просто практическата неработоспособност на много модули ни подсказва, че е още рано да ползваме тази функционалност.

От многото шаблони ще ни трябва прост Empty Pipeline. След його създаване, ще се срещнем с празен екран за редакция, в който ще прекараме доста време.

И така, натискаме на + и попадаме в нещо като магазин за модули, от където ще ни трябват следните компоненти по списък.

Преди да започнем с конфигурацията на тасковете на пайплайна, трябва да създадем и положим в проекта няколко файла. Те ще бъдат ARM Template на нашата виртуална машина, която ще генерираме в Azure DevTest Labs, скрипт за извличане на IP адреса на машината след създаването ѝ и, по желание, скриптове за нашите тестове или каквото искаме да пускаме на хостинга.

4. Генерация на ARM Template

За да създадем виртуалка, първо трябва да генерираме за нея темплейт, JSON файл, който ще поставим в кода на проекта, за да може пайплайнът да го прочете оттам.

Отиваме в нашата лаборатория и намираме менюто Formulas (reusable bases), натискаме да създадем нова.

Срещаме дълъг списък с имиджи в качеството на база, избор на размер на машината, всичко същото както при създаването на виртуалката. На този етап няма да се спираме, а веднага ще преминем към последния пункт на свойствата на машината, а именно артефактите. Можете да използвате всякакви конфигурации, които са необходими за вашата среда. Например, аз добавям машина в домен и добавям на него служебен акаунт в качеството на администратор, за да може пайплайнът впоследствие да влезе на тази машина с тази учетна запис. Това всичко може да варира, но за да тестваме кода успешно, ни е нужен един артефакт, на който ще се спрем по-подробно. За да инсталираме последната версия на софтуера, който тестваме, ще използваме артефакт "Download Azure Pipelines Artifact and Run Script". Помните ли, че в началото казах, че се генерира билд с инсталатор на приложението? Сега трябва да кажем на виртуалната машина, или по-точно на шаблона, да отиде и да вземе този артефакт. И не само да го вземе, а и да го инсталира, за което попълваме специални полета с указание на проекта, името на билда и секретния ключ. Секретният ключ, както и в системите от този род, се генерира в акаунта, в случая в Azure DevOps и се запазва в Secrets в вашата лаборатория. Има малка уговорка, в Secrets ще го запазим, но шаблонът от това не може да се възползва, той ще се изпълнява вече от друг потребител в рамките на пайплайна, затова ще трябва отново ръчно да въведем секретния ключ в шаблона.

Още един артефакт, който е задължително да включим, е "Configure WinRM", той ще ни бъде необходим за последващ достъп до машината. Там има само един параметър, hostname. Тъй като не знаем го предварително, ще използваме променливата %COMPUTERNAME%.

И така, добавихме всички необходими артефакти, преминаваме към целта, за която всъщност сме тук. Извличаме генерирания ARM Template от раздела Advanced на същия прозорец за създаване на формула.

Копираме съдържанието на страницата в файл VMtemplate.json и го поставяме в корена на проекта. Облачното приложение повече не е необходимо, връщаме се в пайплайна.

5. Конфигурация на пайплайна

Да започнем с най-важното и интересно, създаването на виртуалната машина, заради което направихме всички тези интеграции и шаблони. В раздела Azure RM Subscription избираме нашата Service connection, която конфигурирахме в точка 2. След това трябва да се появи наличната лабораторна среда. После избираме JSON файла, който генерирахме, и определяме някои задължителни променливи. Потребителското име и паролата за машината могат да бъдат зададени директно или чрез променливи, но не съм сигурен, че работи, защото каквото и да пиша, не можех да вляза в машината с тези данни. Важно е да зададете името на машината, за да бъде по възможност винаги уникално. За това използвам променлива в средата на изграждане.

Следващата стъпка е да настроим още един важен момент. След като машината стартира, трябва да знаем нейните параметри, а по-добре е не ние, а пайплайнът. Затова създаваме скрипт, например GetLabVMParams.ps1 и го поставяме там, в проекта. Текста на скрипта взех от сайта на Microsoft, но направих малки корекции за моята среда, тъй като той валидираше PublicIP и FQDN на машината. Нито едното от двете нямам, но имам PrivateIP, който не е толкова лесен за извличане, затова добавих малко код.

Param( [string] $labVmId)

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

# Вземи името на ресурсната група на лабораторната виртуална машина
$labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName

# Вземи името на лабораторната виртуална машина
$labVmName = (Get-AzureRmResource -Id $labVmId).Name

# Вземи публичния IP адрес на лабораторната виртуална машина
# $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress

# Вземи FQDN на лабораторната виртуална машина
# $labVMFqdn = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).DnsSettings.Fqdn

# Вземи частния IP адрес на лабораторната виртуална машина
$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

# Задай променлива labVmRgName за съхранение на името на ресурсната група на лабораторната виртуална машина
Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName"

# Задай променлива labVMIpAddress за съхранение на IP адреса на лабораторната виртуална машина
Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress"

# Задай променлива labVMFqdn за съхранение на името FQDN на лабораторната виртуална машина
Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn"

Write-Output $labVMIpAddress

Set-Item wsman:localhostclienttrustedhosts * -Force

От всичко, което скриптът чете, необходима ни е само променливата labVMIpAddress. Това може би е достатъчно за мен, може би на вас ще ви трябва нещо друго, затова не съм премахвал нищо, а просто коментирах излишното.

Също така ще обясня последния ред от скрипта, който разрешава на нашата билд машина достъп до всеки хост чрез WinRM.

На следващия етап стартираме нашия чудесен скрипт. Нужна ни е същата връзка с облака и входна променлива с ID на машината, която по това време вече ще е известна от предишната стъпка. Как? Тук трябва да споменем за една чудесна вещ, наречена Output Variables. Всеки етап може да има списък с променливи, които се предават на следващите стъпки в пайплайна. Съответно, за нашия супер скрипт такава променлива ще бъде labVMIpAddress, не забравяйте да я посочите.

След това правя доста прости неща, които освен това може да варират от случай на случай. Изпълнявам отдалечен скрипт за създаване на споделена папка, в която после ще зареждам моите скриптове.

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

От името на задачите е ясно, че следващото нещо, което правим, е да копираме някакъв sample script на машината и с още една стъпка да го изпълним. Като адрес на отдалечената машина ще ни е полезна нашата променлива $(labVMIpAddress). След това използваме задачата "вземи артефакт от споделената папка" и копираме резултатите от изпълнението на скрипта в нашата билд среда, после с една стандартна задача запазваме тези файлове в артефакт на билда. След като машината вече не ни е нужна, на последния етап я унищожаваме. Основната трудност, както се вижда по обема на статията, е интегрирането с облака и установяването на контакт с виртуалната машина, която сте създали; след това вече можете да се забавлявате колкото желаете.

Това е моята първа статия, затова не бъдете прекалено строги, коментарите са добре дошли.

Източник: habr.com