Cauruļvadu optimizācija Linux sistēmā: no caurulēm līdz uzlabotai CI/CD

Informatec Digital » Resursi » Cauruļvadu optimizācija Linux sistēmā: no caurulēm līdz uzlabotai CI/CD

Cauruļvadu optimizācija operētājsistēmā Linux Tas nav tikai par komandu ķēdēšanu ar simbolu |Aiz visa tā slēpjas vesela pasaule veiktspējas optimizācijaDarbplūsmas dizains, CI/CD, drošība un operētājsistēmas regulēšana ir vissvarīgākā atšķirība starp lēnu, nestabilu cauruļvadu un tādu, kas darbojas dinamiski, ir uzticams un lēts uzturēšanai. Ja strādājat ar Linux serveriem, neatkarīgi no tā, vai automatizējat uzdevumus terminālī vai darbināt nepārtrauktas integrācijas cauruļvadus, šo detaļu izpratne ietaupa daudz laika un galvassāpju.

Šajā rakstā mēs apvienosim divus savstarpēji papildinošus viedokļus: no vienas puses, Klasiska cauruļu izmantošana Linux komandrindā (caurules, pāradresācijas, komandas, piemēram tee, xargs o cpio); no otras puses, CI/CD cauruļvada optimizācija Linux serverosTas ietver kešatmiņu, testu paralēlizāciju, Docker optimizāciju, piegādes ķēdes drošību un uzlabotus darbplūsmas rādītājus. Viss ir izskaidrots spāņu valodā (no Spānijas), ar skaidriem piemēriem un ļoti praktisku pieeju.

Kas ir cauruļvads un kā cauruļvadi iederas Linux sistēmā?

Termins "cauruļvads" cēlies no caurules idejas : datu plūsma, kas pārvietojas no viena punkta uz otru. Datortehnoloģijās, un jo īpaši Linux, caurule ir mehānisms, kas ļauj viena procesa standarta izvadei kļūt par cita procesa standarta ievadi. Citiem vārdiem sakot, vienas komandas izvade tiek automātiski padota nākamajai, neizlaižot starpfailus.

Unix tipa sistēmās ir divi galvenie cauruļu veidi . No vienas puses, pastāv anonīmas jeb nenosauktas caurules , kuras var izmantot tikai starp cieši saistītiem procesiem (piemēram, vecāku un bērnu). No otras puses, pastāv nosauktas caurules , kas pazīstamas arī kā FIFO (First In – First Out), kas ļauj sazināties starp procesiem, kas nav tieši saistīti un var pat atrasties dažādās tīklam pievienotās iekārtās.

Anonīmi kanāli parasti nodrošina vienvirziena saziņu : viens process raksta, bet otrs lasa. Turpretī nosauktie kanāli nodrošina divvirzienu saziņu , ja tie ir šādi izstrādāti, piemēram, atverot FIFO lasīšanas/rakstīšanas režīmā no abiem galiem. Tos plaši izmanto, lai koordinētu dēmonu procesus, skriptus vai pakalpojumus, kuriem ir jānodod dati viens otram bez bloķēšanas.

Ieviešanas līmenī atbalsts cauruļvadiem ir linux kodolsnevis čaulā. Komandu interpretētājs (bash, zsh utt.) vienkārši izveido cauruļvadu, izmantojot sistēmas izsaukumus, piemēram, pipe() y fork()novirzīt failu deskriptorus un pēc tam palaist katru programmu. Sistēmas kodols apstrādā procesu bloķēšanas, bufera pārvaldības un datu izplatīšanas starp ražotāju un patērētāju patieso burvību.

Standarta ievades (stdin), standarta izejas (stdout) un datu plūsmas izpratne

Lai efektīvi strādātu ar cauruļvadiem, ir svarīgi saprast, kas ir stdin, stdout un stderr . Tie nav abstrakti jēdzieni: katrs Linux process sākas ar trim atvērto failu deskriptoriem, kas norāda uz konkrētiem kodola pārvaldītajiem resursiem.

stdin (deskriptors 0) un stdout (deskriptors 1) var uzskatīt par baitu plūsmām, kas savienotas ar kaut ko: tas varētu būt terminālis, fails, tīkla ligzda vai caurule. Tie nav vienkārši buferi; tās ir atsauces uz kodola objektiem ( faila tipa struktūrām ), kas savukārt ir saistītas ar inodiem, ligzdām vai iekšējām cauruļu struktūrām.

