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 ja oleme j\u00f5udnud viimase jao juurde. \u00dcldiselt ei kuulu see tehnoloogia ja sellega seotud \u00fclesanded automaatika inseneride vastutusalasse. Sellel on omad p\u00f5hjused. Esiteks, paljudes organisatsioonides on infrastruktuurik\u00fcsimused DevOps osakonna kontrolli all ja arendusmeeskond ei muretse eriti selle p\u00e4rast, kuidas pipeline t\u00f6\u00f6tab ja kuidas k\u00f5ike, mis sellega seotud, toetada. Teiseks, olgem ausad, praktikad \"Infrastruktuur kui kood (IaC)\" ei ole veel paljudes ettev\u00f5tetes rakendatud. Kuid kindlasti on see saanud populaarseks suunaks ja on oluline p\u00fc\u00fcda olla seotud sellega seotud protsesside, l\u00e4henemiste ja t\u00f6\u00f6riistadega. V\u00f5i v\u00e4hemalt olla kursis arengutega.<\/p>\n
Alustame motivatsiooni arutamisega, miks selline l\u00e4henemine on vajalik. Oleme juba arutanud, et GitlabCI testide k\u00e4ivitamiseks vajame v\u00e4hemalt ressursse Gitlab Runner\u2019i k\u00e4ivitamiseks. Brauserite\/emulaatorite konteinerite k\u00e4ivitamiseks peame reserveerima VM v\u00f5i klastrit. Lisaks testimisressurssidele on meil vaja m\u00e4rkimisv\u00e4\u00e4rset hulka v\u00f5imekust, et toetada arenduse, staging\u2019i ja tootmisprotsesside keskkondi, mis h\u00f5lmavad ka andmebaase, automaatseid ajakavu, v\u00f5rgukonfiguratsioone, koormuse tasakaalustajat, kasutajate \u00f5igusi jne. Peamine probleem seisneb k\u00f5igi nende elementide toetamiseks vajalikes pingutustes. On mitmeid viise, kuidas saame muudatusi teha ja uuendusi rakendada. N\u00e4iteks GCP kontekstis saame kasutada brauseri kasutajaliidest ja t\u00e4ita k\u00f5ik toimingud nuppude klikkimise kaudu. Alternatiivne meetod v\u00f5ib olla API-kutsede kasutamine pilveelementidega suhtlemiseks v\u00f5i gcloud k\u00e4sureautomi kasutamine vajalike toimingute teostamiseks. Kuid t\u00f5eliselt suure hulga erinevate elementide ja infrastruktuuri komponentidega muutub k\u00f5ikide toimingute k\u00e4sitsi tegemine keeruliseks v\u00f5i isegi v\u00f5imatuks. Veelgi enam, k\u00f5ik need k\u00e4sitsi teostatavad toimingud on kontrollimata. Me ei saa neid enne t\u00e4itmist \u00fcle vaadata, versioonihalduss\u00fcsteemi kasutada ega kiiresti tagasi kerida muudatusi, mis viisid probleemini. Selliste probleemide lahendamiseks on insenerid loonud ja loovad automaatseid bash\/shell skripte, mis ei ole palju parem eelmistest meetoditest, kuna neid pole eriti lihtne kiiresti lugeda, m\u00f5ista, hallata ja protseduurilises stiilis muuta.<\/p>\n
Selles artiklis ja praktilises juhendis kasutan kahte t\u00f6\u00f6riista, mis kuuluvad IaC praktikasse. Need on Terraform ja Ansible. M\u00f5ned arvavad, et ei ole m\u00f5tet neid samal ajal kasutada, kuna nende funktsioonid on sarnased ja nad on omavahel asendatavad. Kuid asi on selles, et algselt on nende eesm\u00e4rgid t\u00e4iesti erinevad. Ja t\u00f5siasi, et need t\u00f6\u00f6riistad peavad \u00fcksteist t\u00e4iendama, kinnitati \u00fchises esitluses, mille tegid HashiCorpi ja RedHati esindavad arendajad. Kontseptuaalne erinevus seisneb selles, et Terraform on serverite haldamiseks m\u00f5eldud provisioningu t\u00f6\u00f6riist. Ansible aga on konfigureerimise haldamise t\u00f6\u00f6riist, mille \u00fclesanne on nendele serveritele tarkvara installimine, seadistamine ja haldamine.<\/p>\n
Teiste t\u00f6\u00f6riistade peamine erip\u00e4ra on koodi kirjutamise stiil. Erinevalt bash'ist ja Ansible'ist kasutab Terraform deklaratiivset l\u00e4henemist, mis p\u00f5hineb soovitud l\u00f5ppseisundi kirjelduse loomisel. N\u00e4iteks kui plaanime luua 10 virtuaalmasinat ja rakendada muudatusi l\u00e4bi Terraformi, siis saame 10 virtuaalmasinat. Kui skripti uuesti k\u00e4ivitada, ei juhtu midagi, kuna meil on juba 10 virtuaalmasinat ja Terraform teab sellest, kuna hoiab infrastruktuuri praegust olekut state-failis. Ansible aga kasutab protseduurilist l\u00e4henemist ja kui palume tal luua 10 virtuaalmasinat, siis esimesel k\u00e4ivitamisel saame 10 virtuaalmasinat, just nagu Terraformiga. Kuid p\u00e4rast korduvat k\u00e4ivitamist on meil juba 20 virtuaalmasinat. See ongi oluline erinevus. Protseduurilises stiilis ei hoia me praegust olekut ja kirjeldame lihtsalt sammude j\u00e4rjekorda, mis tuleb t\u00e4ita. Loomulikult saame k\u00e4sitleda erinevaid olukordi, lisada kontrollid ressursside olemasolu ja praeguse oleku kohta, kuid pole m\u00f5tet raisata meie aega ja pingutada selle loogika kontrollimisel. Lisaks suurendab see riski eksida.\u00a0<\/p>\n
Kokkuv\u00f5ttes v\u00f5ib \u00f6elda, et serverite provisionimiseks on k\u00f5ige sobivam t\u00f6\u00f6riist Terraform ja deklaratiivne s\u00fcntaks. Konfiguratsioonide haldamise \u00fclesanded on aga parem delegeerida Ansible'ile. Tutvume n\u00fc\u00fcd automaatika kontekstis kasutamise n\u00e4idetega.<\/p>\n
V\u00e4\u00e4rtus automaatimise infrastruktuurile<\/h3>\n
\n Siin on oluline m\u00f5ista, et testimise automatiseerimise infrastruktuur peab olema osa ettev\u00f5tte kogu infrastruktuurist. See t\u00e4hendab, et k\u00f5ik IaC-praktikad peaksid olema rakendatud globaalselt kogu organisatsiooni ressurssidele. Kes selle eest vastutab, s\u00f5ltub teie protsessidest. DevOps meeskond on selles osas kogenum, nad n\u00e4evad kogu toimuvat pilti. Siiski on QA-insenerid rohkem kaasatud automatiseerimise ehitamisse ja pipeline'i struktuuri, mis v\u00f5imaldab neil paremini n\u00e4ha vajalikke muudatusi ja t\u00e4iustamise v\u00f5imalusi. Parim lahendus on koost\u00f6\u00f6, teadmiste ja ideede jagamine soovitud tulemuse saavutamiseks.\u00a0<\/p>\n
Tulen v\u00e4lja 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. Installida Ansible'i abil testimiseks vajalikud t\u00f6\u00f6riistad: docker, Selenoid, Selenium Grid ning laadida alla vajalikud brauserite\/emulaatorite versioonid.<\/p>\n
3. Kirjeldada Terraformi kaudu VM-i omadused, kus t\u00f6\u00f6tab GitLab Runner.<\/p>\n
4. Installida Ansible'i abil GitLab Runner ja vajalikud seotud t\u00f6\u00f6riistad, seada konfiguratsioonid ja seaded.<\/p>\n
Praeguse infrastruktuuri seisundi illustreerimine<\/h3>\n
\n![\"DevOps](\"\/wp-content\/uploads\/2020\/04\/5d793a800a4ef62e181e6cb3a3f0544e.png\")
<\/p>\n
Uurimislingid:<\/h3>\n
<\/p>\n