Частка 1: Web / Android
Заўвага: дадзены артыкул з'яўляецца перакладам на рускую мову арыгінальнага артыкула Аднак усе ілюстрацыі, спасылкі, цытаты і тэрміны захаваны на мове арыгінала, каб пазбегнуць скажэнні сэнсу пры перакладзе на рускую мову. Жадаю вам прыемнага вывучэння!
У цяперашні час спецыяльнасць DevOps з'яўляецца адной з найболей запатрабаваных у IT-індустрыі. Калі вы адкрыеце папулярныя сайты па пошуку працы і зададзіце фільтр па заробках, то ўбачыце, што вакансіі, звязаныя з DevOps, знаходзяцца ў пачатку спісу. Аднак важна разумець, што гэта ў асноўным адносіцца да пазіцыі 'Senior', што мае на ўвазе, што кандыдат валодае высокім узроўнем навыкаў, веданнем тэхналогій і інструментаў. Да гэтага таксама прыкладаецца высокая ступень адказнасці, злучаная з бесперабойнай працай production. Аднак мы сталі забывацца, што такое DevOps. Першапачаткова гэта не быў нейкі канкрэтны чалавек ці дэпартамент. Калі пашукаць азначэнні гэтага тэрміна, то мы знойдзем шмат прыгожых і правільных назоўнікаў, такіх як метадалогія, практыкі, культурная філасофія, група канцэптаў і гэтак далей.
Мая спецыялізацыя - інжынер па аўтаматызацыі тэсціравання (QA automation engineer), але я лічу, што яна не павінна быць звязана толькі з напісаннем аўта-тэстаў або распрацоўкай архітэктуры тэставага framework. У 2020 годзе веды інфраструктуры аўтаматызацыі таксама неабходныя. Гэта дазваляе арганізаваць працэс аўтаматызацыі самастойна, пачынаючы ад запуску тэстаў і заканчваючы прадастаўленнем вынікаў усім зацікаўленым асобам у адпаведнасці з пастаўленымі мэтамі. У выніку чаго, навыкі DevOps з'яўляюцца абавязковым фактарам для выканання дадзенай працы. І ўсё гэта добра, але, на жаль, ёсць праблема (spoiler: дадзены артыкул робіць спробы спрасціць гэтую праблему). Яна заключаецца ў тым, што DevOps - гэта складана. І гэта відавочна, бо кампаніі не стануць плаціць шмат за тое, што лёгка зрабіць… У свеце DevOps вялікая колькасць інструментаў, тэрмінаў, практык, якімі трэба авалодаць. Асабліва гэта цяжка даецца ў пачатку кар'еры і залежыць ад назапашанага тэхнічнага досведу.
Крыніца:
Тут мы, мабыць, завершым з уступнай часткай і сфакусуемся на мэты дадзенага артыкула.
Пра што гэты артыкул
У гэтым артыкуле я збіраюся падзяліцца маім вопытам пабудовы інфраструктуры аўтаматызацыі тэсціравання. У інтэрнэце можна знайсці шмат крыніц інфармацыі аб розных інструментах і як іх выкарыстоўваць, але я б хацеў разгледзець іх выключна ў кантэксце аўтаматызацыі. Я мяркую, што шматлікім інжынерам па аўтаматызацыі знаёмая сітуацыя, калі распрацаваныя тэсты, акрамя вас саміх, ніхто не запускае і не клапоціцца аб іх падтрымцы. У выніку чаго тэсты становяцца састарэлымі і даводзіцца марнаваць час на іх актуалізацыю. Ізноў жа ў пачатку кар'еры гэта можа быць даволі складанай задачай: пісьменна вырашыць, якія прылады павінны дапамагчы ўхіліць дадзеную праблему, як іх абраць, наладзіць і падтрымліваць. Некаторыя тэсціроўшчыкі звяртаюцца за дапамогай да DevOps (людзям) і, будзем сумленнымі, такі падыход працуе. У шматлікіх выпадках гэта можа быць адзіным варыянтам, бо ў нас адсутнічае бачнасць усіх залежнасцяў. Але, як мы ведаем, DevOps – вельмі занятыя хлопцы, бо яны павінны думаць пра інфраструктуру ўсёй кампаніі, deployment, маніторынг, мікрасэрвісы і пра іншыя падобныя задачы ў залежнасці ад арганізацыі/каманды. Як гэта звычайна бывае, аўтаматызацыя не зьяўляецца прыярытэтам. У такім выпадку мы мусім паспрабаваць зрабіць усё магчымае з нашага боку ад пачатку і да канца. Гэта зменшыць залежнасці, паскорыць працоўны працэс, удасканаліць нашы навыкі і дазволіць убачыць больш шырокую карціну таго, што адбываецца.
У артыкуле прадстаўлены найбольш запатрабаваныя і папулярныя інструменты і паказана, як іх выкарыстоўваць для пакрокавага пабудовы інфраструктуры аўтаматызацыі. Кожная група прадстаўлена інструментамі, якія былі правераны на асабістым досведзе. Але гэта не значыць, што вы павінны выкарыстоўваць тое ж самае. Самі прылады не важныя, яны з'яўляюцца і састарваюцца. Наша інжынерная задача - разуменне базавых прынцыпаў: навошта нам патрэбна гэтая група інструментаў і якія працоўныя задачы мы можам з іх дапамогай вырашыць. Таму ў канцы кожнай секцыі я пакідаю спасылкі на аналагічныя прылады, якія, магчыма, выкарыстоўваюцца ў вашай арганізацыі.
Чаго ў гэтым артыкуле няма
Яшчэ раз паўтару, што артыкул не пра пэўныя прылады, таму тут не будзе ўставак кода з дакументацыі і апісанні пэўных каманд. Але напрыканцы кожнай секцыі я пакідаю спасылкі для дэталёвага вывучэння.
Гэта зроблена з прычыны таго, што:
- гэты матэрыял вельмі лёгка знайсці ў розных крыніцах (дакументацыя, кнігі, відэа курсы);
- калі мы пачнем паглыбляцца, то давядзецца напісаць 10, 20, 30 частак гэтага артыкула (тады як у планах 2-3);
- я проста не хачу марнаваць ваш час, так як, магчыма, вы хочаце выкарыстоўваць іншыя інструменты для дасягнення тых жа мэт.
Практыка
Мне б вельмі хацелася, каб гэты матэрыял быў карысны для кожнага чытача, а не проста быў прачытаны і забыты. У любым вывучэнні практыка з'яўляецца вельмі важным складнікам. Для гэтага я падрыхтаваў. Таксама вас чакае хатняя праца, каб быць упэўненым, што вы бяздумна не скапіявалі радкі выкананых каманд
план
Крок
Тэхналогія
інструменты
1
Local running (prepare web / android дэма-экзамены і run it locally)
Node.js, Selenium, Appium
2
Version control systems
ісці
3
Containerisation
Docker, Selenium grid, Selenoid (Web, Android)
4
CI / CD
Gitlab CI
5
хмарныя платформы
Google Cloud Platform
6
Аркестроўка
Kubernetes
7
Infrastructure as a code (IaC)
Terraform, Ansible
Структура кожнай секцыі
Для падтрымання апавядання ў наглядным выглядзе, кожная секцыя апісана па наступным плане:
- кароткае апісанне тэхналогіі,
- каштоўнасць для інфраструктуры аўтаматызацыі,
- ілюстрацыя бягучага стану інфраструктуры,
- спасылкі для вывучэння,
- аналагічныя прылады.
1. Лакальны запуск тэстаў
Кароткае апісанне тэхналогіі
Гэта ўсяго толькі падрыхтоўчы крок для запуску дэманстрацыйных тэстаў лакальна і для праверкі, што яны паспяхова праходзяць. У практычнай частцы выкарыстоўваецца Node.js, але мова праграмавання і платформа таксама не важныя і можна выкарыстоўваць тыя, што выкарыстоўваюцца ў вашай кампаніі.
Аднак у якасці прылад аўтаматызацыі я рэкамендую выкарыстоўваць Selenium WebDriver для web-платформаў і Appium для Android-платформы адпаведна, бо на наступных кроках мы будзем выкарыстоўваць Docker-выявы, якія заменчаны на працу пэўна з гэтымі прыладамі. Больш за тое, спасылаючыся на патрабаванні ў вакансіях, гэтыя інструменты найбольш запатрабаваны на рынку.
Як вы маглі заўважыць, мы разглядаем толькі web і Android-тэсты. Нажаль, IOS - зусім іншая гісторыя (дзякуй Apple). Я планую прадэманстраваць рашэнні і практыкі, звязаныя з IOS, у наступных частках.
Каштоўнасць для інфраструктуры аўтаматызацыі
З пункту гледжання інфраструктуры лакальны запуск не нясе ніякай каштоўнасці. Вы толькі правяраеце, што тэсты працуюць на лакальнай машыне ў лакальных браўзэрах і сімулятарах. Але ў любым выпадку гэта неабходная адпраўная кропка.
Ілюстрацыя бягучага стану інфраструктуры
Спасылкі для вывучэння
Аналагічныя інструменты
- любую мову праграмавання, якая вам падабаецца, у звязку з Selenium/Appium — тэстамі;
- любыя тэсты;
- любы тэст-ранер.
2. Сістэмы кантролю версій (Git)
Кароткае апісанне тэхналогіі
Ні для каго не будзе вялікім адкрыццём, калі я скажу, што сістэма кантролю версій - надзвычай важная частка распрацоўкі як у камандзе, так і індывідуальна. Абапіраючыся на розныя крыніцы, можна з упэўненасцю сказаць, што Git з'яўляецца найболей папулярным прадстаўніком. Сістэма кантролю версій дае мноства пераваг, такіх як абмен кодам, захоўванне версій, аднаўленне на папярэднія галіны, маніторынг праектнай гісторыі, бэкапы. Мы не будзем абмяркоўваць кожны пункт у дэталях, бо я ўпэўнены, што вы з гэтым добра знаёмыя і карыстаецеся ў паўсядзённай працы. Але калі раптам няма, то я рэкамендую прыпыніць чытанне дадзенага артыкула і як мага хутчэй папоўніць дадзены прабел.
Каштоўнасць для інфраструктуры аўтаматызацыі
І тут вы можаце задаць слушнае пытанне: «Навошта ён нам распавядае пра Git? Усё гэта ведаюць і выкарыстоўваюць як для кода распрацоўкі, так і для кода аўта-тэстаў». Вы будзеце абсалютна правы, але ў гэтым артыкуле мы гаворым аб інфраструктуры і дадзеная секцыя гуляе ролю прэв'ю для секцыі 7: "Інфраструктура як код (IaC)". Для нас гэта азначае, што ўся інфраструктура, у тым ліку тэставую, апісваецца ў выглядзе кода, адпаведна мы да яе таксама можам ужыць сістэмы версіявання і атрымаць аналагічныя перавагі як для кода распрацоўкі і аўтаматызацыі.
Мы разгледзім IaC больш дэталёва на кроку 7, але нават зараз можна пачаць выкарыстоўваць Git лакальна, стварыўшы лакальны рэпазітар. Агульная карціна будзе пашырана, калі мы дадамо да інфраструктуры выдалены рэпазітар.
Ілюстрацыя бягучага стану інфраструктуры
Спасылкі для вывучэння
Аналагічныя інструменты
3. Кантэйнерызацыя (Docker)
Кароткае апісанне тэхналогіі
Для дэманстрацыі таго, як кантэйнерызацыі памяняла правілы гульні, давайце адправімся на некалькі дзесяцігоддзяў у мінулае. У тыя часы людзі набывалі і выкарыстоўвалі серверныя машыны для запуску прыкладанняў. Але ў большасці выпадкаў неабходныя неабходныя рэсурсы для запуску не былі вядомы загадзя. У выніку чаго кампаніі марнавалі грошы на куплю дарагіх магутных сервераў, але частка гэтых магутнасцяў не была поўнасцю ўтылізавана.
Наступным этапам эвалюцыі сталі віртуальныя машыны (VM), якія вырашылі праблему марнавання сродкаў на невыкарыстоўваныя рэсурсы. Гэтая тэхналогія дазволіла запускаць прыкладанні незалежна сябар ад сябра ўсярэдзіне аднаго сервера, вылучаючы цалкам ізаляваную прастору. Але, нажаль, любая тэхналогія мае свае недахопы. Запуск VM патрабуе паўнавартаснай аперацыйнай сістэмы, якая спажывае CPU, RAM, сховішча і, у залежнасці ад OS, трэба ўлічваць выдаткі на ліцэнзію. Гэтыя фактары ўплываюць на хуткасць загрузкі і ўскладняюць пераноснасць.
І вось мы падышлі да кантэйнерызацыі. І зноў дадзеная тэхналогія вырашыла папярэднюю праблему, бо кантэйнеры не выкарыстоўваюць паўнавартасную OS, што дазваляе вызваліць вялікую колькасць рэсурсаў і дае хуткае і гнуткае рашэнне для пераноснасці.
Вядома, тэхналогія кантэйнерызацыі не з'яўляецца нечым новым і ўпершыню была прадстаўлена ў канцы 70-х. У тыя часы праводзілася шмат даследаванняў, напрацовак і спроб. Але менавіта Docker адаптаваў гэтую тэхналогію і зрабіў яе даступнай для мас. У наш час, калі мы гаворым аб кантэйнерах, у большасці выпадкаў мы маем на ўвазе Docker. Калі мы гаворым пра Docker-кантэйнеры, мы маем на ўвазе Linux-кантэйнеры. Мы можам выкарыстоўваць Windows і macOS-сістэмы для запуску кантэйнераў, але важна разумець, што ў такім разе з'яўляецца дадатковая праслойка. Напрыклад, Docker на Mac неўзаметку запускае кантэйнеры ўсярэдзіне легкаважнай Linux VM. Мы яшчэ вернемся да гэтай тэмы, калі будзем абмяркоўваць запуск Android-эмулятараў усярэдзіне кантэйнераў, так так тут з'яўляецца вельмі важны нюанс, які неабходна разабраць больш падрабязна.
Каштоўнасць для інфраструктуры аўтаматызацыі
Мы высветлілі, што кантэйнерызацыя і Docker - гэта крута. Давайце паглядзім на гэта ў кантэксце аўтаматызацыі, бо кожны інструмент або тэхналогія павінны вырашаць якую-небудзь праблему. Абазначым відавочныя праблемы аўтаматызацыі тэставання ў кантэксце UI-тэстаў:
- мноства залежнасцяў пры ўсталёўцы Selenium і асабліва Appium;
- праблемы сумяшчальнасці паміж версіямі браўзэраў, сімулятараў і драйвераў;
- адсутнасць ізаляванай прасторы для браўзэраў/сімулятараў, што асабліва крытычна для раўналежнага запуску;
- цяжка кіраваць і падтрымліваць, калі неабходна запусціць 10, 50, 100 ці нават 1000 браўзэраў адначасова.
Але паколькі Selenium з'яўляецца самай папулярнай прыладай аўтаматызацыі, а Docker – самай папулярнай прыладай кантэйнерызацыі, то ні для каго не павінна быць неспадзеўкай, што хтосьці паспрабаваў іх аб'яднаць, каб атрымаць магутную прыладу для рашэння вышэйзгаданых праблем. Разгледзім такія рашэнні больш падрабязна.
Selenium grid in docker
Гэты інструмент з'яўляецца самым папулярным у свеце Selenium для запуску некалькіх браўзэраў на некалькіх машынах і кіраванне імі з цэнтральнага вузла. Для запуску неабходна зарэгістраваць прынамсі 2 часткі: Hub і Node(s). Hub - гэта цэнтральны вузел, які атрымлівае ўсе запыты ад тэстаў і размяркоўвае іх па адпаведных Nodes. Для кожнага Node мы можам наладзіць пэўную канфігурацыю, напрыклад, паказаўшы патрэбны браўзэр і яго версію. Аднак нам усё яшчэ неабходна самім паклапаціцца аб сумяшчальных драйверах для браўзэраў і ўсталяваць іх на патрэбныя Nodes. Па гэтым чынніку Selenium grid не выкарыстоўваецца ў чыстым выглядзе, за выключэннем тых выпадкаў, калі нам трэба працаваць з браўзэрамі, якія нельга ўсталяваць на Linux OS. Для ўсіх астатніх выпадкаў значна гнуткім і правільным рашэннем будзе выкарыстанне Docker-вобразаў для запуску Selenium grid Hub і Nodes. Такі падыход моцна спрашчае кіраванне вузламі, бо мы можам абраць патрэбную нам выяву з ужо ўсталяванымі сумяшчальнымі версіямі браўзэраў і драйвераў.
Нягледзячы на негатыўныя водгукі аб стабільнасці працы, асабліва пры запуску вялікай колькасці Nodes паралельна, Selenium grid усё яшчэ застаецца самай папулярнай прыладай для раўналежнага запуску Selenium-тэстаў. Важна адзначыць, што ў open-source увесь час з'яўляюцца розныя дапрацоўкі і мадыфікацыі дадзенай прылады, якія дужаюцца з рознымі вузкімі месцамі.
Selenoid for Web
Гэты інструмент з'яўляецца прарывам у свеце Selenium, так як ён працуе адразу са скрынкі і зрабіў жыццё многіх інжынераў па аўтаматызацыі значна прасцей. Першым чынам, гэта не чарговая мадыфікацыя Selenium grid. Замест гэтага распрацоўнікі стварылі абсалютна новую версію Selenium Hub на мове Golang, што ў звязку з легкаважнымі Docker-вобразамі для розных браўзэраў дало штуршок у развіцці аўтаматызацыі тэсціравання. Больш таго, у выпадку Selenium Grid мы павінны вызначыць усе патрабаваныя браўзэры і іх версіі загадзя, што не з'яўляецца праблемай, калі праца ідзе толькі з нейкім адным браўзэрам. Але калі гаворка ідзе аб некалькіх падтрымліваемых браўзэрах, то Selenoid гэта рашэнне нумар адзін, дзякуючы функцыі 'браўзэр па патрабаванні'. Усё, што ад нас патрабуецца, гэта загадзя выгрузіць патрэбныя выявы з браўзэрамі і абнавіць файл канфігурацыі, з якім узаемадзейнічае Selenoid. Пасля таго як Selenoid атрымае запыт ад тэстаў, ён аўтаматычна запусціць патрэбны кантэйнер з патрэбным браўзэрам. Калі тэст завершыцца, Selenoid адставіць кантэйнер, тым самым вызваліўшы рэсурсы для наступных запытаў. Такі падыход цалкам ухіляе вядомую праблему 'дэградацыі вузлоў', што мы часта сустракаем у Selenium grid.
Але, нажаль, Selenoid усё яшчэ не срэбная куля. Мы атрымалі функцыю 'браўзэр па патрабаванні', але функцыя 'рэсурсы па патрабаванні' ўсё яшчэ не даступная. Для выкарыстання Selenoid мы павінны разгарнуць яго на фізічным жалезе ці на VM, што азначае, што мы павінны загадзя ведаць, колькі рэсурсаў неабходна вылучыць. Я мяркую, гэта не праблема для маленькіх праектаў, якія запускаюць 10, 20 ці нават 30 браўзэраў раўналежна. Але што, калі нам трэба 100, 500, 1000 і больш? Не мае ніякага сэнсу падтрымліваць і плаціць за такую колькасць рэсурсаў увесь час. У секцыі 5 і 6 дадзенага артыкула мы абмяркуем рашэнні, якія дазваляюць маштабавацца, тым самым значна змяншаючы выдаткі кампаніі.
Selenoid for Android
Пасля поспеху Selenoid у якасці інструмента для web-аўтаматызацыі, людзі хацелі атрымаць нешта падобнае для Android. І гэта адбылося - Selenoid быў выпушчаны з падтрымкай Android. З высокаўзроўневага карыстацкага пункта гледжання прынцып працы аналагічны web-аўтаматызацыі. Адзінае адрозненне складаецца ў тым, што замест кантэйнераў з браўзэрамі Selenoid запускае кантэйнеры з Android-эмулятарамі. На мой погляд, на сённяшні момант гэта самая магутная бясплатная прылада для запуску Android-тэстаў раўналежна.
Мне б вельмі не жадалася казаць аб негатыўных баках дадзенай прылады, бо ён сапраўды мне вельмі падабаецца. Але ўсё ж тут прысутнічаюць тыя ж недахопы, якія адносяцца і да web-аўтаматызацыі, звязаныя з маштабаваннем. У дадатак да гэтага трэба расказаць пра яшчэ адно абмежаванне, якое можа стаць нечаканасцю, калі мы наладжваем інструмент упершыню. Для запуску Android-вобразаў нам неабходна фізічная машына або VM з nested virtualisation – падтрымкай. У практычным кіраўніцтве я дэманструю, як гэта актываваць на Linux VM. Аднак калі вы з'яўляецеся macOS карыстачом і жадаеце разгарнуць Selenoid лакальна, то для запуску Android-тэстаў гэта будзе немагчыма. Але вы заўсёды можаце запусціць Linux VM лакальна з наладжанай 'nested virtualisation' і разгарнуць Selenoid усярэдзіне.
Ілюстрацыя бягучага стану інфраструктуры
У кантэксце гэтага артыкула мы дадамо 2 інструменты для ілюстрацыі інфраструктуры. Гэта Selenium grid для web-тэстаў і Selenoid для Android-тэстаў. У кіраўніцтве на GitHub я таксама пакажу, як выкарыстоўваць Selenoid для запуску web-тэстаў.
Спасылкі для вывучэння
Аналагічныя інструменты
- Існуюць іншыя прылады кантэйнерызацыі, але Docker - самы папулярны. Калі вы жадаеце паспрабаваць нешта яшчэ, то ўлічыце, што тыя прылады, якія мы разгледзелі для раўналежнага запуску Selenium-тэстаў, не будуць працаваць са скрынкі.
- Як ужо было сказанае, існуе шмат мадыфікацый Selenium grid, напрыклад,.
4. CI / CD
Кароткае апісанне тэхналогіі
Практыка бесперапыннай інтэграцыі даволі папулярная ў распрацоўцы і стаіць у адным шэрагу з сістэмамі кантролю версій. Нягледзячы на гэта, я адчуваю, што існуе блытаніна ў тэрміналогіі. У гэтым параграфе я б хацеў апісаць 3 мадыфікацыі дадзенай тэхналогіі з майго пункту гледжання. У інтэрнэце вы зможаце знайсці шмат артыкулаў з рознымі інтэрпрэтацыямі, і гэта абсалютна нармальна, калі ваша меркаванне будзе адрознівацца. Самае галоўнае, каб вы былі на адной хвалі з вашымі калегамі.
Такім чынам, існуюць 3 тэрміна: CI – Continuous Integration (бесперапынная інтэграцыя), CD – Continuous Delivery (бесперапынная пастаўка) і зноў CD – Continuous Deployment (бесперапыннае разгортванне). (Далей я буду выкарыстоўваць гэтыя тэрміны на англійскай мове). Кожная мадыфікацыя дадае некалькі дадатковых этапаў да вашага канвеера распрацоўкі. Але слова бесперапынны (бесперапынная) з'яўляецца самым галоўным. У гэтым кантэксце мы маем на ўвазе нешта, што адбываецца ад пачатку і да канца, без перапыненняў ці ручнога ўздзеяння. Давайце паглядзім на CI & CD і CD у дадзеным кантэксце.
- Continuous Integration - гэта зыходны крок эвалюцыі. Пасля адпраўкі новага кода на сервер, мы чакаем атрымаць хуткую зваротную сувязь, што з нашымі зменамі ўсё ў парадку. Звычайна CI уключае запуск прылад статычнага аналізу кода і модульныя/унутраныя API тэсты Гэта дазваляе атрымліваць інфармацыю аб нашым кодзе ўжо некалькі секунд/хвілін праз.
- бесперапынная пастаўка з'яўляецца больш прасунутым крокам, на якім мы запускаем інтэграцыйныя/UI-тэсты. Аднак на дадзеным этапе мы не атрымліваем вынікі гэтак жа хутка, як у выпадку з CI. Па-першае, гэтыя тыпы тэстаў патрабуе больш часу для праходжання. Па-другое, перад запускам мы павінны разгарнуць нашы змены на test/staging - асяроддзі. Больш за тое, калі мы гаворым аб мабільнай распрацоўцы, то з'яўляецца дадатковы этап для стварэння зборкі нашага прыкладання.
- Бесперапыннае разгортванне мяркуе, што мы аўтаматычна выпускаем (release) нашы змены на production, калі ўсе прыёмачныя тэсты былі пройдзены на папярэдніх этапах. У дадатак да гэтага пасля этапу release можна наладзіць розныя этапы, такія як запуск smoke - тэстаў на production і збор цікавых метрык. Continuous Deployment магчыма толькі пры добрым пакрыцці аўтаматызаванымі тэстамі. Калі патрабуюцца нейкія ручныя ўмяшанні, у тым ліку і тэсціраванне, то гэта больш не Бесперапынны (бесперапыннае). Тады мы можам казаць, што наш канвеер адпавядае толькі практыцы Continuous Delivery.
Каштоўнасць для інфраструктуры аўтаматызацыі
У гэтым раздзеле я павінен удакладніць, што, калі мы гаворым пра end-to-end UI-тэсты, гэта мае на ўвазе, што мы павінны разгортваць нашы змены і звязаныя сэрвісы на тэставых асяроддзях. Continuous Integration - працэс не прымяняльны для дадзенай задачы і мы павінны паклапаціцца аб укараненні як мінімум Continuous Deliver практык. Continuous Deployment таксама мае сэнс у кантэксце UI-тэстаў, калі мы збіраемся запускаць іх на production.
І перад тым як мы паглядзім на ілюстрацыю змены архітэктуры, я хачу сказаць некалькі слоў аб GitLab CI. У адрозненне ад іншых CI/CD-інструментаў, GitLab дае выдалены рэпазітар і шмат іншых дадатковых функцый. Такім чынам, GitLab - гэта больш чым CI. Ён уключае са скрынкі кіраванне зыходным кодам, Agile кіраванне, CI/CD pipelines, інструменты лагіравання і зборы метрык. Архітэктура GitLab складаецца з Gitlab CI/CD і GitLab Runner. Прыводжу кароткае апісанне з афіцыйна сайта:
Gitlab CI/CD з'яўляецца вэб-прыкладаннем з API, што гандлёвыя паслугі яго сістэм у database, manages projects/builds and provides user interface. GitLab Runner is application which processes builds. Гэта можа быць адпрацавана separately і працы з GitLab CI/CD праз API. Для выпрабаванняў, якія вы патрабуеце Gitlab instance and Runner.
Ілюстрацыя бягучага стану інфраструктуры
Спасылкі для вывучэння
Аналагічныя інструменты
- І многія іншыя
5. Воблачна платформы
Кароткае апісанне тэхналогіі
У гэтым раздзеле мы пагаворым аб папулярным трэндзе, які называецца "публічныя аблокі". Нягледзячы на вялікую карысць, якую даюць апісаныя вышэй тэхналогіі віртуалізацыі і кантэйнерызацыі, нам усё яшчэ неабходны вылічальныя рэсурсы. Кампаніі набываюць дарагія серверы або арандуюць дата-цэнтры, але ў такім выпадку неабходна зрабіць разлікі (часам нерэалістычныя) таго, як шмат рэсурсаў нам спатрэбіцца, ці будзем мы іх выкарыстоўваць 24/7 і для якіх мэт. Напрыклад, для production патрабуецца які працуе кругласутачна сервер, але ці патрэбныя нам аналагічныя рэсурсы для тэставання ў непрацоўны час? Гэта таксама залежыць ад тыпу выкананага тэсціравання. Прыкладам могуць быць нагрузачныя/стрэсавыя тэсты, якія мы плануем праганяць у непрацоўныя гадзіны, каб атрымаць вынікі на наступны дзень. Але, вызначана, кругласутачная даступнасць сервераў не патрабуецца для end-to-end аўта-тэстаў і асабліва для асяроддзяў ручнога тэставання. Для такіх сітуацый было б добра атрымліваць столькі рэсурсаў, колькі неабходна па патрабаванні, выкарыстоўваць іх і спыняць плаціць, калі яны больш не патрэбны. Больш за тое, было б выдатна атрымліваць іх маментальна, зрабіўшы некалькі клікаў мышкай або запусціўшы пару скрыптоў. Для гэтага і выкарыстоўваюцца публічныя аблокі. Давайце паглядзім на вызначэнне:
«Памянічны cloud is defined as computing services offered by third-party providers over the public Internet, making them available to anyone who wants to use or purchase them. Яны могуць быць здольныя або пазбаўленыя патрэбы, атрымліваць карыстачоў, якія патрабуюць толькі для выкарыстання для CPU акцый, гігіены, або бандыту яны consume ».
Існуе меркаванне, што публічныя аблокі - гэта дорага. Але іх ключавая ідэя - памяншэнне выдаткаў кампаніі. Як было згадана раней, публічныя аблокі дазваляюць атрымаць рэсурсы па патрабаванні і плаціць толькі за час іх выкарыстання. Таксама, часам мы забываемся, што супрацоўнікі атрымліваюць заробак, а спецыялісты таксама з'яўляюцца дарагім рэсурсам. Неабходна ўлічваць, што публічныя аблокі значна палягчаюць падтрымку інфраструктуры, што дазваляе інжынерам сфакусавацца на важнейшых задачах.
Каштоўнасць для інфраструктуры аўтаматызацыі
Якія канкрэтна рэсурсы нам неабходныя для end-to-end UI-тэстаў? У асноўным гэта віртуальныя машыны або кластары (мы пагаворым аб Kubernetes у наступнай секцыі) для запуску браўзэраў і эмулятараў. Чым больш браўзэраў і эмулятараў мы жадаем запусціць адначасова, тым больш CPU і памяці патрабуецца і тым больш грошай нам прыйдзецца за гэта заплаціць. Такім чынам, публічныя аблокі ў кантэксце аўтаматызацыі тэставання дазваляюць нам запускаць вялікі лік (100, 200, 1000 …) браўзэраў/эмулятараў па патрабаванні, атрымліваць вынікі тэставання як мага хутчэй і пераставаць плаціць за такія вар'яцка рэсурсазатратныя магутнасці.
Самымі папулярнымі хмарнымі правайдэрамі з'яўляюцца Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). У практычным кіраўніцтве прадстаўлены прыклады выкарыстання GCP, але ў цэлым усё роўна, што менавіта вы будзеце выкарыстоўваць для задач аўтаматызацыі. Усе яны падаюць прыкладна аднолькавы функцыянал. Звычайна для выбару правайдэра кіраўніцтва факусуюць на ўсёй інфраструктуры кампаніі і бізнес-патрабаваннях, што за рамкамі дадзенага артыкула. Для інжынераў па аўтаматызацыі будзе цікавей параўнаць выкарыстанне хмарных правайдэраў з выкарыстаннем хмарных платформаў канкрэтна для мэт тэставання, такіх як Sauce Labs, BrowserStack, BitBar і гэтак далей. Дык давай тыя ж зробім гэта! На мой погляд, Sauce Labs з'яўляецца самай вядомай фермай хмарнага тэсціравання, таму я і ўзяў яе для параўнання.
GCP супраць Sauce Labs для мэт аўтаматызацыі:
Уявім, што нам трэба прагнаць адначасова 8 web-тэстаў і 8 Android-тэстаў. Для гэтага мы будзем выкарыстоўваць GCP і запусцім 2 віртуальныя машыны з Selenoid. На першай мы паднімем 8 кантэйнераў з браўзэрамі. На другі - 8 кантэйнераў з эмулятарамі. Давайце зірнем на кошты:
Для запуску аднаго кантэйнера з Chrome, нам спатрэбіцца n1-standard-1 машына. У выпадку з Android гэта будзе n1-standard-4 для аднаго эмулятара. Насамрэч больш гнуткі і танны спосаб – гэта заданне пэўных карыстацкіх значэнняў для CPU/Memory, але ў дадзены момант для параўнання з Sauce Labs гэта не прынцыпова.
А вось тарыфы на выкарыстанне Sauce Labs:
Я мяркую, вы ўжо заўважылі розніцу, але ўсё ж прывяду табліцу з разлікамі для нашай задачы:
Required resources
Штомесяц
працоўны час(8 гадзін - 8 гадзін)
працоўны час+ Preemptible
GCP for Web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 days * 12h * 0.38 = 104.88$
23 days * 12h * 0.08 = 22.08$
Sauce Labs for Web
Virtual Cloud8 parallel tests
$1.559
-
-
GCP for Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 days * 12h * 1.52 = 419.52$
23 days * 12h * 0.32 = 88.32$
Sauce Labs for Android
Real Device Cloud 8 parallel tests
$1.999
-
-
Як відаць, розніца ў кошце велізарная, асабліва калі запускаць тэсты толькі ў працоўны дванаццацігадзінны прамежак. Але можна яшчэ мацней скараціць выдаткі, калі выкарыстоўваць preemptible машыны. Што ж гэта такое?
У амбіцыйнай VM з'яўляецца instance, што вы можаце стварыць і выконваць у сабе цэлую суму, што неадкладна. However, Compute Engine мае тэрмiнат (preempt) гэтыя instances if it requires access to thos resources for other tasks. Preemptible instances are excess Compute Engine capacity, з іх існуючымі variations with usage.
Калі ў вас мажлівае ўяўленне і можа прытрымлівацца магчымых зыходных заняпадаў, то няздатныя мерапрыемствы могуць аднавіць свае тэхналагічныя стандарты. Для example, batch processing jobs можа выконваць патрэбныя ўмовы. Калі некаторыя мерапрыемствы вызначаюць падчас працэсу, трэніроўкі робяць, а не цалкам задаволены. Preemptible instances kompletne vaše batch processing tasks bez placení additional workload on your existing instances and with requiring you to all full price for additional normal instances.
І гэта ўсё яшчэ не канец! У сапраўднасці я ўпэўнены, што ніхто не запускае тэсты па 12 гадзін без перапынку. І калі гэта так, то вы можаце аўтаматычна запускаць і спыняць віртуальныя машыны, калі яны не патрэбны. Рэальны час выкарыстання можа знізіцца да 6 гадзін за суткі. Тады аплата ў кантэксце нашай задачы паменшыцца ажно да 11$ у месяц за 8 браўзэраў. Няўжо гэта не выдатна? Але з preemptible машынамі мы павінны быць асцярожныя і гатовыя да перапынення і нестабільнай працы, хоць гэтыя сітуацыі могуць быць прадугледжаны і апрацаваны праграмна. Яно таго вартае!
Але ні ў якім разе я не кажу "ніколі не выкарыстоўвайце хмарныя тэставыя фермы". Яны маюць шэраг пераваг. Першым чынам гэта не проста віртуальная машына, а паўнавартаснае рашэнне для аўтаматызацыі тэставання з наборам функцыяналу са скрынкі: выдалены доступ, логі, скрыншоты, відэазапіс, розныя браўзэры і фізічныя мабільныя прылады. У шматлікіх сітуацыях гэта можа быць незаменнай шыкоўнай альтэрнатывай. Асабліва тэставыя платформы карысныя для IOS-аўтаматызацыі, калі публічныя аблокі могуць прапанаваць толькі Linux/Windows-сістэмы. Але размова пра IOS будзе ў наступных артыкулах. Я рэкамендую заўсёды глядзець па сітуацыі і адштурхвацца ад задач: у нейкіх танней і больш эфектыўна выкарыстоўваць публічныя аблокі, а ў нейкіх тэставыя платформы вызначана каштуюць патрачаных грошай.
Ілюстрацыя бягучага стану інфраструктуры
Спасылкі для вывучэння
Аналагічныя інструменты:
6. Аркестрацыя
Кароткае апісанне тэхналогіі
У мяне добрыя навіны - мы амаль дасягнулі канца артыкула! На дадзены момант наша інфраструктура аўтаматызацыі складаецца з web і Android-тэстаў, якія мы запускаем праз GitLab CI паралельна, выкарыстоўваючы прылады з падтрымкай Docker: Selenium grid і Selenoid. Больш за тое, мы выкарыстоўваем створаныя праз GCP віртуальныя машыны для ўзняцця ў іх кантэйнераў з браўзэрамі і эмулятарамі. Для памяншэння выдаткаў мы запускаем гэтым віртуальныя машыны толькі па патрабаванні і спыняем, калі тэставанне не праводзіцца. Ці існуе нешта яшчэ, што можа палепшыць нашу інфраструктуру? Адказ - так! Сустракаем Kubernetes (K8s)!
Для пачатку разгледзім, як словы аркестрацыя, кластар і Kubernetes звязаны паміж сабой. На высокім узроўні аркестрацыя - гэта сістэма, якая разгортвае і кіруе прыкладаннямі. Для аўтаматызацыі тэставання такімі кантэйнерызуемымі (containerised) прыкладаннямі з'яўляюцца Selenium grid і Selenoid. Docker і K8s дапаўняюць адзін аднаго. Першы выкарыстоўваецца для разгортвання прыкладанняў, другі - для аркестрацыі. У сваю чаргу K8s з'яўляецца кластарам. Задача кластара выкарыстоўваць VMs у якасці Nodes, што дазваляе ўсталёўваць розны функцыянал, праграмы і сэрвісы ў рамках аднаго сервера (кластара). Калі які або з Node ўпадзе, то падхопяцца іншыя Nodes, што забяспечвае нашаму з дадаткам бесперабойную працу. У дадатак да гэтага K8s мае важную функцыянальнасць, злучаную з маштабаваннем (scaling), дзякуючы чаму мы аўтаматычна атрымліваем аптымальную колькасць рэсурсаў, засноўваючыся на нагрузцы і ўсталяваных абмежаваннях.
Па праўдзе кажучы, ручное разгортванне Kubernetes з нуля з'яўляецца зусім нетрывіяльнай задачай. Я пакіну спасылку на вядомае практычнае кіраўніцтва "Kubernetes The Hard Way", і, калі вам цікава, вы можаце папрактыкавацца. Але, на шчасце, існуюць альтэрнатыўныя спосабы і інструменты. Самы лёгкі з іх - выкарыстоўваць Google Kubernetes Engine (GKE) у GCP, што дазволіць атрымаць гатовы кластар пасля некалькіх клікаў. Для пачатку вывучэння я рэкамендую выкарыстоўваць менавіта гэты падыход, бо ён дазволіць вам сфакусавацца на вывучэнні таго, як выкарыстоўваць K8s для сваіх задач замест даследавання таго, як унутраныя кампаненты павінны быць паміж сабой інтэграваныя.
Каштоўнасць для інфраструктуры аўтаматызацыі
Разгледзім некалькі значных функцый, якія падае K8s:
- разгортванні прыкладання: выкарыстанне multi-nodes кластара, замест VMs;
- дынамічнае маштабаванне: памяншае выдаткі на рэсурсы, якія выкарыстоўваюцца толькі па патрабаванні;
- самааднаўленне (Self-healing): аўтаматычнае аднаўленне pods (у выніку чаго аднаўляюцца і кантэйнеры);
- выкатка абнаўлення і адкатаў змен без прастою: абнаўленне прылад, браўзэраў і эмулятараў не перарывае працу бягучых карыстачоў
Але K8s усё яшчэ не срэбная куля. Для разумення ўсіх пераваг і абмежаванняў у кантэксце разгляданых намі прылад (Selenium grid, Selenoid) коратка абмяркуем будынак K8s. Cluster змяшчае два тыпу Nodes: Master Nodes і Workers Nodes. Master Nodes адказваюць за кіраванне, разгортванне і scheduling decisions. Workers nodes - гэта тое, дзе прыкладанні запушчаны. Nodes таксама ўтрымоўваюць асяроддзе запуску кантэйнераў. У нашым выпадку гэта Docker, які адказвае за аперацыі, злучаныя з кантэйнерамі. Але ёсць і альтэрнатыўныя рашэнні, напрыклад. Важна разумець, што маштабаванне або самааднаўленне не адносіцца да кантэйнераў напрамую. Гэта рэалізуецца праз даданне/памяншэнне ліку pods, якія ў сваю чаргу ўтрымоўваюць кантэйнеры (звычайна XNUMX container на pod, але ў залежнасці ад задачы можа быць і больш). Высокаўзроўневая іерархія ўяўляе сабою worker nodes, усярэдзіне якіх знаходзяцца pods, усярэдзіне якіх паднятыя кантэйнеры.
Функцыя маштабавання з'яўляецца ключавой і можа быць ужытая як да nodes усярэдзіне cluster node-pool, так і да pods усярэдзіне node. Існуе 2 тыпу маштабавання, якія адносяцца як да nodes, так і pods. Першы тып - гарызантальны - маштабаванне адбываецца за кошт павелічэння колькасці nodes/pods. Такі тып зяўляецца больш пераважнай. Другі тып, адпаведна, вертыкальны. Маштабаванне ажыццяўляецца за рахунак павелічэння памераў nodes/pods, а не іх колькасці.
Цяпер разгледзім нашыя інструменты ў кантэксце вышэйзгаданых тэрмінаў.
Selenium grid
Як было згадана раней, Selenium grid – вельмі папулярная прылада, і не неспадзеўка, што ён быў кантэйнерызаваны (containerised). Такім чынам, не выклікае здзіўленне, што Selenium grid можна разгарнуць у K8s. Прыклад таго, як гэта зрабіць, можна знайсці ў афіцыйным K8s-рэпазітары. Як звычайна, прыкладваю спасылкі ў канцы секцыі. У дадатак да гэтага ў практычным кіраўніцтве паказана, як гэта зрабіць чаргу Terraform. Таксама ёсць інструкцыя, як маштабаваць колькасць pods, якія змяшчаюць кантэйнеры з браўзэрамі. Але функцыя аўтаматычнага маштабавання ў кантэксце K8s усё яшчэ не да канца відавочная задача. Калі я пачынаў вывучэнне, я не знайшоў ніякага практычнага кіраўніцтва ці рэкамендацый. Пасля некалькіх даследаванняў і эксперыментаў пры падтрымцы DevOps-каманды мы абралі падыход узняцця кантэйнераў з патрэбнымі браўзэрамі ўсярэдзіне аднаго pod, які знаходзіцца ўсярэдзіне аднаго worker node. Такі спосаб дазваляе нам ужыць стратэгію гарызантальнага маштабавання nodes за рахунак павелічэння іх ліку. Я спадзяюся, што ў будучыні сітуацыя зменіцца, і мы ўбачым усё больш і больш апісанняў лепшых падыходаў і гатовых рашэнняў, асабліва пасля выпуску Selenium grid 4 са змененай унутранай архітэктурай.
Селеноід:
У цяперашні час разгортванне Selenoid у K8s з'яўляецца самым вялікім расчараваннем. Яны не сумяшчальныя. Тэарэтычна мы можам падняць Selenoid-кантэйнер ўнутры pod, але калі Selenoid пачне запускаць кантэйнеры з браўзэрамі, яны ўсё яшчэ будуць знаходзіцца ўнутры гэтага ж pod. Гэта робіць scaling немагчымым і, як вынік, праца Selenoid ўнутры кластара не будзе адрознівацца ад працы ўнутры віртуальнай машыны. Канец гісторыі.
месяц:
Ведаючы гэта вузкае месца пры працы з Selenoid, распрацоўшчыкі выпусцілі больш магутны інструмент, які назвалі Moon. Гэты інструмент быў першапачаткова задуманы для працы з Kubernetes і, як вынік, можна і трэба выкарыстоўваць функцыю аўтамаштабавання. Больш за тое, я б сказаў, што ў сапраўдны момант гэта адзіны інструмент у свеце Selenium, які са скрынкі мае native K8s cluster-падтрымку (ужо няма, гл. наступную прыладу ). Ключавой асаблівасцю Moon, якая забяспечвае дадзеную падтрымку, з'яўляецца:
Completely stateless. Selenoid stores in memory information currently running browser sessions. Калі для некаторых прычын яе працэсы пашкоджання — усе ўсе зыходныя мерапрыемствы застаюцца. Месяц, безумоўна, не мае нацыянальных дзяржаў і можа быць пераўтвораны ў межах цэнтраў data. Браузер sessions remain alive even if one or more replicas go down.
Такім чынам, Moon шыкоўнае рашэнне, але з адной праблемай, ен не бясплатны. Кошт залежыць ад колькасці сесій. Бясплатна можна запусціць толькі 0-4 сесіі, што не асабліва карысна. Але, пачынаючы ўжо з пятай сесіі, давядзецца заплаціць па 5$ за кожную. Сітуацыя можа адрознівацца ад кампаніі да кампаніі, але ў нашым выпадку выкарыстанне Moon бессэнсоўна. Як я апісваў вышэй, мы можам запусціць VMs з Selenium Grid па патрабаванні або павялічыць колькасць Nodes у кластары. Прыблізна на адзін pipeline мы запускаем 500 браўзэраў і спыняем усе рэсурсы пасля завяршэння тэстаў. Калі б мы выкарыстоўвалі Moon, нам бы прыйшлося заплаціць дадатковых 500 x 5 = 2500 $ у месяц і не важна, як часта мы запускаем тэсты. І зноў жа, я не кажу "не выкарыстоўвайце Moon". Для вашых задач гэта можа быць незаменным рашэннем, напрыклад, калі ў вас у арганізацыі шмат праектаў/каманд і вам патрэбен велізарны агульны кластар для ўсіх. Як заўсёды, я пакідаю спасылку ў канцы і рэкамендую зрабіць усё неабходныя разлікі ў кантэксце вашай задачы.
Каліста: (Увага! Гэтага няма ў арыгінальным артыкуле і змяшчаецца толькі ў рускім перакладзе)
Як я і сказаў, Selenium – вельмі папулярная прылада, а сфера IT развіваецца вельмі хутка. Пакуль я працаваў над перакладам, у сетцы з'явілася новая шматабяцальная прылада Callisto (прывітанне Cypress і іншым забойцам Selenium). Ён працуе натыўна з K8s і дазваляе запускаць Selenoid-кантэйнеры ў pods, размеркавана па Nodes. Усё працуе адразу са скрынкі, уключаючы аўтамаштабаванне. Фантастыка, але трэба тэсціраваць. Мне ўжо атрымалася разгарнуць дадзеную прыладу і паставіць некалькі эксперыментаў. Але высновы рабіць рана, пасля атрымання вынікаў на доўгай дыстанцыі, магчыма, я зраблю агляд у наступных артыкулах. Пакуль пакідаю толькі спасылкі для самастойных даследаванняў.
Ілюстрацыя бягучага стану інфраструктуры
Спасылкі для вывучэння
Аналагічныя інструменты
7. Інфраструктура як код (IaC)
Кароткае апісанне тэхналогіі
І вось мы падабраліся да апошняй часткі. Як правіла, дадзеная тэхналогія і звязаныя з ёй задачы не ўваходзяць у зону адказнасці інжынераў па аўтаматызацыі. І на гэта ёсць свае прычыны. Па-першае, у многіх арганізацыях інфраструктурныя пытанні знаходзяцца пад кантролем DevOps аддзела і каманды распрацоўкі не асабліва клапоцяцца аб тым, дзякуючы чаму працуе pipeline і якім чынам трэба падтрымліваць усё, што з ім звязана. Па-другое, будзем сумленнымі, практыка "Інфраструктура як код (IaC)" усё яшчэ не прымяняецца ў многіх кампаніях. Але вызначана гэта стала папулярным трэндам і важна імкнуцца быць уцягнутым у злучаныя з гэтым працэсы, падыходы і прылады. Ці, прынамсі, быць у курсе падзей.
Пачнём з матывацыі выкарыстання дадзенага падыходу. Мы ўжо абмеркавалі, што для запуску тэстаў у GitlabCI нам спатрэбяцца прынамсі рэсурсы для запуску Gitlab Runner. А для запуску кантэйнераў з браўзэрамі/эмулятарамі нам трэба зарэзерваваць VM ці кластар. Апроч рэсурсаў для тэставання, нам неабходна значная колькасць магутнасцяў для падтрымання асяроддзяў распрацоўкі, staging, production, што таксама ўключае базы дадзеных, аўтаматычныя расклады, канфігурацыі сеткі, балансавальнік нагрузкі, правы карыстальнікаў і гэтак далей. Ключавая праблема заключаецца ў патрэбных намаганнях для падтрымкі гэтага за ўсё. Ёсць некалькі спосабаў таго, як мы можам уносіць змены і выкочваць абнаўленні. Напрыклад, у кантэксце GCP мы можам выкарыстоўваць UI-кансоль у браўзэры і выконваць усе дзеянні, кліку кнопкі. Альтэрнатыўным спосабам можа быць выкарыстанне API-выклікаў для ўзаемадзеяння з хмарнымі сутнасцямі або ўжыванне ўтыліты каманднай тэрміны gcloud для выканання патрэбных маніпуляцый. Але пры сапраўды вялікай колькасці розных сутнасцяў і інфраструктурных элементаў становіцца цяжка ці нават немагчыма выконваць усе аперацыі ўручную. Больш за тое, усе гэтыя ручныя дзеянні некантралюемыя. Мы не можам адправіць іх на review перад выкананнем, выкарыстоўваць сістэму кантролю версій і хутка адкаціць праўкі, якія прывялі да інцыдэнту. Для рашэння такіх праблем інжынеры стваралі і ствараюць аўтаматычныя bash/shell-скрыпты, што ненашмат лепш папярэдніх спосабаў, бо іх не так ужо і лёгка хутка прачытаць, зразумець, падтрымліваць і мадыфікаваць у працэдурным стылі.
У гэтым артыкуле і практычным кіраўніцтве я выкарыстоўваю 2 інструменты, якія адносяцца да практыкі IaC. Гэта Terraform і Ansible. Некаторыя мяркуюць, што не мае сэнсу выкарыстоўваць іх адначасова, бо іх функцыянал падобны і яны ўзаемазаменныя. Але справа ў тым, што першапачаткова перад імі ставяцца розныя задачы. І факт таго, што гэтыя прылады павінны дапаўняць адзін аднаго, быў пацверджаны на сумеснай прэзентацыі распрацоўшчыкамі, якія прадстаўляюць кампаніі HashiCorp і RedHat. Канцэптуальная розніца заключаецца ў тым, што Terraform - гэта provisioning-інструмент для кіравання самімі серверамі. У той час як Ansible з'яўляецца інструментам кіравання канфігурацыямі, задачай якога з'яўляецца ўстаноўка, настройка і кіраванне софтам на гэтых серверах.
Яшчэ адной ключавой адметнай асаблівасцю дадзеных прылад з'яўляецца стыль напісання кода. У адрозненне ад bash і Ansible, Terraform выкарыстоўваюць дэкларатыўны стыль, заснаваны на апісанні жаданага канчатковага стану, якога неабходна дасягнуць у выніку выкананні. Напрыклад, калі мы збіраемся стварыць 10 VMs і прымяніць змены праз Terraform, то мы атрымаем 10 VMs. Калі ўжыць скрыпт яшчэ раз, нічога не адбудзецца, бо ў нас ужо ёсць 10 VMs, і Terraform ведае пра гэта, паколькі ён захоўвае бягучы стан інфраструктуры ў state-файле. А вось Ansible выкарыстоўвае працэдурны падыход і, калі папытаць яго стварыць 10 VMs, то на першым запуску мы атрымаем 10 VMs, аналагічна з Terraform. Але пасля паўторнага запуску ў нас ужо будзе 20 VMs. У гэтым і заключаецца важнае адрозненне. У працэдурным стылі мы не захоўваем цяперашні стан і проста апісваем паслядоўнасць крокаў, якія павінны быць выкананы. Зразумела, мы можам апрацаваць розныя сітуацыі, дадаць некалькі праверак на існаванне рэсурсаў і бягучы стан, але няма сэнсу марнаваць наш час і прыкладаць намаганні на кантраляванне дадзенай логікі. Да таго ж гэта павялічвае рызыку здзейсніць памылкі.
Абагульніўшы ўсё вышэй сказанае, можна зрабіць выснову, што для provisioning сервераў больш прыдатнай прыладай з'яўляецца Terraform і дэкларатыўная натацыя. А вось працу па кіраванні канфігурацыямі лепш дэлегаваць на Ansible. Разабраўшыся з гэтым, давайце паглядзім на прыклады выкарыстання ў кантэксце аўтаматызацыі.
Каштоўнасць для інфраструктуры аўтаматызацыі
Тут важна разумець толькі тое, што інфраструктура аўтаматызацыі тэсціравання павінна разглядацца як частка ўсёй інфраструктуры кампаніі. А гэта значыць, што ўсе IaC-практыкі павінны быць ужытыя глабальна да рэсурсаў усёй арганізацыі. Хто адказны, залежыць ад вашых працэсаў. DevOps-каманда больш дасведчаная ў дадзеных пытаннях, яны бачаць усю карціну адбывалага. Аднак QA-інжынеры мацней уцягнутыя ў працэс пабудовы аўтаматызацыі і структуру pipeline, што дазваляе ім лепш бачыць усе патрабаваныя змены і магчымасці для паляпшэння. Самы лепшы варыянт - гэта працаваць разам, абменьвацца ведамі і ідэямі для дасягнення чаканага выніку.
Прывяду некалькі прыкладаў выкарыстання Terraform і Ansible у кантэксце аўтаматызацыі тэсціравання і інструментаў, якія мы абмяркоўвалі да гэтага:
1. Апісаць праз Terraform неабходныя характарыстыкі і параметры VMs і кластараў.
2. Усталяваць з дапамогай Ansible неабходныя для тэставання прылады: docker, Selenoid, Selenium Grid і загрузіць патрэбныя версіі браўзэраў/эмулятараў.
3. Апісаць праз Terraform характарыстыкі VM, у якой будзе запушчаны GitLab Runner.
4. Усталяваць з дапамогай Ansible GitLab Runner і неабходныя спадарожныя прылады, задаць наладкі і канфігурацыі.
Ілюстрацыя бягучага стану інфраструктуры
Спасылкі для вывучэння:
Аналагічныя інструменты
Падвядзем вынікі!
Крок
Тэхналогія
інструменты
Каштоўнасць для інфраструктуры аўтаматызацыі
1
Local running
Node.js, Selenium, Appium
- Найбольш папулярныя інструменты для web і mobile
- Падтрымка шматлікіх моў і платформаў (уключаючы Node.js)
2
Version control systems
ісці
- Аналагічныя перавагі з кодам распрацоўкі
3
Containerisation
Docker, Selenium grid, Selenoid (Web, Android)
- Паралельны запуск тэстаў
- Ізаляваныя асяроддзі
- Простае, гнуткае абнаўленне версій
- Дынамічны прыпынак рэсурсаў, якія не выкарыстоўваюцца.
- лёгка наладзіць
4
CI / CD
Gitlab CI
- Тэсты частка канвеера
- Хуткая зваротная сувязь
- Бачнасць для ўсёй кампаніі / каманды
5
хмарныя платформы
Google Cloud Platform
- Рэсурсы па патрабаванні (плацім толькі калі патрэбныя)
- Лёгка кіраваць і абнаўляць
- Бачнасць і кантроль усіх рэсурсаў
6
Аркестроўка
Kubernetes
У кантэксце кантэйнераў з браўзэрамі/эмулятарамі ўнутры pods:
- Маштабаванне / аўтамаштабаванне
- Самааднаўленне
- Абнаўленні і адкаты без перапыненняў
7
Infrastructure as a code (IaC)
Terraform, Ansible
- Аналагічныя перавагі з інфраструктурай распрацоўкі
- Усе перавагі версіявання кода
- Лёгка ўносіць змены і падтрымліваць
- Цалкам аўтаматызавана
Mind map дыяграмы: эвалюцыя інфраструктуры
step1: Local
step2: VCS
step3: Containerisation
step4: CI/CD
step5: Cloud Platforms
step6: Orchestration
step7: IaC
Што далей?
Такім чынам, гэта канец артыкула. Але ў зняволенні я бы жадаў усталяваць з вамі некаторыя дамоўленасці.
З вашага боку
Як было сказана спачатку, я б хацеў, каб артыкул несла практычную карысць і дапамог вам прымяніць атрыманыя веды ў рэальнай працы. Дадаю яшчэ раз.
Але нават пасля гэтага не спыняйцеся, практыкуйцеся, вывучайце адпаведныя спасылкі і кніжкі, даведвайцеся, як гэта працуе ў вас у кампаніі, знаходзіце месцы, якія можна палепшыць і прымайце ў гэтым удзел. Удачы!
З майго боку
З загалоўка бачна, што гэта была толькі першая частка. Нягледзячы на тое, што яна атрымалася даволі вялікай, тут усё яшчэ не раскрыты важныя тэмы. У другой частцы я планую разгледзець інфраструктуру аўтаматызацыі ў кантэксце IOS. З-за абмежаванняў Apple, звязаных з запускамі IOS сімулятараў толькі на macOS сістэмах, наш набор рашэнняў звужаны. Напрыклад, мы пазбаўлены магчымасці выкарыстоўваць Docker для запуску сімулятара або публічных аблокаў для запуску віртуальных машын. Але гэта не значыць, што няма іншых альтэрнатыў. Я пастараюся трымаць вас у курсе перадавых рашэнняў і сучасных інструментаў!
Таксама я не згадаў даволі вялікія тэмы, зьвязаныя з маніторынгам. У частцы 3 я збіраюся разгледзець найболей папулярныя прылады для маніторынгу інфраструктуры, а таксама якія дадзеныя і метрыкі варта прыняць да ўвагі.
І напрыканцы. У будучыні я планую выпусціць відэа курс па пабудове тэставай інфраструктуры і папулярным інструментам. У цяперашні час у інтэрнэце даволі шмат курсаў і лекцый па DevOps, але ўсе матэрыялы прадстаўлены ў кантэксце распрацоўкі, але не аўтаматызацыі тэсціравання. У гэтым пытанні мне вельмі патрэбна зваротная сувязь, ці будзе такі курс цікавы і каштоўны для супольнасці тэсціроўшчыкаў і аўтаматызатараў. Загадзя дзякуй!
Крыніца: habr.com