Katram procesam ir savi deskriptori, tāpēc katra komanda cauruļvadā Tas neatkarīgi apskata savu standarta ievades un izejas vērtību. Šādā rindā ls | grep txt | wc -l, ls rakstīt caurulē, grep Tas lasa no vienas caurules un raksta uz citu, un wc Lasīt no pēdējā. Lietotājam tas izskatās kā viena virkne, bet iekšēji tie ir vairāki savienoti kodola buferikatram procesam bloķējoties un atsākot atkarībā no pieejamās vietas vai datiem.

Kad pirmais process ģenerē datus ātrāk nekā otrais tos patērē, caurules buferis piepildās. Šajā brīdī atgriežas turpmākie ieraksti, bloķējot sūtīšanas procesu, līdz patērējošais process... izlasīt pietiekami daudz informācijas un atbrīvo vietu. Tas novērš atmiņas nekontrolējamu izplūšanu; dati neuzkrājas bezgalīgi, ja vien netiek izmantota nebloķējoša I/O vai īpaša signāla plūsma. Piemēram, šādā gadījumā dd if=/dev/sda | gzip -9un gzip saspiež lēnāk, dd viņš ir spiests gaidīt.

Šis pretspiediena mehānisms padara cauruļvadus diezgan stabilus pat tad, ja starp posmiem ir veiktspējas nelīdzsvarotība, kas atspoguļojas arī CI/CD cauruļvadu projektēšanā , kur lēnie posmi kļūst par sašaurinājumu, kas ir jāmēra un jāoptimizē.

Praktiska cauruļu izmantošana Linux terminālī

Ikdienas lietošanā caurules tiek izmantotas, lai savienotu komandas vienā rindā un pakāpeniski pārveidotu datus. Tā vietā, lai palaistu komandu, skatītu izvadi, kopētu to un ielīmētu citā komandā, var izveidot mazas, ļoti elastīgas "datu fabrikas" vienkāršā tekstā.

Tipisks piemērs Unix vidē ir komandu apvienošana fortune, kas rāda nejaušas citātus ar cowsaykas izdrukā "runājošu" govi. Izmantojot pīpi, Fortūnas aiziešana kļūst par Kousijas vēstījumuviss vienā komandā. Tas ir rotaļīgs piemērs, taču tas lieliski ilustrē ideju par vienkāršu rīku savienošanu sarežģītākiem uzdevumiem.

Vēl viena klasiska metode ir nosūtīt rezultātu ls a wc lai saskaitītu rindas, vārdus un rakstzīmes. Kaut kas līdzīgs ls | wc Tas ļauj ātri redzēt, cik vienumu ir uzskaitīti. Skaistums ir tajā, ka jums nav nepieciešama viena programma, lai paveiktu visu, bet gan... Jūs veidojat risinājumus, izmantojot mazas, labi izstrādātas utilītprogrammas..

Tas ir arī ļoti bieži savienot ķēdē cat, sort y more (vai citu peidžeri), lai kārtotu teksta failu un pēc tam pārlūkotu to pa lapai. Izmantojot cauruli, saturs pāriet no vienas komandas uz nākamo, to nesaglabājot īpašos pagaidu failos, kas ievērojami vienkāršo skriptēšanu un administratīvos uzdevumus.

Praktiskos gadījumos, piemēram, apstrādājot studentu sarakstus un atzīmes atsevišķos failos, varat izmantot paste lai apvienotu kolonnas, cut lai atlasītu tikai jūs interesējošos laukus, un ķēdes caurules, lai filtrētu, kārtotu vai pārveidotu visu vienā čaulas skripta rindā. Šis modelis sadalīt lielu problēmu vienkāršās komandās, kas apvienotas ar caurulēm Tā ir Unix filozofijas būtība.

Paplašinātas komandas, lai maksimāli izmantotu caurules: tee, xargs un cpio

Kad Linux sistēmā sākat patiesi automatizēt lietas, caurules kļūst vēl jaudīgākas, pateicoties dažiem svarīgiem rīkiem. Starp tiem ir: tee, xargs y cpiokas ļoti labi papildina standarta datu plūsmu.

