Marathon<\/a><\/noindex>\u00a0<\/li>\n<\/ul>\n<\/p>\n
7. Infrastruktuur kui kood (IaC)<\/h2>\n
<\/p>\n
Tehnoloogia l\u00fchikirjeldus<\/h3>\n
\n Ja n\u00fc\u00fcd oleme j\u00f5udnud viimase jaotuseni. Tavaliselt ei kuulu see tehnoloogia ja seotud \u00fclesanded automatiseerimise inseneride vastutusalasse. Sellel on oma p\u00f5hjused. Esiteks on paljudes organisatsioonides infrastruktuuri k\u00fcsimused DevOps osakonna kontrolli all, ning arendustiimid ei muretse eriti selle p\u00e4rast, kuidas pipeline t\u00f6\u00f6tab ja kuidas k\u00f5ike, mis sellega seotud, toetada. Teiseks, olgem ausad, praktikat \u00abInfrastruktuur kui kood (IaC)\u00bb ei rakendata endiselt paljudes ettev\u00f5tetes. Kuid kindlasti on see saanud populaarseks suunaks ja on oluline p\u00fc\u00fcda olla seotud selle protsesside, l\u00e4henemiste ja t\u00f6\u00f6riistadega. V\u00f5i v\u00e4hemalt olla kursis toimuvaga.<\/p>\n
Alustame selle l\u00e4henemise kasutamise motivatsiooniga. Oleme juba arutanud, et GitlabCI testide k\u00e4ivitamiseks vajame v\u00e4hemalt ressursse Gitlab Runneri k\u00e4itamiseks. Ja et k\u00e4ivitada brauserite\/emulaatorite konteinerid, peame reserveerima VM-i v\u00f5i klastrit. Peale testimise ressursside on meil vaja m\u00e4rkimisv\u00e4\u00e4rset hulka v\u00f5imekust arenduskeskkondade, staging'i ja tootmise toetamiseks, mis h\u00f5lmab ka andmebaase, automaatseid ajakavasid, v\u00f5rgukonfiguratsioone, koormuste tasakaalustajat, kasutajate \u00f5igusi ja nii edasi. Peamine probleem on n\u00f5utavates pingutustes, et seda k\u00f5ike toetada. On mitmeid viise, kuidas saame muudatusi teha ja uuendusi v\u00e4lja anda. N\u00e4iteks GCP kontekstis saame kasutada brauseris UI-konsooli ja teha k\u00f5iki toiminguid, klikkides nuppudel. Alternatiivne meetod v\u00f5ib olla API-k\u00f5nede kasutamine pilveelementidega suhtlemiseks v\u00f5i k \u043a\u043e\u043c\u0430\u043d\u0434\u043d\u043e\u0439 \u0441\u0442\u0440\u043e\u043a\u0435 gcloud utiliidi rakendamine vajalike toimingute teostamiseks. Kuid t\u00f5eliselt suure hulga erinevate elementide ja infrastruktuuri elementide korral muutub k\u00f5iki toiminguid k\u00e4sitsi teostada raske v\u00f5i isegi v\u00f5imatuks. Veelgi enam, k\u00f5ik need k\u00e4sitsi toimingud on kontrollimatud. Me ei saa neid enne t\u00e4itmist \u00fcle vaadata, kasutada versioonihalduss\u00fcsteemi ega kiiresti tagasi kerida muudatusi, mis on p\u00f5hjustanud intsidenti. Selliste problemidega tegelemiseks on insenerid loonud ja loovad automaatseid bash\/shell-skripte, mis ei ole oluliselt parem kui eelnevad meetodid, kuna neid ei ole just lihtne kiiresti lugeda, m\u00f5ista, toetada ja modifitseerida protseduurilises stiilis.<\/p>\n
Selles artiklis ja praktilises juhendis kasutan kahte t\u00f6\u00f6riista, mis kuuluvad IaC praktika alla. Need on Terraform ja Ansible. M\u00f5ned arvavad, et nende samal ajal kasutamine pole m\u00f5ttekas, kuna nende funktsioonid on sarnased ja nad on \u00fcksteisega asendatavad. Kuid asi on selles, et algselt on nende eesm\u00e4rgid t\u00e4iesti erinevad. Ja fakt, et need t\u00f6\u00f6riistad peaksid teineteist t\u00e4iendama, on kinnitatud koosolekul, mille korraldasid HashiCorpi ja RedHati esindavad arendajad. Kontseptuaalne erinevus seisneb selles, et Terraform on serverite haldamiseks m\u00f5eldud provisioningu t\u00f6\u00f6riist, samas kui Ansible on konfiguratsioonihalduse t\u00f6\u00f6riist, mille eesm\u00e4rk on tarkvara installimine, seadistamine ja haldamine nendel serveritel.<\/p>\n
Teine oluline erinevus nende t\u00f6\u00f6riistade vahel on koodi kirjutamise stiil. Erinevalt bashist ja Ansible'ist kasutab Terraform deklaratiivset stiili, mis p\u00f5hineb soovitud l\u00f5ppseisundi kirjeldamisel, mida on vaja saavutada k\u00e4itamise tulemusena. N\u00e4iteks kui kavatseme luua 10 virtuaalmasinat (VM) ja rakendada muudatusi l\u00e4bi Terraformi, saame 10 VM-i. Kui k\u00e4ivitame skripti uuesti, siis ei toimu midagi, kuna meil on juba 10 VM-i ja Terraform teab sellest, kuna ta salvestab infrastruktuuri praeguse oleku olekufaile. Ansible seevastu kasutab protseduuri l\u00e4henemist ja kui palume sellel luua 10 VM-i, saame esimesel k\u00e4ivitamisel 10 VM-i, nagu ka Terraformiga. Kuid p\u00e4rast korduvat k\u00e4ivitamist on meil juba 20 VM-i. See on oluline erinevus. Protseduurilises stiilis me ei salvesta praegust seisundit, vaid kirjeldame lihtsalt samme, mida tuleb j\u00e4rgida. Loomulikult saame t\u00f6\u00f6tada erinevate olukordadega, lisada kontrollib, kas ressursid ja praegune seisund eksisteerivad, kuid pole m\u00f5tet raisata aega ja pingutada selle loogika kontrollimisega. Lisaks suurendab see viga tegemise riski.\u00a0<\/p>\n
Kokkuv\u00f5tteks v\u00f5ib \u00f6elda, et serverite provisionimiseks on sobivam t\u00f6\u00f6riist Terraform ja deklaratiivne m\u00e4rgistus. Kuid konfiguratsioonihalduse t\u00f6\u00f6 tuleks paremini delegeerida Ansible'ile. Kui oleme sellest aru saanud, vaatame automaatimise kontekstis kasutamise n\u00e4iteid.<\/p>\n
V\u00e4\u00e4rtus automatiseerimisinfrastruktuurile<\/h3>\n
\n Siin on oluline m\u00f5ista, et testimise automatiseerimise infrastruktuur peaks olema osa kogu ettev\u00f5tte infrastruktuurist. See t\u00e4hendab, et k\u00f5ik IaC-praktikad tuleb rakendada globaalselt kogu organisatsiooni ressurssidele. Kes on selle eest vastutav, s\u00f5ltub teie protsessidest. DevOps-meeskond on nendes k\u00fcsimustes kogenum, nad n\u00e4evad kogu toimuvat pilti. Samas on QA-insenerid rohkem kaasatud automatiseerimise ja pipeline'i \u00fclesehitamise protsessi, mis v\u00f5imaldab neil paremini n\u00e4ha k\u00f5iki vajalikke muudatusi ja t\u00e4iustamise v\u00f5imalusi. Parim variant on t\u00f6\u00f6tada koos, jagades teadmisi ja ideid oodatud tulemuse saavutamiseks.\u00a0<\/p>\n
Tooksin m\u00f5ned n\u00e4ited Terraformi ja Ansible'i kasutamisest testimise automatiseerimise kontekstis ning t\u00f6\u00f6riistadest, millest oleme varem r\u00e4\u00e4kinud:<\/p>\n
1. Kirjeldada Terraformi kaudu vajalikud omadused ja parameetrid VM-idele ja klastritele.<\/p>\n
2. Paigaldada Ansible'i abil vajalikud testimise t\u00f6\u00f6riistad: docker, Selenoid, Selenium Grid ja laadida vajalikud brauserite\/emulaatorite versioonid.<\/p>\n
3. Kirjeldada Terraformi kaudu VM-i omadused, milles t\u00f6\u00f6tatakse GitLab Runner.<\/p>\n
4. Paigaldada Ansible'i abil GitLab Runner ja vajalikud kaasnevad t\u00f6\u00f6riistad, m\u00e4\u00e4rata seaded ja konfiguratsioonid.<\/p>\n
Praeguse infrastruktuuri oleku illustreerimine<\/h3>\n
\n![\"DevOps'i](\"\/wp-content\/uploads\/2020\/04\/5d793a800a4ef62e181e6cb3a3f0544e.png\")
<\/p>\n
Uuringuks vajalikud lingid:<\/h3>\n
<\/p>\n