1-бөлім: Web/Android
ескерту: бұл мақала түпнұсқа мақаланың орыс тіліне аудармасы Дегенмен, орыс тіліне аударғанда мағынасын бұрмалауды болдырмау үшін барлық иллюстрациялар, сілтемелер, дәйексөздер мен терминдер түпнұсқа тілінде сақталған. Сізге бақытты оқу тілеймін!
Қазіргі уақытта DevOps мамандығы IT индустриясында ең сұранысқа ие мамандықтардың бірі болып табылады. Танымал жұмыс іздеу сайттарын ашсаңыз және жалақы бойынша сүзсеңіз, DevOps-қа қатысты жұмыс орындары тізімнің басында тұрғанын көресіз. Дегенмен, бұл негізінен кандидаттың дағдыларының жоғары деңгейін, технологиялар мен құралдарды білуін білдіретін «Аға» лауазымына қатысты екенін түсіну маңызды. Бұл да өндірістің үздіксіз жұмыс істеуіне байланысты жоғары жауапкершілікпен келеді. Дегенмен, біз DevOps дегеннің не екенін ұмыта бастадық. Бастапқыда бұл қандай да бір нақты тұлға немесе бөлім емес еді. Бұл терминнің анықтамаларын іздейтін болсақ, біз көптеген әдемі және дұрыс зат есімдерді табамыз, мысалы, әдістеме, тәжірибе, мәдени философия, ұғымдар тобы және т.б.
Менің мамандығым – сынақ автоматикасының инженері (QA автоматтандыру инженері), бірақ мен оны тек автотесттерді жазумен немесе сынақ құрылымының архитектурасын әзірлеумен байланыстыруға болмайды деп есептеймін. 2020 жылы автоматтандыру инфрақұрылымын білу де маңызды. Бұл сынақтарды жүргізуден бастап барлық мүдделі тараптарға мақсаттарыңызға сәйкес нәтижелерді беруге дейін автоматтандыру процесін өзіңіз ұйымдастыруға мүмкіндік береді. Нәтижесінде, жұмысты орындау үшін DevOps дағдылары қажет. Мұның бәрі жақсы, бірақ, өкінішке орай, мәселе бар (спойлер: бұл мақала осы мәселені жеңілдетуге тырысады). Мәселе мынада, DevOps қиын. Және бұл анық, өйткені компаниялар жасауға оңай нәрсе үшін көп ақша төлемейді... DevOps әлемінде меңгеруді қажет ететін көптеген құралдар, терминдер және тәжірибелер бар. Бұл мансаптың басында әсіресе қиын және жинақталған техникалық тәжірибеге байланысты.
Ақпарат көзі:
Бұл жерде біз кіріспе бөлімімен аяқтап, осы мақаланың мақсатына тоқталамыз.
Бұл мақала не туралы?
Бұл мақалада мен сынақты автоматтандыру инфрақұрылымын құру тәжірибесімен бөлісемін. Интернетте әртүрлі құралдар және оларды пайдалану жолдары туралы көптеген ақпарат көздері бар, бірақ мен оларды тек автоматтандыру контекстінде қарастырғым келеді. Менің ойымша, көптеген автоматика инженерлері сізден басқа ешкім әзірленген сынақтарды өткізбейтін немесе оларға техникалық қызмет көрсету туралы ойламайтын жағдайды жақсы біледі. Нәтижесінде сынақтар ескіреді және оларды жаңартуға уақыт бөлуге тура келеді. Тағы да, мансаптың басында бұл өте қиын міндет болуы мүмкін: қандай құралдар берілген мәселені жоюға көмектесетінін, оларды қалай таңдауға, конфигурациялауға және ұстауға болатынын ақылмен шешу. Кейбір тестерлер көмек үшін DevOps-қа (адамдарға) жүгінеді және шынын айтсақ, бұл әдіс жұмыс істейді. Көптеген жағдайларда бұл жалғыз нұсқа болуы мүмкін, өйткені бізде барлық тәуелділіктерге көріну мүмкіндігі жоқ. Бірақ біз білетіндей, DevOps өте бос емес жігіттер, өйткені олар ұйымға/топқа байланысты бүкіл компанияның инфрақұрылымы, орналастыру, бақылау, микросервис және басқа да осыған ұқсас тапсырмалар туралы ойлауы керек. Әдеттегідей, автоматтандыру басымдық емес. Мұндай жағдайда біз басынан аяғына дейін өз тарапымыздан қолдан келгеннің бәрін жасауға тырысуымыз керек. Бұл тәуелділікті азайтады, жұмыс процесін жылдамдатады, дағдыларымызды жақсартады және болып жатқан жағдайдың үлкен бейнесін көруге мүмкіндік береді.
Мақала ең танымал және танымал құралдарды ұсынады және оларды автоматтандыру инфрақұрылымын кезең-кезеңімен құру үшін қалай пайдалану керектігін көрсетеді. Әрбір топ жеке тәжірибе арқылы тексерілген құралдармен ұсынылған. Бірақ бұл бірдей нәрсені пайдалану керек дегенді білдірмейді. Құралдардың өзі маңызды емес, олар пайда болып, ескіреді. Біздің инженерлік міндетіміз негізгі принциптерді түсіну болып табылады: бұл құралдар тобы бізге не үшін қажет және олардың көмегімен қандай жұмыс мәселелерін шеше аламыз. Сондықтан әр бөлімнің соңында ұйымыңызда қолданылуы мүмкін ұқсас құралдарға сілтемелер қалдырамын.
Бұл мақалада не жоқ
Мақаланың нақты құралдар туралы емес екенін тағы бір рет қайталаймын, сондықтан құжаттамадан және нақты командалардың сипаттамасынан код кірістірулері болмайды. Бірақ әр бөлімнің соңында мен егжей-тегжейлі зерттеу үшін сілтемелер қалдырамын.
Бұл жасалады, себебі:
- бұл материалды әртүрлі көздерден (құжаттар, кітаптар, бейне курстар) табу өте оңай;
- тереңдете бастасақ, осы мақаланың 10, 20, 30 бөлігін (жоспарлар 2-3 болған кезде) жазуға тура келеді;
- Мен сіздің уақытыңызды босқа өткізгім келмейді, өйткені сіз сол мақсаттарға жету үшін басқа құралдарды пайдаланғыңыз келуі мүмкін.
Тәжірибе
Мен бұл материалдың жай ғана оқып, ұмытып кетпей, әрбір оқырманға пайдалы болғанын қалаймын. Кез келген зерттеуде тәжірибе өте маңызды құрамдас болып табылады. Бұл үшін мен дайындалдым. Сіз орындап жатқан пәрмендердің жолдарын ойланбай көшіріп алмауыңызға көз жеткізу үшін үй тапсырмасы да бар.
жоспар
қадам
технология
Құралдар
1
Жергілікті іске қосу (веб/андроид демо сынақтарын дайындаңыз және оны жергілікті түрде іске қосыңыз)
Node.js, Selenium, Appium
2
Нұсқаларды басқару жүйелері
жүру
3
Контейнерлеу
Docker, Selenium торы, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Бұлтты платформалар
Google Cloud Platform
6
Оркестрация
Kubernetes
7
Инфрақұрылым код ретінде (IaC)
Терраформа, Ansible
Әр бөлімнің құрылымы
Баяндаманы анық сақтау үшін әрбір бөлім келесі схемаға сәйкес сипатталады:
- технологияның қысқаша сипаттамасы,
- автоматтандыру инфрақұрылымының құны,
- инфрақұрылымның ағымдағы жағдайын суреттеу,
- оқуға сілтемелер,
- ұқсас құралдар.
1. Сынақтарды жергілікті орындаңыз
Технологияның қысқаша сипаттамасы
Бұл демонстрациялық сынақтарды жергілікті түрде іске қосу және олардың өткенін тексеру үшін дайындық қадамы ғана. Практикалық бөлімде Node.js пайдаланылады, бірақ бағдарламалау тілі мен платформасы да маңызды емес және сіз өз компанияңызда қолданылатындарды пайдалана аласыз.
Дегенмен, автоматтандыру құралдары ретінде мен веб-платформалар үшін Selenium WebDriver және Android платформасы үшін Appium пайдалануды ұсынамын, өйткені келесі қадамдарда біз осы құралдармен арнайы жұмыс істеуге бейімделген Docker кескіндерін қолданамыз. Сонымен қатар, жұмысқа қойылатын талаптарды ескере отырып, бұл құралдар нарықта ең сұранысқа ие.
Сіз байқағаныңыздай, біз тек веб және Android сынақтарын қарастырамыз. Өкінішке орай, iOS - бұл мүлдем басқа оқиға (Apple-ға рахмет). Мен алдағы бөлімдерде IOS-қа қатысты шешімдер мен тәжірибелерді көрсетуді жоспарлап отырмын.
Автоматтандыру инфрақұрылымының мәні
Инфрақұрылым тұрғысынан жергілікті түрде іске қосу ешқандай мән бермейді. Сынақтардың жергілікті браузерлер мен симуляторлардағы жергілікті құрылғыда орындалатынын ғана тексересіз. Бірақ кез келген жағдайда, бұл қажетті бастапқы нүкте.
Инфрақұрылымның қазіргі жағдайының иллюстрациясы
Зерттеуге арналған сілтемелер
Ұқсас құралдар
- Selenium/Appium сынақтарымен бірге өзіңізге ұнайтын кез келген бағдарламалау тілі;
- кез келген сынақтар;
- кез келген сынақ жүгіруші.
2. Нұсқаларды басқару жүйелері (Git)
Технологияның қысқаша сипаттамасы
Нұсқаларды басқару топта да, жеке тұлғада да дамудың өте маңызды бөлігі екенін айтсам, бұл ешкім үшін үлкен аян болмас. Әртүрлі дереккөздерге сүйене отырып, Гит ең танымал өкіл деп айтуға болады. Нұсқаларды басқару жүйесі кодты бөлісу, нұсқаларды сақтау, алдыңғы тармақтарға қалпына келтіру, жоба тарихын бақылау және сақтық көшірмелерді жасау сияқты көптеген артықшылықтарды қамтамасыз етеді. Әр тармақты егжей-тегжейлі талқыламаймыз, өйткені сіз онымен өте жақсы таныссыз және оны күнделікті жұмысыңызда қолданасыз. Бірақ егер кенеттен олай болмаса, мен осы мақаланы оқуды тоқтатып, бұл олқылықты мүмкіндігінше тезірек толтыруды ұсынамын.
Автоматтандыру инфрақұрылымының мәні
Мұнда сіз ақылға қонымды сұрақ қоя аласыз: «Неге ол бізге Гит туралы айтып жатыр? Мұны бәрі біледі және оны әзірлеу коды үшін де, автоматты сынақ коды үшін де пайдаланады. Сіз мүлдем дұрыс боласыз, бірақ бұл мақалада біз инфрақұрылым туралы айтып отырмыз және бұл бөлім 7-бөлімге алдын ала қарау ретінде әрекет етеді: «Инфрақұрылым код ретінде (IaC)». Біз үшін бұл тестілеуді қоса алғанда, барлық инфрақұрылым код түрінде сипатталғанын білдіреді, сондықтан біз оған нұсқалық жүйелерді қолданып, әзірлеу және автоматтандыру коды сияқты артықшылықтарға ие бола аламыз.
IaC-ті 7-қадамда толығырақ қарастырамыз, бірақ қазірдің өзінде жергілікті репозиторий жасау арқылы Git-ті жергілікті түрде пайдалануды бастауға болады. Инфрақұрылымға қашықтағы репозиторийді қосқанда үлкен сурет кеңейеді.
Инфрақұрылымның қазіргі жағдайының иллюстрациясы
Зерттеуге арналған сілтемелер
Ұқсас құралдар
3. Контейнерлеу (Docker)
Технологияның қысқаша сипаттамасы
Контейнерлеу ойын ережелерін қалай өзгерткенін көрсету үшін бірнеше онжылдықтарға оралайық. Ол кезде адамдар қолданбаларды іске қосу үшін серверлік машиналарды сатып алып, пайдаланатын. Бірақ көп жағдайда қажетті іске қосу ресурстары алдын ала белгілі болған жоқ. Нәтижесінде компаниялар қымбат, қуатты серверлерді сатып алуға ақша жұмсады, бірақ бұл мүмкіндіктердің бір бөлігі толығымен пайдаланылмады.
Эволюцияның келесі кезеңі пайдаланылмаған ресурстарға ақша жұмсау мәселесін шешетін виртуалды машиналар (VM) болды. Бұл технология толығымен оқшауланған кеңістікті бөле отырып, бір сервер ішінде қолданбаларды бір-бірінен тәуелсіз іске қосуға мүмкіндік берді. Бірақ, өкінішке орай, кез келген технологияның кемшіліктері бар. VM іске қосу процессорды, жедел жадты, жадты тұтынатын толық операциялық жүйені қажет етеді және операциялық жүйеге байланысты лицензиялық шығындарды ескеру қажет. Бұл факторлар жүктеу жылдамдығына әсер етеді және тасымалдауды қиындатады.
Ал енді контейнерлеуге келдік. Тағы да айта кетейін, бұл технология алдыңғы мәселені шешеді, өйткені контейнерлер толық ОЖ пайдаланбайды, ол ресурстардың үлкен көлемін босатады және тасымалдану үшін жылдам және икемді шешімді ұсынады.
Әрине, контейнерлеу технологиясы жаңалық емес және алғаш рет 70-ші жылдардың соңында енгізілген. Сол күндері көптеген зерттеулер, әзірлемелер, талпыныстар жасалды. Бірақ бұл технологияны бейімдеп, оны көпшілікке оңай қолжетімді еткен Докер болды. Қазіргі уақытта біз контейнерлер туралы айтатын болсақ, көп жағдайда біз Докерді айтамыз. Docker контейнерлері туралы айтқанда, біз Linux контейнерлерін айтамыз. Контейнерлерді іске қосу үшін Windows және macOS жүйелерін пайдалана аламыз, бірақ бұл жағдайда қосымша қабат пайда болатынын түсіну маңызды. Мысалы, Mac жүйесіндегі Docker жеңіл Linux VM ішіндегі контейнерлерді үнсіз іске қосады. Контейнерлердің ішінде Android эмуляторларын іске қосуды талқылағанда біз осы тақырыпқа қайта ораламыз, сондықтан мұнда толығырақ талқылауды қажет ететін өте маңызды нюанс бар.
Автоматтандыру инфрақұрылымының мәні
Біз контейнерлеу және Docker керемет екенін білдік. Мұны автоматтандыру контекстінде қарастырайық, өйткені әрбір құрал немесе технология мәселені шешуі керек. UI тестілерінің контекстінде тестілеуді автоматтандырудың айқын мәселелерін көрсетейік:
- Selenium және әсіресе Appium орнату кезінде тәуелділіктің үлкен саны;
- браузерлердің, симуляторлардың және драйверлердің нұсқалары арасындағы үйлесімділік мәселелері;
- браузерлер/симуляторлар үшін оқшауланған кеңістіктің болмауы, бұл әсіресе параллель жұмыс істеу үшін өте маңызды;
- бір уақытта 10, 50, 100 немесе тіпті 1000 браузерді іске қосу қажет болса, басқару және қызмет көрсету қиын.
Бірақ Selenium - ең танымал автоматтандыру құралы және Docker - ең танымал контейнерлеу құралы болғандықтан, біреу жоғарыда аталған мәселелерді шешу үшін қуатты құрал жасау үшін оларды біріктіруге тырысқанына таң қалмау керек. Мұндай шешімдерді толығырақ қарастырайық.
Докердегі селен торы
Бұл құрал Selenium әлемінде бірнеше браузерлерді бірнеше машиналарда іске қосу және оларды орталық хабтан басқару үшін ең танымал болып табылады. Бастау үшін кем дегенде 2 бөлікті тіркеу қажет: хаб және түйін(тер). Хаб - сынақтардан барлық сұрауларды қабылдайтын және оларды сәйкес Түйіндерге тарататын орталық түйін. Әрбір Түйін үшін біз нақты конфигурацияны конфигурациялай аламыз, мысалы, қалаған шолғышты және оның нұсқасын көрсету арқылы. Дегенмен, біз әлі де үйлесімді браузер драйверлері туралы қамқорлық жасауымыз керек және оларды қалаған түйіндерге орнатуымыз керек. Осы себепті Selenium торы Linux операциялық жүйесінде орнатуға болмайтын браузерлермен жұмыс істеу қажет болған жағдайларды қоспағанда, оның таза түрінде пайдаланылмайды. Барлық басқа жағдайлар үшін Selenium тор хабы мен түйіндерін іске қосу үшін Docker кескіндерін пайдалану айтарлықтай икемді және дұрыс шешім болады. Бұл тәсіл түйінді басқаруды айтарлықтай жеңілдетеді, өйткені біз бұрыннан орнатылған браузерлер мен драйверлердің үйлесімді нұсқалары арқылы қажетті кескінді таңдай аламыз.
Тұрақтылық туралы теріс пікірлерге қарамастан, әсіресе көптеген түйіндерді параллельді іске қосқанда, Selenium торы әлі күнге дейін Selenium сынақтарын параллельді орындау үшін ең танымал құрал болып табылады. Бұл құралдың әртүрлі жақсартулары мен модификациялары әртүрлі кедергілермен күресетін ашық бастапқы кодта үнемі пайда болатынын атап өту маңызды.
Вебке арналған селеноид
Бұл құрал Selenium әлеміндегі жаңалық болып табылады, өйткені ол қораптан тыс жұмыс істейді және көптеген автоматика инженерлерінің өмірін айтарлықтай жеңілдетеді. Біріншіден, бұл Selenium торының басқа модификациясы емес. Оның орнына әзірлеушілер Голангта Selenium Hub-тың мүлдем жаңа нұсқасын жасады, ол әртүрлі браузерлерге арналған жеңіл Docker кескіндерімен біріктіріліп, тестілеуді автоматтандыруды дамытуға серпін берді. Сонымен қатар, Selenium Grid жағдайында біз барлық қажетті браузерлерді және олардың нұсқаларын алдын ала анықтауымыз керек, бұл тек бір шолғышпен жұмыс істегенде проблема емес. Бірақ бірнеше қолдау көрсетілетін браузерлер туралы айтатын болсақ, Selenoid «сұраныс бойынша шолғыш» мүмкіндігінің арқасында нөмірі бірінші шешім болып табылады. Бізден талап етілетін нәрсе - қажетті кескіндерді браузерлермен алдын ала жүктеп алу және Selenoid өзара әрекеттесетін конфигурация файлын жаңарту. Selenoid сынақтардан сұрауды алғаннан кейін, ол қажетті контейнерді қалаған браузермен автоматты түрде іске қосады. Сынақ аяқталғанда, Selenoid контейнерді өшіреді, осылайша болашақ сұраулар үшін ресурстарды босатады. Бұл тәсіл Selenium торында жиі кездесетін «түйіндердің деградациясының» белгілі проблемасын толығымен жояды.
Бірақ, өкінішке орай, Селеноид әлі де күміс оқ емес. Бізде «сұраныс бойынша шолғыш» мүмкіндігі бар, бірақ «сұраныс бойынша ресурстар» мүмкіндігі әлі қол жетімді емес. Selenoid пайдалану үшін біз оны физикалық жабдықта немесе VM-де орналастыруымыз керек, яғни қанша ресурстар бөліну керектігін алдын ала білуіміз керек. Менің ойымша, бұл 10, 20 немесе тіпті 30 браузерді параллельді түрде басқаратын шағын жобалар үшін проблема емес. Бірақ бізге 100, 500, 1000 немесе одан да көп қажет болса ше? Көптеген ресурстарды үнемі ұстап тұру және төлеу мағынасы жоқ. Осы мақаланың 5 және 6 бөлімдерінде біз масштабтауға мүмкіндік беретін шешімдерді талқылаймыз, осылайша компания шығындарын айтарлықтай азайтады.
Android үшін селеноид
Selenoid веб-автоматтандыру құралы ретінде сәтті болғаннан кейін адамдар Android үшін ұқсас нәрсені алғысы келді. Және бұл болды - Selenoid Android қолдауымен шығарылды. Жоғары деңгейдегі пайдаланушы тұрғысынан жұмыс принципі веб-автоматтандыруға ұқсас. Жалғыз айырмашылығы - браузер контейнерлерінің орнына Selenoid Android эмулятор контейнерлерін іске қосады. Менің ойымша, бұл қазіргі уақытта Android сынақтарын параллель жүргізуге арналған ең қуатты тегін құрал.
Мен бұл құралдың жағымсыз жақтары туралы айтқым келмейді, өйткені ол маған өте ұнайды. Дегенмен, веб-автоматтандыруға қолданылатын және масштабтаумен байланысты бірдей кемшіліктер бар. Бұған қоса, біз құралды бірінші рет орнататын болсақ, таң қалуы мүмкін тағы бір шектеу туралы айтуымыз керек. Android кескіндерін іске қосу үшін бізге кірістірілген виртуализация қолдауы бар физикалық машина немесе VM қажет. Әдістемелік нұсқаулықта мен мұны Linux VM жүйесінде қалай қосу керектігін көрсетемін. Алайда, егер сіз macOS пайдаланушысы болсаңыз және Selenoid қолданбасын жергілікті түрде қолданғыңыз келсе, Android сынақтарын іске қосу мүмкін болмайды. Бірақ сіз әрқашан конфигурацияланған «кірістірілген виртуалдандыру» бар Linux VM-ді жергілікті түрде іске қосып, Selenoid ішіне орналастыра аласыз.
Инфрақұрылымның қазіргі жағдайының иллюстрациясы
Осы мақаланың контекстінде біз инфрақұрылымды суреттейтін 2 құралды қосамыз. Бұл веб-тесттерге арналған Selenium торы және Android сынақтарына арналған Selenoid. GitHub оқулығында мен сізге веб-тесттерді орындау үшін Selenoid пайдалану жолын көрсетемін.
Зерттеуге арналған сілтемелер
Ұқсас құралдар
- Басқа контейнерлеу құралдары бар, бірақ Docker ең танымал. Егер сіз басқа нәрсені көргіңіз келсе, Selenium сынақтарын параллель орындау үшін біз қарастырған құралдар қораптан тыс жұмыс істемейтінін есте сақтаңыз.
- Жоғарыда айтылғандай, Selenium торының көптеген модификациялары бар, мысалы,.
4.CI/CD
Технологияның қысқаша сипаттамасы
Үздіксіз интеграция тәжірибесі әзірлеуде айтарлықтай танымал және нұсқаларды басқару жүйелерімен тең. Осыған қарамастан мен терминологияда шатасу барын сеземін. Бұл параграфта мен өз көзқарасым бойынша осы технологияның 3 модификациясын сипаттағым келеді. Интернетте сіз әртүрлі түсіндірмелері бар көптеген мақалаларды таба аласыз және сіздің пікіріңіз басқаша болса, бұл қалыпты жағдай. Ең бастысы, әріптестеріңізбен бір беттесіз.
Сонымен, 3 термин бар: CI - Үздіксіз интеграция, CD - Үздіксіз жеткізу және қайтадан CD - Үздіксіз орналастыру. (Төменде мен бұл терминдерді ағылшын тілінде қолданатын боламын). Әрбір өзгерту әзірлеу құбырына бірнеше қосымша қадамдарды қосады. Бірақ сөз Үздіксіз (үздіксіз) ең маңызды нәрсе. Бұл тұрғыда біз басынан аяғына дейін үзіліссіз немесе қолмен араласусыз болатын нәрсені айтамыз. Осы контексте CI & CD және CD-ді қарастырайық.
- Үздіксіз интеграция бұл эволюцияның бастапқы қадамы. Серверге жаңа кодты жібергеннен кейін біз өзгертулеріміздің дұрыс екендігі туралы жылдам кері байланыс аламыз деп күтеміз. Әдетте, CI статикалық кодты талдау құралдарын және бірлік/ішкі API сынақтарын қамтиды.Бұл бірнеше секунд/минут ішінде кодымыз туралы ақпаратты алуға мүмкіндік береді.
- Үздіксіз жеткізу интеграция/UI сынақтарын орындайтын неғұрлым жетілдірілген қадам. Дегенмен, бұл кезеңде біз CI сияқты тез нәтиже ала алмаймыз. Біріншіден, бұл сынақ түрлерін аяқтау үшін ұзағырақ уақыт қажет. Екіншіден, іске қосу алдында біз өзгертулерімізді сынақ/сақтау ортасына енгізуіміз керек. Сонымен қатар, егер біз мобильді даму туралы айтатын болсақ, онда біздің қосымшамыздың құрылымын жасау үшін қосымша қадам пайда болады.
- Үздіксіз орналастыру барлық қабылдау сынақтары алдыңғы кезеңдерде өткен болса, біз өз өзгерістерімізді өндіріске автоматты түрде жібереміз деп болжайды. Бұған қоса, шығару кезеңінен кейін өндірісте түтін сынақтарын жүргізу және қызығушылық көрсеткіштерін жинау сияқты әртүрлі кезеңдерді конфигурациялауға болады. Үздіксіз орналастыру автоматтандырылған сынақтармен жақсы қамтылған жағдайда ғана мүмкін болады. Қандай да бір қолмен араласу, соның ішінде тестілеу қажет болса, бұл енді болмайды Үздіксіз (үздіксіз). Сонда біздің құбырымыз тек Үздіксіз жеткізу тәжірибесіне сәйкес келеді деп айта аламыз.
Автоматтандыру инфрақұрылымының мәні
Бұл бөлімде мен UI сынақтары туралы айтатын болсақ, бұл өзгерістер мен байланысты қызметтерді сынақ орталарына қолдануымыз керек екенін түсіндіруім керек. Үздіксіз интеграция - бұл процесс бұл тапсырма үшін қолданылмайды және біз кем дегенде Continuous Deliver тәжірибелерін енгізу туралы қамқорлық жасауымыз керек. Үздіксіз орналастыру UI сынақтары контекстінде де мағынасы бар, егер біз оларды өндірісте іске қосатын болсақ.
Сәулет өзгерісінің иллюстрациясын қарастырмас бұрын, мен GitLab CI туралы бірнеше сөз айтқым келеді. Басқа CI/CD құралдарынан айырмашылығы, GitLab қашықтағы репозиторийді және басқа да көптеген қосымша мүмкіндіктерді ұсынады. Осылайша, GitLab CI-ден жоғары. Ол бастапқы кодты басқаруды, Agile басқаруды, CI/CD құбырларын, тіркеу құралдарын және қораптан тыс көрсеткіштер жинағын қамтиды. GitLab архитектурасы Gitlab CI/CD және GitLab Runner жүйесінен тұрады. Ресми веб-сайттан қысқаша сипаттама:
Gitlab CI/CD – күйін дерекқорда сақтайтын, жобаларды/құрылымдарды басқаратын және пайдаланушы интерфейсін қамтамасыз ететін API интерфейсі бар веб-бағдарлама. GitLab Runner - құрастыруларды өңдейтін қолданба. Оны бөлек орналастыруға болады және API арқылы GitLab CI/CD-мен жұмыс істейді. Іске қосылған сынақтар үшін сізге Gitlab данасы да, Runner да қажет.
Инфрақұрылымның қазіргі жағдайының иллюстрациясы
Зерттеуге арналған сілтемелер
Ұқсас құралдар
- Және басқалары
5. Бұлтты платформалар
Технологияның қысқаша сипаттамасы
Бұл бөлімде біз «қоғамдық бұлттар» деп аталатын танымал тренд туралы айтатын боламыз. Жоғарыда сипатталған виртуалдандыру және контейнерлеу технологиялары беретін орасан зор артықшылықтарға қарамастан, бізге әлі де есептеу ресурстары қажет. Компаниялар қымбат серверлерді сатып алады немесе дата орталықтарын жалға алады, бірақ бұл жағдайда бізге қанша ресурстар қажет болатынын, біз оларды тәулік бойы пайдаланамыз ба және қандай мақсаттарда пайдаланамыз ба (кейде шындыққа жанаспайтын) есептеулер жасау керек. Мысалы, өндіріс тәулік бойы жұмыс істейтін серверді қажет етеді, бірақ жұмыс уақытынан тыс тестілеу үшін бізге ұқсас ресурстар қажет пе? Ол сондай-ақ орындалатын сынақ түріне байланысты. Мысал келесі күні нәтиже алу үшін жұмыс емес уақытта орындауды жоспарлайтын жүктеме/стресс сынақтары болуы мүмкін. Бірақ, әрине, 24/7 сервер қолжетімділігі толық автоматтандырылған сынақтар үшін қажет емес, әсіресе қолмен тестілеу орталары үшін қажет емес. Мұндай жағдайларда сұраныс бойынша қажетті ресурстарды алу, оларды пайдалану және қажет болмаған кезде төлеуді тоқтату жақсы болар еді. Оның үстіне, тінтуірді бірнеше рет басу немесе бірнеше сценарийді іске қосу арқылы оларды бірден алу тамаша болар еді. Қоғамдық бұлттар осы үшін пайдаланылады. Анықтаманы қарастырайық:
«Қоғамдық бұлт жалпыға қолжетімді Интернет арқылы үшінші тарап провайдерлері ұсынатын, оларды пайдаланғысы немесе сатып алғысы келетін кез келген адамға қолжетімді ететін есептеу қызметтері ретінде анықталады. Олар ақысыз болуы немесе сұраныс бойынша сатылуы мүмкін, бұл тұтынушыларға CPU циклдері, сақтау орны немесе тұтынатын өткізу қабілеттілігі үшін тек пайдалану үшін төлеуге мүмкіндік береді.
Қоғамдық бұлттар қымбат деген пікір бар. Бірақ олардың негізгі идеясы компания шығындарын азайту болып табылады. Жоғарыда айтылғандай, жалпыға қолжетімді бұлттар сұраныс бойынша ресурстарды алуға және оларды пайдаланған уақыт үшін ғана төлеуге мүмкіндік береді. Сондай-ақ, кейде қызметкерлердің жалақы алатынын ұмытып кетеміз, ал мамандар да қымбат ресурс. Жалпыға қолжетімді бұлттар инфрақұрылымды қолдауды айтарлықтай жеңілдететінін ескеру қажет, бұл инженерлерге маңыздырақ тапсырмаларға назар аударуға мүмкіндік береді.
Автоматтандыру инфрақұрылымының мәні
UI сынақтары үшін бізге қандай нақты ресурстар қажет? Негізінен бұл браузерлер мен эмуляторларды іске қосуға арналған виртуалды машиналар немесе кластерлер (біз келесі бөлімде Kubernetes туралы айтатын боламыз). Неғұрлым көп браузерлер мен эмуляторларды бір уақытта іске қосқымыз келсе, соғұрлым көп процессор мен жад қажет және соғұрлым көп ақша төлеуге тура келеді. Осылайша, тестілеуді автоматтандыру контекстіндегі жалпыға қолжетімді бұлттар сұраныс бойынша браузерлердің/эмуляторлардың үлкен санын (100, 200, 1000...) іске қосуға, сынақ нәтижелерін мүмкіндігінше тез алуға және мұндай өте көп ресурстарды қажет ететін төлемді тоқтатуға мүмкіндік береді. қуат.
Ең танымал бұлттық провайдерлер - Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Әдістемелік нұсқаулық GCP пайдаланудың мысалдарын береді, бірақ жалпы алғанда автоматтандыру тапсырмалары үшін нені пайдаланатыныңыз маңызды емес. Олардың барлығы шамамен бірдей функционалдылықты қамтамасыз етеді. Әдетте, провайдерді таңдау үшін басшылық компанияның барлық инфрақұрылымы мен бизнес талаптарына назар аударады, бұл осы мақаланың аясынан тыс. Автоматтандыру инженерлері үшін бұлттық провайдерлерді қолдануды Sauce Labs, BrowserStack, BitBar және т. Ендеше, оны да жасайық! Менің ойымша, Sauce Labs - бұл ең танымал бұлтты тестілеу фермасы, сондықтан мен оны салыстыру үшін қолдандым.
Автоматтандыру мақсатында GCP vs Sauce Labs:
Біз бір уақытта 8 веб-тест пен 8 Android тестін орындауымыз керек деп елестетіп көрейік. Ол үшін біз GCP қолданамыз және Selenoid көмегімен 2 виртуалды машинаны іске қосамыз. Біріншісінде біз браузерлермен 8 контейнерді көтереміз. Екіншісінде эмуляторы бар 8 контейнер бар. Бағаларды қарастырайық:
Chrome көмегімен бір контейнерді іске қосу үшін бізге қажет n1-стандартты-1 машина. Android жағдайында бұл болады n1-стандартты-4 бір эмулятор үшін. Шындығында, неғұрлым икемді және арзанырақ әдіс - CPU/жад үшін нақты пайдаланушы мәндерін орнату, бірақ қазіргі уақытта бұл Sauce Labs-пен салыстыру үшін маңызды емес.
Міне, Sauce Labs пайдалану тарифтері:
Сіз айырмашылықты байқадыңыз деп ойлаймын, бірақ мен әлі де біздің тапсырмамыз үшін есептеулер бар кестені ұсынамын:
Қажетті ресурстар
Ай сайын
Жұмыс сағаттары(8 - 8)
Жұмыс сағаттары+ Артықшылықты
Web үшін GCP
n1-стандарт-1 x 8 = n1-стандарт-8
$194.18
23 күн * 12 сағ * 0.38 = $104.88
23 күн * 12 сағ * 0.08 = $22.08
Интернетке арналған тұздық зертханалары
Virtual Cloud8 параллель сынақтары
$1.559
-
-
Android үшін GCP
n1-стандартты-4 x 8: n1-стандартты-16
$776.72
23 күн * 12 сағ * 1.52 = $419.52
23 күн * 12 сағ * 0.32 = $88.32
Android үшін Sauce Labs
Real Device Cloud 8 параллель сынақтары
$1.999
-
-
Көріп отырғаныңыздай, құнының айырмашылығы өте үлкен, әсіресе егер сіз сынақтарды тек он екі сағаттық жұмыс кезеңінде орындасаңыз. Бірақ егер сіз артықшылықты машиналарды пайдалансаңыз, шығындарды одан әрі қысқартуға болады. Бұл не?
Артықшылықты VM - қалыпты даналарға қарағанда әлдеқайда арзанырақ бағамен жасауға және іске қосуға болатын данасы. Дегенмен, Compute Engine басқа тапсырмалар үшін сол ресурстарға кіруді қажет ететін болса, бұл даналарды тоқтатуы (алдын ала алуы) мүмкін. Артықшылықты мысалдар - Compute Engine сыйымдылығы артық, сондықтан олардың қолжетімділігі пайдалануға байланысты өзгереді.
Қолданбалар ақауларға төзімді болса және ықтимал даналарды алдын ала алуларға төтеп бере алса, басымдықты үлгілер Compute Engine шығындарын айтарлықтай азайтады. Мысалы, пакеттік өңдеу тапсырмалары таңдаулы даналарда жұмыс істей алады. Өңдеу кезінде осы даналардың кейбірі тоқтатылатын болса, жұмыс баяулайды, бірақ толық тоқтамайды. Артықшылықты даналар бар даналарыңызға қосымша жұмыс жүктемесін қоймастан және қосымша қалыпты даналар үшін толық бағаны төлеуді талап етпей-ақ пакеттік өңдеу тапсырмаларын аяқтайды.
Және әлі біткен жоқ! Шындығында, мен ешкім үзіліссіз 12 сағат бойы сынақ жүргізбейтініне сенімдімін. Егер солай болса, виртуалды машиналарды қажет емес кезде автоматты түрде қосуға және тоқтатуға болады. Нақты пайдалану уақытын күніне 6 сағатқа дейін қысқартуға болады. Содан кейін біздің тапсырма контекстіндегі төлем 11 браузер үшін айына $8 дейін төмендейді. Бұл керемет емес пе? Бірақ басым машиналармен біз абай болуымыз керек және үзілістер мен тұрақсыздыққа дайын болуымыз керек, бірақ бұл жағдайлар бағдарламалық жасақтамада қарастырылуы және өңделуі мүмкін. Бұл тұрарлық!
Бірақ мен «ешқашан бұлтты сынақ фермаларын пайдаланбаңыз» деп айтпаймын. Олардың бірқатар артықшылықтары бар. Біріншіден, бұл жай ғана виртуалды машина емес, сонымен қатар қораптан тыс функционалдық жиынтығы бар тестілеуді автоматтандырудың толыққанды шешімі: қашықтан қол жеткізу, журналдар, скриншоттар, бейне жазбалар, әртүрлі браузерлер және физикалық мобильді құрылғылар. Көптеген жағдайларда бұл маңызды сәнді балама болуы мүмкін. Жалпыға қолжетімді бұлттар тек Linux/Windows жүйелерін ұсына алатын кезде тестілеу платформалары әсіресе IOS автоматтандыруы үшін пайдалы. Бірақ iOS туралы келесі мақалаларда айтатын боламыз. Мен әрқашан жағдайға қарап, тапсырмалардан бастауды ұсынамын: кейбір жағдайларда қоғамдық бұлттарды пайдалану арзанырақ және тиімдірек, ал басқаларында сынақ платформалары жұмсалған ақшаға тұрарлық.
Инфрақұрылымның қазіргі жағдайының иллюстрациясы
Зерттеуге арналған сілтемелер
Ұқсас құралдар:
6. Оркестрация
Технологияның қысқаша сипаттамасы
Менде жақсы жаңалық бар – біз мақаланың соңына таяп қалдық! Қазіргі уақытта біздің автоматтандыру инфрақұрылымымыз GitLab CI арқылы параллельде Docker қолдайтын құралдарды пайдалана отырып орындайтын веб және Android сынақтарынан тұрады: Selenium grid және Selenoid. Сонымен қатар, біз браузерлер мен эмуляторлары бар контейнерлерді орналастыру үшін GCP арқылы жасалған виртуалды машиналарды қолданамыз. Шығындарды азайту үшін біз бұл виртуалды машиналарды тек сұраныс бойынша іске қосамыз және тестілеу жүргізілмей жатқанда тоқтатамыз. Біздің инфрақұрылымды жақсартатын тағы бір нәрсе бар ма? Жауап иә! Кубернетеспен (K8s) танысыңыз!
Алдымен оркестр, кластер және кубернетес сөздерінің бір-бірімен байланысын қарастырайық. Жоғары деңгейде оркестрлеу қолданбаларды орналастыратын және басқаратын жүйе болып табылады. Сынақтарды автоматтандыру үшін мұндай контейнерлік қолданбалар Selenium тор және Selenoid болып табылады. Docker және K8 бір-бірін толықтырады. Біріншісі қолданбаны орналастыру үшін, екіншісі оркестрлеу үшін пайдаланылады. Өз кезегінде, K8s кластер болып табылады. Кластердің міндеті - бір сервер (кластер) ішінде әртүрлі функционалдылықты, бағдарламаларды және қызметтерді орнатуға мүмкіндік беретін VM-ді Түйін ретінде пайдалану. Түйіндердің кез келгені сәтсіз болса, басқа түйіндер қабылданады, бұл біздің қолданбаның үздіксіз жұмысын қамтамасыз етеді. Бұған қоса, K8s масштабтаумен байланысты маңызды функционалдылыққа ие, соның арқасында біз жүктеме негізінде ресурстардың оңтайлы көлемін автоматты түрде аламыз және шектеулерді белгілейміз.
Шындығында, Kubernetes-ті нөлден қолмен орналастыру тривиальды міндет емес. Мен атақты «Кубернетес The Hard Way» нұсқаулығына сілтеме қалдырамын, егер сізді қызықтырса, оны тәжірибе жүзінде қолдана аласыз. Бірақ, бақытымызға орай, балама әдістер мен құралдар бар. Ең оңай жолы - GCP жүйесінде Google Kubernetes Engine (GKE) пайдалану, ол бірнеше рет басу арқылы дайын кластерді алуға мүмкіндік береді. Мен оқуды бастау үшін осы тәсілді пайдалануды ұсынамын, себебі ол ішкі құрамдастардың бір-бірімен біріктірілуін үйренудің орнына K8-ді тапсырмаларыңыз үшін қалай пайдалану керектігін үйренуге назар аударуға мүмкіндік береді.
Автоматтандыру инфрақұрылымының мәні
K8s қамтамасыз ететін бірнеше маңызды мүмкіндіктерді қарастырайық:
- қолданбаларды орналастыру: VM орнына көп түйінді кластерді пайдалану;
- динамикалық масштабтау: тек сұраныс бойынша пайдаланылатын ресурстардың құнын төмендетеді;
- өзін-өзі емдеу: бұршақтарды автоматты түрде қалпына келтіру (оның нәтижесінде контейнерлер де қалпына келтіріледі);
- үзіліссіз жаңартуларды шығару және өзгертулерді кері қайтару: құралдарды, браузерлерді және эмуляторларды жаңарту ағымдағы пайдаланушылардың жұмысын тоқтатпайды
Бірақ K8s әлі де күміс оқ емес. Біз қарастыратын құралдар (Selenium торы, Selenoid) контекстіндегі барлық артықшылықтар мен шектеулерді түсіну үшін біз K8 құрылымын қысқаша талқылаймыз. Кластерде түйіндердің екі түрі бар: негізгі түйіндер және жұмысшылар түйіндері. Негізгі түйіндер басқару, орналастыру және жоспарлау шешімдеріне жауап береді. Жұмысшы түйіндері қолданбалар іске қосылатын жер. Түйіндер сонымен қатар контейнердің орындалу ортасын қамтиды. Біздің жағдайда бұл контейнерге қатысты операцияларға жауап беретін Docker. Бірақ, мысалы, балама шешімдер де бар. Масштабтау немесе өзін-өзі емдеу контейнерлерге тікелей қолданылмайтынын түсіну маңызды. Бұл өз кезегінде контейнерлерді (әдетте бір подводқа бір контейнер, бірақ тапсырмаға байланысты одан да көп болуы мүмкін) қамтитын түйіршіктер санын қосу/азайту арқылы жүзеге асырылады. Жоғары деңгейлі иерархия жұмысшы түйіндерден тұрады, олардың ішінде бөтелкелер бар, олардың ішінде контейнерлер көтеріледі.
Масштабтау мүмкіндігі негізгі болып табылады және оны кластерлік түйін пулындағы екі түйінге де, түйін ішіндегі түйіндерге де қолдануға болады. Түйіндерге де, тармақтарға да қолданылатын масштабтаудың 2 түрі бар. Бірінші түрі көлденең – масштабтау түйіндердің/түйінділердің санын көбейту арқылы жүзеге асады. Бұл түрі қолайлырақ. Екінші түрі, тиісінше, тік. Масштабтау түйіндердің/түйінділердің санын емес, өлшемін ұлғайту арқылы жүзеге асырылады.
Енді жоғарыдағы терминдер контекстінде құралдарымызды қарастырайық.
Селен торы
Жоғарыда айтылғандай, Selenium торы өте танымал құрал болып табылады және оның контейнерге салынғаны таңқаларлық емес. Сондықтан Selenium торын K8-де орналастыруға болатыны таңқаларлық емес. Мұны қалай жасау керектігінің мысалын K8s ресми репозиторийінен табуға болады. Әдеттегідей, мен сілтемелерді бөлімнің соңына қосамын. Бұған қоса, нұсқаулық Terraform бағдарламасында мұны қалай жасау керектігін көрсетеді. Сондай-ақ, шолғыш контейнерлері бар қосқыштардың санын қалай масштабтауға болатыны туралы нұсқаулар бар. Бірақ K8 контекстіндегі автоматты масштабтау функциясы әлі де толық айқын тапсырма емес. Оқуды бастаған кезде мен ешқандай практикалық нұсқаулар немесе ұсыныстар таппадым. DevOps командасының қолдауымен бірнеше зерттеулер мен эксперименттерден кейін біз бір жұмысшы түйіннің ішінде орналасқан бір блоктың ішінде қажетті браузерлері бар контейнерлерді көтеру тәсілін таңдадық. Бұл әдіс олардың санын көбейту арқылы түйіндерді көлденең масштабтау стратегиясын қолдануға мүмкіндік береді. Бұл болашақта өзгереді деп үміттенемін және біз жақсырақ тәсілдер мен дайын шешімдердің көбірек сипаттамаларын көреміз, әсіресе ішкі архитектурасы өзгерген Selenium торы 4 шығарылғаннан кейін.
Селеноид:
K8-де селеноидты орналастыру қазіргі уақытта ең үлкен көңілсіздік болып табылады. Олар үйлесімді емес. Теориялық тұрғыдан біз Selenoid контейнерін подводтың ішінде көтере аламыз, бірақ Selenoid браузерлері бар контейнерлерді іске қоса бастағанда, олар бәрібір сол подкасттың ішінде болады. Бұл масштабтауды мүмкін емес етеді және нәтижесінде кластердегі Selenoid жұмысы виртуалды машинадағы жұмыстан ерекшеленбейді. Әңгіменің соңы.
ай:
Selenoid-пен жұмыс істеу кезінде бұл қиыншылықты біле отырып, әзірлеушілер Moon деп аталатын неғұрлым қуатты құралды шығарды. Бұл құрал бастапқыда Kubernetes-пен жұмыс істеуге арналған және нәтижесінде автомасштабтау мүмкіндігін пайдалануға болады және қажет. Оның үстіне, дәл қазір солай дер едім жалғыз Selenium әлеміндегі құрал, ол K8s кластерін қораптан шығарады (енді қолжетімді емес, келесі құралды қараңыз ). Бұл қолдауды қамтамасыз ететін Айдың негізгі ерекшеліктері:
Толығымен азаматтығы жоқ. Селеноид ағымдағы іске қосылған браузер сеанстары туралы ақпаратты жадта сақтайды. Егер қандай да бір себептермен оның процесі бұзылса, онда барлық іске қосылған сеанстар жоғалады. Айдың, керісінше, ішкі күйі жоқ және оны деректер орталықтарында көшіруге болады. Браузер сеанстары тіпті бір немесе бірнеше көшірмелердің жойылғанына қарамастан тірі қалады.
Сонымен, Ай - тамаша шешім, бірақ бір мәселе бар: ол тегін емес. Бағасы сеанстардың санына байланысты. Сіз тек 0-4 сеансты тегін орындай аласыз, бұл әсіресе пайдалы емес. Бірақ бесінші сессиядан бастап әрқайсысы үшін 5 доллар төлеуге тура келеді. Жағдай әр компанияда әртүрлі болуы мүмкін, бірақ біздің жағдайда Айды пайдалану мағынасыз. Жоғарыда сипаттағанымдай, біз сұраныс бойынша Selenium Grid көмегімен виртуалды құрылғыларды іске қоса аламыз немесе кластердегі түйіндер санын көбейте аламыз. Шамамен бір құбыр үшін біз 500 браузерді іске қосамыз және сынақтар аяқталғаннан кейін барлық ресурстарды тоқтатамыз. Егер біз Айды пайдалансақ, сынақтарды қаншалықты жиі өткізсек те, айына қосымша 500 x 5 = $2500 төлеуге тура келеді. Тағы да, мен Айды қолданбаңыз деп айтпаймын. Тапсырмаларыңыз үшін бұл таптырмас шешім болуы мүмкін, мысалы, ұйымыңызда көптеген жобалар/командалар болса және сізге барлығына ортақ үлкен кластер қажет болса. Әдеттегідей, мен соңында сілтеме қалдырамын және тапсырмаңыздың контекстінде барлық қажетті есептеулерді орындауды ұсынамын.
Callisto(Назар аударыңыз! Бұл түпнұсқа мақалада жоқ және тек орыс тіліндегі аудармасында бар)
Мен айтқанымдай, Selenium - бұл өте танымал құрал және IT саласы өте жылдам дамып келеді. Мен аудармамен жұмыс істеп жатқанда, интернетте Callisto деп аталатын жаңа перспективалық құрал пайда болды (hello Cypress және басқа Selenium killers). Ол K8 құрылғыларымен жұмыс істейді және Selenoid контейнерлерін түйіндер бойынша таратылған түйіндерде іске қосуға мүмкіндік береді. Барлығы қораптан тыс жұмыс істейді, соның ішінде автомасштабтау. Фантастикалық, бірақ сынақтан өту керек. Мен бұл құралды қолданып, бірнеше эксперименттер жүргізіп үлгердім. Ұзақ қашықтықтан нәтиже алғаннан кейін қорытынды жасауға әлі ерте, мүмкін болашақ мақалаларда шолу жасаймын. Әзірге мен тек тәуелсіз зерттеулерге сілтемелер қалдырамын.
Инфрақұрылымның қазіргі жағдайының иллюстрациясы
Зерттеуге арналған сілтемелер
Ұқсас құралдар
7. Инфрақұрылым код ретінде (IaC)
Технологияның қысқаша сипаттамасы
Ал енді соңғы бөлімге келдік. Әдетте, бұл технология және оған қатысты міндеттер автоматтандыру инженерлерінің жауапкершілігі емес. Ал мұның өз себептері бар. Біріншіден, көптеген ұйымдарда инфрақұрылым мәселелері DevOps департаментінің бақылауында және әзірлеу топтары құбырдың не істейтінін және онымен байланысты барлық нәрсеге қалай қолдау көрсету керектігін ойламайды. Екіншіден, шынын айту керек, көптеген компанияларда Инфраструктура ретінде кодекс (IaC) тәжірибесі әлі де қабылданбайды. Бірақ бұл сөзсіз танымал трендке айналды және онымен байланысты процестерге, тәсілдерге және құралдарға қатысуға тырысу маңызды. Немесе, ең болмағанда, жаңалықтардан хабардар болыңыз.
Осы тәсілді қолданудың мотивациясынан бастайық. Біз GitlabCI-де сынақтарды орындау үшін Gitlab Runner іске қосу үшін кем дегенде ресурстар қажет болатынын талқыладық. Браузерлер/эмуляторлары бар контейнерлерді іске қосу үшін бізге VM немесе кластерді резервтеу керек. Ресурстарды тестілеуден басқа, бізге әзірлеуге, кезеңге, өндірістік орталарға қолдау көрсету үшін үлкен көлемдегі мүмкіндіктер қажет, ол сондай-ақ дерекқорларды, автоматты кестелерді, желі конфигурацияларын, жүктеме теңестірушілерін, пайдаланушы құқықтарын және т.б. қамтиды. Басты мәселе - мұның бәрін қолдау үшін күш қажет. Өзгерістер енгізудің және жаңартуларды шығарудың бірнеше жолы бар. Мысалы, GCP контекстінде біз браузерде UI консолін пайдалана аламыз және түймелерді басу арқылы барлық әрекеттерді орындай аламыз. Бұлт нысандарымен әрекеттесу үшін API қоңырауларын пайдалану немесе қажетті манипуляцияларды орындау үшін gcloud пәрмен жолы утилитасын пайдалану балама болады. Бірақ әртүрлі нысандар мен инфрақұрылым элементтерінің шынымен үлкен санымен барлық операцияларды қолмен орындау қиынға соғады немесе тіпті мүмкін емес. Оның үстіне, бұл қолмен жасалған әрекеттердің барлығын бақылау мүмкін емес. Біз оларды орындау алдында тексеруге жібере алмаймыз, нұсқаларды басқару жүйесін пайдалана алмаймыз және оқиғаға әкелген өзгерістерді жылдам кері қайтара алмаймыз. Мұндай мәселелерді шешу үшін инженерлер автоматты bash/shell сценарийлерін жасады және жасайды, олар алдыңғы әдістерге қарағанда жақсы емес, өйткені оларды процедуралық стильде жылдам оқу, түсіну, қолдау және өзгерту оңай емес.
Бұл мақалада және нұсқаулықта мен IaC тәжірибесіне қатысты 2 құралды қолданамын. Бұл Terraform және Ansible. Кейбір адамдар оларды бір уақытта пайдаланудың мағынасы жоқ деп санайды, өйткені олардың функционалдығы ұқсас және олар бір-бірін алмастырады. Бірақ факт, бастапқыда оларға мүлдем басқа тапсырмалар беріледі. Бұл құралдардың бірін-бірі толықтыруы керек екендігі HashiCorp және RedHat ұсынатын әзірлеушілермен бірлескен презентацияда расталды. Концептуалды айырмашылық Terraform серверлердің өзін басқаруға арналған провизия құралы болып табылады. Ansible – бұл серверлерде бағдарламалық құралды орнату, конфигурациялау және басқару міндеті конфигурацияны басқару құралы.
Бұл құралдардың тағы бір басты ерекшелігі кодтау стилі болып табылады. bash және Ansible-дан айырмашылығы, Terraform орындау нәтижесінде қол жеткізілетін қажетті соңғы күйдің сипаттамасына негізделген декларативті стильді пайдаланады. Мысалы, егер біз 10 VM жасап, өзгертулерді Terraform арқылы қолданатын болсақ, онда біз 10 VM аламыз. Сценарийді қайта іске қоссақ, ештеңе болмайды, өйткені бізде 10 VM бар және Terraform бұл туралы біледі, себебі ол инфрақұрылымның ағымдағы күйін күй файлында сақтайды. Бірақ Ansible процедуралық тәсілді қолданады және егер сіз одан 10 VM жасауды сұрасаңыз, онда бірінші іске қосуда біз Terraform сияқты 10 VM аламыз. Бірақ қайта іске қосқаннан кейін бізде 20 VM болады. Бұл маңызды айырмашылық. Процедуралық стильде біз ағымдағы күйді сақтамаймыз және жай ғана орындалуы керек қадамдар тізбегін сипаттаймыз. Әрине, біз әртүрлі жағдайларды шеше аламыз, ресурстардың бар-жоғын және ағымдағы жағдайды бірнеше тексеруді қоса аламыз, бірақ бұл логиканы бақылауға уақытымызды жұмсаудың және күш салудың мағынасы жоқ. Бұған қоса, бұл қателік жасау қаупін арттырады.
Жоғарыда айтылғандардың барлығын қорытындылай келе, Terraform және декларативті белгілер серверлерді қамтамасыз ету үшін қолайлы құрал болып табылады деп қорытынды жасауға болады. Бірақ конфигурацияны басқару жұмысын Ansible-ге тапсырған дұрыс. Бұл жағдайдан кейін автоматтандыру контекстінде пайдалану жағдайларын қарастырайық.
Автоматтандыру инфрақұрылымының мәні
Мұнда түсінуге болатын жалғыз маңызды нәрсе - сынақты автоматтандыру инфрақұрылымы компанияның барлық инфрақұрылымының бөлігі ретінде қарастырылуы керек. Бұл барлық IaC тәжірибелері бүкіл ұйымның ресурстарына жаһандық деңгейде қолданылуы керек дегенді білдіреді. Бұған кім жауапты, сіздің процестеріңізге байланысты. DevOps командасы бұл мәселелерде тәжірибелі, олар не болып жатқанын толықтай көреді. Дегенмен, QA инженерлері құрылысты автоматтандыру процесіне және құбырдың құрылымына көбірек қатысады, бұл оларға барлық қажетті өзгерістер мен жақсарту мүмкіндіктерін жақсырақ көруге мүмкіндік береді. Күтілетін нәтижеге қол жеткізу үшін бірігіп жұмыс жасау, білім және идеялармен алмасу ең жақсы нұсқа болып табылады.
Мұнда тестілеуді автоматтандыру контекстінде Terraform және Ansible қолданудың бірнеше мысалдары және біз бұрын талқылаған құралдар берілген:
1. Terraform көмегімен VM және кластерлердің қажетті сипаттамалары мен параметрлерін сипаттаңыз.
2. Ansible көмегімен тестілеуге қажетті құралдарды орнатыңыз: docker, Selenoid, Selenium Grid және браузерлердің/эмуляторлардың қажетті нұсқаларын жүктеп алыңыз.
3. Terraform көмегімен GitLab Runner іске қосылатын VM сипаттамаларын сипаттаңыз.
4. Ansible көмегімен GitLab Runner және қажетті ілеспе құралдарды орнатыңыз, параметрлер мен конфигурацияларды орнатыңыз.
Инфрақұрылымның қазіргі жағдайының иллюстрациясы
Зерттеуге арналған сілтемелер:
Ұқсас құралдар
Жинақтау!
қадам
технология
Құралдар
Автоматтандыру инфрақұрылымының мәні
1
Жергілікті жүгіру
Node.js, Selenium, Appium
- Веб және мобильді құрылғыларға арналған ең танымал құралдар
- Көптеген тілдер мен платформаларды қолдайды (соның ішінде Node.js)
2
Нұсқаларды басқару жүйелері
жүру
- Әзірлеу кодымен ұқсас артықшылықтар
3
Контейнерлеу
Docker, Selenium торы, Selenoid (Web, Android)
- Тесттерді параллель орындау
- Оқшауланған орталар
- Қарапайым, икемді нұсқа жаңартулары
- Пайдаланылмаған ресурстарды динамикалық түрде тоқтату
- Орнату оңай
4
CI/CD
Gitlab CI
- Құбырдың бір бөлігін сынақтан өткізеді
- Жылдам кері байланыс
- Бүкіл компания/команда үшін көріну
5
Бұлтты платформалар
Google Cloud Platform
- Сұраныс бойынша ресурстар (қажет болғанда ғана төлейміз)
- Басқару және жаңарту оңай
- Барлық ресурстарды көру және бақылау
6
Оркестрация
Kubernetes
Бөлшектердің ішіндегі браузерлері/эмуляторлары бар контейнерлер контекстінде:
- Масштабтау/автоматты масштабтау
- Өзін-өзі емдеу
- Үзіліссіз жаңартулар мен кері қайтарулар
7
Инфрақұрылым код ретінде (IaC)
Терраформа, Ansible
- Даму инфрақұрылымымен ұқсас артықшылықтар
- Код нұсқасын жасаудың барлық артықшылықтары
- Өзгерістер енгізу және жөндеу оңай
- Толық автоматтандырылған
Ақыл картасы диаграммалары: инфрақұрылымның эволюциясы
1-қадам: Жергілікті
2-қадам: VCS
3-қадам: Контейнерлеу
4-қадам: CI/CD
5-қадам: Бұлттық платформалар
6-қадам: Оркестрация
7-қадам: IaC
Ары қарай не?
Сонымен, бұл мақаланың соңы. Бірақ қорытындылай келе, мен сізбен кейбір келісімдер жасағым келеді.
Сіздің тарапыңыздан
Бастапқыда айтқанымдай, мен мақаланың практикалық маңызы бар және алған біліміңізді нақты жұмыста қолдануға көмектескенін қалаймын. тағы қосамын.
Бірақ одан кейін де тоқтамаңыз, жаттығу жасаңыз, сәйкес сілтемелер мен кітаптарды зерттеңіз, оның сіздің компанияңызда қалай жұмыс істейтінін біліңіз, жақсартуға болатын жерлерді табыңыз және оған қатысыңыз. Іске сәт!
Менің жағымнан
Тақырыптан бұл тек бірінші бөлім болғанын көруге болады. Бұл өте үлкен болғанымен, маңызды тақырыптар әлі де қамтылмаған. Екінші бөлімде IOS контекстінде автоматтандыру инфрақұрылымын қарастыруды жоспарлап отырмын. Apple компаниясының iOS тренажерларын тек macOS жүйелерінде іске қосу шектеулеріне байланысты шешімдеріміздің ауқымы тарылды. Мысалы, біз симуляторды іске қосу үшін Docker қолданбасын немесе виртуалды машиналарды іске қосу үшін жалпыға ортақ бұлттарды пайдалана алмаймыз. Бірақ бұл басқа балама жоқ дегенді білдірмейді. Мен сізді озық шешімдер мен заманауи құралдармен жаңартуға тырысамын!
Сондай-ақ, мен мониторингке қатысты үлкен тақырыптарды айтқан жоқпын. 3-бөлімде мен ең танымал инфрақұрылымды бақылау құралдарын және қандай деректер мен көрсеткіштерді қарастыру керектігін қарастырамын.
Және соңында. Болашақта мен тесттік инфрақұрылым мен танымал құралдарды құру бойынша бейне курс шығаруды жоспарлап отырмын. Қазіргі уақытта Интернетте DevOps бойынша бірнеше курстар мен лекциялар бар, бірақ барлық материалдар тесттік автоматтандыру емес, әзірлеу контекстінде ұсынылған. Бұл мәселе бойынша маған мұндай курс тестерлер мен автоматика инженерлері қауымдастығы үшін қызықты және құнды бола ма деген пікір керек. Алдын ала рахмет!
Ақпарат көзі: www.habr.com