Komanda tee Tas darbojas kā "T" ūdensvadā: tas lasa no standarta ievades (stdin), raksta standarta izejā (stdout) un arī kopē to pašu izvadi uz vienu vai vairākiem failiem. Tas ir ideāli piemērots, ja vēlaties apskatīt izvadi ekrānā un vienlaikus to saglabāt lai to pārskatītu vēlāk vai apstrādātu citā posmā. Ar iespēju -a Tas pievieno datus faila beigās, nevis tos pārraksta.

Piemēram, sarakstu var kārtot ar sortnosūtīt rezultātu uz tee lai to saglabātu žurnālā un vienlaikus nodotu more lai to lapotu. Tādā veidā vienā cauruļvadā varat veikt kārtošanu, saglabāšanu diskā un ērtu apskati, neatkārtojot kārtošanas procesu.

Komanda xargs Tā ir vēl viena būtiska daļa, runājot par caurulēm. Tās funkcija ir ņemt to, kas pienāk caur standarta ievades sistēmu (parasti elementu sarakstu), un pārvērst to argumentos citai komandai. Tas ir īpaši noderīgi, ja programma avarē, jo vienlaikus saņem pārāk daudz parametru, vai ja vēlaties sadaliet darbu partijās ar iespēju -n, kas ierobežo argumentu skaitu, kas tiek nodoti vienā izpildes reizē.

