- „Linux“ vamzdynai leidžia sujungti procesus grandinėje, sujungiant „stdout“ ir „stdin“, o sudėtingesniems srautams palaikyti naudojamas branduolio palaikymas ir tokie įrankiai kaip „tee“, „xargs“ ir „cpio“.
- Efektyvus CI/CD srautas „Linux“ sistemoje priklauso nuo gero scenos dizaino, intensyvaus talpyklų naudojimo, nekintamų artefaktų ir lygiagretaus testavimo.
- „Linux“ serverio (procesoriaus, RAM, įvesties/išvesties, „Docker“) ir „Jenkins“, „GitHub Actions“ arba „GitLab Runner“ vykdytojų optimizavimas yra labai svarbus norint sutrumpinti laiką.
- Saugumo, stebimumo ir sąnaudų kontrolės integravimas į procesą užtikrina patikimą, atsekamą ir tvarų diegimą gamybinėje aplinkoje.
Vamzdynų optimizavimas Linux sistemoje Tai ne tik komandų sujungimas su simboliu |Už viso to slypi visas pasaulis našumo optimizavimasDarbo eigos dizainas, CI/CD, saugumas ir operacinės sistemos derinimas yra esminiai skirtumai tarp lėto, nestabilaus ir sklandaus, patikimo bei nebrangiai prižiūrimo srauto. Jei dirbate su „Linux“ serveriais, nesvarbu, ar automatizuojate užduotis terminale, ar vykdote nuolatinės integracijos srautus, šių detalių supratimas sutaupo daug laiko ir galvos skausmo.
Šiame straipsnyje apjungsime dvi viena kitą papildančias perspektyvas: viena vertus, Klasikinis vamzdžių naudojimas „Linux“ komandinėje eilutėje (vamzdžiai, peradresavimai, komandos, pvz. tee, xargs o cpio); kita vertus, CI/CD srauto optimizavimas Linux serveriuoseTai apima kaupimą talpykloje, testų paralelizavimą, „Docker“ derinimą, tiekimo grandinės saugumą ir pažangius darbo eigos rodiklius. Visa tai paaiškinta ispanų kalba (iš Ispanijos), pateikiant aiškius pavyzdžius ir labai praktišką požiūrį.
Kas yra vamzdynas ir kaip vamzdžiai tinka „Linux“?
Terminas „vamzdynas“ kilęs iš vamzdžio idėjos : tai duomenų srautas, keliaujantis iš vieno taško į kitą. Skaičiavimo srityje, o ypač „Linux“, vamzdis yra mechanizmas, leidžiantis vieno proceso standartinei išvesties informacijai tapti kito proceso standartine įvestimi. Kitaip tariant, vienos komandos išvestis automatiškai perduodama kitam, neperduodant tarpinių failų.
Unix tipo sistemose yra du pagrindiniai kanalų tipai . Viena vertus, yra anoniminiai arba neįvardyti kanalai , kurie gali būti naudojami tik tarp glaudžiai susijusių procesų (pavyzdžiui, tėvų ir vaikų). Kita vertus, yra įvardyti kanalai , dar vadinami FIFO (angl. First In – First Out), kurie leidžia bendrauti tarp procesų, kurie nėra tiesiogiai susiję ir gali būti net skirtinguose prie tinklo prijungtuose kompiuteriuose.
Anoniminiai kanalai paprastai užtikrina vienakryptį ryšį : vienas procesas rašo, o kitas skaito. Priešingai, įvardyti kanalai leidžia dvikryptį ryšį, jei jie yra taip sukurti, pavyzdžiui, atidarant FIFO skaitymo/rašymo režimu iš abiejų galų. Jie plačiai naudojami koordinuojant demonų procesus, scenarijus ar paslaugas, kurioms reikia perduoti duomenis viena kitai neblokuojant.
Įgyvendinimo lygmeniu parama vamzdynams yra „Linux“ branduolysne apvalkale. Komandų interpretatorius („bash“, „zsh“ ir kt.) tiesiog sukuria srautą naudodamas sisteminius iškvietimus, pvz., pipe() y fork()peradresuokite failų deskriptorius ir paleiskite kiekvieną programą. Tikrąją magiją, kaip blokuojami procesai, kaip valdomas buferis ir kaip duomenys perduodami tarp kūrėjo ir vartotojo, atlieka sistemos branduolys.
Standartinės įvesties (stdin), standartinės išvesties (stdout) ir duomenų srauto supratimas
Norint efektyviai dirbti su konvejeriais, labai svarbu suprasti, kas yra stdin, stdout ir stderr . Tai nėra abstrakčios sąvokos: kiekvienas „Linux“ procesas prasideda nuo trijų atvirų failų deskriptorių, kurie nurodo konkrečius branduolio valdomus išteklius.
stdin (deskriptorius 0) ir stdout (deskriptorius 1) gali būti laikomi baitų srautais, prijungtais prie kažko: tai gali būti terminalas, failas, tinklo lizdas arba kanalas. Jie nėra tiesiog buferiai; tai nuorodos į branduolio objektus ( failo tipo struktūras ), kurie savo ruožtu yra susieti su inodais, lizdais arba vidinėmis kanalo struktūromis.
Kiekvienas procesas turi savo deskriptorius, todėl kiekviena komanda sraute Jis peržiūri savo standartinę įvesties ir išvesties reikšmes nepriklausomai viena nuo kitos. Tokioje eilutėje kaip ls | grep txt | wc -l, ls rašyti vamzdyje, grep Jis skaito iš vieno vamzdžio ir rašo į kitą, ir wc Skaitoma nuo paskutinio. Vartotojui tai atrodo kaip viena eilutė, bet viduje jie yra keli sujungti branduolio buferiaikiekvienas procesas blokuojamas ir atnaujinamas priklausomai nuo turimos vietos ar duomenų.
Kai pirmasis procesas sukuria duomenis greičiau nei antrasis juos sunaudoja, kanalizacijos buferis užsipildo. Tuo metu vėlesni įrašai grįžta, blokuodami siuntimo procesą, kol sunaudojantis procesas... perskaitykite pakankamai informacijos ir atlaisvina vietos. Tai apsaugo atmintį nuo nekontroliuojamo išsikrovimo; duomenys nesikaupia neribotą laiką, nebent naudojate neblokuojančius įvesties / išvesties arba specialius signalus. Pavyzdžiui, tokiu atveju dd if=/dev/sda | gzip -9Ir gzip suspaudžiasi lėčiau, dd jis priverstas laukti.
Šis priešslėgio mechanizmas užtikrina gana stabilius vamzdynus net ir tada, kai tarp etapų yra našumo disbalansas, o tai atsispindi ir CI/CD vamzdynų projektavime , kur lėti etapai tampa kliūtimi, kurią reikia išmatuoti ir optimizuoti.
Praktinis vamzdžių panaudojimas Linux terminale
Kasdieniniame naudojime vamzdžiai naudojami komandoms sujungti vienoje eilutėje ir duomenims transformuoti žingsnis po žingsnio. Užuot paleidę komandą, peržiūrėję išvestį, ją kopijuodami ir įklijuodami į kitą komandą, galite kurti mažas, labai lanksčias „duomenų gamyklas“ paprasto teksto formatu.
Tipiškas pavyzdys Unix aplinkoje yra komandų sujungimas fortune, kuriame rodomos atsitiktinės kabutės su cowsaykuris atspausdina „kalbančią“ karvę. Naudojant pypkę, Fortūnos išvykimas tampa Cowsay žiniavisa tai vienoje komandoje. Tai žaismingas pavyzdys, puikiai iliustruojantis paprastų įrankių sujungimo idėją sudėtingesnėms užduotims atlikti.
Kitas klasikinis būdas – nusiųsti rezultatą ls a wc skaičiuoti eilutes, žodžius ir simbolius. Kažkas panašaus ls | wc Tai leidžia greitai pamatyti, kiek elementų yra išvardyta. Grožis yra tas, kad jums nereikia vienos programos viskam atlikti, o... Kuriate sprendimus naudodami mažas, gerai suprojektuotas priemones..
Taip pat labai įprasta grandinėmis sujungti cat, sort y more (arba kitą puslapių gaviklį), kad rūšiuotų tekstinį failą ir naršytų jį puslapis po puslapio. Naudojant kanalą, turinys pereina iš vienos komandos į kitą neišsaugomas laikinuosiuose failuose, o tai labai supaprastina scenarijų kūrimą ir administravimo užduotis.
Praktiniais atvejais, pavyzdžiui, apdorojant studentų sąrašus ir pažymius atskiruose failuose, galite naudoti paste sujungti stulpelius, cut , kad pasirinktumėte tik jus dominančius laukus, ir sujungtus kanalus, kad filtruotumėte, rūšiuotumėte arba transformuotumėte viską vienoje apvalkalo scenarijaus eilutėje. Šis modelis suskaidyti didelę problemą į paprastas komandas kartu su kanalais Tai yra Unix filosofijos esmė.
Išplėstinės komandos, skirtos maksimaliai išnaudoti vamzdžius: tee, xargs ir cpio
Kai pradedate iš tikrųjų automatizuoti dalykus „Linux“ sistemoje, vamzdžiai tampa dar galingesni dėl kai kurių pagrindinių įrankių. Tarp jų yra: tee, xargs y cpiokurie labai gerai papildo standartinį duomenų srautą.
Įsakymas tee Jis veikia kaip „T“ vandens vamzdyje: skaito iš standartinės įvesties (stdin), rašo į standartinę išvestį (stdout) ir kopijuoja tą pačią išvestį į vieną ar daugiau failų. Tai idealu, kai norite peržiūrėti išvestį ekrane ir tuo pačiu metu ją išsaugoti peržiūrėti vėliau arba apdoroti kitame etape. Turėdami parinktį -a Jis prideda duomenis failo pabaigoje, o ne juos perrašo.
Pavyzdžiui, galite rūšiuoti sąrašą pagal sortsiųskite rezultatą į tee saugoti jį žurnale ir tuo pačiu metu perduoti more puslapiuoti. Tokiu būdu viename sraute galite rūšiuoti, įrašyti į diską ir patogiai peržiūrėti, nekartodami rūšiavimo proceso.
Įsakymas xargs Tai dar vienas esminis elementas, kalbant apie vamzdžius. Jo funkcija – paimti tai, kas gaunama per standartinę įvestį (dažniausiai elementų sąrašą), ir paversti tai argumentais kitai komandai. Tai ypač naudinga, kai programa sugenda, nes vienu metu gauna per daug parametrų arba kai norite... suskaidyti darbą į partijas su galimybe -n, o tai riboja, kiek argumentų perduodama vieno vykdymo metu.
Pavyzdžiui, su ls | xargs -n 4 Failų sąrašą suskirstote į keturias grupes, vykdydami tikslinę komandą (pagal numatytuosius nustatymus echo(arba jūsų nurodytą) kelis kartus. Tokiu būdu galite kurti tokius srautus kaip „peržiūrėti, ką ketinu ištrinti“, derindami ls, xargs y echo rm prieš pradedant tikrąjį valymą.
Būkite atsargūs su sudėtingais įvesties duomenimis: keliai su tarpais arba specialiaisiais simboliais gali sutrikdyti numatytąjį elgesį xargsTokiais atvejais jis paprastai vartojamas kartu su find ir variantas -print0, kuris atskiria elementus nuliniu simboliu kartu su xargs -0 kad abu galai naudotų tą patį patikimą skyriklį.
Galiausiai, cpio Tai mažiau žinoma komanda nei tarTačiau jis yra neįtikėtinai lankstus dirbant su failų srautais per vamzdžius. Skirtingai nuo „tar“, jis nuo pat pradžių sukurtas veikti su peradresavimai ir kanalai: gauna failų sąrašą per standartinį įvestį (paprastai generuojamą su find) ir sukuria arba naudoja „paketo“ tipo failus be jų pačių suspaudimo, kuriuos vėliau galite suspausti naudodami gzip ar pan.
Pagrindiniai režimai cpio leisti kurti failus (-o), kopijuoti katalogų medžius (-p) arba išskleisti turinį (-i(dažnai vadinamas „kopijavimu“). Tokios parinktys kaip -u perrašyti, -m išsaugoti laiko žymas arba -d katalogų struktūros atkūrimas leidžia išsamiai kontroliuoti, kas ir kaip kopijuojama, ypač naudinga sudėtinguose scenarijuose, kur tar neatitinka lūkesčių.
CI/CD kanalų projektavimas ir optimizavimas Linux serveriuose
Be tradicinės komandinės eilutės, konvejerio koncepcija tapo esminiu nuolatinės integracijos ir nuolatinio teikimo (CI/CD) pasaulyje . „Linux“ serveryje CI/CD konvejeris yra automatizuota veiksmų seka: kodo gavimas, priklausomybių diegimas, kompiliavimas, testų vykdymas, artefaktų pakavimas ir diegimas.
„Linux“ tam ypač tinka, nes išsiskiria greičiu, stabilumu ir automatizavimo įrankių ekosistema . Tokios platformos kaip „Jenkins“, „GitHub Actions“ ir „GitLab CI“ naudoja „Linux“ vykdytojus (fizines mašinas, virtualias mašinas arba konteinerius), kad srautai veiktų nuosekliai.
Šių srautų optimizavimas reiškia ne tik jų „veikimą“, bet ir kuo mažesnę trintį. Tai reiškia, kad reikia sutrumpinti patikros laiką, sumažinti pasikartojančius priklausomybių diegimus, optimizuoti „Docker“ atvaizdus, siekiant išvengti nereikalingo atkūrimo, pakartotinai naudoti jau sugeneruotus artefaktus ir užtikrinti aplinkos saugumą bei stebimumą.
Geroji pagrindinė praktika yra suskirstyti srautą į aiškiai apibrėžtus etapus: kompiliavimą, testavimą ir diegimą . Idealiu atveju reikėtų kompiliuoti tik vieną kartą, sugeneruoti artefaktą (dvejetainį failą, paketą, „Docker“ atvaizdą), kuris būtų testuojamas lygiagrečiai skirtingais variantais (pavyzdžiui, įvairiomis kalbinėmis versijomis), o tada tą patį artefaktą diegti parengiamojoje ir gamybinėje aplinkose nekompiliuojant iš naujo.
Darbas su nekintamais artefaktais, saugomais saugyklose („S3“, „Nexus“, „Artifactory“, konteinerių registruose arba „GitLab“ / „GitHub“ įterptuose paketuose), supaprastina auditą, leidžia greitai atšaukti versijas ir sumažina tikimybę, kad „viskas veikia mano kompiuteryje, bet ne gamybinėje aplinkoje“.
Būtinos sąlygos: platinimas, CI vartotojo ir serverio apsaugos stiprinimas
Prieš pradedant optimizuoti milisekundėmis, svarbu sukurti stabilų „Linux“ serverio pagrindą , kuris veiks kaip CI/CD vykdytojas. Tai prasideda nuo platinimo ir minimalios saugumo konfigūracijos pasirinkimo.
Protingiausias būdas paprastai yra standartizuoti pagal LTS arba stabilų platinimą , su kuriuo komanda yra susipažinusi: „Ubuntu LTS“, „Debian Stable“ arba įmonių alternatyvas, tokias kaip „AlmaLinux“ ar „Rocky Linux“. Turint visus paleidiklius toje pačioje versijoje, išvengiama netikėto elgesio, kurį sukelia skirtingos bibliotekos ar branduoliai tarp užduočių.
Kita rekomendacija – sukonfigūruoti skirtas CI vartotojasbe root teisių, o sudo komanda leidžia atlikti tik pagrindines komandas (pavyzdžiui, systemctl o docker (jei to tikrai reikia). Šis vartotojas turi autentifikuotis naudodamas SSH raktus, kad galėtų prisijungti prie serverio ir sąveikauti su „Git“ saugyklomis ar kitais nuotoliniais kompiuteriais.
Sistemos lygmeniu patartina prižiūrėti serverį atnaujintas ir minimaliai sustiprintasTai apima saugos naujinimų diegimą, ribojančios užkardos konfigūravimą (pavyzdžiui, naudojant UFW: blokuojant visą įeinantį srautą, išskyrus būtiną, ir leidžiant išeinantį srautą) ir įjungiant tokius įrankius kaip fail2ban sustabdyti „brute-force“ atakas SSH tinkle ir pakoreguoti kai kuriuos tinklo bei branduolio parametrus per sysctl siekiant pagerinti patikimumą ir našumą.
Pavyzdžiui, įprasta kelti ribą neinformuoti kad kūrimo sistemoms, kurios stebi daug failų, nepritrūktų išteklių, ir pakoreguokite parametrą vm.swappiness kad branduolys būtų konservatyvesnis naudojant swap, o tai ypač aktualu, kai CI užduotys vienu metu sunaudoja daug atminties.
Talpyklos, „Docker“ ir lygiagretinimas: CI/CD našumo svertai
Jei pažiūrėsite, kiek laiko iš tikrųjų sugaišta vidutiniame apdorojimo procese, pamatysite, kad didelė jo dalis prarandama diegiant priklausomybes ir perkuriant „Docker“ atvaizdus . Šios problemos sprendimas paprastai yra efektyvesnis nei bandymo kodo optimizavimas keliomis milisekundėmis.
Pirmasis svertas yra priklausomybių kaupimas talpykloje . Beveik visi priklausomybių tvarkytuvai („pip“, „npm“, „Maven“, „Gradle“, „Go“ moduliai ir kt.) naudoja vietinius talpyklos katalogus. Nuolatiniame „Linux“ serveryje galite bendrinti šiuos katalogus tarp užduočių arba prijungti juos prie nuolatinio tomo. Tokiu būdu kiekvienam vykdymui nereikia iš naujo atsisiųsti pusės interneto.
„Docker“ įjunkite Sukurti rinkinį ir gerai struktūrizuoti Dockerfile Tai žymi lūžio tašką. Priklausomybių diegimas iškart po reikalavimų failo nukopijavimo ir prieš likusį kodą užtikrina, kad sluoksniai bus pakartotinai naudojami tol, kol tų priklausomybių versijos išliks nepakitusios. Be to, pačiame kūrimo procese galima nustatyti konkrečias talpyklas pip, npm ir kt.
Antras svarbus svertas yra lygiagretus testų vykdymasDaugelis sistemų iš esmės palaiko lygiagretumą: pytest su -n auto„Java“ įrankiai, tokie kaip „Surefire“, „Jest“ „JavaScript“ kalba --maxWorkersir kt. Programų rinkinio padalijimas į modulius, aplankus ar net pagal numatomą laiką ir paskirstymas tarp kelių darbuotojų leidžia 2–5 kartus sutrumpinti testavimo etapo trukmę nekeičiant nė vienos verslo krypties.
Galiausiai, iškyla artefaktų ir diegimo problema . Užuot iš naujo kompiliavus tą patį atvaizdą testavimui, ikigamybinei ir gamybinei aplinkai, efektyviausias būdas yra sukurti vieną kartą, išsaugoti rezultatą saugykloje ir pažymėti jį pagal diegimo aplinką. Tai sumažina procesoriaus naudojimą, išvengiama neatitikimų ir žymiai pagreitina ilgus procesus.
„Jenkins“, „GitHub Actions“ ir „GitLab Runner“ optimizavimas „Linux“ sistemoje
Kiekviena CI sistema turi savo ypatumų, tačiau visos jos veikia „Linux“ sistemoje, naudodamos tas pačias pagrindines idėjas. Svarbiausia paprastai yra naudoti trumpalaikius ir švarius vykdytojus , palaikyti tinkamo dydžio nuolatinę talpyklą ir kontroliuoti lygiagretumą.
„Jenkins“ sistemoje įprasta naudoti lengvus, laikinus agentus (pvz., „Docker“ konteinerius arba „anksčius“ „Kubernetes“ ar kituose konteinerių orkestravimo sprendimuose ) užduotims vykdyti, išlaikant kuo paprastesnį pagrindinį mazgą. Šie agentai gali būti konfigūruojami kaip „systemd“ paslaugos „Linux“ serveriuose, registruojami valdiklyje ir paleidžiami automatiškai, kai kompiuteris paleidžiamas.
„GitHub“ veiksmams su savarankiškai talpinamais vykdikliais rekomenduojama juos diegti „Linux“ virtualios mašinos su greitais SSD diskaisNorėdami sukurti didelį talpyklos katalogą, skirtą veiksmams (kalbos priklausomybėms, talpyklų kūrimo ir kt.), apribokite vienu metu atliekamų užduočių skaičių, kad išvengtumėte procesoriaus ir disko perkrovos. Pasinaudokite oficialiu talpyklos veiksmu su tokiais keliais kaip ~/.cache/pip, ~/.npm o ~/.m2 Tai daro didžiulį skirtumą laike.
„GitLab Runner“ programoje pasirinkimas tarp apvalkalo vykdytojo ir „Docker“ priklauso nuo reikiamos našumo ir izoliacijos pusiausvyros. Apvalkalo vykdytojas yra greitesnis, nes veikia tiesiogiai pagrindiniame kompiuteryje, o „Docker“ vykdytojas siūlo švarias ir atkartojamas aplinkas. Taip pat galite konfigūruoti bendrą talpyklą (vietinę arba S3) ir koreguoti maksimalų vienu metu atliekamų užduočių skaičių, kad išnaudotumėte aparatinę įrangą jos neperkraudami.
Visais šiais atvejais labai svarbu turėti bendrus tomus priklausomybių kaupimui talpykloje, kartu užkertant kelią darbo sričių perpildymui tarp kompiliacijų. Trumpalaikės mašinos arba konteineriai, kurie sukuriami ir sunaikinami kartu su kiekvienu konvejeriu ar konvejerių grupe, labai sumažina problemas, kylančias dėl ankstesnių kompiliacijų likučių, kai „veikė vakar, o šiandien nebe“.
„Linux“ serverio našumas: procesorius, atmintis, įvestis/išvestis ir „Docker“
Kad ir kokie optimizuoti būtų jūsų scenarijai, jei „Linux“ serveris, kuriame veikia srautas, nėra tinkamo dydžio, susidursite su nesibaigiančiomis eilėmis ir lėtai judančiomis užduotimis. Įprasta, pagrįsta vidutinės klasės kompiuterio konfigūracija yra 4–8 vCPU ir 8–16 GB RAM , su SSD atmintimi (idealiu atveju NVMe) ir šiek tiek mainų vietos (2–4 GB), kad būtų galima susidoroti su didžiausiomis apkrovomis agresyviai nesustabdant procesų.
Failų sistema taip pat svarbi. Naudokite ext4 arba XFS su parinktimi noatime Tomuose, kuriuose kompiliuojate arba rašote žurnalus, sumažinkite nereikalingą įvesties/išvesties kiekį. Be to, prijungiant tmpfs laikiniems failams arba trumpalaikiams artefaktams (pvz., /mnt/ci-tmp) pagreitina intensyvias operacijas ir neleidžia diskui užsipildyti likusiais failais tarp užduočių.
Kalbant apie „Docker“, svarbiausia yra demonų higiena. Saugus ir reguliarus nenaudojamų atvaizdų ir tomų pašalinimas, išlaikant aktyvius bazinius atvaizdus, padeda kontroliuoti disko vietą ir įkrovos laikąKomandos, tokios kaip docker system prune Su atitinkamais laiko filtrais jie leidžia valyti neperkraunant neseniai naudotų išteklių.
Jei jūsų CI reikalauja daug konteinerių, taip pat galite naudoti veidrodinius registrus , kad nereikėtų nuolat atsisiųsti iš interneto, naudoti „BuildKit“ lygiagrečiam veikimui ir sluoksnių kaupimui talpykloje ir netgi konfigūruoti procesoriaus afinitetus (CPU rinkinius) arba dedikuotus mazgus reikliausiems vykdytojams, kad būtų išvengta trukdžių tarp gretimų darbo krūvių. Be to, CPU mikroarchitektūros supratimas padeda geriau paskirstyti išteklius intensyviems CI darbo krūviams.
Saugumo diegimas ir diegimas „Linux“ sistemoje
Greitas, bet nesaugus konvejeris yra tiksinti laiko bomba. Saugumo integravimas į patį konvejerį ir „Docker“ konteinerių saugumas dabar yra standartinis bet kurioje „DevSecOps“ strategijoje, o „Linux“ siūlo daug tam skirtų įrankių.
Pirmiausia reikia elgtis su paslaptimis ir prisijungimo duomenimis itin atsargiai . Jie niekada neturėtų būti kode ar versuotuose konfigūracijos failuose. Vietoj to, jie saugomi paslapčių tvarkyklėse („GitLab“ užmaskuoti kintamieji, „GitHub“ užšifruoti paslaptys, „HashiCorp Vault“ ir kt.) ir įšvirkščiami tik vykdant užduotį, kuriai jų reikia, kai tik įmanoma, naudojant trumpalaikius žetonus.
Kitas svarbus sluoksnis yra SBOM (programinės įrangos medžiagų sąrašų) generavimas ir artefaktų pasirašymas. Tokios priemonės kaip „Syft“ ar „CycloneDX“ leidžia išvardyti visus atvaizdą ar dvejetainį failą sudarančius komponentus, o „Cosign“ ar kiti patikrinami pasirašymo sprendimai užtikrina, kad būtų diegiami tik tie artefaktai, kurie jau praėjo visą procesą ir buvo patvirtinti.
Kalbant apie tinklą ir prieigą, patartina segmentuoti CI ir gamybinius tinklus , įdiegti griežtas ugniasienes, audito vykdymo žurnalus ir reguliariai keisti prisijungimo duomenis. Kai naudojamas SSH, geriau naudoti sertifikatus arba raktus su galiojimo datomis, o ne statinius slaptažodžius.
Diegiant „Linux“ sistemoje, tokios strategijos kaip „Blue/Green“, „rolling“ ir „canary“ gerokai sumažina diegimo klaidų poveikį. Paleidus programą kaip „systemd“ paslaugą, prieš ją įdiegus „Nginx“ arba „HAProxy“ ir kontroliuojant srautą tarp versijų naudojant sveikatos patikrinimus, atnaujinimų metu galima praktiškai išvengti prastovų.
Pavyzdžiui, perkraunant „Nginx“ ir paleidus paslaugas iš naujo su „systemd“ naudojant švelnaus sustabdymo signalus (pvz., SIGTERMEsant protingam laukimo laikui, galite apriboti aktyvius ryšius prieš sustabdant procesą, išlaikydami naudotojo patirtį, kol fone keičiate versijas.
Stebimumas, metrika ir išlaidos „Linux“ vamzdynuose
Kai jūsų srautai bus paruošti ir veiks, kitas žingsnis bus juos išmatuoti ir suprasti, kur eikvojamas laikas ir ištekliai . Nepakanka žinoti, ar darbo eiga sėkminga, ar nesėkminga; reikia stebėti kiekvieno etapo trukmę, eilės laiką, sėkmės rodiklį, diegimo dažnumą, talpyklos patekimo rodiklį ir pan.
Įprasta eksportuoti sistemos metriką naudojant node_exporterCentralizuokite žurnalus naudodami tokius sprendimus kaip ELK ar Loki ir vizualizuokite viską „Grafana“ ataskaitų suvestinėse. Tokiu būdu galite, pavyzdžiui, nustatyti, ar testavimo etapas per pastarąją savaitę pailgėjo 30 %, ar darbai per daug laiko praleidžia laukdami laisvo vykdytojo; tinklo srauto stebėjimas Atvirojo kodo įrankiai papildo tą matomumą.
Taip pat galima instrumentuoti patį srautą, pavyzdžiui, naudojant „GitHub Actions“ arba „GitLab CI“, kad programiškai išmatuoti, kiek vykdymų buvo sėkmingų, kiek laiko truko kiekvienas vykdymas ir kokia yra bendra būsenaScenarijus, kuris iškviečia teikėjo API, apskaičiuoja bendrą paleidimų skaičių, sėkmingų paleidimų skaičių, nepavykusių paleidimų skaičių, sėkmės rodiklį ir vidutinę trukmę ir viską išsaugo JSON faile (pvz., pipeline-metrics.json) leidžia integruoti šiuos rodiklius į ataskaitas arba ataskaitų suvestines.
Turėdami šią informaciją, galite priimti sprendimus dėl vykdomųjų mazgų dydžio ir skaičiaus : kartais geriau turėti daugiau mažų vykdomųjų mazgų nei kelis labai didelius, kad sumažėtų laukimo laikas. Automatinis mastelio keitimas, pavyzdžiui, automatinis debesies mastelio keitimas arba dinaminiai „Kubernetes“ mazgų telkiniai, padeda sugerti didžiausią aktyvumą dienos metu ir sumažinti nepakankamai naudojamus išteklius naktį.
Ši praktika ne tik pagerina komandos patirtį, bet ir padeda koreguoti infrastruktūros sąnaudas, kontroliuojant procesoriaus, atminties ir ypač saugyklos sunaudojimą, kuris paprastai smarkiai išauga dėl vaizdų ir talpyklų, jei jos nevalomos reguliariai ir planuotai.
Įvaldę klasikinius komandinės eilutės kanalus ir modernius CI/CD kanalus „Linux“ sistemoje, galite automatizuoti viską – nuo paprastų teksto filtravimo užduočių iki sudėtingų, lengvai prižiūrimų, saugių ir greitų kūrimo, testavimo ir diegimo kanalų. Supratimas, kaip informacija teka tarp procesų, kaip kaupiamos priklausomybės, kaip derinami serveriai ir kaip integruojama metrika bei saugumas, leidžia kurti darbo eigas, kurios prisitaikytų prie jūsų komandos ir projektų, netapdamos nuolatine kliūtimi.
