1 dalis: žiniatinklis / „Android“.
Atkreipti dėmesį: šis straipsnis yra originalaus straipsnio vertimas į rusų kalbą Tačiau visos iliustracijos, nuorodos, citatos ir terminai išsaugomi originalo kalba, kad būtų išvengta prasmės iškraipymo verčiant į rusų kalbą. Linkiu jums laimingų studijų!
Šiuo metu DevOps specialybė yra viena paklausiausių IT industrijoje. Jei atidarysite populiarias darbo paieškos svetaines ir filtruosite pagal atlyginimą, pamatysite, kad su DevOps susiję darbai yra sąrašo viršuje. Tačiau svarbu suprasti, kad tai daugiausia reiškia „vyresnes“ pareigas, o tai reiškia, kad kandidatas turi aukšto lygio įgūdžius, išmano technologijas ir įrankius. Tai taip pat apima didelę atsakomybę, susijusią su nenutrūkstamu gamybos procesu. Tačiau mes pradėjome pamiršti, kas yra „DevOps“. Iš pradžių tai nebuvo koks nors konkretus asmuo ar skyrius. Jei ieškotume šio termino apibrėžimų, rastume daug gražių ir teisingų daiktavardžių, tokių kaip metodika, praktika, kultūros filosofija, sąvokų grupė ir pan.
Mano specializacija yra testavimo automatizavimo inžinierius (QA automation engineer), bet manau, kad ji neturėtų būti siejama tik su automatinių testų rašymu ar testavimo sistemos architektūros kūrimu. 2020 metais taip pat būtinos žinios apie automatikos infrastruktūrą. Tai leidžia patiems organizuoti automatizavimo procesą – nuo testų vykdymo iki rezultatų pateikimo visoms suinteresuotosioms šalims pagal savo tikslus. Todėl norint atlikti darbą būtini „DevOps“ įgūdžiai. Ir visa tai yra gerai, bet, deja, yra problema (spoileris: šis straipsnis bando supaprastinti šią problemą). Esmė ta, kad „DevOps“ yra sunku. Ir tai akivaizdu, nes už tai, ką lengva padaryti, įmonės daug nemokės... DevOps pasaulyje yra labai daug įrankių, terminų ir praktikų, kurias reikia įsisavinti. Tai ypač sunku karjeros pradžioje ir priklauso nuo sukauptos techninės patirties.
Šaltinis:
Čia tikriausiai baigsime įžanginę dalį ir sutelksime dėmesį į šio straipsnio tikslą.
Apie ką šis straipsnis?
Šiame straipsnyje pasidalinsiu savo patirtimi kuriant testavimo automatizavimo infrastruktūrą. Internete yra daugybė informacijos šaltinių apie įvairius įrankius ir jų naudojimą, tačiau norėčiau į juos pažvelgti grynai automatizavimo kontekste. Manau, kad daugelis automatikos inžinierių yra susipažinę su situacija, kai niekas, išskyrus jus, neatlieka sukurtų testų ir nesirūpina jų priežiūra. Dėl to testai pasensta ir jūs turite skirti laiko juos atnaujinti. Vėlgi, karjeros pradžioje tai gali būti gana sudėtinga užduotis: protingai nuspręsti, kurios priemonės turėtų padėti pašalinti konkrečią problemą, kaip jas pasirinkti, konfigūruoti ir prižiūrėti. Kai kurie bandytojai kreipiasi pagalbos į „DevOps“ (žmones) ir, būkime atviri, šis metodas veikia. Daugeliu atvejų tai gali būti vienintelė galimybė, nes nematome visų priklausomybių. Bet kaip žinome, DevOps yra labai užsiėmę vaikinai, nes jie turi galvoti apie visos įmonės infrastruktūrą, diegimą, stebėjimą, mikropaslaugas ir kitas panašias užduotis priklausomai nuo organizacijos/komandos. Kaip paprastai, automatizavimas nėra prioritetas. Tokiu atveju turime stengtis padaryti viską, kas įmanoma nuo pradžios iki pabaigos. Tai sumažins priklausomybes, pagreitins darbo eigą, pagerins mūsų įgūdžius ir leis mums pamatyti didesnį vaizdą apie tai, kas vyksta.
Straipsnyje pristatomi populiariausi ir populiariausi įrankiai bei parodoma, kaip jas žingsnis po žingsnio panaudoti kuriant automatizavimo infrastruktūrą. Kiekvienai grupei atstovauja įrankiai, kurie buvo išbandyti per asmeninę patirtį. Bet tai nereiškia, kad turite naudoti tą patį. Pačios priemonės nėra svarbios, jos atsiranda ir pasensta. Mūsų inžinerinė užduotis – suprasti pagrindinius principus: kam mums reikia šios grupės įrankių ir kokias darbo problemas galime išspręsti jų pagalba. Štai kodėl kiekvienos dalies pabaigoje palieku nuorodas į panašius įrankius, kurie gali būti naudojami jūsų organizacijoje.
Ko nėra šiame straipsnyje
Dar kartą pasikartosiu, kad straipsnis ne apie konkrečius įrankius, todėl nebus jokių kodų įterpimų iš dokumentacijos ir konkrečių komandų aprašymų. Bet kiekvieno skyriaus pabaigoje palieku nuorodas išsamiam tyrimui.
Tai daroma, nes:
- šią medžiagą labai lengva rasti įvairiuose šaltiniuose (dokumentacijoje, knygose, video kursuose);
- jei pradėsime gilintis, turėsime parašyti 10, 20, 30 šio straipsnio dalių (kol planai 2-3);
- Aš tiesiog nenoriu gaišti jūsų laiko, nes galbūt norėsite naudoti kitus įrankius, kad pasiektumėte tuos pačius tikslus.
Praktika
Labai norėčiau, kad ši medžiaga būtų naudinga kiekvienam skaitytojui, o ne tik perskaityta ir pamiršta. Bet kuriame tyrime praktika yra labai svarbus komponentas. Tam aš pasiruošiau. Taip pat jūsų laukia namų darbai, kad įsitikintumėte, jog be proto nekopijuojate vykdomų komandų eilučių.
planas
Žingsnis
Technologija
Ištekliai
1
Vietinis veikimas (paruoškite žiniatinklio / „Android“ demonstracinius testus ir paleiskite juos vietoje)
Node.js, Selenas, Appium
2
Versijų valdymo sistemos
git
3
Konteineravimas
Docker, seleno tinklelis, selenoidas (žiniatinklis, „Android“)
4
CI/CD
Gitlab CI
5
Debesų platformos
"Google" debesies platforma
6
Orkestravimas
Kubernetes
7
Infrastruktūra kaip kodas (IaC)
Terraform, Ansible
Kiekvieno skyriaus struktūra
Kad pasakojimas būtų aiškus, kiekvienas skyrius aprašomas taip:
- trumpas technologijos aprašymas,
- vertė automatizavimo infrastruktūrai,
- dabartinės infrastruktūros būklės iliustracija,
- nuorodos į studijas,
- panašių įrankių.
1. Vykdykite bandymus vietoje
Trumpas technologijos aprašymas
Tai tik parengiamasis veiksmas, norint atlikti demonstracinius bandymus vietoje ir patikrinti, ar jie yra sėkmingi. Praktinėje dalyje naudojamas Node.js, tačiau programavimo kalba ir platforma taip pat nėra svarbios ir galite naudoti tas, kurios naudojamos jūsų įmonėje.
Tačiau kaip automatizavimo įrankius rekomenduoju naudoti „Selenium WebDriver“, skirtą žiniatinklio platformoms, ir „Appium“, skirtą „Android“ platformai, nes kituose veiksmuose naudosime „Docker“ vaizdus, kurie yra pritaikyti dirbti būtent su šiais įrankiais. Be to, atsižvelgiant į darbo reikalavimus, šios priemonės yra paklausiausios rinkoje.
Kaip galbūt pastebėjote, svarstome tik žiniatinklio ir „Android“ testus. Deja, iOS yra visiškai kitokia istorija (ačiū Apple). Planuoju pristatyti su IOS susijusius sprendimus ir praktiką būsimose dalyse.
Vertė automatizavimo infrastruktūrai
Žvelgiant iš infrastruktūros perspektyvos, veikimas vietoje nesuteikia jokios vertės. Tik patikrinate, ar bandymai vykdomi vietiniame kompiuteryje vietinėse naršyklėse ir treniruokliuose. Bet bet kuriuo atveju tai yra būtinas atspirties taškas.
Dabartinės infrastruktūros būklės iliustracija
Nuorodos tyrinėti
Panašūs įrankiai
- bet kokia jums patinkanti programavimo kalba, kartu su Selenium/Appium testais;
- bet kokie testai;
- bet kuris bandomasis bėgikas.
2. Versijų valdymo sistemos („Git“)
Trumpas technologijos aprašymas
Niekam nebus didelis atradimas, jei pasakysiu, kad versijų kontrolė yra nepaprastai svarbi kūrimo dalis tiek komandoje, tiek individualiai. Remiantis įvairiais šaltiniais, galima drąsiai teigti, kad Gitas yra populiariausias atstovas. Versijų valdymo sistema suteikia daug privalumų, tokių kaip bendrinimas kodu, versijų saugojimas, ankstesnių šakų atkūrimas, projekto istorijos stebėjimas ir atsarginės kopijos. Mes nenagrinėsime kiekvieno punkto išsamiai, nes esu tikras, kad esate su juo gerai susipažinę ir naudojate jį savo kasdieniame darbe. Bet jei staiga ne, rekomenduoju pristabdyti šio straipsnio skaitymą ir kuo greičiau užpildyti šią spragą.
Vertė automatizavimo infrastruktūrai
Ir čia galite užduoti pagrįstą klausimą: „Kodėl jis mums pasakoja apie Gitą? Visi tai žino ir naudoja jį tiek kūrimo kodui, tiek automatinio testavimo kodui. Būsite visiškai teisūs, tačiau šiame straipsnyje kalbame apie infrastruktūrą, o šis skyrius veikia kaip 7 skyriaus „Infrastruktūra kaip kodas (IaC)“ peržiūra. Mums tai reiškia, kad visa infrastruktūra, įskaitant testavimą, yra aprašyta kodo forma, todėl galime jai pritaikyti ir versijų kūrimo sistemas bei gauti panašią naudą kaip ir kuriant bei automatizuojant kodą.
Išsamiau apžvelgsime IaC 7 veiksme, tačiau net ir dabar galite pradėti naudoti „Git“ vietoje, sukurdami vietinę saugyklą. Bendras vaizdas bus išplėstas, kai į infrastruktūrą įtrauksime nuotolinę saugyklą.
Dabartinės infrastruktūros būklės iliustracija
Nuorodos tyrinėti
Panašūs įrankiai
3. Konteineris (Docker)
Trumpas technologijos aprašymas
Norėdami parodyti, kaip konteinerizavimas pakeitė žaidimo taisykles, grįžkime į praeitį kelis dešimtmečius. Tada žmonės pirko ir naudojo serverių įrenginius programoms paleisti. Tačiau daugeliu atvejų reikalingi paleisties ištekliai nebuvo žinomi iš anksto. Dėl to įmonės išleido pinigus brangiems, galingiems serveriams įsigyti, tačiau dalis šių pajėgumų nebuvo visiškai išnaudoti.
Kitas evoliucijos etapas buvo virtualios mašinos (VM), kurios išsprendė pinigų švaistymo nepanaudotiems resursams problemą. Ši technologija leido paleisti programas nepriklausomai viena nuo kitos tame pačiame serveryje, skiriant visiškai izoliuotą erdvę. Bet, deja, bet kuri technologija turi savo trūkumų. Norint paleisti VM, reikia visos operacinės sistemos, kuri naudoja procesorių, RAM, saugyklą ir, priklausomai nuo OS, reikia atsižvelgti į licencijos išlaidas. Šie veiksniai turi įtakos pakrovimo greičiui ir apsunkina nešiojamumą.
O dabar pereiname prie konteinerizacijos. Ši technologija dar kartą išsprendžia ankstesnę problemą, nes konteineriuose nenaudojama visa OS, o tai atlaisvina daug resursų ir suteikia greitą bei lankstų nešiojamumo sprendimą.
Žinoma, konteinerių transportavimo technologija nėra jokia naujiena ir pirmą kartą buvo pristatyta 70-ųjų pabaigoje. Tais laikais buvo atlikta daug tyrimų, plėtros ir bandymų. Tačiau būtent „Docker“ pritaikė šią technologiją ir padarė ją lengvai prieinamą masėms. Šiais laikais, kai kalbame apie konteinerius, daugeliu atvejų turime omenyje Docker. Kai kalbame apie „Docker“ konteinerius, turime omenyje „Linux“ konteinerius. Konteineriams paleisti galime naudoti Windows ir macOS sistemas, tačiau svarbu suprasti, kad tokiu atveju atsiranda papildomas sluoksnis. Pavyzdžiui, „Docker“ sistemoje „Mac“ tyliai paleidžia konteinerius lengvoje „Linux“ virtualiojoje mašinoje. Prie šios temos grįšime, kai aptarsime Android emuliatorių veikimą konteineriuose, todėl čia yra labai svarbus niuansas, kurį reikia aptarti plačiau.
Vertė automatizavimo infrastruktūrai
Sužinojome, kad konteinerizavimas ir „Docker“ yra puikūs. Pažvelkime į tai automatizavimo kontekste, nes kiekvienas įrankis ar technologija turi išspręsti problemą. Apibūdinkime akivaizdžias testavimo automatizavimo problemas UI testų kontekste:
- daugybė priklausomybių diegiant seleną ir ypač Appium;
- naršyklių, simuliatorių ir tvarkyklių versijų suderinamumo problemos;
- nėra izoliuotos vietos naršyklėms / simuliatoriams, o tai ypač svarbu lygiagrečiam veikimui;
- sunku valdyti ir prižiūrėti, jei vienu metu reikia paleisti 10, 50, 100 ar net 1000 naršyklių.
Tačiau kadangi „Selenium“ yra populiariausias automatizavimo įrankis, o „Docker“ – populiariausias konteinerių talpinimo įrankis, nenuostabu, kad kažkas bandė juos sujungti, kad sukurtų galingą įrankį aukščiau paminėtoms problemoms spręsti. Panagrinėkime tokius sprendimus išsamiau.
Seleno tinklelis dokeryje
Šis įrankis yra populiariausias Selenium pasaulyje, skirtas kelioms naršyklėms paleisti keliuose kompiuteriuose ir valdyti jas iš centrinio mazgo. Norėdami pradėti, turite užregistruoti bent 2 dalis: šakotuvą ir mazgą (-us). Hub yra centrinis mazgas, kuris gauna visas užklausas iš testų ir paskirsto jas atitinkamiems mazgams. Kiekvienam Node galime konfigūruoti konkrečią konfigūraciją, pavyzdžiui, nurodydami norimą naršyklę ir jos versiją. Tačiau suderinamomis naršyklės tvarkyklėmis vis tiek turime pasirūpinti patys ir jas įdiegti norimuose Nodes. Dėl šios priežasties Selenium grid nenaudojamas gryna forma, išskyrus atvejus, kai reikia dirbti su naršyklėmis, kurių negalima įdiegti Linux OS. Visais kitais atvejais labai lankstus ir teisingas sprendimas būtų naudoti „Docker“ atvaizdus, kad paleistumėte „Selenium grid Hub“ ir „Nodes“. Šis metodas labai supaprastina mazgų valdymą, nes galime pasirinkti reikiamą vaizdą su jau įdiegtomis suderinamomis naršyklių ir tvarkyklių versijomis.
Nepaisant neigiamų atsiliepimų apie stabilumą, ypač kai lygiagrečiai veikia daug mazgų, seleno tinklelis vis dar yra populiariausias įrankis Seleno testams atlikti lygiagrečiai. Svarbu pažymėti, kad atvirajame kode nuolat atsiranda įvairių šio įrankio patobulinimų ir modifikacijų, kurios kovoja su įvairiomis kliūtimis.
Selenoidas žiniatinkliui
Šis įrankis yra proveržis seleno pasaulyje, nes jis veikia iš karto ir palengvino daugelio automatikos inžinierių gyvenimą. Visų pirma, tai nėra dar viena Selenium tinklelio modifikacija. Vietoj to kūrėjai Golang mieste sukūrė visiškai naują Selenium Hub versiją, kuri kartu su lengvais Docker vaizdais įvairioms naršyklėms suteikė postūmį plėtoti testavimo automatizavimą. Be to, Selenium Grid atveju turime iš anksto nustatyti visas reikalingas naršykles ir jų versijas, o tai nėra problema dirbant tik su viena naršykle. Tačiau kalbant apie kelias palaikomas naršykles, „Selenoid“ yra pirmasis sprendimas dėl savo „naršyklės pagal poreikį“ funkcijos. Viskas, ko mums reikia, yra iš anksto atsisiųsti reikiamus vaizdus su naršyklėmis ir atnaujinti konfigūracijos failą, su kuriuo sąveikauja Selenoid. Kai Selenoid gaus užklausą iš testų, jis automatiškai paleis norimą konteinerį su norima naršykle. Kai bandymas bus baigtas, Selenoid pašalins konteinerį ir taip atlaisvins išteklių būsimoms užklausoms. Šis metodas visiškai pašalina gerai žinomą „mazgų degradacijos“ problemą, su kuria dažnai susiduriame seleno tinklelyje.
Bet, deja, selenoidas vis dar nėra sidabrinė kulka. Gavome funkciją „Naršyklė pagal pareikalavimą“, tačiau funkcija „Ištekliai pagal pareikalavimą“ vis dar nepasiekiama. Norėdami naudoti Selenoid, turime jį įdiegti fizinėje aparatinėje įrangoje arba VM, o tai reiškia, kad turime iš anksto žinoti, kiek išteklių reikia skirti. Manau, tai nėra problema mažiems projektams, kuriuose lygiagrečiai veikia 10, 20 ar net 30 naršyklių. O kas, jei mums reikia 100, 500, 1000 ir daugiau? Nėra prasmės visą laiką išlaikyti ir mokėti už tiek daug išteklių. Šio straipsnio 5 ir 6 skyriuose aptarsime sprendimus, leidžiančius padidinti mastelį ir taip žymiai sumažinti įmonės išlaidas.
Selenoidas, skirtas Android
Po Selenoid, kaip žiniatinklio automatizavimo įrankio, sėkmės žmonės norėjo kažko panašaus ir „Android“. Ir atsitiko – „Selenoid“ buvo išleistas su „Android“ palaikymu. Aukšto lygio vartotojo požiūriu, veikimo principas panašus į interneto automatizavimą. Vienintelis skirtumas yra tas, kad vietoj naršyklės konteinerių Selenoid veikia Android emuliatoriaus konteineriai. Mano nuomone, šiuo metu tai yra galingiausias nemokamas įrankis, leidžiantis lygiagrečiai vykdyti Android testus.
Tikrai nenorėčiau kalbėti apie neigiamus šios priemonės aspektus, nes man jis labai patinka. Tačiau vis tiek yra tie patys trūkumai, kurie taikomi žiniatinklio automatizavimui ir yra susiję su mastelio keitimu. Be to, turime kalbėti apie dar vieną apribojimą, kuris gali nustebinti, jei įrankį nustatome pirmą kartą. Norint paleisti „Android“ vaizdus, mums reikia fizinio įrenginio arba VM su įdėtosios virtualizacijos palaikymu. Vadove parodysiu, kaip tai įjungti „Linux“ virtualioje mašinoje. Tačiau jei esate „MacOS“ vartotojas ir norite įdiegti „Selenoid“ vietoje, „Android“ testų paleisti nebus įmanoma. Bet visada galite paleisti „Linux“ VM vietoje su sukonfigūruota „įdėta virtualizacija“ ir įdiegti „Selenoid“ viduje.
Dabartinės infrastruktūros būklės iliustracija
Šiame straipsnyje mes pridėsime 2 infrastruktūros iliustravimo įrankius. Tai yra seleno tinklelis, skirtas žiniatinklio bandymams, ir selenoidas, skirtas „Android“ bandymams. „GitHub“ vadovėlyje taip pat parodysiu, kaip naudoti „Selenoid“ žiniatinklio testams vykdyti.
Nuorodos tyrinėti
Panašūs įrankiai
- Yra ir kitų konteinerių talpinimo įrankių, tačiau „Docker“ yra populiariausias. Jei norite išbandyti ką nors kita, atminkite, kad įrankiai, kuriuos aptarėme lygiagrečiai atlikti Seleno testus, neveiks.
- Kaip jau minėta, yra daug seleno tinklelio modifikacijų, pavyzdžiui,.
4.CI/CD
Trumpas technologijos aprašymas
Nuolatinio integravimo praktika yra gana populiari kuriant ir prilygsta versijų valdymo sistemoms. Nepaisant to, manau, kad terminologijoje yra painiavos. Šioje pastraipoje norėčiau aprašyti 3 šios technologijos modifikacijas mano požiūriu. Internete rasite daugybę straipsnių su įvairiomis interpretacijomis, ir visiškai normalu, jei jūsų nuomonė skiriasi. Svarbiausia, kad su kolegomis esate viename lape.
Taigi, yra 3 terminai: CI – nuolatinis integravimas, CD – nuolatinis pristatymas ir vėl CD – nuolatinis diegimas. (Toliau šiuos terminus vartosiu anglų kalba). Kiekviena modifikacija prideda keletą papildomų žingsnių į jūsų kūrimo dujotiekį. Bet žodis tęstinis (nepertraukiamas) yra svarbiausias dalykas. Šiame kontekste turime omenyje tai, kas vyksta nuo pradžios iki pabaigos, be pertrūkių ar rankinio įsikišimo. Šiame kontekste pažvelkime į CI & CD ir CD.
- Nuolatinė integracija tai yra pradinis evoliucijos žingsnis. Pateikę naują kodą serveriui, tikimės sulaukti greito atsiliepimo, kad pakeitimai yra tinkami. Paprastai CI apima statinių kodų analizės įrankių paleidimą ir vieneto / vidinius API testus. Tai leidžia mums gauti informaciją apie kodą per kelias sekundes / minutes.
- Nepertrauktos Pristatymas yra pažangesnis žingsnis, kai vykdome integravimo / vartotojo sąsajos testus. Tačiau šiame etape rezultatų nepasiekiame taip greitai, kaip naudojant CI. Pirma, tokio tipo bandymai užtrunka ilgiau. Antra, prieš paleidžiant, turime įdiegti pakeitimus bandymo / sustojimo aplinkoje. Be to, jei kalbame apie mobiliojo ryšio kūrimą, atsiranda papildomas veiksmas, skirtas sukurti mūsų programos versiją.
- Nuolatinis diegimas daro prielaidą, kad mes automatiškai išleidžiame savo pakeitimus į gamybą, jei visi priėmimo testai buvo išlaikyti ankstesniuose etapuose. Be to, po išleidimo etapo galite konfigūruoti įvairius etapus, pvz., vykdyti gamybos dūmų testus ir rinkti dominančią metriką. Nuolatinis diegimas įmanomas tik gerai aprėpiant automatinius testus. Jei reikia kokių nors rankinių intervencijų, įskaitant testavimą, tai nebėra nepertraukiamas (nuolatinis). Tada galime pasakyti, kad mūsų vamzdynas atitinka tik nuolatinio pristatymo praktiką.
Vertė automatizavimo infrastruktūrai
Šiame skyriuje turėčiau paaiškinti, kad kai kalbame apie galutinius vartotojo sąsajos testus, tai reiškia, kad turėtume įdiegti pakeitimus ir susijusias paslaugas, kad išbandytume aplinkas. Nuolatinis integravimas – procesas netaikomas šiai užduočiai ir mes turime pasirūpinti bent jau nuolatinio pristatymo praktikos įgyvendinimu. Nuolatinis diegimas taip pat prasmingas UI testų kontekste, jei ketiname juos vykdyti gamyboje.
Ir prieš pažvelgdami į architektūros pasikeitimo iliustraciją, noriu pasakyti keletą žodžių apie GitLab CI. Skirtingai nuo kitų CI / CD įrankių, „GitLab“ suteikia nuotolinę saugyklą ir daugybę kitų papildomų funkcijų. Taigi, „GitLab“ yra daugiau nei CI. Tai apima šaltinio kodo valdymą, judrų valdymą, CI / CD vamzdynus, registravimo įrankius ir metrikos rinkimą iš dėžutės. „GitLab“ architektūra susideda iš „Gitlab CI/CD“ ir „GitLab Runner“. Čia yra trumpas aprašymas iš oficialios svetainės:
Gitlab CI/CD yra žiniatinklio programa su API, kuri saugo savo būseną duomenų bazėje, tvarko projektus/versijas ir teikia vartotojo sąsają. „GitLab Runner“ yra programa, kuri apdoroja kūrinius. Jis gali būti įdiegtas atskirai ir veikia su GitLab CI / CD per API. Norint vykdyti bandymus, reikia ir „Gitlab“ egzemplioriaus, ir „Runner“.
Dabartinės infrastruktūros būklės iliustracija
Nuorodos tyrinėti
Panašūs įrankiai
- Ir daugelis kitų
5. Debesų platformos
Trumpas technologijos aprašymas
Šiame skyriuje kalbėsime apie populiarią tendenciją, vadinamą „viešaisiais debesimis“. Nepaisant milžiniškos naudos, kurią teikia aukščiau aprašytos virtualizacijos ir konteinerių sudarymo technologijos, mums vis tiek reikia skaičiavimo išteklių. Įmonės perka brangius serverius ar nuomoja duomenų centrus, tačiau tokiu atveju reikia atlikti skaičiavimus (kartais nerealu), kiek mums reikės resursų, ar juos naudosime 24/7 ir kokiems tikslams. Pavyzdžiui, gamybai reikalingas serveris, veikiantis XNUMX valandas per parą, XNUMX dienas per savaitę, bet ar mums reikia panašių išteklių testavimui ne darbo valandomis? Tai taip pat priklauso nuo atliekamo tyrimo tipo. Pavyzdys galėtų būti apkrovos/streso testai, kuriuos planuojame atlikti ne darbo valandomis, kad gautume rezultatus kitą dieną. Tačiau neabejotinai serverio prieinamumas XNUMX valandas per parą, XNUMX dienas per savaitę nebūtinas atliekant automatinius testus ir ypač ne rankinio testavimo aplinkas. Tokiose situacijose būtų gerai pagal poreikį gauti tiek išteklių, kiek reikia, juos panaudoti ir nebemokėti, kai jų nebereikia. Be to, būtų puiku juos gauti akimirksniu, spustelėjus kelis pelės mygtukus arba paleidus keletą scenarijų. Tam naudojami viešieji debesys. Pažvelkime į apibrėžimą:
„Viešas debesis apibrėžiamas kaip kompiuterinės paslaugos, kurias viešuoju internetu siūlo trečiųjų šalių tiekėjai, todėl jomis gali naudotis visi, kurie nori jomis naudotis ar įsigyti. Jie gali būti nemokami arba parduodami pagal pareikalavimą, todėl klientai gali mokėti tik už naudojimą už procesoriaus ciklus, saugyklą arba pralaidumą.
Yra nuomonė, kad viešieji debesys yra brangūs. Tačiau pagrindinė jų idėja yra sumažinti įmonės išlaidas. Kaip minėta anksčiau, viešieji debesys leidžia gauti išteklių pagal poreikį ir mokėti tik už jų naudojimo laiką. Taip pat kartais pamirštame, kad darbuotojai gauna atlyginimus, o specialistai taip pat yra brangus resursas. Reikia atsižvelgti į tai, kad viešieji debesys žymiai palengvina infrastruktūros palaikymą, o tai leidžia inžinieriams sutelkti dėmesį į svarbesnes užduotis.
Vertė automatizavimo infrastruktūrai
Kokių konkrečių išteklių mums reikia norint atlikti galutinius vartotojo sąsajos testus? Iš esmės tai yra virtualios mašinos arba klasteriai (apie Kubernetes kalbėsime kitame skyriuje), skirtos naršyklėms ir emuliatoriams paleisti. Kuo daugiau naršyklių ir emuliatorių norime paleisti vienu metu, tuo daugiau procesoriaus ir atminties reikia ir tuo daugiau pinigų turime už tai mokėti. Taigi viešieji debesys testų automatizavimo kontekste leidžia mums pagal poreikį paleisti daugybę (100, 200, 1000...) naršyklių/emuliatorių, gauti testų rezultatus kuo greičiau ir nebemokėti už tokius beprotiškai daug resursų reikalaujančius dalykus. galia.
Populiariausi debesų paslaugų teikėjai yra „Amazon Web Services“ (AWS), „Microsoft Azure“, „Google Cloud Platform“ (GCP). Vadove pateikiami GCP naudojimo pavyzdžiai, tačiau apskritai nesvarbu, ką naudojate automatizavimo užduotims atlikti. Visi jie suteikia maždaug tą patį funkcionalumą. Paprastai, rinkdamasi teikėją, vadovybė sutelkia dėmesį į bendrą įmonės infrastruktūrą ir verslo reikalavimus, o tai nepatenka į šio straipsnio taikymo sritį. Automatikos inžinieriams bus įdomiau palyginti debesų tiekėjų naudojimą su debesų platformų naudojimu specialiai testavimo tikslais, pavyzdžiui, Sauce Labs, BrowserStack, BitBar ir pan. Taigi padarykime tai ir mes! Mano nuomone, „Sauce Labs“ yra garsiausias debesų testavimo ūkis, todėl ir panaudojau jį palyginimui.
GCP vs Sauce Labs automatizavimo tikslais:
Įsivaizduokime, kad vienu metu turime atlikti 8 žiniatinklio ir 8 „Android“ testus. Tam naudosime GCP ir paleisime 2 virtualias mašinas su Selenoid. Pirmajame iškelsime 8 konteinerius su naršyklėmis. Antrajame yra 8 konteineriai su emuliatoriais. Pažiūrėkime į kainas:
Norint paleisti vieną konteinerį su „Chrome“, mums reikia n1-standartas-1 automobilis. „Android“ atveju taip bus n1-standartas-4 vienam emuliatoriui. Tiesą sakant, lankstesnis ir pigesnis būdas yra nustatyti konkrečias vartotojo procesoriaus / atminties reikšmes, tačiau šiuo metu tai nėra svarbu palyginimui su Sauce Labs.
O čia yra Sauce Labs naudojimo tarifai:
Manau, kad jūs jau pastebėjote skirtumą, bet vis tiek pateiksiu lentelę su mūsų užduoties skaičiavimais:
Reikalingi ištekliai
Kas mėnesį
Darbo valandos(8–8 val.)
Darbo valandos+ Aplenkiamas
GCP žiniatinkliui
n1-standartas-1 x 8 = n1-standartas-8
$194.18
23 dienos * 12 val. * 0.38 = 104.88 USD
23 dienos * 12 val. * 0.08 = 22.08 USD
Sauce Labs for Web
„Virtual Cloud8“ lygiagrečiai bandymai
$1.559
-
-
GCP, skirta „Android“.
n1-standartas-4 x 8: n1-standartas-16
$776.72
23 dienos * 12 val. * 1.52 = 419.52 USD
23 dienos * 12 val. * 0.32 = 88.32 USD
„Sauce Labs“, skirta „Android“.
„Real Device Cloud 8“ lygiagrečiai atliekami bandymai
$1.999
-
-
Kaip matote, sąnaudų skirtumas yra didžiulis, ypač jei testus atliekate tik per dvylikos valandų darbo laikotarpį. Bet jūs galite dar labiau sumažinti išlaidas, jei naudojate prevencines mašinas. Kas tai?
Išankstinė VM yra egzempliorius, kurį galite sukurti ir paleisti už daug mažesnę kainą nei įprasti egzemplioriai. Tačiau Compute Engine gali nutraukti (išvengti) šiuos atvejus, jei jai reikia prieigos prie tų išteklių kitoms užduotims atlikti. Išankstiniai atvejai yra Compute Engine talpos perteklius, todėl jų prieinamumas priklauso nuo naudojimo.
Jei jūsų programos yra atsparios gedimams ir gali atlaikyti galimas atvejo prevencijas, iš anksto išvengiamieji egzemplioriai gali žymiai sumažinti Compute Engine išlaidas. Pavyzdžiui, paketinio apdorojimo užduotys gali būti vykdomos iš anksto neapdorotuose egzemplioriuose. Jei kai kurie iš šių atvejų baigiasi apdorojimo metu, darbas sulėtėja, bet visiškai nesustoja. Išankstiniai egzemplioriai užbaigia paketinio apdorojimo užduotis nesukeldami papildomo darbo krūvio esamiems egzemplioriams ir nereikalaujant mokėti visos kainos už papildomus įprastus egzempliorius.
Ir vis dar nesibaigė! Tiesą sakant, esu tikras, kad niekas neatlieka testų 12 valandų be pertraukos. Ir jei taip, tuomet galite automatiškai paleisti ir sustabdyti virtualias mašinas, kai jų nereikia. Faktinis naudojimo laikas gali būti sutrumpintas iki 6 valandų per dieną. Tada mokėjimas mūsų užduoties kontekste sumažės iki 11 USD per mėnesį už 8 naršykles. Argi tai ne nuostabu? Tačiau naudodamiesi prevencinėmis mašinomis turime būti atsargūs ir pasiruošę trikdžiams ir nestabilumui, nors tokias situacijas galima numatyti ir tvarkyti programinėje įrangoje. Tai verta!
Bet jokiu būdu nesakau „niekada nenaudokite debesų bandymų fermų“. Jie turi nemažai privalumų. Visų pirma, tai ne šiaip virtuali mašina, o visavertis testavimo automatizavimo sprendimas, turintis funkcionalumo rinkinį iš karto: nuotolinė prieiga, žurnalai, ekrano kopijos, vaizdo įrašymas, įvairios naršyklės ir fiziniai mobilieji įrenginiai. Daugeliu atvejų tai gali būti labai prašmatni alternatyva. Testavimo platformos ypač naudingos IOS automatizavimui, kai viešieji debesys gali pasiūlyti tik Linux/Windows sistemas. Tačiau apie iOS kalbėsime kituose straipsniuose. Rekomenduoju visada žiūrėti į situaciją ir pradėti nuo užduočių: vienais atvejais naudotis viešaisiais debesimis yra pigiau ir efektyviau, o kitais – bandomosios platformos tikrai vertos išleistų pinigų.
Dabartinės infrastruktūros būklės iliustracija
Nuorodos tyrinėti
Panašūs įrankiai:
6. Orkestravimas
Trumpas technologijos aprašymas
Turiu gerų naujienų – jau beveik baigiame straipsnį! Šiuo metu mūsų automatizavimo infrastruktūrą sudaro žiniatinklio ir „Android“ testai, kuriuos lygiagrečiai vykdome per GitLab CI, naudodami „Docker“ įgalintus įrankius: Selenium grid ir Selenoid. Be to, mes naudojame virtualias mašinas, sukurtas naudojant GCP, kad talpintume konteinerius su naršyklėmis ir emuliatoriais. Siekdami sumažinti išlaidas, šias virtualias mašinas paleidžiame tik pagal poreikį ir sustabdome, kai testavimas neatliekamas. Ar yra dar kas nors, kas galėtų pagerinti mūsų infrastruktūrą? Atsakymas yra taip! Susipažinkite – Kubernetes (K8s)!
Pirmiausia pažiūrėkime, kaip žodžiai orkestravimas, klasteris ir „Kubernetes“ yra susiję vienas su kitu. Aukšto lygio orkestravimas yra sistema, kuri diegia ir valdo programas. Bandymų automatizavimui tokios talpyklos programos yra seleno tinklelis ir selenoidas. Docker ir K8 papildo vienas kitą. Pirmasis naudojamas programos diegimui, antrasis - orkestravimui. Savo ruožtu K8s yra klasteris. Klasterio užduotis yra naudoti VM kaip mazgus, leidžiančius viename serveryje (klasteryje) įdiegti įvairias funkcijas, programas ir paslaugas. Jei kuris nors iš mazgų sugenda, kiti mazgai pasiims, o tai užtikrina nepertraukiamą mūsų programos veikimą. Be to, K8s turi svarbias su mastelio keitimu susijusias funkcijas, kurių dėka mes automatiškai gauname optimalų išteklių kiekį pagal apkrovą ir nustatytus limitus.
Tiesą sakant, rankinis „Kubernetes“ diegimas nuo nulio nėra nereikšminga užduotis. Paliksiu nuorodą į garsųjį vadovą „Kubernetes The Hard Way“ ir, jei susidomėjote, galite tai praktikuoti. Tačiau, laimei, yra alternatyvių metodų ir priemonių. Lengviausias būdas yra naudoti Google Kubernetes Engine (GKE) GCP, kuris leis jums gauti paruoštą klasterį keliais paspaudimais. Rekomenduoju naudoti šį metodą pradedant mokytis, nes tai leis jums sutelkti dėmesį į mokymąsi, kaip naudoti K8 savo užduotims, o ne mokytis, kaip turėtų būti integruoti vidiniai komponentai.
Vertė automatizavimo infrastruktūrai
Pažvelkime į keletą svarbių funkcijų, kurias suteikia K8s:
- taikomųjų programų diegimas: kelių mazgų klasterio naudojimas vietoj VM;
- dinaminis mastelio keitimas: sumažina išteklių, kurie naudojami tik pagal poreikį, sąnaudas;
- savaiminis išgydymas: automatinis ankščių atkūrimas (dėl to atkuriami ir konteineriai);
- naujinimų diegimas ir pakeitimų atšaukimas be prastovų: atnaujinimo įrankiai, naršyklės ir emuliatoriai nenutraukia esamų vartotojų darbo
Tačiau K8s vis dar nėra sidabrinė kulka. Norėdami suprasti visus mūsų svarstomų įrankių (Selenium grid, Selenoid) pranašumus ir apribojimus, trumpai aptarsime K8 struktūrą. Klasteryje yra dviejų tipų mazgai: pagrindiniai mazgai ir darbininkų mazgai. Pagrindiniai mazgai yra atsakingi už valdymo, diegimo ir planavimo sprendimus. Darbuotojų mazgai yra ten, kur paleidžiamos programos. Mazguose taip pat yra konteinerio vykdymo aplinka. Mūsų atveju tai yra Docker, atsakingas už su konteineriais susijusias operacijas. Tačiau yra ir, pavyzdžiui, alternatyvių sprendimų. Svarbu suprasti, kad pleiskanojimas arba savaiminis gijimas netaikomas konteineriams. Tai įgyvendinama pridedant/sumažinus ankščių, kuriose savo ruožtu yra konteinerių, skaičių (dažniausiai po vieną konteinerį po vieną, bet priklausomai nuo užduoties gali būti ir daugiau). Aukšto lygio hierarchiją sudaro darbuotojų mazgai, kurių viduje yra ankštys, kurių viduje yra pakeliami konteineriai.
Mastelio keitimo funkcija yra pagrindinė ir gali būti taikoma tiek klasterio mazgų telkinio mazgams, tiek mazgo grupėms. Yra 2 mastelio keitimo tipai, taikomi ir mazgams, ir ankštims. Pirmasis tipas yra horizontalus – mastelio keitimas vyksta didinant mazgų/podų skaičių. Šis tipas yra labiau tinkamas. Antrasis tipas yra atitinkamai vertikalus. Mastelio keitimas atliekamas didinant mazgų / ankščių dydį, o ne jų skaičių.
Dabar pažvelkime į savo įrankius aukščiau pateiktų terminų kontekste.
Seleno tinklelis
Kaip minėta anksčiau, seleno tinklelis yra labai populiarus įrankis ir nenuostabu, kad jis buvo talpinamas. Todėl nenuostabu, kad seleno tinklelis gali būti naudojamas K8. Pavyzdį, kaip tai padaryti, galite rasti oficialioje K8s saugykloje. Kaip įprasta, skyriaus pabaigoje pridedu nuorodas. Be to, vadove parodyta, kaip tai padaryti naudojant Terraform. Taip pat yra instrukcijų, kaip padidinti rinkinių, kuriose yra naršyklės konteinerių, skaičių. Tačiau automatinio mastelio keitimo funkcija K8s vis dar nėra visiškai akivaizdi užduotis. Pradėjęs studijuoti neradau jokių praktinių nurodymų ar rekomendacijų. Po kelių tyrimų ir eksperimentų, padedami „DevOps“ komandos, pasirinkome konteinerių su reikiamomis naršyklėmis kėlimą viename bloke, kuris yra viename darbuotojų mazge. Šis metodas leidžia taikyti horizontalaus mazgų mastelio strategiją didinant jų skaičių. Tikiuosi, kad ateityje tai pasikeis ir matysime vis daugiau geresnių požiūrių ir paruoštų sprendimų aprašymų, ypač išleidus Selenium grid 4 su pakeista vidine architektūra.
Selenoidas:
Selenoidų diegimas K8 šiuo metu yra didžiausias nusivylimas. Jie nesuderinami. Teoriškai Selenoid talpyklą galime pakelti dėžutės viduje, bet kai Selenoid pradės paleisti konteinerius su naršyklėmis, jie vis tiek bus toje pačioje talpykloje. Dėl to mastelio keitimas neįmanomas, todėl Selenoid darbas klasteryje nesiskiria nuo darbo virtualioje mašinoje. Istorijos pabaiga.
Mėnulis:
Žinodami šią kliūtį dirbant su Selenoid, kūrėjai išleido galingesnį įrankį pavadinimu Moon. Šis įrankis iš pradžių buvo sukurtas dirbti su Kubernetes, todėl automatinio mastelio keitimo funkciją galima ir reikia naudoti. Be to, sakyčiau, kad šiuo metu taip yra vienišas įrankis seleno pasaulyje, turintis vietinį K8s klasterio palaikymą (nebepasiekiamas, žr. kitą įrankį ). Pagrindinės Mėnulio funkcijos, teikiančios šią paramą:
Visiškai be pilietybės. Selenoidas saugo atmintyje informaciją apie šiuo metu vykdomas naršyklės sesijas. Jei dėl kokių nors priežasčių jo procesas užstringa, prarandamos visos vykdomos sesijos. Mėnulis, priešingai, neturi vidinės būsenos ir gali būti atkartotas duomenų centruose. Naršyklės seansai išlieka gyvi, net jei sugenda viena ar daugiau kopijų.
Taigi, Mėnulis yra puikus sprendimas, tačiau yra viena problema: jis nėra nemokamas. Kaina priklauso nuo seansų skaičiaus. Nemokamai galite paleisti tik 0–4 seansus, o tai nėra ypač naudinga. Tačiau nuo penktos sesijos turėsite sumokėti 5 USD už kiekvieną. Situacija įvairiose įmonėse gali skirtis, tačiau mūsų atveju naudoti Moon yra beprasmiška. Kaip aprašiau aukščiau, galime paleisti VM su Selenium Grid pagal poreikį arba padidinti mazgų skaičių klasteryje. Maždaug vienam konvejeriui paleidžiame 500 naršyklių ir sustabdome visus išteklius, kai bus baigti bandymai. Jei naudotume Mėnulį, turėtume mokėti papildomus 500 x 5 = 2500 USD per mėnesį, nesvarbu, kaip dažnai atliekame testus. Vėlgi, aš nesakau, kad nenaudokite Moon. Jūsų užduotims tai gali būti nepakeičiamas sprendimas, pavyzdžiui, jei jūsų organizacijoje yra daug projektų / komandų ir jums reikia didžiulio bendro klasterio visiems. Kaip visada, pabaigoje palieku nuorodą ir rekomenduoju atlikti visus reikiamus skaičiavimus jūsų užduoties kontekste.
Kalista: (Dėmesio! Tai nėra originaliame straipsnyje ir yra tik vertime į rusų kalbą)
Kaip sakiau, Selenas yra labai populiarus įrankis, o IT sritis labai sparčiai vystosi. Kol dirbau prie vertimo, žiniatinklyje pasirodė naujas daug žadantis įrankis Callisto (labas Cypress ir kiti seleno žudikai). Jis savaime veikia su K8 ir leidžia paleisti selenoidinius konteinerius ankštyse, paskirstytuose mazguose. Viskas veikia iš karto, įskaitant automatinį mastelio keitimą. Fantastiška, bet reikia išbandyti. Man jau pavyko įdiegti šį įrankį ir atlikti keletą eksperimentų. Tačiau dar per anksti daryti išvadas, gavęs rezultatus per ilgą atstumą, galbūt būsimuose straipsniuose padarysiu apžvalgą. Kol kas palieku tik nuorodas nepriklausomiems tyrimams.
Dabartinės infrastruktūros būklės iliustracija
Nuorodos tyrinėti
Panašūs įrankiai
7. Infrastruktūra kaip kodas (IAC)
Trumpas technologijos aprašymas
Ir dabar mes einame į paskutinę dalį. Paprastai už šią technologiją ir susijusias užduotis automatikos inžinieriai neatsako. Ir tam yra priežasčių. Pirma, daugelyje organizacijų infrastruktūros klausimus kontroliuoja „DevOps“ skyrius, o kūrimo komandoms nelabai rūpi, kas verčia dujotiekį veikti ir kaip reikia palaikyti viską, kas su juo susiję. Antra, būkime sąžiningi, daugelyje įmonių vis dar nepriimta Infrastruktūros kaip kodekso (IAC) praktika. Tačiau tai neabejotinai tapo populiaria tendencija ir svarbu stengtis dalyvauti su ja susijusiuose procesuose, požiūriuose ir priemonėse. Arba bent jau atnaujinkite informaciją.
Pradėkime nuo motyvacijos naudoti šį metodą. Jau aptarėme, kad norint atlikti bandymus „GitlabCI“, mums reikės mažiausiai išteklių, kad galėtume paleisti „Gitlab Runner“. Ir norėdami paleisti konteinerius su naršyklėmis / emuliatoriais, turime rezervuoti VM arba klasterį. Be testavimo išteklių, mums reikia daug pajėgumų, kad galėtume palaikyti kūrimo, sustojimo, gamybos aplinkas, įskaitant duomenų bazes, automatinius tvarkaraščius, tinklo konfigūracijas, apkrovos balansavimo priemones, vartotojo teises ir pan. Pagrindinis klausimas yra pastangos, reikalingos visa tai paremti. Yra keletas būdų, kaip galime atlikti pakeitimus ir įdiegti naujinimus. Pavyzdžiui, GCP kontekste galime naudoti UI konsolę naršyklėje ir visus veiksmus atlikti spustelėdami mygtukus. Alternatyva būtų naudoti API iškvietimus sąveikai su debesies objektais arba naudoti komandų eilutės įrankį gcloud norimoms manipuliacijoms atlikti. Tačiau esant tikrai daugybei skirtingų objektų ir infrastruktūros elementų, visas operacijas atlikti rankiniu būdu tampa sunku ar net neįmanoma. Be to, visi šie rankiniai veiksmai yra nekontroliuojami. Negalime pateikti jų peržiūrėti prieš vykdymą, naudoti versijų valdymo sistemą ir greitai atšaukti pakeitimų, dėl kurių įvyko incidentas. Norėdami išspręsti tokias problemas, inžinieriai sukūrė ir sukuria automatinius bash/shell scenarijus, kurie nėra daug geresni už ankstesnius metodus, nes juos nėra taip lengva greitai perskaityti, suprasti, prižiūrėti ir modifikuoti procedūriniu stiliumi.
Šiame straipsnyje ir vadove naudoju 2 įrankius, susijusius su IaC praktika. Tai yra „Terraform“ ir „Ansible“. Kai kurie žmonės mano, kad nėra prasmės juos naudoti vienu metu, nes jų funkcionalumas yra panašus ir juos galima pakeisti. Tačiau faktas yra tas, kad iš pradžių jiems skiriamos visiškai skirtingos užduotys. O tai, kad šios priemonės turi papildyti viena kitą, bendrame pristatyme patvirtino HashiCorp ir RedHat atstovaujantys kūrėjai. Koncepcinis skirtumas yra tas, kad „Terraform“ yra aprūpinimo įrankis patiems serveriams valdyti. Nors Ansible yra konfigūracijos valdymo įrankis, kurio užduotis yra įdiegti, konfigūruoti ir valdyti programinę įrangą šiuose serveriuose.
Kitas svarbus šių įrankių skiriamasis bruožas yra kodavimo stilius. Skirtingai nuo bash ir Ansible, Terraform naudoja deklaratyvų stilių, pagrįstą norimos galutinės būsenos, kurią reikia pasiekti atlikus vykdymą, aprašymu. Pavyzdžiui, jei ketiname sukurti 10 VM ir pritaikyti pakeitimus per Terraform, tada gausime 10 VM. Jei scenarijų paleisime dar kartą, nieko neatsitiks, nes jau turime 10 VM, o Terraform apie tai žino, nes saugo dabartinę infrastruktūros būseną būsenos faile. Tačiau Ansible naudoja procedūrinį metodą ir, jei paprašysite sukurti 10 VM, pirmą kartą paleidus gausime 10 VM, panašių į Terraform. Bet iš naujo paleidę jau turėsime 20 VM. Tai yra svarbus skirtumas. Procedūriniu stiliumi nesaugome dabartinės būsenos ir tiesiog aprašome veiksmų seką, kurią reikia atlikti. Žinoma, galime tvarkyti įvairias situacijas, pridėti keletą resursų egzistavimo ir esamos būklės patikrinimų, tačiau nėra prasmės gaišti laiko ir dėti pastangų šios logikos suvaldymui. Be to, tai padidina klaidų riziką.
Apibendrinant visa tai, kas išdėstyta pirmiau, galime daryti išvadą, kad Terraform ir deklaratyvus žymėjimas yra tinkamesnis serverių aprūpinimo įrankis. Bet geriau konfigūracijos valdymo darbą deleguoti Ansible. To nepaisydami, pažvelkime į naudojimo atvejus automatizavimo kontekste.
Vertė automatizavimo infrastruktūrai
Vienintelis svarbus dalykas, kurį čia reikia suprasti, yra tai, kad testavimo automatizavimo infrastruktūra turėtų būti laikoma visos įmonės infrastruktūros dalimi. Tai reiškia, kad visa IAC praktika turi būti taikoma globaliai visos organizacijos ištekliams. Kas už tai atsakingas, priklauso nuo jūsų procesų. DevOps komanda yra labiau patyrusi šiose problemose, jie mato visą vaizdą, kas vyksta. Tačiau kokybės užtikrinimo inžinieriai labiau įsitraukia į pastatų automatizavimo procesą ir vamzdyno struktūrą, o tai leidžia geriau matyti visus reikiamus pokyčius ir tobulėjimo galimybes. Geriausias variantas – dirbti kartu, keistis žiniomis ir idėjomis, kad būtų pasiektas laukiamas rezultatas.
Štai keli „Terraform“ ir „Ansible“ naudojimo bandymų automatizavimo ir įrankių, kuriuos aptarėme anksčiau, pavyzdžiai:
1. Apibūdinkite reikalingas VM ir klasterių charakteristikas ir parametrus naudojant Terraform.
2. Naudodami Ansible įdiekite testavimui reikalingus įrankius: docker, Selenoid, Selenium Grid ir atsisiųskite reikiamas naršyklių/emuliatorių versijas.
3. Naudodami Terraform apibūdinkite VM, kurioje bus paleistas GitLab Runner, charakteristikas.
4. Įdiekite „GitLab Runner“ ir reikiamus pridedamus įrankius naudodami Ansible, nustatykite nustatymus ir konfigūracijas.
Dabartinės infrastruktūros būklės iliustracija
Nuorodos tyrinėti:
Panašūs įrankiai
Apibendrinkime!
Žingsnis
Technologija
Ištekliai
Vertė automatizavimo infrastruktūrai
1
Vietinis bėgimas
Node.js, Selenas, Appium
- Populiariausi žiniatinklio ir mobiliojo ryšio įrankiai
- Palaiko daugybę kalbų ir platformų (įskaitant Node.js)
2
Versijų valdymo sistemos
git
- Panašūs pranašumai su plėtros kodu
3
Konteineravimas
Docker, seleno tinklelis, selenoidas (žiniatinklis, „Android“)
- Testų vykdymas lygiagrečiai
- Izoliuotos aplinkos
- Paprasti, lankstūs versijų atnaujinimai
- Dinamiškai stabdo nepanaudotus išteklius
- Lengva nustatyti
4
CI/CD
Gitlab CI
- Tikrina dalį dujotiekio
- Greitas Atsiliepimas
- Matomumas visai įmonei/komandai
5
Debesų platformos
"Google" debesies platforma
- Ištekliai pagal poreikį (mokame tik tada, kai reikia)
- Lengva valdyti ir atnaujinti
- Visų išteklių matomumas ir valdymas
6
Orkestravimas
Kubernetes
Kalbant apie konteinerius su naršyklėmis / emuliatoriais, esančiais ankštyse:
- Mastelio keitimas / automatinis mastelio keitimas
- Savaime išgijantis
- Atnaujinimai ir atšaukimai be pertrūkių
7
Infrastruktūra kaip kodas (IaC)
Terraform, Ansible
- Panaši nauda su plėtros infrastruktūra
- Visi kodo versijų kūrimo pranašumai
- Lengva atlikti pakeitimus ir prižiūrėti
- Visiškai automatizuota
Minčių žemėlapių diagramos: infrastruktūros raida
1 veiksmas: vietinis
2 veiksmas: VCS
3 žingsnis: talpinimas
4 veiksmas: CI / CD
5 veiksmas: debesų platformos
6 žingsnis: Orkestravimas
7 žingsnis: IaC
Kas toliau?
Taigi, tai yra straipsnio pabaiga. Bet pabaigai norėčiau su jumis sudaryti keletą susitarimų.
Iš tavo pusės
Kaip jau sakiau pradžioje, norėčiau, kad straipsnis būtų naudingas ir padėtų įgytas žinias pritaikyti realiame darbe. dar kartą pridedu.
Tačiau net ir po to nesustokite, praktikuokite, studijuokite aktualias nuorodas ir knygas, sužinokite, kaip tai veikia jūsų įmonėje, suraskite vietas, kurias būtų galima tobulinti, ir dalyvaukite tame. Sėkmės!
Iš mano pusės
Iš pavadinimo matosi, kad tai buvo tik pirmoji dalis. Nepaisant to, kad jis pasirodė gana didelis, svarbios temos čia vis dar neaptariamos. Antroje dalyje planuoju pažvelgti į automatikos infrastruktūrą IOS kontekste. Dėl Apple apribojimų paleisti iOS simuliatorius tik MacOS sistemose, mūsų sprendimų asortimentas susiaurinamas. Pavyzdžiui, negalime naudoti „Docker“ treniruokliui paleisti arba viešųjų debesų virtualioms mašinoms paleisti. Tačiau tai nereiškia, kad nėra kitų alternatyvų. Pasistengsiu jus informuoti apie pažangius sprendimus ir modernias priemones!
Be to, nepaminėjau gana didelių temų, susijusių su stebėjimu. 3 dalyje apžvelgsiu populiariausius infrastruktūros stebėjimo įrankius ir į kokius duomenis bei metrikas reikia atsižvelgti.
Ir, galiausiai. Ateityje planuoju išleisti vaizdo kursą apie bandymų infrastruktūros ir populiarių įrankių kūrimą. Šiuo metu internete yra nemažai kursų ir paskaitų apie DevOps, tačiau visa medžiaga pateikiama kūrimo, o ne testavimo automatizavimo kontekste. Šiuo klausimu man labai reikia atsiliepimų, ar toks kursas bus įdomus ir vertingas testuotojų ir automatikos inžinierių bendruomenei. Iš anksto dėkoju!
Šaltinis: www.habr.com