Piemēram, ar ls | xargs -n 4 Failu sarakstu sadaliet četrās grupās, izpildot mērķa komandu (pēc noklusējuma echo(vai jūsu norādīto) vairākas reizes. Tādā veidā jūs varat veidot tādus kanālus kā "priekšskatīt to, ko es dzēsīšu", apvienojot ls, xargs y echo rm pirms faktiskās tīrīšanas palaišanas.

Esiet uzmanīgi ar sarežģītām ievades reizēm: ceļi ar atstarpēm vai speciālajām rakstzīmēm var pārtraukt noklusējuma darbību xargsŠādos gadījumos to parasti lieto kombinācijā ar find un opcija -print0, kas atdala elementus ar nulles rakstzīmi, kā arī xargs -0 lai abos galos tiktu izmantots viens un tas pats robusts norobežotājs.

Visbeidzot, cpio Tā ir mazāk zināma komanda nekā tarTaču tas ir neticami elastīgs darbam ar failu plūsmām, izmantojot caurules. Atšķirībā no tar, tas ir izstrādāts no paša sākuma, lai darbotos ar pāradresācijas un caurules: saņem failu sarakstu, izmantojot standarta ievades kanālu (parasti ģenerēts ar find) un ģenerē vai patērē "pakotnes" tipa failus bez to saspiešanas, kurus pēc tam var saspiest ar gzip vai tamlīdzīgi.

Galvenie režīmi cpio atļaut failu izveidi (-o), kopēt direktoriju kokus (-p) vai izvilkt saturu (-i(bieži dēvēta par “ievadkopēšanu”). Iespējas, piemēram, -u pārrakstīt, -m lai saglabātu laika zīmogus vai -d direktoriju struktūras atjaunošana ļauj detalizēti kontrolēt, kas un kā tiek kopēts, īpaši noderīgi sarežģītos skriptos, kur tar neatbilst prasībām.

CI/CD cauruļvadu projektēšana un optimizācija Linux serveros

Papildus tradicionālajai komandrindai, cauruļvada koncepcija ir kļuvusi par fundamentālu nepārtrauktas integrācijas un nepārtrauktas piegādes (CI/CD) pasaulē . Linux serverī CI/CD cauruļvads ir automatizēta darbību secība: koda ielāde, atkarību instalēšana, kompilēšana, testu veikšana, artefaktu iesaiņošana un izvietošana.

Linux ir īpaši piemērots šim nolūkam, jo ​​tas izceļas ar savu ātrumu, stabilitāti un automatizācijas rīku ekosistēmu . Tādas platformas kā Jenkins, GitHub Actions un GitLab CI paļaujas uz Linux izpildītājiem (fiziskām mašīnām, virtuālām mašīnām vai konteineriem), lai nodrošinātu cauruļvadu konsekventu darbību.

Šo cauruļvadu optimizēšana nozīmē ne tikai panākt, lai tie "darbotos", bet arī panākt, lai tie darbotos ar pēc iespējas mazāku berzi. Tas nozīmē samazināt pārbaudes laikus, samazināt atkārtotu atkarību instalēšanu, optimizēt Docker attēlus , lai izvairītos no nevajadzīgas pārbūves, atkārtoti izmantot jau ģenerētus artefaktus un saglabāt vidi drošu un novērojamu.

Pamata laba prakse ir strukturēt cauruļvadu precīzi definētos posmos: izveide, testēšana un izvietošana . Ideālā gadījumā jums vajadzētu kompilēt tikai vienu reizi, ģenerēt artefaktu (bināro failu, pakotni, Docker attēlu), kas tiek testēts paralēli dažādos variantos (piemēram, dažādās valodu versijās), un pēc tam izvietot to pašu artefaktu izstrādes un ražošanas vidē bez atkārtotas kompilācijas.

Darbs ar nemaināmiem artefaktiem, kas glabājas repozitorijos (S3, Nexus, Artifactory, konteineru reģistros vai GitLab/GitHub iegultās pakotnēs), vienkāršo auditēšanu, ļauj ātri atsaukt versijas un samazina varbūtību, ka "tas darbojas manā datorā, bet ne ražošanas vidē".

Priekšnosacījumi: izplatīšana, CI lietotāju un servera aizsardzības stiprināšana

Pirms ķerties pie milisekundes optimizācijas te un tur, ir svarīgi izveidot stabilu pamatu Linux serverī , kas darbosies kā CI/CD izpildītājs. Tas sākas ar izplatīšanas un minimālās drošības konfigurācijas izvēli.

Vissaprātīgākā pieeja parasti ir standartizēt uz LTS vai stabilas versijas , ar kuru komanda ir pazīstama: Ubuntu LTS, Debian Stable vai uzņēmumu alternatīvas, piemēram, AlmaLinux vai Rocky Linux. Visu palaisto versiju izmantošana novērš negaidītu uzvedību, ko izraisa dažādas bibliotēkas vai kodoli starp uzdevumiem.

Vēl viens ieteikums ir konfigurēt īpašs lietotājs CI, bez root privilēģijām, ar sudo, kas ir ļoti ierobežots tikai ar svarīgākajām komandām (piemēram, systemctl o docker (ja tas tiešām ir nepieciešams). Šim lietotājam ir jāautentificējas, izmantojot SSH atslēgas, gan lai piekļūtu serverim, gan lai mijiedarbotos ar Git repozitorijiem vai citām attālajām iekārtām.

Sistēmas līmenī ieteicams uzturēt serveri atjaunināts un minimāli pastiprinātsTas ietver drošības atjauninājumu lietošanu, ierobežojoša ugunsmūra konfigurēšanu (piemēram, ar UFW: liedzot visu ienākošo datplūsmu, izņemot nepieciešamo, un atļaujot izejošo datplūsmu) un iespējojot tādus rīkus kā fail2ban lai apturētu brutāla spēka uzbrukumus SSH un pielāgotu dažus tīkla un kodola parametrus, izmantojot sysctl lai uzlabotu uzticamību un veiktspēju.

Piemēram, ir ierasts paaugstināt robežu inozīmēt lai novērstu resursu trūkumu būvēšanas sistēmām, kas pārrauga daudzus failus, un pielāgotu parametru vm.swappiness lai padarītu kodolu konservatīvāku, izmantojot mijmaiņas funkciju, kas ir īpaši svarīgi, ja CI darbi vienlaikus patērē daudz atmiņas.

Kešatmiņas, Docker un paralēlizācija: CI/CD veiktspējas sviras

Ja aplūkosiet, cik daudz laika faktiski patērē vidējā cauruļvadā, redzēsiet, ka liela daļa laika tiek zaudēta, instalējot atkarības un atjaunojot Docker attēlus . Šīs problēmas risināšana parasti ir efektīvāka nekā testa koda optimizēšana par dažām milisekundēm.

Pirmais sviras elements ir atkarību kešatmiņa . Gandrīz visi atkarību pārvaldnieki (pip, npm, Maven, Gradle, Go moduļi utt.) izmanto lokālās kešatmiņas direktorijus. Pastāvīgā Linux serverī šos direktorijus var koplietot starp uzdevumiem vai pievienot tos pastāvīgam sējumam. Tādā veidā katrai izpildei nav atkārtoti jālejupielādē puse interneta.

Docker gadījumā iespējojiet BuildKit un labi strukturēt Dockerfile Tas iezīmē pagrieziena punktu. Atkarību instalēšanas novietošana tieši pēc prasību faila kopēšanas un pirms pārējā koda, nodrošina, ka slāņi tiek atkārtoti izmantoti, ja vien šo atkarību versijas paliek nemainīgas. Turklāt pašā būvējumā var iestatīt īpašas kešatmiņas pip, npm utt.

Otrais galvenais sviras elements ir paralēla testa izpildeDaudzi ietvari jau sākotnēji atbalsta vienlaicīgumu: pytest ar -n autoJava rīki, piemēram, Surefire, Jest JavaScript valodā ar --maxWorkersKomplekta sadalīšana pa moduļiem, mapēm vai pat pēc paredzamā laika un tā sabalansēšana starp vairākiem darbiniekiem ļauj samazināt testēšanas fāzes ilgumu 2 līdz 5 reizes, nemainot nevienu darbības jomu.

Visbeidzot, pastāv artefaktu un izvietošanas jautājums . Tā vietā, lai atkārtoti kompilētu vienu un to pašu attēlu izstrādes, pirmsražošanas un ražošanas vidēm, efektīva pieeja ir izveidot vienu reizi, saglabāt rezultātu repozitorijā un atzīmēt to atbilstoši izvietošanas videi. Tas samazina centrālā procesora noslodzi, novērš neatbilstības un ievērojami paātrina garus procesus.

Jenkins, GitHub Actions un GitLab Runner optimizācija operētājsistēmā Linux

Katrai CI sistēmai ir savas īpatnības, taču, darbojoties Linux vidē, tās visas gūst labumu no vienām un tām pašām pamatidejām. Galvenais parasti ir izmantot īslaicīgus un tīrus izpildītājus , uzturēt pietiekami lielu pastāvīgu kešatmiņu un kontrolēt vienlaicīgumu.

Jenkins vidē izplatīta prakse ir izmantot vieglus, pagaidu aģentus (piemēram, Docker konteinerus vai podus Kubernetes vai citos konteineru orķestrēšanas risinājumos ), lai izpildītu uzdevumus, vienlaikus saglabājot galveno mezglu pēc iespējas vienkāršāku. Šos aģentus var konfigurēt kā systemd pakalpojumus Linux serveros, reģistrējoties kontrolierī un automātiski startējoties, kad mašīna tiek startēta.

GitHub darbībām ar pašviesotiem izpildītājiem ieteicams tos izvietot Linux virtuālās mašīnas ar ātriem SSD diskiemLai izveidotu lielu kešatmiņas direktoriju, kas paredzēts darbībām (valodu atkarībām, kešatmiņu veidošanai utt.), ierobežojiet vienlaicīgu uzdevumu skaitu, lai izvairītos no centrālā procesora un diska pārslodzes. Izmantojiet oficiālās kešatmiņas darbības priekšrocības ar tādiem ceļiem kā ~/.cache/pip, ~/.npm o ~/.m2 Tas rada milzīgu atšķirību laikā.

GitLab Runner vidē izvēle starp čaulas izpildītāju un Docker ir atkarīga no nepieciešamā līdzsvara starp veiktspēju un izolāciju. Čaulas izpildītājs ir ātrāks, jo tas darbojas tieši resursdatorā, bet Docker izpildītājs piedāvā tīras un replicējamas vides. Varat arī konfigurēt koplietoto kešatmiņu (lokāli vai S3) un pielāgot maksimālo vienlaicīgo uzdevumu skaitu, lai izmantotu aparatūru, to nepārslogojot.

Visos šajos gadījumos ir ļoti svarīgi koplietot sējumus atkarību kešatmiņai, vienlaikus novēršot darbvietu pārslodzi starp versijām. Īslaicīgas mašīnas vai konteineri, kas tiek izveidoti un iznīcināti kopā ar katru cauruļvadu vai cauruļvadu grupu, ievērojami samazina problēmas, ko rada iepriekšējo versiju paliekas, piemēram, "tas darbojās vakar, bet ne šodien".

Linux servera veiktspēja: centrālais procesors, atmiņa, I/O un Docker

Neatkarīgi no tā, cik optimizēti ir jūsu skripti, ja Linux serveris, kurā darbojas cauruļvads, nav parekta izmēra, jūs saskarsieties ar nebeidzamām rindām un lēni virzošiem uzdevumiem. Tipiska, saprātīga vidējas klases datora konfigurācija ir 4–8 vCPU un 8–16 GB RAM , ar SSD atmiņu (ideālā gadījumā NVMe) un nelielu mijmaiņas vietu (2–4 GB), lai apstrādātu maksimālās slodzes, agresīvi neapturot procesus.

Svarīga ir arī failu sistēma. ext4 vai XFS ar opciju noatime Sējumos, kuros kompilējat vai rakstāt žurnālus, samaziniet nevajadzīgo ievadi/izvadi. Turklāt, pievienojot tmpfs pagaidu failiem vai īslaicīgiem artefaktiem (piemēram, /mnt/ci-tmp) paātrina intensīvas darbības un neļauj diskam piepildīties ar atlikušajiem failiem starp darbiem.

Attiecībā uz Docker dēmonu higiēna ir galvenais. Neizmantoto attēlu un sējumu droša un regulāra noņemšana, vienlaikus saglabājot karstos bāzes attēlus, palīdz... kontrolēt diska vietu un sāknēšanas laikusKomandas, piemēram, docker system prune Ar atbilstošiem laika filtriem tie ļauj veikt tīrīšanu, nepārslogojot nesen izmantotos resursus.

Ja jūsu CI ir konteineru ietilpīga, varat izmantot arī spoguļotus reģistrus , lai izvairītos no pastāvīgas lejupielādes no interneta, izmantot BuildKit vienlaicīgumam un slāņu kešatmiņai un pat konfigurēt centrālā procesora (CPU) afinitātes (CPU kopas) vai īpašus mezglus visprasīgākajiem izpildītājiem, novēršot traucējumus starp blakus esošajām darba slodzēm. Turklāt, izprotot centrālā procesora (CPU) mikroarhitektūru, varat labāk noteikt resursu apjomu intensīvām CI darba slodzēm.

Drošība izstrādes stadijā (DevSecOps) un izvietošana operētājsistēmā Linux

Ātrs, bet nedrošs cauruļvads ir laika bumba. Drošības integrēšana pašā cauruļvadā un Docker konteineru drošība tagad ir standarta jebkurai DevSecOps stratēģijai, un Linux piedāvā daudzus rīkus šim nolūkam.

Pirmkārt, ir jāizturas pret noslēpumiem un akreditācijas datiem ar vislielāko rūpību . Tiem nekad nevajadzētu atrasties kodā vai versiju konfigurācijas failos. Tā vietā tie tiek glabāti noslēpumu pārvaldniekos (GitLab maskētie mainīgie, GitHub šifrētie noslēpumi, HashiCorp Vault utt.) un tiek ievadīti tikai tā uzdevuma izpildes laikā, kuram tie ir nepieciešami, kad vien iespējams, izmantojot īslaicīgas pilnvaras.

Vēl viens svarīgs slānis ir SBOM (programmatūras materiālu saraksta) ģenerēšana un artefaktu parakstīšana. Tādi rīki kā Syft vai CycloneDX ļauj uzskaitīt visus komponentus, kas veido attēlu vai bināro failu, savukārt Cosign vai citi pārbaudāmi parakstīšanas risinājumi nodrošina, ka tiek izvietoti tikai tie artefakti, kas ir izgājuši cauri procesam un ir validēti.

Tīkla un piekļuves ziņā ieteicams segmentēt CI un ražošanas tīklus , ieviest stingrus ugunsmūrus, auditēt izpildes žurnālus un regulāri mainīt akreditācijas datus. Ja tiek izmantots SSH, labāk ir izmantot sertifikātus vai atslēgas ar derīguma termiņiem, nevis statiskas paroles.

Izvietojot operētājsistēmā Linux, tādas stratēģijas kā “Blue/Green”, “rolling” un “canary” ievērojami samazina izvietošanas kļūdu ietekmi. Lietojumprogrammas palaišana kā systemd pakalpojums, Nginx vai HAProxy novietošana tās priekšā un datplūsmas kontrole starp versijām ar veselības pārbaudēm ļauj praktiski panākt nulles dīkstāvi atjauninājumu laikā.

Piemēram, atkārtoti ielādējot Nginx un restartējot pakalpojumus ar systemd, izmantojot mīkstās apturēšanas signālus (piemēram, SIGTERMAr saprātīgu gaidīšanas laiku jūs varat iztukšot aktīvos savienojumus, pirms process apstājas, saglabājot lietotāja pieredzi neskartu, kamēr fonā pārslēdzat versijas.

Novērojamība, metrika un izmaksas Linux cauruļvados

Kad jūsu cauruļvadi ir izveidoti un darbojas, nākamais solis ir tos izmērīt un saprast, kur tiek tērēts laiks un resursi . Nepietiek tikai zināt, vai darbplūsma ir veiksmīga vai neveiksmīga; jums ir jāuzrauga katra posma ilgums, rindas laiks, veiksmes rādītājs, izvietošanas biežums, kešatmiņas trāpījumu rādītājs utt.

Sistēmas rādītājus parasti eksportē, izmantojot node_exporterCentralizējiet žurnālus ar tādiem risinājumiem kā ELK vai Loki un vizualizējiet visu Grafana informācijas paneļos. Tādā veidā jūs varat noteikt, piemēram, vai testēšanas fāzes ilgums pēdējās nedēļas laikā ir palielinājies par 30% vai vai darbi pavada pārāk daudz laika, gaidot pieejamu izpildītāju; tīkla datplūsmas uzraudzība Atvērtā pirmkoda rīki papildina šo redzamību.

Ir iespējams arī instrumentēt pašu cauruļvadu, piemēram, GitHub Actions vai GitLab CI, lai lai programmatiski izmērītu, cik izpildes ir bijušas veiksmīgas, cik ilgi ir ilgušas katras izpildes un kāds ir kopējais statussSkripts, kas izsauc pakalpojumu sniedzēja API, aprēķina kopējo palaišanas reižu skaitu, veiksmīgo palaišanas reižu skaitu, neveiksmīgo palaišanas reižu skaitu, veiksmes līmeni un vidējo ilgumu un visu saglabā JSON failā (piemēram, pipeline-metrics.json) ļauj integrēt šos rādītājus pārskatos vai informācijas paneļos.

Izmantojot šo informāciju, varat pieņemt lēmumus par izpildītāju lielumu un skaitu : dažreiz labāk ir, ja ir vairāk mazu izpildītāju nekā daži ļoti lieli, lai samazinātu gaidīšanas laiku. Automātiskā mērogojamība — piemēram, mākoņa automātiskā mērogošana vai Kubernetes mezglu dinamiskās kopas — palīdz absorbēt maksimālo aktivitāti dienas laikā un samazināt nepietiekami izmantotos resursus naktī.

Šīs prakses ne tikai uzlabo komandas pieredzi, bet arī palīdz pielāgot infrastruktūras izmaksas, kontrolējot centrālā procesora, atmiņas un jo īpaši krātuves patēriņu, kas parasti strauji pieaug, lietojot attēlus un kešatmiņu, ja tie netiek regulāri un plānoti tīrīti.

Gan klasisko komandrindas kanālu, gan moderno CI/CD kanālu apgūšana operētājsistēmā Linux piedāvā jaudīgu kombināciju: jūs varat automatizēt visu, sākot no vienkāršiem teksta filtrēšanas uzdevumiem līdz sarežģītiem, uzturējamiem, drošiem un ātriem izveides, testēšanas un izvietošanas kanāliem. Izpratne par to, kā informācija plūst starp procesiem, kā tiek kešatmiņā saglabātas atkarības, kā tiek noregulēti serveri un kā tiek integrēti rādītāji un drošība, ļauj jums veidot darbplūsmas, kas mērogojas atbilstoši jūsu komandai un projektiem, nekļūstot par pastāvīgu sašaurinājumu.