1-р хэсэг: Вэб/Андройд
тайлбар: Энэ нийтлэл нь эх өгүүллийн орос хэл дээрх орчуулга юм Гэсэн хэдий ч орос хэл рүү орчуулахдаа утгыг гажуудуулахгүйн тулд бүх зураглал, холбоос, ишлэл, нэр томъёог эх хэлээр нь хадгалсан болно. Танд аз жаргалтай суралцахыг хүсч байна!
Одоогийн байдлаар DevOps мэргэжил нь мэдээллийн технологийн салбарт хамгийн эрэлт хэрэгцээтэй байгаа. Хэрэв та алдартай ажил хайх сайтуудыг нээж, цалингаар нь шүүвэл DevOps-тэй холбоотой ажлууд жагсаалтын эхэнд байгааг харах болно. Гэсэн хэдий ч энэ нь голчлон "Ахлах" албан тушаалд хамаатай гэдгийг ойлгох нь чухал бөгөөд энэ нь нэр дэвшигч өндөр ур чадвар, технологи, багаж хэрэгслийн мэдлэгтэй байгааг илтгэнэ. Энэ нь үйлдвэрлэлийн тасралтгүй үйл ажиллагаатай холбоотой өндөр хариуцлагатай холбоотой юм. Гэсэн хэдий ч бид DevOps гэж юу болохыг мартаж эхэлсэн. Эхэндээ энэ нь тодорхой хүн, хэлтэс биш байсан. Энэ нэр томъёоны тодорхойлолтыг хайвал арга зүй, дадал зуршил, соёлын гүн ухаан, бүлэг ойлголт гэх мэт олон сайхан, зөв нэр үг олдоно.
Миний мэргэшсэн мэргэжил бол туршилтын автоматжуулалтын инженер (QA автоматжуулалтын инженер) боловч энэ нь зөвхөн автомат тест бичих эсвэл тестийн бүтцийн архитектур боловсруулахтай холбоотой байх ёсгүй гэж би үзэж байна. 2020 онд автоматжуулалтын дэд бүтцийн мэдлэг бас чухал юм. Энэ нь танд зорилгодоо нийцүүлэн туршилт явуулахаас эхлээд бүх оролцогч талуудад үр дүнг өгөх хүртэл автоматжуулалтын үйл явцыг өөрөө зохион байгуулах боломжийг олгоно. Үүний үр дүнд DevOps ур чадвар нь ажлаа дуусгахад зайлшгүй шаардлагатай. Энэ бүхэн сайн, гэхдээ харамсалтай нь асуудал байна (Спойлер: энэ нийтлэл нь энэ асуудлыг хялбарчлахыг оролдсон). Гол нь DevOps бол хэцүү юм. Энэ нь мэдээжийн хэрэг, учир нь компаниуд хийхэд хялбар зүйлд их хэмжээний мөнгө төлөхгүй ... DevOps ертөнцөд маш олон тооны хэрэгсэл, нэр томъёо, практикийг эзэмших шаардлагатай байдаг. Энэ нь карьерын эхэнд ялангуяа хэцүү бөгөөд хуримтлагдсан техникийн туршлагаас хамаардаг.
Эх сурвалж:
Энд бид магадгүй оршил хэсгийг дуусгаж, энэ өгүүллийн зорилгод анхаарлаа хандуулах болно.
Энэ нийтлэл юуны тухай вэ?
Энэ нийтлэлд би туршилтын автоматжуулалтын дэд бүтцийг бий болгох туршлагаа хуваалцах болно. Интернетэд янз бүрийн хэрэгсэл, тэдгээрийг хэрхэн ашиглах талаар олон мэдээллийн эх сурвалж байдаг, гэхдээ би тэдгээрийг зөвхөн автоматжуулалтын хүрээнд авч үзэхийг хүсч байна. Танаас өөр хэн ч боловсруулсан туршилтыг ажиллуулдаггүй эсвэл тэдгээрийг засварлахад санаа тавьдаггүй нөхцөл байдлыг олон автоматжуулалтын инженерүүд мэддэг гэдэгт би итгэдэг. Үүний үр дүнд тестүүд хуучирч, тэдгээрийг шинэчлэхэд цаг хугацаа зарцуулах шаардлагатай болдог. Дахин хэлэхэд, карьерын эхэнд энэ нь нэлээд хэцүү ажил байж болно: өгөгдсөн асуудлыг арилгахад туслах ямар хэрэгсэл, тэдгээрийг хэрхэн сонгох, тохируулах, арчлах талаар ухаалгаар шийдэх. Зарим тестерүүд DevOps (хүмүүс)-ээс тусламж хүсдэг бөгөөд үнэнийг хэлэхэд энэ арга нь үр дүнтэй байдаг. Ихэнх тохиолдолд бид бүх хамаарлыг харах боломжгүй тул энэ нь цорын ганц сонголт байж болох юм. Гэхдээ бидний мэдэж байгаагаар DevOps бол маш завгүй залуус, учир нь тэд байгууллага/багаас хамааран компанийн бүх дэд бүтэц, байршуулалт, хяналт, микро үйлчилгээ болон бусад ижил төстэй ажлуудын талаар бодох ёстой. Ердийнх шиг автоматжуулалт нь нэн тэргүүний асуудал биш юм. Ийм тохиолдолд эхнээс нь дуустал өөрсдийн зүгээс чадах бүхнээ хийхийг хичээх ёстой. Энэ нь хараат байдлыг бууруулж, ажлын урсгалыг хурдасгаж, ур чадвараа дээшлүүлж, юу болж байгааг илүү томоор харах боломжийг олгоно.
Нийтлэлд хамгийн алдартай, алдартай хэрэгслүүдийг танилцуулж, тэдгээрийг автоматжуулалтын дэд бүтцийг бий болгоход хэрхэн ашиглахыг алхам алхмаар харуулсан болно. Бүлэг бүрийг хувийн туршлагаар туршиж үзсэн хэрэгслээр төлөөлдөг. Гэхдээ энэ нь та ижил зүйлийг ашиглах ёстой гэсэн үг биш юм. Багаж хэрэгсэл нь өөрөө чухал биш, тэд гарч ирж, хуучирдаг. Бидний инженерийн даалгавар бол үндсэн зарчмуудыг ойлгох явдал юм: яагаад энэ бүлэг хэрэгсэл хэрэгтэй вэ, тэдгээрийн тусламжтайгаар бид ямар ажлын асуудлыг шийдэж чадна. Тийм ч учраас би хэсэг бүрийн төгсгөлд танай байгууллагад ашиглаж болох ижил төстэй хэрэгслүүдийн холбоосыг үлдээдэг.
Энэ нийтлэлд юу байхгүй байна
Энэ нийтлэл нь тодорхой хэрэгслүүдийн тухай биш гэдгийг дахин давтан хэлье, тиймээс тодорхой командуудын баримт бичиг, тайлбараас кодын оруулга байхгүй болно. Гэхдээ хэсэг бүрийн төгсгөлд би дэлгэрэнгүй судлах холбоосыг үлдээдэг.
Үүнийг дараах шалтгаанаар хийдэг.
- энэ материалыг янз бүрийн эх сурвалжаас (баримт бичиг, ном, видео курс) олоход хялбар байдаг;
- хэрэв бид илүү гүнзгийрээд эхэлбэл энэ өгүүллийн 10, 20, 30 хэсгийг бичих хэрэгтэй болно (төлөвлөгөө нь 2-3 байхад);
- Та ижил зорилгодоо хүрэхийн тулд өөр хэрэгслийг ашиглахыг хүсч магадгүй тул би таны цагийг үрэхийг хүсэхгүй байна.
Практик
Энэ материалыг зүгээр л уншаад мартчихдаггүй, уншигч бүрт хэрэгтэй байгаасай гэж би үнэхээр хүсч байна. Аливаа судалгаанд дадлага бол маш чухал бүрэлдэхүүн хэсэг юм. Үүний тулд би бэлдсэн. Гүйцэтгэж буй командынхаа мөрийг ухаалгаар хуулахгүй байх гэрийн даалгавар бас хүлээж байна.
Төлөвлөгөө
Алхам
Технологийн
арга хэрэгсэл
1
Орон нутгийн гүйлт (вэб / андройд демо тестүүдийг бэлтгэж, дотооддоо ажиллуулах)
Node.js, Selenium, Appium
2
Хувилбарын хяналтын системүүд
явах
3
Контейнер хийх
Docker, Selenium grid, Selenoid (Вэб, Android)
4
CI/CD
Gitlab CI
5
Үүлэн платформууд
Google Cloud платформ
6
Найрал хөгжим
Kubernetes
7
Дэд бүтэц нь код (IaC)
Terraform, Ansible
Хэсэг бүрийн бүтэц
Өгүүллийг ойлгомжтой байлгахын тулд хэсэг бүрийг дараах тойм дагуу тайлбарлав.
- технологийн товч тайлбар,
- автоматжуулалтын дэд бүтцийн үнэ цэнэ,
- дэд бүтцийн өнөөгийн байдлын зураглал,
- суралцах холбоосууд,
- ижил төстэй хэрэгслүүд.
1. Орон нутагт туршилт явуулах
Технологийн товч тайлбар
Энэ бол демо тестийг орон нутагт явуулж, тэнцсэн эсэхийг шалгах бэлтгэл алхам юм. Практик хэсэгт Node.js ашигладаг боловч програмчлалын хэл, платформ нь чухал биш бөгөөд та өөрийн компанид ашигладаг хэлийг ашиглаж болно.
Гэсэн хэдий ч автоматжуулалтын хэрэгслийн хувьд би вэб платформд Selenium WebDriver, Android платформд Appium ашиглахыг зөвлөж байна, учир нь бид дараагийн алхамуудад эдгээр хэрэгслүүдтэй тусгайлан ажиллахад тохирсон Docker зургуудыг ашиглах болно. Түүгээр ч зогсохгүй ажлын байрны шаардлагын дагуу эдгээр хэрэгслүүд нь зах зээлд хамгийн их эрэлт хэрэгцээтэй байдаг.
Та анзаарсан байх, бид зөвхөн вэб болон Android тестийг авч үздэг. Харамсалтай нь iOS бол огт өөр түүх юм (Apple-д баярлалаа). Би дараагийн хэсгүүдэд IOS-тэй холбоотой шийдэл, туршлагыг харуулахаар төлөвлөж байна.
Автоматжуулалтын дэд бүтцийн үнэ цэнэ
Дэд бүтцийн үүднээс авч үзвэл орон нутагт ажиллах нь ямар ч үнэ цэнийг өгөхгүй. Та туршилтыг зөвхөн локал хөтөч болон симулятор дээр локал машин дээр ажиллуулж байгаа эсэхийг шалгана уу. Гэхдээ ямар ч тохиолдолд энэ нь зайлшгүй эхлэх цэг юм.
Дэд бүтцийн өнөөгийн байдлыг харуулсан зураг
Судлах холбоосууд
Үүнтэй төстэй хэрэгслүүд
- Selenium/Appium тесттэй хамт дуртай програмчлалын хэл;
- аливаа туршилт;
- ямар ч туршилтын гүйгч.
2. Хувилбарын хяналтын систем (Git)
Технологийн товч тайлбар
Хэрэв би хувилбарын хяналт нь багийн болон хувь хүний хөгжлийн маш чухал хэсэг гэж хэлвэл энэ нь хэнд ч том нээлт болохгүй. Төрөл бүрийн эх сурвалжид үндэслэн Гит бол хамгийн алдартай төлөөлөгч гэж хэлж болно. Хувилбарын хяналтын систем нь код хуваалцах, хувилбаруудыг хадгалах, өмнөх салбаруудад сэргээх, төслийн түүхийг хянах, нөөцлөлт хийх гэх мэт олон давуу талыг өгдөг. Та үүнийг маш сайн мэддэг бөгөөд үүнийг өдөр тутмын ажилдаа ашигладаг гэдэгт итгэлтэй байгаа тул бид тус бүрийг нарийвчлан хэлэлцэхгүй. Гэхдээ хэрэв гэнэт үгүй бол би энэ өгүүллийг уншихаа түр зогсоож, энэ цоорхойг аль болох хурдан бөглөхийг зөвлөж байна.
Автоматжуулалтын дэд бүтцийн үнэ цэнэ
Эндээс та үндэслэлтэй асуулт асууж болно: "Тэр яагаад бидэнд Гитийн тухай яриад байгаа юм бэ? Хүн бүр үүнийг мэддэг бөгөөд үүнийг хөгжүүлэлтийн код болон автомат туршилтын код болгон ашигладаг." Та туйлын зөв байх болно, гэхдээ энэ нийтлэлд бид дэд бүтцийн тухай ярьж байгаа бөгөөд энэ хэсэг нь "Дэд бүтэц код (IaC)" гэсэн 7-р хэсгийн урьдчилсан тайлбар болж байна. Бидний хувьд энэ нь бүх дэд бүтэц, түүний дотор туршилтыг код хэлбэрээр тайлбарласан гэсэн үг бөгөөд бид үүнд хувилбарын системийг ашиглаж, хөгжүүлэлт, автоматжуулалтын кодтой адил ашиг тусыг авах боломжтой.
Бид 7-р алхам дээр IaC-ийг илүү нарийвчлан авч үзэх болно, гэхдээ одоо ч гэсэн та локал репозитор үүсгэснээр Git-г дотооддоо ашиглаж эхлэх боломжтой. Дэд бүтцэд алсын нөөцийн санг нэмж оруулснаар том дүр зураг өргөжих болно.
Дэд бүтцийн өнөөгийн байдлыг харуулсан зураг
Судлах холбоосууд
Үүнтэй төстэй хэрэгслүүд
3. Контейнержуулалт (Docker)
Технологийн товч тайлбар
Контейнержүүлэлт нь тоглоомын дүрмийг хэрхэн өөрчилсөнийг харуулахын тулд хэдэн арван жилийн хугацаанд эргэн харцгаая. Тэр үед хүмүүс програмуудыг ажиллуулахын тулд серверийн машин худалдаж аваад ашигладаг байсан. Гэхдээ ихэнх тохиолдолд эхлүүлэх шаардлагатай нөөцийг урьдчилан мэддэггүй байв. Үүний үр дүнд компаниуд өндөр үнэтэй, хүчирхэг сервер худалдаж авахад мөнгө зарцуулсан боловч энэ хүчин чадлын зарим хэсгийг бүрэн ашиглаж чадаагүй байна.
Хувьслын дараагийн үе шат бол ашиглагдаагүй нөөцөд мөнгө үрэх асуудлыг шийдсэн виртуал машинууд (VMs) байв. Энэхүү технологи нь бүрэн тусгаарлагдсан орон зайг хуваарилж, нэг сервер доторх програмуудыг бие биенээсээ хамааралгүйгээр ажиллуулах боломжтой болгосон. Гэвч харамсалтай нь аливаа технологид сул тал бий. VM ажиллуулахын тулд CPU, RAM, санах ой зарцуулдаг бүрэн үйлдлийн систем шаардлагатай бөгөөд үйлдлийн системээс хамааран лицензийн зардлыг харгалзан үзэх шаардлагатай. Эдгээр хүчин зүйлс ачаалах хурдад нөлөөлж, зөөвөрлөхөд хүндрэл учруулдаг.
Одоо бид чингэлэгжүүлэх ажилд ирлээ. Дахин хэлэхэд энэ технологи нь өмнөх асуудлыг шийддэг, учир нь контейнерууд бүрэн OS ашигладаггүй бөгөөд энэ нь их хэмжээний нөөцийг чөлөөлж, зөөвөрлөхөд хурдан бөгөөд уян хатан шийдлийг өгдөг.
Мэдээжийн хэрэг, савлах технологи нь шинэ зүйл биш бөгөөд 70-аад оны сүүлээр анх нэвтрүүлсэн. Тэр өдрүүдэд маш их судалгаа, боловсруулалт, оролдлого хийсэн. Гэвч Докер энэ технологийг өөрчилсөн бөгөөд үүнийг олон нийтэд хялбархан ашиглах боломжтой болгосон. Өнөө үед бид контейнерийн тухай ярихдаа ихэнх тохиолдолд Docker-ийг хэлдэг. Бид Docker контейнерын тухай ярихдаа Линукс контейнерийг хэлдэг. Бид Windows болон macOS системүүдийг контейнер ажиллуулах боломжтой боловч энэ тохиолдолд нэмэлт давхарга гарч ирнэ гэдгийг ойлгох нь чухал юм. Жишээлбэл, Mac дээрх Docker нь хөнгөн жинтэй Linux VM дотор контейнеруудыг чимээгүй ажиллуулдаг. Бид савны доторх Android эмуляторуудыг ажиллуулах талаар ярилцахдаа энэ сэдэв рүү буцах болно, тиймээс энд илүү нарийвчлан авч үзэх шаардлагатай маш чухал нюанс байна.
Автоматжуулалтын дэд бүтцийн үнэ цэнэ
Контейнержуулалт болон Docker нь маш сайн гэдгийг бид олж мэдсэн. Аливаа хэрэгсэл, технологи нь аливаа асуудлыг шийдвэрлэх шаардлагатай байдаг тул үүнийг автоматжуулалтын хүрээнд авч үзье. UI тестийн хүрээнд туршилтын автоматжуулалтын тодорхой асуудлуудыг тоймлон авч үзье.
- Selenium, ялангуяа Appium суулгах үед асар олон тооны хамаарал;
- хөтөч, симулятор, драйверуудын хувилбаруудын нийцтэй байдлын асуудал;
- Хөтөч/симуляторуудын хувьд тусгаарлагдсан зай байхгүй, энэ нь зэрэгцээ ажиллахад онцгой ач холбогдолтой;
- Хэрэв та 10, 50, 100 эсвэл бүр 1000 хөтөчийг нэгэн зэрэг ажиллуулах шаардлагатай бол удирдах, засварлахад хэцүү.
Гэхдээ Selenium бол хамгийн алдартай автоматжуулалтын хэрэгсэл бөгөөд Docker бол хамгийн алдартай контейнержуулалтын хэрэгсэл учраас хэн нэгэн эдгээр асуудлыг нэгтгэхийн тулд дээр дурдсан асуудлуудыг шийдвэрлэх хүчирхэг хэрэгсэл бүтээхийг оролдсон нь гайхах зүйл биш юм. Ийм шийдлүүдийг илүү нарийвчлан авч үзье.
Докер дахь селенийн сүлжээ
Энэхүү хэрэгсэл нь олон машин дээр олон хөтөч ажиллуулж, тэдгээрийг төв төвөөс удирдахад зориулагдсан Selenium ертөнцөд хамгийн алдартай хэрэгсэл юм. Эхлэхийн тулд та дор хаяж 2 хэсгийг бүртгүүлэх шаардлагатай: Hub болон Node(s). Hub нь тестээс ирсэн бүх хүсэлтийг хүлээн авч зохих зангилаанууд руу түгээдэг төв зангилаа юм. Зангилаа бүрийн хувьд бид тодорхой тохиргоог тохируулж болно, жишээлбэл, хүссэн хөтөч болон түүний хувилбарыг зааж өгөх замаар. Гэсэн хэдий ч бид тохирох хөтөчийн драйверуудыг өөрсдөө анхаарч, хүссэн зангилаа дээрээ суулгах шаардлагатай хэвээр байна. Энэ шалтгааны улмаас Selenium grid нь Linux үйлдлийн систем дээр суулгах боломжгүй хөтчүүдтэй ажиллахаас бусад тохиолдолд цэвэр хэлбэрээр ашиглагддаггүй. Бусад бүх тохиолдлуудад Selenium grid Hub болон Nodes-ийг ажиллуулахын тулд Docker дүрсийг ашиглах нь нэлээд уян хатан бөгөөд зөв шийдэл байх болно. Энэ арга нь зангилааны удирдлагыг ихээхэн хялбаршуулдаг, учир нь бид аль хэдийн суулгасан хөтөч болон драйверуудын нийцтэй хувилбаруудын тусламжтайгаар шаардлагатай зургийг сонгож болно.
Тогтвортой байдлын талаархи сөрөг үнэлгээг үл харгалзан, ялангуяа олон тооны зангилаануудыг зэрэгцээ ажиллуулах үед Selenium grid нь Selenium тестийг зэрэгцээ ажиллуулах хамгийн түгээмэл хэрэгсэл хэвээр байна. Энэ хэрэгслийн янз бүрийн сайжруулалт, өөрчлөлтүүд нь янз бүрийн саад бэрхшээлийг даван туулах нээлттэй эх сурвалжид байнга гарч ирдэг гэдгийг тэмдэглэх нь зүйтэй.
Вэбд зориулсан селеноид
Энэхүү хэрэгсэл нь Селений ертөнцөд нээлт болж, олон автоматжуулалтын инженерүүдийн амьдралыг илүү хялбар болгосон. Юуны өмнө энэ нь Селенийн сүлжээний өөр нэг өөрчлөлт биш юм. Үүний оронд хөгжүүлэгчид Голанг дахь Selenium Hub-ийн цоо шинэ хувилбарыг бүтээсэн бөгөөд энэ нь янз бүрийн хөтчүүдэд зориулсан хөнгөн жинтэй Docker зургуудтай хослуулан туршилтын автоматжуулалтыг хөгжүүлэхэд түлхэц өгсөн юм. Түүнээс гадна, Selenium Grid-ийн хувьд бид шаардлагатай бүх хөтөч болон тэдгээрийн хувилбаруудыг урьдчилан тодорхойлох ёстой бөгөөд энэ нь зөвхөн нэг хөтөчтэй ажиллахад асуудал биш юм. Гэхдээ олон тооны дэмжигдсэн хөтчүүдийн тухайд Selenoid нь "эрэлттэй хөтөч" функцийн ачаар номер нэг шийдэл юм. Биднээс шаардлагатай бүх зүйл бол хөтчөөр шаардлагатай зургуудыг урьдчилан татаж авах, Selenoid-тай харьцдаг тохиргооны файлыг шинэчлэх явдал юм. Selenoid нь туршилтуудаас хүсэлтийг хүлээн авсны дараа хүссэн хөтчөөр хүссэн контейнерээ автоматаар ажиллуулна. Туршилт дуусмагц Selenoid савыг зогсоож, улмаар ирээдүйн хүсэлтэд зориулж нөөцийг чөлөөлнө. Энэ арга нь Селенийн сүлжээнд бидний байнга тулгардаг "зангилааны эвдрэл"-ийн асуудлыг бүрэн арилгадаг.
Гэвч харамсалтай нь Селеноид мөнгөн сум биш хэвээр байна. Бид "эрэлттэй хөтөч" функцийг авсан боловч "эрэлт хэрэгцээний нөөц" функцийг ашиглах боломжгүй хэвээр байна. 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 grid болон Android-д зориулсан Selenoid тест юм. GitHub зааварт би мөн танд Selenoid ашиглан вэб тестийг хэрхэн ашиглахыг харуулах болно.
Судлах холбоосууд
Үүнтэй төстэй хэрэгслүүд
- Бусад савлах хэрэгслүүд байдаг ч хамгийн алдартай нь Docker юм. Хэрэв та өөр зүйл туршиж үзэхийг хүсч байвал Selenium-ийн туршилтыг зэрэгцүүлэн ажиллуулахад зориулагдсан хэрэгслүүд нь хайрцагнаас гарахгүй гэдгийг санаарай.
- Өмнө дурьдсанчлан, Селен сүлжээний олон өөрчлөлтүүд байдаг, жишээлбэл,.
4.CI/CD
Технологийн товч тайлбар
Тасралтгүй интеграцийн практик нь хөгжүүлэлтийн хувьд нэлээд түгээмэл бөгөөд хувилбарын хяналтын системтэй ижил түвшинд байна. Гэсэн хэдий ч нэр томьёоны хувьд будлиантай байгаа мэт санагдаж байна. Энэ догол мөрөнд би энэ технологийн 3 өөрчлөлтийг өөрийн үзэл бодлоос тайлбарлахыг хүсч байна. Интернет дээр та өөр өөр тайлбартай олон нийтлэлийг олох болно, хэрэв таны бодол өөр байвал энэ нь туйлын хэвийн зүйл юм. Хамгийн гол нь та хамт олонтойгоо нэг хуудсанд байгаа юм.
Тэгэхээр CI - Continuous Integration, CD - Continuous Delivery ба дахин CD - Continuous Deployment гэсэн 3 нэр томьёо байдаг. (Доор би эдгээр нэр томъёог англи хэл дээр ашиглах болно). Өөрчлөлт бүр нь таны хөгжлийн шугаманд хэд хэдэн нэмэлт алхмуудыг нэмж өгдөг. Гэхдээ үг Үргэлжилсэн (тасралтгүй) нь хамгийн чухал зүйл юм. Энэ утгаараа бид ямар нэг зүйлийг эхнээс нь дуустал, тасалдалгүйгээр, гар ажиллагаагүйгээр хийдэг. Энэ хүрээнд 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 instance болон Runner хэрэгтэй.
Дэд бүтцийн өнөөгийн байдлыг харуулсан зураг
Судлах холбоосууд
Үүнтэй төстэй хэрэгслүүд
- Мөн бусад олон
5. Үүлэн платформууд
Технологийн товч тайлбар
Энэ хэсэгт бид "нийтийн үүл" хэмээх алдартай чиг хандлагын талаар ярих болно. Дээр дурдсан виртуалчлал болон контейнержуулалтын технологи нь асар их ашиг тустай хэдий ч бидэнд тооцоолох нөөц хэрэгтэй хэвээр байна. Компаниуд үнэтэй сервер худалдаж авах эсвэл дата төв түрээслэх боловч энэ тохиолдолд бидэнд хичнээн нөөц хэрэгтэй болох, тэдгээрийг 24/7 ашиглах эсэх, ямар зорилгоор ашиглах талаар тооцоо хийх (заримдаа бодит бус) хийх шаардлагатай байдаг. Жишээлбэл, үйлдвэрлэл нь XNUMX/XNUMX ажилладаг сервер шаарддаг ч ажлын бус цагаар туршилт хийхэд ижил төстэй нөөц хэрэгтэй юу? Энэ нь мөн хийгдэж буй туршилтын төрлөөс хамаарна. Үүний нэг жишээ бол дараагийн өдөр нь үр дүнд хүрэхийн тулд ажлын бус цагаар хийхээр төлөвлөж буй ачаалал/стресс тест байж болно. Гэхдээ эцсийн автоматжуулсан туршилтын хувьд XNUMX/XNUMX серверийн бэлэн байх шаардлагагүй, ялангуяа гарын авлагын туршилтын орчинд шаардлагагүй. Ийм нөхцөл байдлын хувьд эрэлт хэрэгцээний хэмжээгээр шаардлагатай нөөцийг олж авах, тэдгээрийг ашиглах, шаардлагагүй болсон үед төлөхөө зогсоох нь зүйтэй юм. Түүгээр ч зогсохгүй хулганаар хэд хэдэн товшилт хийх эсвэл хэд хэдэн скрипт ажиллуулах замаар тэдгээрийг шууд хүлээн авах нь сайхан байх болно. Үүнд нийтийн үүл ашигладаг. Тодорхойлолтыг харцгаая:
“Нийтийн үүл гэдэг нь гуравдагч талын үйлчилгээ үзүүлэгчдийн нийтийн интернетээр санал болгож, ашиглах эсвэл худалдан авахыг хүссэн хэн бүхэнд ашиглах боломжтой болгох тооцооллын үйлчилгээг хэлнэ. Тэдгээр нь үнэ төлбөргүй эсвэл эрэлтийн дагуу зарагдаж болох бөгөөд энэ нь үйлчлүүлэгчдэд зөвхөн CPU-ийн цикл, хадгалах сан эсвэл ашигладаг зурвасын өргөний төлбөрийг ашиглах боломжийг олгодог."
Нийтийн үүл өндөр үнэтэй гэсэн ойлголт байдаг. Гэхдээ тэдний гол санаа бол компанийн зардлыг бууруулах явдал юм. Өмнө дурьдсанчлан, нийтийн үүл нь хэрэгцээт нөөцийг олж авах, зөвхөн ашигласан хугацаандаа төлөх боломжийг олгодог. Түүнчлэн, заримдаа бид ажилчид цалин авдаг, мэргэжилтнүүд нь бас үнэтэй нөөц гэдгийг мартдаг. Нийтийн үүл нь дэд бүтцийн дэмжлэгийг ихээхэн хөнгөвчлөх бөгөөд энэ нь инженерүүдэд илүү чухал ажлуудад анхаарлаа төвлөрүүлэх боломжийг олгодог гэдгийг анхаарах хэрэгтэй.
Автоматжуулалтын дэд бүтцийн үнэ цэнэ
UI-ийн төгсгөлийн тест хийхэд бидэнд ямар тусгай нөөц хэрэгтэй вэ? Үндсэндээ эдгээр нь хөтөч болон эмулятор ажиллуулахад зориулагдсан виртуал машин эсвэл кластерууд (дараагийн хэсэгт Kubernetes-ийн тухай ярих болно). Бид хэдий чинээ олон вэб хөтчүүд болон эмуляторуудыг нэгэн зэрэг ажиллуулахыг хүсэж байна төдий чинээ их CPU болон санах ой шаардагддаг бөгөөд үүний төлөө бид илүү их мөнгө төлөх шаардлагатай болдог. Тиймээс туршилтын автоматжуулалтын хүрээнд нийтийн үүл нь бидэнд эрэлт хэрэгцээний дагуу олон тооны (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 машин. Андройдын хувьд ийм байх болно n1-стандарт-4 нэг эмуляторын хувьд. Үнэн хэрэгтээ илүү уян хатан, хямд арга бол CPU/санах ойд хэрэглэгчийн тодорхой утгыг тохируулах явдал боловч одоогоор Sauce Labs-тай харьцуулах нь тийм ч чухал биш юм.
Sauce Labs ашиглах тарифыг энд оруулав.
Та ялгааг аль хэдийн анзаарсан гэдэгт би итгэж байна, гэхдээ би бидний даалгаварт тооцоолол бүхий хүснэгтийг өгөх болно.
Шаардлагатай нөөц
Сар бүр
Ажлын цаг(8-8 цаг)
Ажлын цаг+ Давуу эрхтэй
Вэбд зориулсан GCP
n1-стандарт-1 x 8 = n1-стандарт-8
$194.18
23 хоног * 12 цаг * 0.38 = 104.88 доллар
23 хоног * 12 цаг * 0.08 = 22.08 доллар
Вэбд зориулсан Sauce Labs
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 доллар болж буурах болно. Энэ гайхалтай биш гэж үү? Гэхдээ давуу эрхтэй машинуудын хувьд бид анхааралтай байж, тасалдал, тогтворгүй байдалд бэлэн байх ёстой, гэхдээ эдгээр нөхцөл байдлыг програм хангамжаар хангаж, зохицуулж болно. Энэ нь үнэ цэнэтэй юм!
Гэхдээ би "үүл туршилтын фермүүдийг хэзээ ч бүү ашигла" гэж хэлэхгүй. Тэд хэд хэдэн давуу талтай. Юуны өмнө, энэ нь зүгээр л виртуал машин биш, харин хайрцагнаас гарсан функц бүхий бүрэн хэмжээний туршилтын автоматжуулалтын шийдэл юм: алсаас нэвтрэх, бүртгэл, дэлгэцийн агшин, видео бичлэг, төрөл бүрийн хөтөч, физик хөдөлгөөнт төхөөрөмж. Ихэнх тохиолдолд энэ нь маш гоёмсог хувилбар байж болно. Олон нийтийн үүл нь зөвхөн Линукс/Windows системийг санал болгох боломжтой үед туршилтын платформууд нь ялангуяа IOS автоматжуулалтад хэрэгтэй байдаг. Гэхдээ бид дараагийн нийтлэлүүдэд iOS-ийн талаар ярих болно. Би үргэлж нөхцөл байдлыг харж, даалгавраас эхлэхийг зөвлөж байна: зарим тохиолдолд нийтийн үүл ашиглах нь илүү хямд бөгөөд илүү үр дүнтэй байдаг бол зарим тохиолдолд туршилтын платформууд нь зарцуулсан мөнгөөр үнэ цэнэтэй байдаг.
Дэд бүтцийн өнөөгийн байдлыг харуулсан зураг
Судлах холбоосууд
Үүнтэй төстэй хэрэгслүүд:
6. Найрал хөгжим
Технологийн товч тайлбар
Надад сайн мэдээ байна - бид нийтлэлийн төгсгөлд бараг л байна! Одоогийн байдлаар манай автоматжуулалтын дэд бүтэц нь Selenium grid болон Selenoid зэрэг Docker-ийг идэвхжүүлсэн хэрэгслүүдийг ашиглан GitLab CI-ээр зэрэгцүүлэн ажиллуулдаг вэб болон Android тестүүдээс бүрддэг. Нэмж дурдахад бид GCP-ээр үүсгэсэн виртуал машинуудыг хөтчүүд болон эмуляторуудтай контейнеруудыг байрлуулахад ашигладаг. Зардлыг бууруулахын тулд бид эдгээр виртуал машинуудыг зөвхөн хүсэлтээр ажиллуулж, туршилт хийгээгүй үед зогсоодог. Манай дэд бүтцийг сайжруулах өөр зүйл бий юу? Хариулт нь тийм! Кубернетестэй (K8s) уулзаарай!
Эхлээд оркестр, кластер, Кубернетес гэсэн үгс хоорондоо ямар холбоотой болохыг харцгаая. Өндөр түвшинд, зохион байгуулалт нь програмуудыг байрлуулж, удирддаг систем юм. Туршилтын автоматжуулалтын хувьд ийм савласан програмууд нь Selenium grid болон Selenoid юм. Docker болон K8 нь бие биенээ нөхдөг. Эхнийх нь програмыг байрлуулахад, хоёр дахь нь зохион байгуулалтад ашиглагддаг. Хариуд нь K8s нь кластер юм. Кластерын үүрэг бол VM-ийг зангилаа болгон ашиглах явдал бөгөөд энэ нь нэг сервер (кластер) дотор янз бүрийн функц, програм, үйлчилгээг суулгах боломжийг олгодог. Зангилааны аль нэг нь бүтэлгүйтвэл бусад зангилаанууд ажиллах бөгөөд энэ нь манай програмын тасралтгүй ажиллагааг хангана. Нэмж дурдахад K8s нь масштабтай холбоотой чухал функцтэй бөгөөд үүний ачаар бид ачаалал, хязгаарлалт дээр үндэслэн хамгийн оновчтой нөөцийг автоматаар олж авдаг.
Үнэнийг хэлэхэд, Кубернетесийг эхнээс нь гараар байрлуулах нь тийм ч энгийн ажил биш юм. Би алдарт "Kubernetes The Hard Way" гарын авлагын холбоосыг үлдээх бөгөөд хэрэв та сонирхож байвал үүнийг дадлага хийж болно. Гэхдээ аз болоход өөр арга, хэрэгсэл байдаг. Хамгийн хялбар арга бол Google Kubernetes Engine (GKE)-г GCP-д ашиглах бөгөөд энэ нь танд хэдхэн товшилтоор бэлэн кластер авах боломжийг олгоно. Дотоод бүрэлдэхүүн хэсгүүдийг бие биетэйгээ хэрхэн уялдуулах талаар сурахын оронд K8-ийг ажилдаа хэрхэн ашиглах талаар суралцахад анхаарлаа төвлөрүүлэх боломжийг олгох тул суралцаж эхлэхийн тулд энэ аргыг ашиглахыг зөвлөж байна.
Автоматжуулалтын дэд бүтцийн үнэ цэнэ
K8s-ийн хангадаг хэд хэдэн чухал шинж чанаруудыг харцгаая.
- програмын байршуулалт: VM-ийн оронд олон зангилааны кластер ашиглах;
- динамик масштаб: зөвхөн эрэлт хэрэгцээнд ашигладаг нөөцийн зардлыг бууруулдаг;
- өөрийгөө эдгээх: хонхорцог автоматаар нөхөн сэргээх (үүний үр дүнд савнууд мөн сэргээгддэг);
- Сул зогсолтгүйгээр шинэчлэлтүүдийг нэвтрүүлэх, өөрчлөлтүүдийг буцаах: хэрэгсэл, хөтөч, эмуляторуудыг шинэчлэх нь одоогийн хэрэглэгчдийн ажлыг тасалдуулахгүй.
Гэхдээ K8s нь мөнгөн сум биш хэвээр байна. Бидний авч үзэж буй хэрэгслүүдийн (Selenium grid, Selenoid) бүх давуу болон хязгаарлалтыг ойлгохын тулд бид K8-ийн бүтцийг товчхон авч үзэх болно. Кластер нь хоёр төрлийн зангилаа агуулдаг: Мастер зангилаа ба Ажилчдын зангилаа. Мастер зангилаа нь удирдлага, байршуулалт, хуваарь гаргах шийдвэрийг хариуцдаг. Ажилчдын зангилаа нь програмуудыг ажиллуулдаг газар юм. Зангилаанууд нь мөн контейнер ажиллах орчныг агуулдаг. Манай тохиолдолд энэ нь контейнертэй холбоотой үйл ажиллагааг хариуцдаг Docker юм. Гэхдээ жишээ нь өөр шийдлүүд бас байдаг. Хуваарилах эсвэл өөрийгөө эдгээх нь саванд шууд хамаарахгүй гэдгийг ойлгох нь чухал юм. Энэ нь савны тоог нэмэх/багасгах замаар хэрэгждэг бөгөөд тэдгээр нь эргээд савыг агуулдаг (ихэвчлэн нэг саванд нэг сав байдаг, гэхдээ даалгавараас хамааран илүү олон байж болно). Дээд түвшний шатлал нь ажилчдын зангилаанаас бүрдэх ба дотор нь хонхорцог, дотор нь савнууд өргөгдсөн байдаг.
Масштабтай болгох онцлог нь чухал бөгөөд үүнийг кластерийн зангилааны сан болон зангилаа доторх хонгилд хоёуланд нь хэрэглэж болно. Зангилаа болон хонхорхойд хоёуланд нь хамаарах 2 төрлийн масштаб байдаг. Эхний төрөл нь хэвтээ - зангилаа / хонхорцог тоог нэмэгдүүлснээр масштаб үүсдэг. Энэ төрөл нь илүү тохиромжтой. Хоёрдахь төрөл нь босоо байрлалтай. Хуваарилалт нь зангилаа / хонхорцог хэмжээг нэмэгдүүлэх замаар хийгддэг бөгөөд тэдгээрийн тоог биш юм.
Одоо дээрх нэр томъёоны хүрээнд өөрсдийн хэрэглүүрүүдийг харцгаая.
Селен сүлжээ
Өмнө дурьдсанчлан, Selenium grid бол маш алдартай хэрэгсэл бөгөөд үүнийг саванд хийсэн нь гайхах зүйл биш юм. Тиймээс Selenium сүлжээг K8-д байрлуулж болох нь гайхах зүйл биш юм. Үүнийг хэрхэн хийх жишээг албан ёсны K8s репозитороос олж болно. Ердийнх шигээ би хэсгийн төгсгөлд холбоосуудыг хавсаргав. Нэмж дурдахад, хэрхэн хийх заавар нь үүнийг Terraform дээр хэрхэн хийхийг харуулж байна. Мөн хөтчийн контейнер агуулсан pods-ийн тоог хэрхэн нэмэгдүүлэх заавар байдаг. Гэхдээ K8-ийн контекст дахь автомат масштабын функц нь бүрэн тодорхой ажил биш хэвээр байна. Би суралцаж эхлэхдээ ямар ч практик заавар, зөвлөмж олж чадаагүй. DevOps багийн дэмжлэгтэйгээр хэд хэдэн судалгаа, туршилт хийсний дараа бид нэг ажилчны зангилаа дотор байрлах нэг хонхорцог дотор шаардлагатай хөтчүүдтэй савыг өсгөх аргыг сонгосон. Энэ арга нь зангилааны тоог нэмэгдүүлэх замаар хэвтээ масштабын стратегийг ашиглах боломжийг бидэнд олгодог. Энэ нь ирээдүйд өөрчлөгдөж, илүү сайн арга барил, бэлэн шийдлүүдийн талаар илүү олон тайлбарыг олж харах болно гэж найдаж байна, ялангуяа дотоод бүтэц өөрчлөгдсөн Selenium grid 4 гарсны дараа.
Селеноид:
K8s-д селеноидын суурилуулалт нь одоогоор хамгийн том урам хугарах зүйл юм. Тэд тохирохгүй байна. Онолын хувьд бид Selenoid савыг pod дотор босгож болох боловч Selenoid хөтчүүдтэй савыг ажиллуулж эхлэхэд тэдгээр нь нэг подвол дотор байх болно. Энэ нь масштаблах боломжгүй болгодог бөгөөд үүний үр дүнд кластер доторх Selenoid-ийн ажил нь виртуал машин доторх ажлаас ялгаатай байх болно. Түүхийн төгсгөл.
Moon:
Selenoid-тэй ажиллахдаа энэхүү саад бэрхшээлийг мэдэж байсан хөгжүүлэгчид Moon хэмээх илүү хүчирхэг хэрэгслийг гаргасан. Энэ хэрэгсэл нь анх Kubernetes-тэй ажиллахаар бүтээгдсэн бөгөөд үүний үр дүнд автоматаар масштаблах функцийг ашиглах боломжтой бөгөөд ашиглах ёстой. Түүгээр ч зогсохгүй би яг одоо байгаа гэж хэлмээр байна цорын ганц Selenium ертөнцөд төрөлх K8 кластерийн дэмжлэгтэй хэрэгсэл (ашиглах боломжгүй болсон тул дараагийн хэрэгслийг үзнэ үү ). Энэ дэмжлэгийг үзүүлдэг Сарны гол шинж чанарууд нь:
Бүрэн харьяалалгүй. Selenoid нь одоо ажиллаж байгаа хөтөчийн сешнүүдийн талаарх мэдээллийг санах ойд хадгалдаг. Хэрэв ямар нэг шалтгааны улмаас түүний процесс гацсан бол бүх ажиллаж байгаа сессүүд алга болно. Сар нь эсрэгээрээ дотоод төлөвгүй бөгөөд дата төвүүдэд хуулбарлах боломжтой. Нэг буюу хэд хэдэн хуулбар унасан ч хөтчийн сессүүд амьд хэвээр байна.
Тиймээс, Сар бол маш сайн шийдэл боловч нэг асуудал бий: энэ нь үнэ төлбөргүй биш юм. Үнэ нь сессийн тооноос хамаарна. Та зөвхөн 0-4 сессийг үнэгүй ажиллуулах боломжтой бөгөөд энэ нь тийм ч ашигтай биш юм. Харин тав дахь сессээс эхлэн тус бүрдээ 5 доллар төлөх шаардлагатай болно. Нөхцөл байдал компаниас хамаарч өөр өөр байж болох ч манай тохиолдолд Moon ашиглах нь утгагүй юм. Дээр дурдсанчлан бид Selenium Grid-тай VM-ийг хүссэнээр ажиллуулах эсвэл кластер дахь зангилааны тоог нэмэгдүүлэх боломжтой. Ойролцоогоор нэг дамжуулах хоолойн хувьд бид 500 хөтөч ажиллуулж, туршилт дууссаны дараа бүх нөөцийг зогсооно. Хэрэв бид Moon-г ашигласан бол хэчнээн удаа шинжилгээ хийлгэж байгаагаас үл хамааран сард нэмэлт 500 x 5 = 2500 доллар төлөх шаардлагатай болно. Дахин хэлэхэд би Мүүнийг бүү ашигла гэж хэлэхгүй. Жишээлбэл, танай байгууллагад олон төсөл/багууд байгаа бөгөөд танд хүн бүрт зориулсан асар том нийтлэг кластер хэрэгтэй бол энэ нь таны даалгавруудын хувьд зайлшгүй шийдэл байж болно. Үргэлжлүүлэн би төгсгөлд нь холбоосыг үлдээж, ажлынхаа хүрээнд шаардлагатай бүх тооцоог хийхийг зөвлөж байна.
Callisto(Анхаар! Энэ нь эх нийтлэлд байхгүй бөгөөд зөвхөн орос орчуулгад багтсан болно)
Миний хэлсэнчлэн Selenium бол маш алдартай хэрэгсэл бөгөөд мэдээллийн технологийн салбар маш хурдан хөгжиж байна. Би орчуулга дээр ажиллаж байх үед вэб дээр Callisto хэмээх шинэ ирээдүйтэй хэрэгсэл гарч ирэв (Сайн уу Cypress болон бусад Selenium алуурчид). Энэ нь үндсэндээ K8-тэй ажилладаг бөгөөд Selenoid контейнеруудыг зангилаануудад тарааж, хонхорцог хэлбэрээр ажиллуулах боломжийг танд олгоно. Автомат масштабыг оруулаад бүх зүйл хайрцагнаас гарч ажиллана. Гайхалтай, гэхдээ туршиж үзэх шаардлагатай. Би аль хэдийн энэ хэрэгслийг байрлуулж, хэд хэдэн туршилт хийж чадсан. Гэхдээ холын зайнаас үр дүнг хүлээн авсны дараа дүгнэлт хийхэд эрт байна, магадгүй би дараагийн нийтлэлүүдэд тойм хийх болно. Одоогоор би зөвхөн бие даасан судалгааны холбоосыг үлдээж байна.
Дэд бүтцийн өнөөгийн байдлыг харуулсан зураг
Судлах холбоосууд
Үүнтэй төстэй хэрэгслүүд
7. Дэд бүтэц нь код (IaC)
Технологийн товч тайлбар
Одоо бид сүүлчийн хэсэг рүү ирлээ. Ерөнхийдөө энэ технологи болон холбогдох ажлууд нь автоматжуулалтын инженерүүдийн үүрэг биш юм. Мөн үүнд шалтгаан бий. Нэгдүгээрт, олон байгууллагад дэд бүтцийн асуудал DevOps хэлтсийн хяналтанд байдаг бөгөөд хөгжлийн багууд дамжуулах хоолойг юу болгодог, үүнтэй холбоотой бүх зүйлийг хэрхэн дэмжих талаар огт хамаагүй байдаг. Хоёрдугаарт, үнэнийг хэлэхэд, Дэд бүтцийг код (IaC) болгон ашиглах практикийг олон компанид нэвтрүүлээгүй хэвээр байна. Гэхдээ энэ нь гарцаагүй түгээмэл чиг хандлага болсон бөгөөд үүнтэй холбоотой үйл явц, арга барил, хэрэгсэлд оролцохыг хичээх нь чухал юм. Эсвэл ядаж шинэчлэгдэж байгаарай.
Энэ аргыг ашиглах сэдэлээс эхэлье. GitlabCI дээр туршилт явуулахын тулд Gitlab Runner-ийг ажиллуулахад хамгийн багадаа нөөц хэрэгтэй болно гэдгийг бид аль хэдийн хэлэлцсэн. Хөтөч/эмулятор бүхий контейнер ажиллуулахын тулд бид VM эсвэл кластер нөөцлөх хэрэгтэй. Туршилтын нөөцөөс гадна бидэнд мэдээллийн сан, автомат хуваарь, сүлжээний тохиргоо, ачаалал тэнцвэржүүлэгч, хэрэглэгчийн эрх гэх мэтийг багтаасан хөгжүүлэлт, үе шат, үйлдвэрлэлийн орчныг дэмжих ихээхэн хэмжээний хүчин чадал хэрэгтэй. Гол асуудал бол энэ бүхнийг дэмжихэд шаардагдах хүчин чармайлт юм. Өөрчлөлт хийх, шинэчлэлтүүдийг нэвтрүүлэх хэд хэдэн арга бий. Жишээлбэл, GCP-ийн хүрээнд бид хөтөч дээрх UI консолыг ашиглаж, товчлуур дээр дарж бүх үйлдлийг гүйцэтгэх боломжтой. Өөр нэг хувилбар бол үүлэн байгууллагуудтай харилцахын тулд API дуудлагыг ашиглах эсвэл gcloud командын шугамын хэрэгслийг ашиглан хүссэн залруулга хийх явдал юм. Гэхдээ үнэхээр олон тооны өөр өөр аж ахуйн нэгж, дэд бүтцийн элементүүдтэй тул бүх үйлдлийг гараар гүйцэтгэх нь хэцүү эсвэл бүр боломжгүй болдог. Түүнээс гадна эдгээр бүх гарын авлагын үйлдэл нь хяналтгүй байдаг. Бид тэдгээрийг гүйцэтгэхээс өмнө хянуулах, хувилбарын хяналтын системийг ашиглах, осолд хүргэсэн өөрчлөлтийг хурдан буцаах боломжгүй. Иймэрхүү асуудлыг шийдэхийн тулд инженерүүд автомат bash/shell скриптүүдийг бүтээж, бий болгосон нь өмнөх аргуудаас тийм ч сайн биш, учир нь тэдгээрийг процедурын хэв маягаар хурдан унших, ойлгох, хадгалах, өөрчлөхөд тийм ч хялбар биш юм.
Энэ нийтлэл болон хэрхэн зааварчилгаанд би IaC дадлагатай холбоотой 2 хэрэгслийг ашигладаг. Эдгээр нь Terraform болон Ansible юм. Зарим хүмүүс тэдгээрийг нэгэн зэрэг ашиглах нь утгагүй гэж үздэг, учир нь тэдгээрийн үйл ажиллагаа ижил төстэй бөгөөд тэдгээрийг сольж болно. Гэхдээ үнэн хэрэгтээ эхлээд тэдэнд огт өөр үүрэг даалгавар өгдөг. Эдгээр хэрэгслүүд нь бие биенээ нөхөх ёстой гэдгийг HashiCorp болон RedHat-ийг төлөөлдөг хөгжүүлэгчид хамтарсан танилцуулга дээр батлав. Үзэл баримтлалын ялгаа нь Terraform нь серверүүдийг өөрсдөө удирдахад зориулагдсан хэрэгсэл юм. Хэдийгээр Ansible бол эдгээр серверүүд дээр програм суулгах, тохируулах, удирдах үүрэгтэй тохиргооны удирдлагын хэрэгсэл юм.
Эдгээр хэрэгслүүдийн өөр нэг гол онцлог нь кодчилол юм. Terraform нь bash болон Ansible-ээс ялгаатай нь гүйцэтгэлийн үр дүнд хүрэхийг хүссэн эцсийн төлөвийн тайлбар дээр үндэслэн тунхаглалын хэв маягийг ашигладаг. Жишээлбэл, хэрэв бид 10 VM үүсгэж, өөрчлөлтийг Terraform-ээр дамжуулан хэрэгжүүлэх гэж байгаа бол бид 10 VM авах болно. Хэрэв бид скриптийг дахин ажиллуулбал бидэнд аль хэдийн 10 VM байгаа тул юу ч тохиолдохгүй бөгөөд Терраформ дэд бүтцийн одоогийн төлөвийг төлөвийн файлд хадгалдаг тул энэ талаар мэддэг. Гэхдээ Ansible нь процедурын аргыг ашигладаг бөгөөд хэрэв та түүнээс 10 VM үүсгэхийг хүсэх юм бол бид эхний нээлтэд Terraform-тай төстэй 10 VM авах болно. Гэхдээ дахин эхлүүлсний дараа бид аль хэдийн 20 VM-тэй болно. Энэ бол чухал ялгаа юм. Процедурын хэв маягаар бид одоогийн төлөвийг хадгалдаггүй бөгөөд зүгээр л хийх ёстой алхамуудын дарааллыг тайлбарладаг. Мэдээжийн хэрэг, бид янз бүрийн нөхцөл байдлыг зохицуулж, нөөц байгаа эсэх, одоогийн байдлыг хэд хэдэн удаа шалгаж болно, гэхдээ энэ логикийг хянахын тулд цаг заваа үрэх, хүчин чармайлт гаргах нь утгагүй юм. Үүнээс гадна энэ нь алдаа гаргах эрсдэлийг нэмэгдүүлдэг.
Дээр дурдсан бүх зүйлийг нэгтгэн дүгнэж үзвэл Terraform болон мэдэгдлийн тэмдэглэгээ нь серверүүдийг бэлтгэхэд илүү тохиромжтой хэрэгсэл юм гэж бид дүгнэж болно. Гэхдээ тохиргооны удирдлагын ажлыг Ansible-д шилжүүлэх нь дээр. Ийм зүйл байхгүй тул автоматжуулалтын хүрээнд хэрэглээний тохиолдлуудыг авч үзье.
Автоматжуулалтын дэд бүтцийн үнэ цэнэ
Энд ойлгох ёстой цорын ганц чухал зүйл бол туршилтын автоматжуулалтын дэд бүтцийг компанийн бүх дэд бүтцийн нэг хэсэг гэж үзэх ёстой. Энэ нь IaC-ийн бүх практикийг бүхэл бүтэн байгууллагын нөөцөд ашиглах ёстой гэсэн үг юм. Үүнийг хэн хариуцах нь таны үйл явцаас хамаарна. DevOps баг эдгээр асуудалд илүү туршлагатай тул юу болж байгааг бүхэлд нь хардаг. Гэсэн хэдий ч чанарын хяналтын инженерүүд барилгын автоматжуулалт, дамжуулах хоолойн бүтцэд илүү их оролцдог бөгөөд энэ нь шаардлагатай бүх өөрчлөлт, сайжруулах боломжийг илүү сайн харах боломжийг олгодог. Хүлээгдэж буй үр дүнд хүрэхийн тулд хамтран ажиллах, мэдлэг, санаа бодлоо солилцох нь хамгийн сайн сонголт юм.
Туршилтын автоматжуулалтын хүрээнд 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 grid, Selenoid (Вэб, Android)
- Туршилтуудыг зэрэгцээ ажиллуулж байна
- Тусгаарлагдсан орчин
- Энгийн, уян хатан хувилбарын шинэчлэлтүүд
- Ашиглагдаагүй нөөцийг динамикаар зогсоох
- Тохируулахад хялбар
4
CI/CD
Gitlab CI
- Дамжуулах хоолойн хэсгийг турших
- Шуурхай санал хүсэлт
- Бүхэл бүтэн компани/багийн хувьд харагдах байдал
5
Үүлэн платформууд
Google Cloud платформ
- Хүсэлтийн дагуу нөөц (бид шаардлагатай үед л төлдөг)
- Удирдах, шинэчлэхэд хялбар
- Бүх нөөцийн харагдах байдал, хяналт
6
Найрал хөгжим
Kubernetes
Pod доторх хөтч/эмулятор бүхий контейнеруудын хүрээнд:
- Масштаб/автоматаар масштаблах
- Өөрийгөө эдгээх
- Тасалдалгүйгээр шинэчлэлтүүд болон буцаалтууд
7
Дэд бүтэц нь код (IaC)
Terraform, Ansible
- Хөгжлийн дэд бүтэцтэй ижил төстэй ашиг тус
- Кодын хувилбарын бүх ашиг тус
- Өөрчлөлт хийх, засвар үйлчилгээ хийхэд хялбар
- Бүрэн автоматжуулсан
Оюун санааны газрын зургийн диаграм: дэд бүтцийн хувьсал
Алхам 1: Орон нутгийн
Алхам 2: VCS
Алхам 3: Савыг савлах
4-р алхам: CI/CD
Алхам 5: Үүлэн платформууд
Алхам 6: найрал хөгжим
Алхам 7: IaC
Дараа нь юу юм бэ?
Тиймээс, энэ нийтлэлийн төгсгөл юм. Гэхдээ эцэст нь би тантай зарим гэрээ хэлцэл хиймээр байна.
Таны талаас
Би эхэнд хэлсэнчлэн энэ нийтлэлийг практикт ашиглахыг хүсч, олж авсан мэдлэгээ бодит ажил дээр хэрэгжүүлэхэд тань туслах болно. Би дахин нэмж байна.
Гэхдээ үүний дараа ч бүү зогсоо, дадлага хийж, холбогдох холбоос, номыг судалж, энэ нь танай компанид хэрхэн ажилладагийг олж мэдээд, сайжруулах боломжтой газруудыг хайж олоод оролцоорой. Амжилт хүсье!
Миний талаас
Гарчигнаас харахад энэ бол зөвхөн эхний хэсэг байсан. Энэ нь нэлээд том хэмжээтэй болсон ч чухал сэдвүүдийг энд оруулаагүй хэвээр байна. Хоёр дахь хэсэгт би автоматжуулалтын дэд бүтцийг IOS-ийн хүрээнд авч үзэхээр төлөвлөж байна. Apple-аас iOS симуляторуудыг зөвхөн macOS систем дээр ажиллуулахыг хязгаарласан тул бидний шийдлийн хүрээ нарийссан. Жишээлбэл, бид симуляторыг ажиллуулахын тулд Docker эсвэл виртуал машиныг ажиллуулах нийтийн үүл ашиглах боломжгүй. Гэхдээ энэ нь өөр хувилбар байхгүй гэсэн үг биш юм. Би та бүхэнд дэвшилтэт шийдэл, орчин үеийн хэрэгслүүдийн талаар мэдээлэл өгөхийг хичээх болно!
Мөн хяналттай холбоотой нэлээд том сэдвүүдийг би дурдаагүй. 3-р хэсэгт би хамгийн алдартай дэд бүтцийн хяналтын хэрэгслүүд болон ямар өгөгдөл, хэмжүүрүүдийг анхаарч үзэх талаар авч үзэх болно.
Мөн эцэст нь. Ирээдүйд би туршилтын дэд бүтэц, түгээмэл хэрэглүүрийг бий болгох талаар видео курс гаргахаар төлөвлөж байна. Одоогийн байдлаар Интернет дээр DevOps-ийн талаар нэлээд хэдэн курс, лекц байдаг боловч бүх материалыг туршилтын автоматжуулалт биш харин хөгжүүлэлтийн хүрээнд танилцуулж байна. Энэ асуудалд ийм сургалт нь тестер, автоматжуулалтын инженерүүдийн нийгэмлэгт сонирхолтой, үнэ цэнэтэй байх эсэх талаар санал хүсэлт надад үнэхээр хэрэгтэй байна. Урьдчилан баярлалаа!
Эх сурвалж: www.habr.com