Bagian 1: Wéb/Android
nyarios: artikel ieu mangrupa tarjamahan kana Rusia tina artikel aslina Nanging, sadaya ilustrasi, tautan, tanda petik sareng istilah disimpen dina basa asli pikeun ngahindarkeun distorsi makna nalika ditarjamahkeun kana basa Rusia. Kuring miharep anjeun senang diajar!
Ayeuna, khususna DevOps mangrupikeun salah sahiji anu paling dipénta dina industri IT. Upami anjeun muka situs milarian padamelan anu populer sareng nyaring ku gaji, anjeun bakal ningali yén padamelan anu aya hubunganana sareng DevOps aya di luhur daptar. Sanajan kitu, hal anu penting pikeun ngarti yén ieu utamana nujul kana posisi 'Senior', nu ngakibatkeun yen calon boga tingkat luhur kaahlian, pangaweruh ngeunaan téhnologi jeung parabot. Ieu ogé hadir kalawan gelar luhur tanggung jawab pakait sareng operasi uninterrupted produksi. Nanging, urang mimiti hilap naon DevOps. Mimitina, éta sanés jalma atanapi jabatan khusus. Upami urang milarian definisi istilah ieu, urang bakal mendakan seueur kecap barang anu saé sareng leres, sapertos metodologi, prakték, filsafat budaya, kelompok konsép, sareng sajabana.
Spésialisasi kuring nyaéta insinyur automation test (insinyur automation QA), tapi kuring yakin yén éta henteu kedah dikaitkeun ngan ukur nyerat tés otomatis atanapi ngembangkeun arsitéktur kerangka tés. Dina 2020, pangaweruh ngeunaan infrastruktur automation ogé penting. Ieu ngamungkinkeun anjeun pikeun ngatur prosés otomatisasi sorangan, ti ngajalankeun tés dugi ka masihan hasil ka sadaya pamangku kapentingan saluyu sareng tujuan anjeun. Hasilna, kaahlian DevOps mangrupikeun kabutuhan pikeun ngalaksanakeun padamelan. Sareng sadaya ieu saé, tapi, hanjakalna, aya masalah (spoiler: artikel ieu nyoba simplify masalah ieu). Intina nyaéta DevOps sesah. Sareng ieu atra, sabab perusahaan moal mayar pisan pikeun hal anu gampang dilakukeun ... Di dunya DevOps, aya sajumlah ageung alat, istilah, sareng prakték anu kedah dikuasai. Ieu hususna hésé dina awal karir jeung gumantung kana akumulasi pangalaman teknis.
sumber:
Di dieu urang sigana bakal ngabéréskeun bagian bubuka sareng fokus kana tujuan tulisan ieu.
Naon artikel ieu ngeunaan?
Dina tulisan ieu, kuring bakal ngabagi pangalaman kuring ngawangun infrastruktur automasi tés. Aya seueur sumber inpormasi dina Internét ngeunaan rupa-rupa alat sareng cara ngagunakeunana, tapi kuring hoyong ningal aranjeunna dina konteks automation. Kuring yakin yén loba insinyur automation wawuh jeung kaayaan nalika euweuh hiji iwal anjeun ngajalankeun tés dimekarkeun atawa paduli ngeunaan ngajaga aranjeunna. Hasilna, tés janten luntur sareng anjeun kedah nyéépkeun waktos pikeun ngapdet aranjeunna. Sakali deui, dina awal karir, ieu tiasa janten tugas anu sesah: sacara bijaksana mutuskeun alat mana anu ngabantosan ngaleungitkeun masalah anu dipasihkeun, kumaha milih, ngonpigurasikeun sareng ngajagaana. Sababaraha testers giliran DevOps (manusa) pikeun pitulung sareng, hayu urang jujur, pendekatan ieu jalan. Dina loba kasus ieu bisa jadi hiji-hijina pilihan sabab urang teu boga pisibilitas kana sagala kagumantungan. Tapi sakumaha anu urang terang, DevOps mangrupikeun jalma anu sibuk pisan, sabab aranjeunna kedah mikirkeun sadaya infrastruktur perusahaan, panyebaran, ngawaskeun, microservices sareng tugas anu sami gumantung kana organisasi / tim. Sapertos biasana, otomatisasi sanés prioritas. Dina kasus sapertos kitu, urang kedah nyobian ngalakukeun sagala hal anu mungkin di pihak urang ti mimiti dugi ka akhir. Ieu bakal ngirangan katergantungan, nyepetkeun alur kerja, ningkatkeun kaahlian urang sareng ngamungkinkeun urang ningali gambaran anu langkung ageung ngeunaan naon anu kajantenan.
Tulisan nampilkeun alat anu pang populerna sareng populér sareng nunjukkeun kumaha cara ngagunakeunana pikeun ngawangun infrastruktur automation léngkah-léngkah. Unggal kelompok diwakilan ku pakakas anu geus diuji ngaliwatan pangalaman pribadi. Tapi sanés hartosna anjeun kedah nganggo hal anu sami. Alat-alat sorangan henteu penting, aranjeunna muncul sareng janten leungit. Tugas rékayasa urang nyaéta ngartos prinsip dasar: naha urang peryogi grup alat ieu sareng masalah naon anu tiasa direngsekeun kalayan bantosanana. Éta sababna dina tungtung unggal bagian kuring ngantepkeun tautan kana alat anu sami anu tiasa dianggo dina organisasi anjeun.
Naon teu aya dina artikel ieu
Kuring ngulang sakali deui yén artikel teu ngeunaan parabot husus, jadi moal aya inserts kode tina dokuméntasi jeung déskripsi paréntah husus. Tapi dina ahir unggal bagian kuring ninggalkeun tumbu pikeun ulikan lengkep.
Hal ieu dilakukeun kusabab:
- bahan ieu pisan gampang pikeun manggihan di sagala rupa sumber (dokumentasi, buku, kursus video);
- lamun urang mimiti bade deeper, urang kudu nulis 10, 20, 30 bagian tina artikel ieu (bari rencana anu 2-3);
- Kuring ngan ukur hoyong miceunan waktos anjeun sabab anjeun panginten hoyong nganggo alat anu sanés pikeun ngahontal tujuan anu sami.
praktek
Abdi hoyong pisan bahan ieu mangpaat pikeun unggal pamaca, sarta henteu ngan maca jeung poho. Dina pangajaran naon waé, prakték mangrupikeun komponén anu penting pisan. Pikeun ieu Kuring geus disiapkeun. Aya ogé PR ngantosan anjeun pikeun mastikeun yén anjeun teu mindlessly nyalin garis paréntah anjeun executing.
Rencanana
Lengkah
teknologi
pakakas
1
Jalankeun lokal (nyiapkeun tés demo wéb / android sareng jalankeun sacara lokal)
Node.js, Selenium, Appium
2
Sistim kontrol Vérsi
indit
3
Containerization
Docker, Selenium grid, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Platform awan
Google Awan Platform
6
Orkestra
Kubernetes
7
Infrastruktur salaku kode (IaC)
Terraform, Ansible
Struktur unggal bagian
Sangkan narasi tetep écés, unggal bagian dijéntrékeun dumasar kana outline ieu:
- pedaran ringkes téknologi,
- nilai pikeun infrastruktur automation,
- ilustrasi kaayaan infrastruktur ayeuna,
- link pikeun diajar,
- parabot sarupa.
1. Jalankeun tés lokal
Katerangan ringkes ngeunaan téknologi
Ieu mangrupikeun léngkah préparasi pikeun ngajalankeun tés demo sacara lokal sareng pariksa yén aranjeunna lulus. Dina bagian praktis, Node.js dianggo, tapi basa program sareng platform ogé henteu penting sareng anjeun tiasa nganggo anu dianggo di perusahaan anjeun.
Nanging, salaku alat automasi, kuring nyarankeun ngagunakeun Selenium WebDriver pikeun platform wéb sareng Appium pikeun platform Android masing-masing, sabab dina léngkah-léngkah salajengna urang bakal ngagunakeun gambar Docker anu disaluyukeun pikeun dianggo sacara khusus sareng alat ieu. Sumawona, ngarujuk kana syarat padamelan, alat-alat ieu anu paling dipénta di pasar.
Sakumaha anjeun tiasa perhatikeun, urang ngan ukur nganggap tés wéb sareng Android. Hanjakalna, ios mangrupikeun carita anu béda-béda (hatur nuhun Apple). Abdi badé nunjukkeun solusi sareng prakték anu aya hubunganana sareng ios di bagian anu bakal datang.
Nilai pikeun infrastruktur automation
Tina sudut pandang infrastruktur, ngajalankeun lokal henteu masihan nilai nanaon. Anjeun ngan ukur pariksa yén tés dijalankeun dina mesin lokal dina panyungsi lokal sareng simulator. Tapi dina sagala hal, ieu téh titik awal perlu.
Ilustrasi kaayaan infrastruktur ayeuna
Tumbu pikeun ngajajah
parabot sarupa
- naon waé basa pamrograman anu anjeun pikahoyong sareng tés Selenium / Appium;
- sagala tés;
- sagala test runner.
2. Sistem kontrol Vérsi (Git)
Katerangan ringkes ngeunaan téknologi
Éta moal janten wahyu anu ageung pikeun saha waé upami kuring nyarios yén kontrol vérsi mangrupikeun bagian anu penting pisan pikeun pangwangunan, boh dina tim sareng individu. Dumasar kana sababaraha sumber, éta aman pikeun nyarios yén Git mangrupikeun perwakilan anu paling populér. Hiji sistem kontrol versi nyadiakeun loba mangpaat, kayaning babagi kode, nyimpen versi, malikkeun ka cabang saméméhna, ngawas sajarah proyék, sarta cadangan. Kami moal ngabahas unggal titik sacara rinci, sabab kuring yakin yén anjeun wawuh pisan sareng dianggo dina padamelan sapopoé. Tapi upami ujug-ujug henteu, maka kuring nyarankeun ngareureuhkeun maca tulisan ieu sareng ngeusian jurang ieu pas-gancang.
Nilai pikeun infrastruktur automation
Sareng di dieu anjeun tiasa naroskeun patarosan anu lumrah: "Naha anjeunna nyarioskeun ka kami ngeunaan Git? Sadayana terang ieu sareng dianggo pikeun kode pamekaran sareng kode uji otomatis. Anjeun bakal leres-leres leres, tapi dina tulisan ieu urang ngobrolkeun ngeunaan infrastruktur sareng bagian ieu janten sawangan pikeun bagian 7: "Infrastruktur salaku Kode (IaC)". Pikeun urang, ieu ngandung harti yén sakabéh infrastruktur, kaasup nguji, dijelaskeun dina bentuk kode, jadi urang ogé bisa nerapkeun sistem versioning ka dinya tur meunangkeun mangpaat sarupa pikeun ngembangkeun sarta kode automation.
Kami bakal ningal IaC sacara langkung rinci dina Lengkah 7, tapi ayeuna anjeun tiasa ngamimitian nganggo Git sacara lokal ku nyiptakeun gudang lokal. Gambar ageung bakal dilegaan nalika urang nambihan gudang jauh kana infrastruktur.
Ilustrasi kaayaan infrastruktur ayeuna
Tumbu pikeun ngajajah
parabot sarupa
3. Wadahna (Docker)
Katerangan ringkes ngeunaan téknologi
Pikeun demonstrate kumaha containerization geus robah aturan kaulinan, hayu urang balik dina jangka waktu sababaraha dekade. Jaman harita, jalma-jalma ngagaleuh sareng nganggo mesin server pikeun ngajalankeun aplikasi. Tapi dina kalolobaan kasus, sumber daya ngamimitian anu diperyogikeun henteu dipikanyaho sateuacanna. Hasilna, pausahaan méakkeun duit keur meuli mahal, server kuat, tapi sababaraha kapasitas ieu teu sagemblengna garapan.
Tahap évolusi salajengna nyaéta mesin virtual (VM), anu ngarengsekeun masalah ngabuang artos pikeun sumber anu henteu dianggo. Téknologi ieu ngamungkinkeun pikeun ngajalankeun aplikasi sacara mandiri dina server anu sami, nyayogikeun rohangan anu terasing. Tapi, hanjakalna, sagala téhnologi boga drawbacks na. Ngajalankeun VM merlukeun sistem operasi pinuh, nu meakeun CPU, RAM, neundeun jeung, gumantung kana OS, waragad lisénsi kudu dibawa kana rekening. Faktor ieu mangaruhan kagancangan ngamuat sareng ngajantenkeun portabilitas sesah.
Tur ayeuna urang datang ka containerization. Sakali deui, téknologi ieu ngarengsekeun masalah anu saencana, sabab wadahna henteu nganggo OS anu lengkep, anu ngabebaskeun sumber daya anu ageung sareng nyayogikeun solusi anu gancang sareng fleksibel pikeun portabilitas.
Tangtosna, téknologi containerization sanés énggal sareng mimiti diwanohkeun dina ahir taun 70an. Jaman harita, loba panalungtikan, pamekaran, jeung usaha anu dilaksanakeun. Tapi éta Docker anu diadaptasi téknologi ieu sareng ngajantenkeun gampang diakses ku massa. Kiwari, nalika urang ngobrol ngeunaan peti, dina kalolobaan kasus urang hartosna Docker. Nalika urang ngobrol ngeunaan wadah Docker, kami hartosna wadah Linux. Urang tiasa nganggo sistem Windows sareng macOS pikeun ngajalankeun wadah, tapi penting pikeun ngartos yén dina hal ieu lapisan tambahan muncul. Contona, Docker on Mac cicingeun ngajalankeun peti di jero hiji lightweight Linux Ubuntu VM. Urang bakal uih deui ka topik ieu nalika urang ngabahas ngajalankeun émulator Android di jero wadah, janten didieu aya nuansa anu penting anu kedah dibahas langkung rinci.
Nilai pikeun infrastruktur automation
Kami mendakan yén containerization sareng Docker keren. Hayu urang tingali ieu dina konteks automation, sabab unggal alat atawa téhnologi perlu ngajawab masalah. Hayu urang outline masalah atra tina automation test dina konteks tés UI:
- sajumlah ageung katergantungan nalika masang Selenium sareng khususna Appium;
- masalah kasaluyuan antara versi browser, simulators jeung drivers;
- kurangna spasi terasing pikeun browser / simulators, nu utamana kritis pikeun ngajalankeun paralel;
- hese ngatur jeung ngajaga lamun kudu ngajalankeun 10, 50, 100 atawa malah 1000 browser dina waktos anu sareng.
Tapi saprak Selenium mangrupikeun alat otomatisasi anu paling populér sareng Docker mangrupikeun alat wadahisasi anu paling populér, éta henteu heran yén aya anu nyobian ngagabungkeun aranjeunna pikeun nyiptakeun alat anu kuat pikeun ngabéréskeun masalah anu disebatkeun di luhur. Hayu urang nganggap solusi sapertos di leuwih jéntré.
Selenium grid dina docker
Alat ieu anu pang populerna di dunya Selenium pikeun ngajalankeun sababaraha panyungsi dina sababaraha mesin sareng ngatur aranjeunna tina hub sentral. Pikeun ngamimitian, anjeun kedah ngadaptar sahenteuna 2 bagian: Hub sareng Node. Hub mangrupikeun titik sentral anu nampi sadaya pamundut ti tés sareng ngadistribusikaeun kana Titik anu pas. Pikeun unggal Node urang tiasa ngonpigurasikeun konfigurasi khusus, contona, ku netepkeun browser anu dipikahoyong sareng versi na. Nanging, urang tetep kedah ngurus supir browser anu cocog sareng masangkeunana dina Nodes anu dipikahoyong. Ku sabab kitu, Selenium grid teu dipaké dina formulir murni, iwal mun urang kudu digawekeun ku browser nu teu bisa dipasang dina OS Linux Ubuntu. Pikeun sadaya kasus anu sanés, solusi anu fléksibel sareng leres leres nyaéta ngagunakeun gambar Docker pikeun ngajalankeun Selenium grid Hub sareng Nodes. Pendekatan ieu nyederhanakeun pisan manajemén titik, sabab urang tiasa milih gambar anu urang peryogikeun sareng versi browser anu cocog sareng supir anu parantos dipasang.
Sanaos ulasan négatip ngeunaan stabilitas, khususna nalika ngajalankeun sajumlah ageung Node paralel, Selenium grid masih mangrupikeun alat anu paling populér pikeun ngajalankeun tés Selenium paralel. Perlu dicatet yén sagala rupa perbaikan sareng modifikasi alat ieu terus-terusan muncul dina open-source, anu merangan sagala rupa bottlenecks.
Selenoid pikeun Wéb
Alat ieu mangrupikeun terobosan dina dunya Selenium sabab tiasa dianggo langsung tina kotak sareng ngajantenkeun kahirupan seueur insinyur automation langkung gampang. Anu mimiti, ieu sanés modifikasi sanés tina Selenium grid. Gantina, pamekar dijieun versi lengkep anyar Selenium Hub di Golang, nu, digabungkeun jeung gambar Docker lightweight pikeun sagala rupa panyungsi, masihan impetus kana ngembangkeun automation test. Sumawona, dina kasus Selenium Grid, urang kedah nangtoskeun sadaya panyungsi anu diperyogikeun sareng versina sateuacanna, anu henteu janten masalah nalika damel sareng ngan hiji browser. Tapi lamun datang ka sababaraha panyungsi anu dirojong, Selenoid mangrupikeun solusi nomer hiji berkat fitur 'browser on demand' na. Sadaya anu diperyogikeun ku urang nyaéta pikeun ngaunduh gambar anu diperyogikeun sareng browser sateuacanna sareng ngapdet file konfigurasi anu berinteraksi sareng Selenoid. Saatos Selenoid nampi pamundut ti tés, éta bakal otomatis ngaluncurkeun wadah anu dipikahoyong sareng browser anu dipikahoyong. Nalika tés réngsé, Selenoid bakal pensiunan wadahna, ku kituna ngabebaskeun sumber daya pikeun paménta ka hareup. Pendekatan ieu ngaleungitkeun masalah anu terkenal ngeunaan 'degradasi node' anu sering urang tepang dina grid Selenium.
Tapi, sayangna, Selenoid masih sanés pélor pérak. Kami ngagaduhan fitur 'browser on demand', tapi fitur 'resources on demand' masih teu sayogi. Pikeun ngagunakeun Selenoid, urang kedah nyebarkeun éta dina hardware fisik atanapi dina VM, anu hartosna urang kedah terang sateuacanna sabaraha sumber anu kedah dialokasikeun. Kuring nebak ieu teu masalah pikeun proyék-proyék leutik nu ngajalankeun 10, 20 atawa malah 30 panyungsi dina paralel. Tapi kumaha upami urang peryogi 100, 500, 1000 atanapi langkung? Henteu aya rasa pikeun ngajaga sareng mayar seueur sumber daya sepanjang waktos. Dina bagian 5 sareng 6 tina tulisan ieu, urang bakal ngabahas solusi anu ngamungkinkeun anjeun pikeun skala, ku kituna sacara signifikan ngirangan biaya perusahaan.
Selenoid pikeun Android
Saatos kasuksésan Selenoid salaku alat automasi wéb, jalma-jalma hoyong anu sami pikeun Android. Sareng kajadian - Selenoid dileupaskeun kalayan dukungan Android. Tina sudut pandang pangguna tingkat luhur, prinsip operasina sami sareng otomatisasi wéb. Hijina bédana nyaéta yén tinimbang wadah browser, Selenoid ngajalankeun wadah émulator Android. Dina pamanggih kuring, ieu ayeuna mangrupikeun alat gratis anu paling kuat pikeun ngajalankeun tés Android paralel.
Abdi leres-leres henteu hoyong ngobrol ngeunaan aspék négatip tina alat ieu, sabab kuring resep pisan. Tapi tetep, aya kalemahan anu sami anu dilarapkeun kana otomatisasi wéb sareng aya hubunganana sareng skala. Sajaba ti éta, urang kudu ngobrol ngeunaan hiji deui watesan nu bisa datang salaku kejutan lamun urang nyetel alat pikeun kahiji kalina. Pikeun ngajalankeun gambar Android, urang peryogi mesin fisik atanapi VM kalayan dukungan virtualisasi nested. Dina pituduh kumaha-cara, kuring nunjukkeun kumaha cara ngaktipkeun ieu dina Linux VM. Nanging, upami anjeun pangguna macOS sareng hoyong nyebarkeun Selenoid sacara lokal, maka ieu moal mungkin pikeun ngajalankeun tés Android. Tapi anjeun salawasna tiasa ngajalankeun Linux VM lokal sareng 'virtualisasi bersarang' dikonpigurasi sareng nyebarkeun Selenoid di jero.
Ilustrasi kaayaan infrastruktur ayeuna
Dina kontéks tulisan ieu, urang bakal nambihan 2 alat pikeun ngagambarkeun infrastruktur. Ieu mangrupikeun Selenium grid pikeun tés wéb sareng Selenoid pikeun tés Android. Dina tutorial GitHub, kuring ogé bakal nunjukkeun anjeun kumaha ngagunakeun Selenoid pikeun ngajalankeun tés wéb.
Tumbu pikeun ngajajah
parabot sarupa
- Aya alat wadahna anu sanés, tapi Docker anu paling populér. Upami anjeun hoyong nyobian anu sanés, émut yén alat anu kami katutupan pikeun ngajalankeun tés Selenium sacara paralel moal jalan kaluar tina kotak.
- Sakumaha anu parantos nyarios, aya seueur modifikasi grid Selenium, contona,.
4. CI/CD
Katerangan ringkes ngeunaan téknologi
Praktek integrasi kontinyu cukup populer dina pamekaran sareng sami sareng sistem kontrol versi. Sanaos ieu, kuring ngarasa aya kabingungan dina terminologi. Dina paragraf ieu kuring hoyong ngajelaskeun 3 modifikasi téknologi ieu tina sudut pandang kuring. Dina internét anjeun bakal manggihan loba artikel kalawan interpretasi béda, tur éta normal lamun pendapat anjeun béda. Anu paling penting nyaéta anjeun dina halaman anu sami sareng kolega anjeun.
Jadi, aya 3 istilah: CI - Continuous Integration, CD - Continuous Delivery jeung deui CD - Continuous Deployment. (Di handap ieu kuring bakal ngagunakeun istilah ieu dina basa Inggris). Unggal modifikasi nambihan sababaraha léngkah tambahan kana pipa pangembangan anjeun. Tapi kecap terus-terusan (sinambung) mangrupa hal pangpentingna. Dina kontéks ieu, urang hartosna hiji hal anu lumangsung ti mimiti nepi ka rengse, tanpa gangguan atawa campur manual. Hayu urang tingali CI & CD sareng CD dina kontéks ieu.
- Integrasi kontinyu ieu mangrupikeun léngkah awal évolusi. Saatos ngirimkeun kodeu énggal ka server, kami ngarep-arep nampi tanggapan gancang yén parobihan kami henteu kunanaon. Ilaharna, CI ngawengku ngajalankeun parabot analisis kode statik sarta Unit / tés API internal.Hal ieu ngamungkinkeun urang pikeun ménta inpo ngeunaan kode urang dina sababaraha detik/menit.
- Pangiriman kontinyu mangrupakeun hambalan leuwih maju dimana urang ngajalankeun integrasi / UI tés. Nanging, dina tahap ieu kami henteu kéngingkeun hasil gancang sapertos CI. Kahiji, jenis tés ieu butuh waktu leuwih lila pikeun réngsé. Kadua, sateuacan diluncurkeun, urang kedah nyebarkeun parobihan kana lingkungan uji / pementasan. Sumawona, upami urang ngobrol ngeunaan pamekaran mobile, maka léngkah tambahan muncul pikeun nyiptakeun ngawangun aplikasi urang.
- Panyebaran kontinyu nganggap yén urang sacara otomatis ngabebaskeun parobahan produksi upami sadaya tés katampi parantos lulus dina tahap sateuacana. Salaku tambahan, saatos tahap pelepasan, anjeun tiasa ngonpigurasikeun sababaraha tahap, sapertos ngajalankeun tés haseup dina produksi sareng ngumpulkeun métrik anu dipikaresep. Panyebaran kontinyu ngan ukur tiasa dilaksanakeun kalayan sinyalna anu saé ku tés otomatis. Upami aya campur tangan manual anu diperyogikeun, kalebet tés, maka ieu henteu deui terus-terusan (terus-terusan). Teras urang tiasa nyebatkeun yén pipa kami ngan ukur patuh kana prakték Pangiriman Kontinyu.
Nilai pikeun infrastruktur automation
Dina bagian ieu, kuring kedah netelakeun yén nalika urang ngobrol ngeunaan tés UI tungtung-to-tungtung, éta hartosna urang kedah nyebarkeun parobahan sareng jasa anu aya hubunganana pikeun nguji lingkungan. Integrasi Kontinyu - prosésna henteu lumaku pikeun tugas ieu sareng urang kedah ngurus ngalaksanakeun sahenteuna prakték Continuous Deliver. Panyebaran Kontinyu ogé asup akal dina konteks tés UI upami urang badé ngajalankeun éta dina produksi.
Sareng sateuacan urang ningali ilustrasi parobihan arsitéktur, kuring badé nyarios sababaraha kecap ngeunaan GitLab CI. Beda sareng alat CI / CD anu sanés, GitLab nyayogikeun gudang jauh sareng seueur fitur tambahan anu sanés. Ku kituna, GitLab leuwih ti CI. Éta kalebet manajemén kode sumber, manajemén tangkas, pipa CI / CD, alat logging sareng koleksi métrik tina kotak. Arsitéktur GitLab diwangun ku Gitlab CI/CD sareng GitLab Runner. Ieu pedaran pondok tina situs wéb resmi:
Gitlab CI / CD mangrupakeun aplikasi wéb kalawan API nu nyimpen kaayaan na di database a, manages proyék / ngawangun sarta nyadiakeun antarbeungeut pamaké. GitLab Runner mangrupikeun aplikasi anu ngawangun prosés. Éta tiasa disebarkeun nyalira sareng tiasa dianggo sareng GitLab CI / CD ngalangkungan API. Pikeun tés ngajalankeun anjeun peryogi duanana conto Gitlab sareng Runner.
Ilustrasi kaayaan infrastruktur ayeuna
Tumbu pikeun ngajajah
parabot sarupa
- Jeung loba batur
5. platform awan
Katerangan ringkes ngeunaan téknologi
Dina bagian ieu urang bakal ngobrol ngeunaan trend populér disebut 'awan publik'. Sanaos kauntungan anu ageung anu disayogikeun ku téknologi virtualisasi sareng wadahisasi anu dijelaskeun di luhur, urang masih peryogi sumber komputasi. Pausahaan mésér server mahal atawa nyéwa puseur data, tapi dina hal ieu perlu nyieun itungan (kadangkala unrealistic) tina sabaraha sumberdaya urang bakal butuh, naha urang bakal ngagunakeun éta 24/7 jeung naon kaperluan. Contona, produksi merlukeun server ngajalankeun XNUMX/XNUMX, tapi urang kudu sumberdaya sarupa pikeun nguji luar jam gawé? Éta ogé gumantung kana jinis tés anu dilakukeun. Hiji conto bakal beban / stress tés nu urang rencanana ngajalankeun salila jam non-kerja dina urutan pikeun meunangkeun hasil poé saterusna. Tapi pasti kasadiaan server XNUMX/XNUMX henteu diperyogikeun pikeun tés otomatis tungtung-ka-tungtung sareng khususna sanés pikeun lingkungan tés manual. Pikeun kaayaan kitu, éta bakal hadé pikeun ménta saloba sumberdaya sakumaha diperlukeun dina paménta, make aranjeunna, sarta ngeureunkeun mayar lamun aranjeunna henteu deui diperlukeun. Leuwih ti éta, éta bakal hadé pikeun nampa eta instan ku nyieun sababaraha clicks mouse atawa ngajalankeun sababaraha Aksara. Ieu kanggo naon awan umum dianggo. Hayu urang tingali definisi:
"Awan umum diartikeun salaku jasa komputasi anu ditawarkeun ku panyadia pihak katilu dina Internét umum, ngajantenkeun aranjeunna sayogi pikeun saha waé anu hoyong nganggo atanapi mésér. Éta tiasa gratis atanapi dijual dumasar kana paménta, ngamungkinkeun para nasabah ngan ukur mayar per pamakean pikeun siklus CPU, neundeun, atanapi bandwidth anu aranjeunna konsumsi.
Aya pamadegan yén awan umum mahal. Tapi ide konci maranéhanana nyaéta pikeun ngirangan biaya perusahaan. Sakumaha anu disebatkeun sateuacana, awan umum ngamungkinkeun anjeun kéngingkeun sumber anu diperyogikeun sareng ngan ukur mayar kanggo waktos anjeun nganggoana. Ogé, sakapeung urang hilap yén pagawé nampi gaji, sareng spesialis ogé sumber anu mahal. Éta kedah diperhatoskeun yén awan umum ngajantenkeun dukungan infrastruktur langkung gampang, anu ngamungkinkeun para insinyur fokus kana tugas anu langkung penting.
Nilai pikeun infrastruktur automation
Sumber daya khusus naon anu urang peryogikeun pikeun tés UI tungtung-ka-tungtung? Dasarna ieu mesin virtual atanapi klaster (urang bakal ngobrol ngeunaan Kubernetes dina bagian salajengna) pikeun ngajalankeun panyungsi sareng émulator. Langkung seueur browser sareng émulator anu urang hoyong jalankeun sakaligus, langkung seueur CPU sareng mémori anu diperyogikeun sareng langkung seueur artos anu urang kedah mayar. Ku kituna, awan publik dina konteks automation test ngamungkinkeun urang pikeun ngajalankeun angka nu gede ngarupakeun (100, 200, 1000 ...) tina panyungsi / emulators on demand, meunang hasil test gancang-gancang sarta ngeureunkeun mayar misalna insanely sumberdaya-intensif. kakuatan.
Panyadia awan anu pang populerna nyaéta Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Pituduh kumaha-cara nyadiakeun conto cara ngagunakeun GCP, tapi sacara umum henteu masalah naon anu anjeun anggo pikeun tugas-tugas otomatisasi. Éta sadayana nyayogikeun fungsionalitas anu sami. Ilaharna, pikeun milih panyadia, manajemén museurkeun kana sadaya prasarana sareng syarat bisnis perusahaan, anu saluareun ruang lingkup tulisan ieu. Pikeun insinyur otomasi, bakal langkung narik pikeun ngabandingkeun panggunaan panyadia awan sareng panggunaan platform awan khusus pikeun tujuan uji, sapertos Sauce Labs, BrowserStack, BitBar, sareng sajabana. Ku kituna hayu urang ngalakukeun ogé! Dina pamanggih kuring, Sauce Labs mangrupikeun tegalan tés awan anu paling kasohor, naha éta kuring dianggo pikeun ngabandingkeun.
GCP vs Sauce Labs pikeun tujuan otomatisasi:
Bayangkeun yén urang kedah ngajalankeun 8 tés wéb sareng 8 tés Android sakaligus. Pikeun ieu kami bakal nganggo GCP tur ngajalankeun 2 mesin virtual kalawan Selenoid. Dina kahiji urang bakal ngangkat 8 peti jeung browser. Dina kadua aya 8 peti jeung emulators. Hayu urang tingali hargana:
Pikeun ngajalankeun hiji wadah sareng Chrome, urang peryogi n1-baku-1 mobil. Dina kasus Android éta bakal n1-baku-4 pikeun hiji émulator. Nyatana, cara anu langkung fleksibel sareng langkung mirah nyaéta nyetél nilai pangguna khusus pikeun CPU / Mémori, tapi ayeuna ieu henteu penting pikeun ngabandingkeun sareng Sauce Labs.
Sareng ieu mangrupikeun tarif pikeun ngagunakeun Sauce Labs:
Kuring yakin anjeun parantos ningali bédana, tapi kuring masih bakal nyayogikeun méja itungan pikeun tugas urang:
sumberdaya diperlukeun
Bulanan
jam gawe(8 am - 8 pm)
jam gawe+ Preemptible
GCP pikeun Wéb
n1-baku-1 x 8 = n1-baku-8
$194.18
23 poé * 12h * 0.38 = $ 104.88
23 poé * 12h * 0.08 = $ 22.08
Labs saos pikeun Wéb
Virtual Cloud8 tés paralel
$1.559
-
-
GCP pikeun Android
n1-baku-4 x 8: n1-baku-16
$776.72
23 poé * 12h * 1.52 = $ 419.52
23 poé * 12h * 0.32 = $ 88.32
Labs saos pikeun Android
Real Alat Awan 8 tés paralel
$1.999
-
-
Sakumaha anjeun tiasa tingali, bédana dina biaya anu ageung, khususna upami anjeun ngan ukur ngajalankeun tés salami periode kerja dua belas jam. Tapi anjeun tiasa ngirangan biaya langkung jauh upami anjeun nganggo mesin preemptible. Anu mana?
A VM preemptible mangrupakeun conto nu bisa Anjeun jieun tur ngajalankeun kalawan harga muchower ti instansi normal. Sanajan kitu, Compute Engine bisa ngeureunkeun (preempt) instansi ieu lamun merlukeun aksés ka eta sumberdaya pikeun tugas séjén. Instance preemptible nyaéta kaleuwihan kapasitas Compute Engine, ku kituna kasadiaanna béda-béda dumasar kana pamakean.
Upami aplikasi anjeun toleran kasalahan sareng tiasa tahan kamungkinan preemptions instan, maka instansi anu tiasa diprediksi tiasa ngirangan biaya Compute Engine anjeun sacara signifikan. Contona, jobs processing bets bisa ngajalankeun on instansi preemptible. Upami sababaraha instansi éta ngeureunkeun nalika ngolah, padamelan ngalambatkeun tapi henteu lirén lengkep. Instance preemptible ngalengkepan tugas ngolah bets anjeun tanpa nempatkeun beban kerja tambahan dina instansi anjeun anu tos aya sareng tanpa meryogikeun anjeun mayar harga pinuh pikeun instansi normal tambahan.
Sareng éta henteu acan réngsé! Kanyataanna, kuring yakin teu aya anu ngajalankeun tés salami 12 jam tanpa istirahat. Sareng upami kitu, anjeun tiasa otomatis ngamimitian sareng ngeureunkeun mesin virtual nalika henteu diperyogikeun. Waktu pamakean saleresna tiasa dikirangan dugi ka 6 jam sadinten. Lajeng pamayaran dina konteks tugas urang bakal turun ka $11 per bulan pikeun 8 browser. Teu ieu éndah? Tapi kalawan mesin preemptible urang kudu ati tur disiapkeun keur interruptions na instability, sanajan kaayaan ieu bisa disadiakeun pikeun tur diatur dina software. Ieu patut eta!
Tapi sanés hartosna kuring nyarios 'pernah nganggo kebon uji awan'. Aranjeunna mibanda sababaraha kaunggulan. Anu mimiti, ieu mah sakadar mesin virtual, tapi solusi automation test full-fledged kalawan sakumpulan fungsionalitas out of the box: aksés jauh, log, Potret layar, rekaman video, rupa-rupa browser jeung alat nu bagerak fisik. Dina loba kaayaan, ieu bisa jadi alternatif Srimanganti penting. Platform nguji hususna kapaké pikeun otomatisasi ios, nalika awan umum ngan ukur tiasa nawiskeun sistem Linux/Windows. Tapi urang bakal ngobrol ngeunaan ios dina tulisan di handap ieu. Kuring nganjurkeun salawasna ningali kaayaan tur mimitian ti tugas: dina sababaraha kasus éta langkung mirah tur leuwih efisien ngagunakeun awan umum, sarta di batur platform test pasti patut duit spent.
Ilustrasi kaayaan infrastruktur ayeuna
Tumbu pikeun ngajajah
Alat anu sami:
6. Orkestrasi
Katerangan ringkes ngeunaan téknologi
Kuring boga warta alus - kami ampir di ahir artikel! Ayeuna, infrastruktur automation kami diwangun ku tés wéb sareng Android, anu kami jalankeun ngaliwatan GitLab CI sacara paralel, nganggo alat anu diaktipkeun Docker: Selenium grid sareng Selenoid. Sumawona, kami nganggo mesin virtual anu diciptakeun via GCP pikeun nyayogikeun wadah sareng browser sareng émulator. Pikeun ngirangan biaya, urang ngamimitian mesin virtual ieu ngan ukur upami diperyogikeun sareng ngeureunkeunana nalika tés henteu dilaksanakeun. Naha aya deui anu tiasa ningkatkeun infrastruktur urang? Jawabna enya! Minuhan Kubernetes (K8s)!
Kahiji, hayu urang tingali kumaha kecap orkestrasi, klaster, sareng Kubernetes aya hubunganana. Dina tingkat anu luhur, orkestra nyaéta sistem anu nyebarkeun sareng ngatur aplikasi. Pikeun otomatisasi tés, aplikasi wadahna sapertos Selenium grid sareng Selenoid. Docker sareng K8 silih pelengkap. Anu kahiji dianggo pikeun panyebaran aplikasi, anu kadua pikeun orkestra. Kahareupna K8s mangrupakeun klaster. Tugas kluster nyaéta ngagunakeun VM salaku Nodes, anu ngamungkinkeun anjeun masang rupa-rupa fungsionalitas, program sareng jasa dina hiji server (cluster). Upami salah sahiji Node gagal, Node sanésna bakal diangkat, anu ngajamin operasi anu teu diganggu tina aplikasi urang. Sajaba ti éta, K8s boga fungsi penting patali skala, hatur nuhun nu urang otomatis ménta jumlah optimal sumberdaya dumasar kana beban sarta set wates.
Sabenerna, sacara manual nyebarkeun Kubernetes ti mimiti sanés mangrupikeun tugas anu sepele. Kuring bakal ninggalkeun tumbu ka kawentar kumaha-pikeun pituduh "Kubernetes The Hard Way" jeung lamun resep, anjeun tiasa latihan eta. Tapi, untungna, aya metode sareng alat alternatif. Cara panggampangna nyaéta ngagunakeun Google Kubernetes Engine (GKE) dina GCP, anu ngamungkinkeun anjeun kéngingkeun kluster anu siap-siap dina sababaraha klik. Abdi nyarankeun ngagunakeun pendekatan ieu pikeun ngamimitian diajar, sabab bakal ngidinan Anjeun pikeun difokuskeun diajar kumaha carana make K8s pikeun tugas anjeun tinimbang diajar kumaha komponén internal kudu terpadu saling.
Nilai pikeun infrastruktur automation
Hayu urang tingali sababaraha fitur penting anu disayogikeun ku K8s:
- deployment aplikasi: ngagunakeun klaster multi-titik tinimbang VMs;
- skala dinamis: ngurangan biaya sumberdaya nu dipaké ukur dina paménta;
- nyageurkeun diri: pamulihan otomatis tina pods (salaku hasilna wadahna ogé disimpen deui);
- rollout of apdet sarta rollbacks parobahan tanpa downtime: ngamutahirkeun parabot, browser jeung emulators teu ngaganggu karya pamaké ayeuna
Tapi K8s masih teu pérak pérak. Ngartos sagala kaunggulan tur watesan dina konteks parabot urang tempo (Selenium grid, Selenoid), urang sakeudeung bakal ngabahas struktur K8s. Kluster ngandung dua jinis Node: Master Nodes sareng Workers Nodes. Master Nodes tanggung jawab pikeun manajemén, panyebaran sareng kaputusan jadwal. Titik pagawe mangrupikeun tempat aplikasi diluncurkeun. Node ogé ngandung lingkungan runtime wadahna. Dina hal urang, ieu Docker, anu tanggung jawab pikeun operasi anu aya hubunganana sareng wadahna. Tapi aya ogé solusi alternatif, contona. Penting pikeun ngarti yén skala atanapi nyageurkeun diri henteu langsung dilarapkeun kana wadahna. Ieu dilaksanakeun ku nambahkeun / ngurangan jumlah pods, anu dina gilirannana ngandung peti (biasana hiji wadah per pod, tapi gumantung kana tugas meureun aya deui). Hierarki tingkat luhur diwangun ku titik pagawe, di jerona aya polong, di jero wadahna diangkat.
Fitur skala mangrupikeun konci sareng tiasa diterapkeun ka kadua titik dina simpul-kolam klaster sareng pod dina titik. Aya 2 jinis skala anu berlaku pikeun node sareng pods. Tipe kahiji nyaéta horizontal - scaling lumangsung ku ngaronjatna jumlah titik / pods. Jenis ieu langkung dipikaresep. Jenis kadua, sasuai, vertikal. Skala dilaksanakeun ku cara ningkatkeun ukuran node/pods, sanes jumlahna.
Ayeuna hayu urang tingali alat urang dina konteks istilah di luhur.
Selenium grid
Sakumaha anu disebatkeun sateuacana, Selenium grid mangrupikeun alat anu kasohor, sareng éta henteu heran yén éta wadahna. Ku alatan éta, teu heran yén Selenium grid bisa deployed di K8s. Conto kumaha ngalakukeun ieu tiasa dipendakan dina gudang resmi K8s. Sakumaha biasa, kuring ngagantelkeun tautan dina tungtung bagian. Salaku tambahan, pituduh kumaha-cara nunjukkeun kumaha ngalakukeun ieu dina Terraform. Aya ogé parentah ngeunaan cara skala jumlah pods nu ngandung wadahna browser. Tapi fungsi skala otomatis dina konteks K8s masih teu tugas lengkep atra. Nalika kuring mimiti diajar, kuring henteu mendakan pituduh atanapi rekomendasi praktis. Saatos sababaraha panilitian sareng ékspérimén kalayan dukungan tim DevOps, kami milih pendekatan pikeun ngangkat wadah sareng panyungsi anu diperyogikeun dina hiji pod, anu aya di jero hiji titik padamel. Metoda ieu ngamungkinkeun urang pikeun nerapkeun strategi skala horizontal titik ku cara ningkatkeun jumlah maranéhanana. Kuring miharep yén ieu bakal robah dina mangsa nu bakal datang sarta kami bakal ningali beuki loba déskripsi ngeunaan pendekatan hadé tur solusi siap-dijieun, utamana sanggeus sékrési Selenium grid 4 kalawan arsitektur internal robah.
Selenoid:
deployment Selenoid di K8s ayeuna teh disappointment pangbadagna. Aranjeunna teu cocog. Sacara tiori, urang tiasa ngangkat wadah Selenoid di jero pod, tapi nalika Selenoid ngamimitian ngaluncurkeun wadah nganggo browser, aranjeunna tetep aya di jero pod anu sami. Hal ieu ngajadikeun skala teu mungkin jeung, salaku hasilna, karya Selenoid di jero klaster moal béda ti pagawean di jero mesin virtual. Tungtung carita.
bulan:
Nyaho bottleneck ieu nalika damel sareng Selenoid, pamekar ngaluarkeun alat anu langkung kuat anu disebut Bulan. Alat ieu asalna dirancang pikeun digawe sareng Kubernetes sareng, salaku hasilna, fitur autoscaling tiasa sareng kedah dianggo. Leuwih ti éta, kuring bakal nyebutkeun yén dina momen éta ngan alat di dunya Selenium, anu ngagaduhan dukungan kluster asli K8s out of the box (euweuh deui sadia, tingali alat salajengna ). Fitur konci Moon anu nyayogikeun dukungan ieu nyaéta:
Lengkep stateless. Selenoid nyimpen inpormasi mémori ngeunaan sési browser ayeuna. Upami kusabab sababaraha alesan prosésna ngadat - maka sadaya sesi jalan leungit. Bulan sabalikna teu boga kaayaan internal tur bisa replicated sakuliah puseur data. Sesi browser tetep hirup sanajan hiji atawa leuwih réplika turun.
Janten, Moon mangrupikeun solusi anu saé, tapi aya hiji masalah: éta henteu gratis. Hargana gumantung kana jumlah sesi. Anjeun ngan bisa ngajalankeun 0-4 sesi haratis, nu teu utamana mangpaat. Tapi, mimitian ti sési kalima, anjeun kudu mayar $5 pikeun tiap. Kaayaanana tiasa bénten-béda ti perusahaan ka perusahaan, tapi dina kasus urang, nganggo Moon henteu aya gunana. Salaku I ditétélakeun di luhur, urang tiasa ngajalankeun VMs kalawan Selenium Grid on paménta atawa nambahan jumlah titik dina kluster. Pikeun kira-kira hiji pipa, kami ngajalankeun 500 browser sareng ngeureunkeun sadaya sumber saatos tés réngsé. Upami urang nganggo Moon, urang kedah mayar tambahan 500 x 5 = $ 2500 per bulan, henteu paduli sabaraha sering urang ngajalankeun tés. Deui, Kuring teu nyebutkeun teu make Bulan. Pikeun tugas anjeun, ieu tiasa janten solusi anu penting, contona, upami anjeun ngagaduhan seueur proyék / tim dina organisasi anjeun sareng anjeun peryogi klaster umum anu ageung pikeun sadayana. Sapertos biasa, kuring ngantunkeun tautan dina tungtungna sareng nyarankeun ngalakukeun sadaya itungan anu diperyogikeun dina konteks tugas anjeun.
Callisto: (Perhatosan! Ieu henteu aya dina tulisan asli sareng ngan aya dina tarjamahan Rusia)
Sakumaha anu kuring nyarios, Selenium mangrupikeun alat anu kasohor, sareng widang IT ngembang pisan gancang. Nalika kuring damel dina tarjamahan, alat anu ngajangjikeun anyar anu disebut Callisto muncul dina wéb (halo Cypress sareng pembunuh Selenium anu sanés). Gawéna natively kalawan K8s tur ngidinan Anjeun pikeun ngajalankeun peti Selenoid dina pods, disebarkeun sakuliah Nodes. Sadayana jalan langsung tina kotak, kalebet autoscaling. Hebat, tapi kedah diuji. Kuring parantos junun nyebarkeun alat ieu sareng ngajalankeun sababaraha percobaan. Tapi teuing mimiti ngagambar conclusions, sanggeus narima hasil dina jarak jauh, sugan kuring bakal ngalakukeun review dina artikel nu bakal datang. Pikeun ayeuna mah ngan ninggalkeun Tumbu pikeun panalungtikan bebas.
Ilustrasi kaayaan infrastruktur ayeuna
Tumbu pikeun ngajajah
parabot sarupa
7. Infrastruktur salaku Kodeu (IaC)
Katerangan ringkes ngeunaan téknologi
Tur ayeuna urang datang ka bagian panungtungan. Biasana, téknologi ieu sareng tugas anu aya hubunganana sanés tanggung jawab insinyur automation. Sareng aya alesan pikeun ieu. Anu mimiti, dina seueur organisasi, masalah infrastruktur aya dina kadali departemén DevOps sareng tim pamekaran henteu paduli pisan ngeunaan naon anu ngajantenkeun pipa sareng kumaha sadayana anu aya hubunganana sareng éta kedah didukung. Kadua, jujur, praktek Infrastructure as Code (IaC) masih teu diadopsi di seueur perusahaan. Tapi éta pasti parantos janten tren anu populer sareng penting pikeun nyobian aub dina prosés, pendekatan sareng alat anu aya hubunganana. Atawa sahenteuna tetep nepi ka tanggal.
Hayu urang mimitian ku motivasi pikeun ngagunakeun pendekatan ieu. Kami parantos ngabahas yén pikeun ngajalankeun tés dina GitlabCI, urang peryogi sahenteuna sumber daya pikeun ngajalankeun Gitlab Runner. Sarta pikeun ngajalankeun wadah kalawan browser / emulators, urang kudu cagar VM atanapi klaster. Salian sumber daya nguji, urang peryogi jumlah signifikan kapasitas pikeun ngarojong ngembangkeun, pementasan, lingkungan produksi, nu ogé ngawengku database, jadwal otomatis, konfigurasi jaringan, load balancers, hak pamaké, jeung saterusna. Masalah konci nyaéta usaha anu diperyogikeun pikeun ngadukung éta sadayana. Aya sababaraha cara urang tiasa ngarobih sareng ngaluncurkeun apdet. Salaku conto, dina konteks GCP, urang tiasa nganggo konsol UI dina browser sareng ngalaksanakeun sagala tindakan ku ngaklik tombol. Alternatipna nyaéta nganggo sauran API pikeun berinteraksi sareng éntitas awan, atanapi nganggo utilitas garis paréntah gcloud pikeun ngalakukeun manipulasi anu dipikahoyong. Tapi kalayan sajumlah ageung éntitas sareng elemen infrastruktur anu béda, janten sesah atanapi bahkan teu mungkin pikeun ngalakukeun sadayana operasi sacara manual. Sumawona, sadaya tindakan manual ieu teu tiasa dikadalikeun. Kami henteu tiasa ngalebetkeun aranjeunna pikeun ditinjau sateuacan dieksekusi, nganggo sistem kontrol vérsi, sareng gancang ngagulung deui parobihan anu nyababkeun kajadian éta. Pikeun ngabéréskeun masalah sapertos kitu, insinyur nyiptakeun sareng nyiptakeun skrip bash / cangkang otomatis, anu henteu langkung saé tibatan metode sateuacana, sabab henteu gampang dibaca gancang, ngartos, ngajaga sareng ngarobih dina gaya prosedural.
Dina artikel ieu sareng kumaha-pikeun pituduh, kuring nganggo 2 alat anu aya hubunganana sareng prakték IaC. Ieu Terraform sareng Ansible. Sababaraha urang yakin yén teu aya rasa ngagunakeun éta dina waktos anu sareng, sabab fungsionalitasna sami sareng aranjeunna tiasa ditukeurkeun. Tapi kanyataanana mimitina aranjeunna dibéré tugas lengkep béda. Sareng kanyataan yén alat-alat ieu kedah saling melengkapi dikonfirmasi dina presentasi gabungan ku pamekar anu ngalambangkeun HashiCorp sareng RedHat. Beda konseptual nyaéta Terraform mangrupikeun alat panyediaan pikeun ngatur server sorangan. Nalika Ansible mangrupikeun alat manajemén konfigurasi anu tugasna masang, ngonpigurasikeun sareng ngatur parangkat lunak dina server ieu.
Fitur utama anu ngabédakeun alat ieu nyaéta gaya coding. Beda sareng bash sareng Ansible, Terraform nganggo gaya déklaratif dumasar kana pedaran ngeunaan kaayaan tungtung anu dipikahoyong pikeun dihontal salaku hasil tina palaksanaan. Salaku conto, upami urang badé nyiptakeun 10 VM sareng nerapkeun parobihan ngalangkungan Terraform, maka urang bakal nampi 10 VM. Lamun urang ngajalankeun naskah deui, nanaon bakal kajadian saprak urang geus boga 10 VM, sarta Terraform weruh ngeunaan ieu sabab nyimpen kaayaan ayeuna infrastruktur dina file kaayaan. Tapi Ansible nganggo pendekatan prosedural sareng, upami anjeun naroskeun nyiptakeun 10 VM, maka dina peluncuran anu munggaran urang bakal nampi 10 VM, sami sareng Terraform. Tapi saatos dibalikan deui kami bakal ngagaduhan 20 VM. Ieu bédana penting. Dina gaya prosedural, urang henteu nyimpen kaayaan ayeuna sareng ngan saukur ngajelaskeun runtuyan léngkah anu kedah dilakukeun. Tangtosna, urang tiasa ngadamel sababaraha kaayaan, nambihan sababaraha cek pikeun ayana sumber daya sareng kaayaan ayeuna, tapi teu aya gunana pikeun ngabuang waktos sareng usaha pikeun ngatur logika ieu. Salaku tambahan, ieu ningkatkeun résiko kasalahan.
Nyimpulkeun sadayana di luhur, urang tiasa nyimpulkeun yén Terraform sareng notasi déklaratif mangrupikeun alat anu langkung cocog pikeun nyayogikeun server. Tapi éta hadé pikeun utusan karya manajemén konfigurasi ka Ansible. Kalayan éta, hayu urang tingali kasus pamakean dina kontéks otomatisasi.
Nilai pikeun infrastruktur automation
Hiji-hijina hal anu penting pikeun ngartos di dieu nyaéta yén prasarana automasi tés kedah dianggap salaku bagian tina sakumna infrastruktur perusahaan. Ieu ngandung harti yén sakabéh prakték IaC kudu diterapkeun sacara global kana sumber daya sakabéh organisasi. Saha anu tanggung jawab ieu gumantung kana prosés anjeun. Tim DevOps langkung ngalaman dina masalah ieu, aranjeunna ningali sadayana gambar naon anu kajantenan. Nanging, insinyur QA langkung aub dina prosés ngawangun automation sareng struktur pipa, anu ngamungkinkeun aranjeunna ningali langkung saé sadaya parobihan anu diperyogikeun sareng kasempetan pikeun perbaikan. Pilihan pangsaéna nyaéta gawé bareng, tukeur pangaweruh sareng ideu pikeun ngahontal hasil anu dipiharep.
Ieu sababaraha conto ngagunakeun Terraform sareng Ansible dina kontéks otomatisasi tés sareng alat anu urang bahas sateuacanna:
1. Ngajelaskeun ciri perlu jeung parameter VMs na klaster maké Terraform.
2. Ngagunakeun Ansible, install parabot diperlukeun pikeun nguji: docker, Selenoid, Selenium Grid tur ngundeur versi diperlukeun tina browser / emulators.
3. Ngagunakeun Terraform, ngajelaskeun karakteristik VM dimana GitLab Runner bakal diluncurkeun.
4. Pasang GitLab Runner sareng alat anu diperyogikeun nganggo Ansible, set setélan sareng konfigurasi.
Ilustrasi kaayaan infrastruktur ayeuna
Tumbu pikeun ngajajah:
parabot sarupa
Hayu urang nyimpulkeun!
Lengkah
teknologi
pakakas
Nilai pikeun infrastruktur automation
1
Ngajalankeun lokal
Node.js, Selenium, Appium
- Alat anu pang populerna pikeun wéb sareng mobile
- Ngarojong seueur basa sareng platform (kalebet Node.js)
2
Sistim kontrol Vérsi
indit
- Mangpaat anu sami sareng kode pangembangan
3
Containerization
Docker, Selenium grid, Selenoid (Web, Android)
- Ngajalankeun tés paralel
- Lingkungan terasing
- Basajan, upgrades Vérsi fléksibel
- Dinamis ngeureunkeun sumberdaya anu henteu dianggo
- Gampang nyetél
4
CI/CD
Gitlab CI
- Nguji bagian tina pipa
- Eupan Balik Gancang
- Visibilitas pikeun sakabéh perusahaan / tim
5
Platform awan
Google Awan Platform
- Sumberdaya on demand (urang mayar ngan lamun diperlukeun)
- Gampang pikeun ngatur sareng ngapdet
- Visibilitas sareng kontrol sadaya sumber
6
Orkestra
Kubernetes
Dina kontéks wadah sareng browser / émulator di jero pods:
- Skala / skala otomatis
- Nyageurkeun diri
- Apdet sarta rollbacks tanpa gangguan
7
Infrastruktur salaku kode (IaC)
Terraform, Ansible
- Mangpaat anu sami sareng infrastruktur pangwangunan
- Sadaya kauntungan tina versi kode
- Gampang nyieun parobahan jeung mertahankeun
- Sapinuhna otomatis
Diagram peta pikiran: évolusi infrastruktur
lengkah 1: Lokal
lengkah2: VCS
step3: Containerization
lengkah 4: CI / CD
step5: Platform awan
lengkah 6: Orkestrasi
lengkah 7: IaC
Naon saterusna?
Janten, ieu mangrupikeun tungtung tulisan. Tapi dina kacindekan, abdi hoyong ngadamel sababaraha perjangjian sareng anjeun.
Ti sisi anjeun
Sakumaha anu kuring nyarios di awal, kuring hoyong tulisan éta tiasa dianggo praktis sareng ngabantosan anjeun ngalarapkeun pangaweruh anu dicandak dina karya nyata. Kuring nambahan deui.
Tapi sanajan sanggeus éta, ulah eureun, latihan, diajar Tumbu relevan sarta buku, manggihan cara gawéna di parusahaan anjeun, manggihan tempat nu bisa ningkat jeung ilubiung dina eta. Sing salamet!
Ti sisi kuring
Tina judul anjeun tiasa ningali yén ieu ngan ukur bagian munggaran. Najan kanyataan yén tétéla rada badag, topik penting masih teu katutupan di dieu. Dina bagian kadua, abdi rencana pikeun nempo infrastruktur automation dina konteks ios. Alatan larangan Apple dina ngajalankeun simulators ios ngan dina sistem macOS, rentang solusi kami sempit. Salaku conto, urang henteu tiasa nganggo Docker pikeun ngajalankeun simulator atanapi awan umum pikeun ngajalankeun mesin virtual. Tapi ieu lain hartosna yén euweuh alternatif séjén. Kuring bakal nyobian tetep anjeun up to date jeung solusi canggih tur parabot modern!
Ogé, kuring henteu acan nyarioskeun topik anu ageung anu aya hubunganana sareng monitoring. Dina Bagian 3, kuring bakal ningali alat ngawaskeun infrastruktur anu paling populér sareng data sareng métrik anu kedah dipertimbangkeun.
Sarta pamustunganana. Dina mangsa nu bakal datang, abdi rencanana ngaleupaskeun kursus video dina ngawangun infrastruktur test na parabot populér. Ayeuna, aya sababaraha kursus sareng ceramah dina DevOps dina Internét, tapi sadaya bahan dibere dina kontéks pamekaran, sanés tés otomatis. Dina masalah ieu, kuring peryogi eupan balik naha kursus sapertos kitu bakal pikaresepeun sareng berharga pikeun komunitas panguji sareng insinyur automation. Hatur nuhun sateuacana!
sumber: www.habr.com