Pipelineoptimalisering i Linux: fra pipes til avansert CI/CD

Informatec Digital » Ressurser » Pipelineoptimalisering i Linux: fra pipes til avansert CI/CD

Optimalisering av pipelines i Linux Det handler ikke bare om å kjede kommandoer med symbolet |Bak alt dette ligger en hel verden av ytelsesoptimaliseringArbeidsflytdesign, CI/CD, sikkerhet og justering av operativsystemet utgjør hele forskjellen mellom en treg og ustabil pipeline og en som fungerer, er pålitelig og rimelig å vedlikeholde. Hvis du jobber med Linux-servere, enten det er å automatisere oppgaver i terminalen eller kjøre kontinuerlige integrasjonspipeliner, sparer det deg mye tid og hodepine å forstå disse detaljene.

I denne artikkelen skal vi kombinere to komplementære perspektiver: på den ene siden, Klassisk bruk av pipes i Linux-kommandolinjen (pipes, omdirigeringer, kommandoer som tee, xargs o cpio); på den andre CI/CD-pipelineoptimalisering på Linux-servereDette inkluderer mellomlagring, testparallellisering, Docker-justering, forsyningskjedesikkerhet og avanserte arbeidsflytmålinger. Alt forklart på spansk (fra Spania), med klare eksempler og en svært praktisk tilnærming.

Hva er en pipeline, og hvordan passer pipes inn i Linux?

Begrepet Rørledningen kommer fra ideen om et rørEn pipe er en datastrøm som beveger seg fra ett punkt til et annet. Innen databehandling, og spesielt i Linux, er en pipe en mekanisme som gjør at standardutdataene fra én prosess kan konverteres direkte til standardinndataene til en annen. Med andre ord, utdataene fra én kommando mates automatisk inn i den neste uten å passere gjennom mellomliggende filer.

I Unix-lignende systemer finnes det to hovedtyper rørPå den ene siden, den anonyme rør o navnløse rørsom bare kan brukes mellom nært beslektede prosesser (for eksempel foreldre og barn). På den annen side, navngitte rør o navngitte rør, også kjent som FIFO (First In – First Out), som tillater kommunikasjon mellom prosesser som ikke er direkte relaterte og som til og med kan være på forskjellige nettverksmaskiner.

Anonyme rør gir vanligvis en enveis kommunikasjonÉn prosess skriver og den andre leser. Med navngitte rør kan du imidlertid etablere kommunikasjon. toveis Hvis du designer det på den måten, for eksempel ved å åpne FIFO i lese/skrive-modus fra begge ender, kan det brukes til å koordinere prosesser til daemoner, skript eller tjenester som trenger å sende data til hverandre uten å blokkere.

På implementeringsnivået er støtten til rørledningene i Linux-kjernenikke i skallet. Kommandotolken (bash, zsh, osv.) oppretter ganske enkelt pipelinen gjennom systemkall som pipe() y fork()omdiriger filbeskrivelsene og start deretter hvert program. Den virkelige magien med hvordan prosesser blokkeres, hvordan bufferen administreres og hvordan data forplantes mellom produsent og forbruker håndteres av systemkjernen.

Forstå stdin, stdout og dataflyt

For å jobbe bra med rørledninger er det viktig å ha en klar forståelse av hva de er. stdin, stdout og stderrDette er ikke abstrakte konsepter: hver prosess i Linux starter med tre åpne filbeskrivelser, som peker til spesifikke ressurser som administreres av kjernen.

stdin (beskrivelse 0) og stdout (beskrivelse 1) De kan sees på som strømmer av byte koblet til noe: det kan være en terminal, en fil, en nettverkssocket eller en pipe. De er ikke bare buffere; de ​​er referanser til kjerneobjekter (strukturer av typen fil) som igjen er assosiert med inoder, sokler eller interne rørstrukturer.

Hver prosess har sine egne beskrivelser, slik at hver kommando i en pipeline Den viser stdin og stdout uavhengig av hverandre. På en linje som ls | grep txt | wc -l, The ls skriv i et rør, grep Den leser fra ett rør og skriver til et annet, og wc Les fra den siste. For brukeren vises det som en enkelt streng, men internt er de flere sammenkoblede kjernebufferehvor hver prosess blokkeres og gjenopptas avhengig av tilgjengelig plass eller data.

Når den første prosessen produserer data raskere enn den andre bruker dem, fylles pipe-bufferen opp. På det tidspunktet returnerer påfølgende skrivinger, og blokkerer sendeprosessen inntil den brukerprosessen... les nok informasjon og frigjør plass. Dette forhindrer at minnet kommer ut av kontroll; data akkumuleres ikke i det uendelige med mindre du bruker ikke-blokkerende I/O eller spesielle signaler. For eksempel, i et tilfelle som dd if=/dev/sda | gzip -9og gzip komprimeres saktere, dd han er tvunget til å vente.

Denne mottrykksmekanismen gjør rørledningene ganske stabile selv når det er ytelsesubalanser mellom trinnene, noe som også gjenspeiles i utformingen av CI/CD-rørledningerder de langsomme stadiene blir flaskehalsen som må måles og optimaliseres.

Praktisk bruk av pipes i Linux-terminalen

I hverdagen brukes rør til kjede kommandoer i én linje og transformere data trinn for trinn. I stedet for å kjøre en kommando, se på resultatet, kopiere det, lime det inn i en annen ... kan du bygge små «datafabrikker» i ren tekst med stor fleksibilitet.

Et typisk eksempel i Unix-miljøer er å kombinere kommandoen fortune, som viser tilfeldige sitater, med cowsaysom skriver ut en «snakkende» ku. Når man bruker et rør, Fortunes avgang blir Cowsays budskapalt i én kommando. Det er et lekent eksempel, men det illustrerer perfekt ideen om å koble sammen enkle verktøy for mer komplekse oppgaver.

En annen klassiker er å sende resultatet av ls a wc å telle linjer, ord og tegn. Noe sånt som ls | wc Det lar deg raskt se hvor mange elementer som er oppført. Det fine er at du ikke trenger et enkelt program for å gjøre alt, men heller... Du lager løsninger med små, veldesignede verktøy..

Det er også veldig vanlig å lenke sammen cat, sort y more (eller en annen personsøker) for å sortere en tekstfil og deretter bla gjennom den side for side. Med en pipe går innhold fra én kommando til den neste uten å bli lagret i eksplisitte midlertidige filer, noe som forenkler skripting og administrative oppgaver betraktelig.

I praktiske tilfeller, som å behandle elevlister og karakterer i separate filer, kan du bruke paste å slå sammen kolonner, cut for å velge bare feltene du er interessert i og kjedede rør for å filtrere, sortere eller transformere alt i en enkelt linje med skallskript. Dette mønsteret av dele opp et stort problem i enkle kommandoer kombinert med rør Det er essensen av Unix-filosofien.

Avanserte kommandoer for å få mest mulig ut av pipes: tee, xargs og cpio

Når du begynner å automatisere ting i Linux, blir pipes enda kraftigere takket være noen viktige verktøy. Blant dem er: tee, xargs y cpiosom utfyller standard dataflyt veldig godt.

Kommandoen tee Den fungerer som en «T» i et vannrør: den leser fra stdin, skriver til stdout, og kopierer også den samme utdataen til en eller flere filer. Den er ideell når du vil se resultatet på skjermen og lagre det samtidig for å gjennomgå den senere eller behandle den på et annet tidspunkt. Med alternativet -a Den legger til data på slutten av filen i stedet for å overskrive den.

For eksempel kan du sortere en liste med sortsend resultatet til tee å lagre den i en logg og samtidig sende den videre til more å paginere den. På denne måten har du i én enkelt pipeline sortering, lagring på disk og praktisk visning uten å gjenta sorteringsprosessen.

Kommandoen xargs Det er en annen grunnleggende del når det gjelder pipes. Funksjonen er å ta det som kommer inn via stdin (vanligvis en liste med elementer) og konvertere det til argumenter for en annen kommando. Det er spesielt nyttig når et program krasjer fordi det mottar for mange parametere samtidig, eller når du vil del opp arbeidet i omganger med alternativet -n, som begrenser hvor mange argumenter som sendes per utførelse.

For eksempel med ls | xargs -n 4 Du deler fillisten inn i grupper på fire, og utfører målkommandoen (som standard echo(eller den du spesifiserer) flere ganger. På denne måten kan du bygge pipelines som «forhåndsvis hva jeg skal slette» ved å kombinere ls, xargs y echo rm før den faktiske slettingen startes.

Vær forsiktig med komplekse inndata: stier med mellomrom eller spesialtegn kan bryte standardoppførselen til xargsI slike tilfeller brukes det vanligvis i kombinasjon med find og alternativet -print0, som skiller elementer med et nulltegn, sammen med xargs -0 slik at begge ender bruker den samme robuste skilletegnet.

Endelig, cpio Det er en mindre kjent kommando enn tarMen den er utrolig fleksibel for å jobbe med filstrømmer via rør. I motsetning til tar er den designet fra grunnen av for å fungere med omdirigeringer og rørledningermottar en liste over filer via stdin (vanligvis generert med find) og produserer eller forbruker filer av typen "pakke" uten egen komprimering, som du deretter kan komprimere med gzip eller liknende.

De viktigste modusene for cpio tillate oppretting av filer (-o), kopier katalogtrær (-p) eller trekke ut innhold (-i(ofte referert til som «kopiering»). Alternativer som -u å overskrive, -m for å bevare tidsstempler eller -d å gjenskape katalogstrukturen gjør det mulig å kontrollere i detalj hva som kopieres og hvordan, spesielt nyttig i komplekse skript der tar kommer til kort.

Design og optimalisering av CI/CD-pipelines på Linux-servere

Utover den tradisjonelle kommandolinjen har pipeline-konseptet blitt grunnleggende i verdenen av Kontinuerlig integrasjon og kontinuerlig levering (CI/CD)På en Linux-server er en CI/CD-pipeline en automatisert sekvens av trinn: hente kode, installere avhengigheter, kompilere, kjøre tester, pakke artefakter og distribuere.

Linux er spesielt godt egnet til dette fordi det utmerker seg på sitt hastighet, stabilitet og økosystem for automatiseringsverktøyPlattformer som Jenkins, GitHub Actions eller GitLab CI er avhengige av Linux-eksekutører (fysiske maskiner, virtuelle maskiner eller containere) for å kjøre pipelines konsekvent.

Å optimalisere disse pipelines betyr ikke bare å få dem til å "fungere", men å få dem til å fungere med så lite friksjon som mulig. Dette betyr å redusere utsjekkingstider, minimere repeterende avhengighetsinstallasjoner, Docker-bildeoptimalisering for å unngå unødvendige rekonstruksjoner, gjenbruke allerede genererte artefakter og holde miljøet trygt og observerbart.

En god grunnleggende praksis er å strukturere rørledningen i veldefinerte stadier: bygge, teste og distribuereIdeelt sett bør du kompilere bare én gang, generere en artefakt (binærfil, pakke, Docker-avbildning) som testes parallelt på forskjellige varianter (for eksempel flere språkversjoner), og deretter promotere den samme artefakten til staging- og produksjonsmiljøer, uten å kompilere på nytt.

Å jobbe med uforanderlige artefakter lagret i repositorier (S3, Nexus, Artifactory, containerregistre eller pakker innebygd i GitLab/GitHub) forenkler revisjon, muliggjør rask tilbakestilling av versjoner og reduserer sannsynligheten for at "det fungerer på maskinen min, men ikke i produksjon".

Forutsetninger: distribusjon, CI-bruker og serverherding

Før man går inn på finjustering av millisekundoptimalisering her og der, er det viktig å etablere en stabil base på Linux-serveren som vil fungere som CI/CD-eksekutor. Dette begynner med valg av distribusjon og minimum sikkerhetskonfigurasjon.

Det mest fornuftige er vanligvis å standardisere en LTS eller stabil distribusjon som teamet er kjent med: Ubuntu LTS, Debian Stable eller bedriftsalternativer som AlmaLinux eller Rocky Linux. Å ha alle kjørbare filer på samme versjon forhindrer uventet oppførsel forårsaket av forskjellige biblioteker eller kjerner mellom jobber.

En annen anbefaling er å konfigurere en dedikert bruker for CI, uten root-rettigheter, med sudo svært begrenset til kun de essensielle kommandoene (for eksempel, systemctl o docker (hvis det virkelig er nødvendig). Denne brukeren må autentisere seg med SSH-nøkler, både for å få tilgang til serveren og for å samhandle med Git-repositorier eller andre eksterne maskiner.

På systemnivå er det lurt å vedlikeholde serveren oppdatert og minimalt forsterketDette inkluderer å installere sikkerhetsoppdateringer, konfigurere en restriktiv brannmur (for eksempel med UFW: nekte all innkommende trafikk unntatt det som er nødvendig og tillate utgående trafikk), og aktivere verktøy som fail2ban å stoppe brute-force-angrep på SSH og justere noen nettverks- og kjerneparametere via sysctl for å forbedre pålitelighet og ytelse.

For eksempel er det vanlig å heve grensen for inotify for å forhindre at byggesystemer som overvåker mange filer går tom for ressurser, og justere parameteren vm.swappiness for å gjøre kjernen mer konservativ når man bruker swap, noe som er spesielt relevant når CI-jobber bruker mye minne om gangen.

Hurtigbuffer, Docker og parallellisering: ytelsesspakene i CI/CD

Hvis du ser på hvor tiden faktisk går i en gjennomsnittlig rørledning, vil du se at en stor del går tapt i Installer avhengigheter og gjenoppbygg Docker-bilderÅ løse dette problemet gir ofte bedre resultater enn å optimalisere testkoden med noen få millisekunder.

Den første spaken er avhengighetsbufferingNesten alle filbehandlere (pip, npm, Maven, Gradle, Go-moduler osv.) bruker lokale hurtigbufferkataloger. På en permanent Linux-server kan du dele disse katalogene mellom jobber eller montere dem på et permanent volum. På denne måten trenger ikke hver utførelse å laste ned halve internett på nytt.

For Docker, aktiver Byggesett og strukturer godt Dockerfile Dette markerer et vendepunkt. Å plassere avhengighetsinstallasjonen rett etter at kravfilen er kopiert, og før resten av koden, sikrer at lagene brukes om igjen så lenge versjonene av disse avhengighetene forblir uendret. Videre kan spesifikke mellomlagringer for pip, npm osv. settes opp i selve byggingen.

Den andre store spaken er parallell testutførelseMange rammeverk støtter samtidighet innebygd: pytest med -n autoJava-verktøy som Surefire og Jest i JavaScript med --maxWorkersosv. Å dele opp programpakken etter moduler, mapper eller til og med etter estimert tid og fordele den mellom flere arbeidere gir en reduksjon på 2 til 5 ganger i testfasens varighet uten å endre en eneste forretningslinje.

Til slutt er det spørsmålet om gjenstander og promoteringI stedet for å kompilere det samme bildet på nytt for oppsett, førproduksjon og produksjon, er den effektive tilnærmingen å bygge én gang, lagre resultatet i et repository og tagge det i henhold til distribusjonsmiljøet. Dette reduserer CPU-bruken, unngår inkonsekvenser og øker hastigheten på lange pipelines betydelig.

Optimalisering av Jenkins, GitHub Actions og GitLab Runner på Linux

Hvert CI-system har sine egne særtrekk, men de drar alle nytte av de samme grunnleggende ideene når de kjører på Linux. Nøkkelen ligger vanligvis i bruk flyktige og rene utførereOppretthold en vedvarende hurtigbuffer av god størrelse og kontroller samtidighet.

I Jenkins er det en veldig vanlig praksis å bruke lette og midlertidige agenter (for eksempel Docker-containere eller -poder i Kubernetes eller andre løsninger av containerorkestreringå kjøre jobbene, mens hovednoden holdes så enkel som mulig. Agentene kan konfigureres som systemd-tjenester på Linux-servere, registreres hos kontrolleren og starter automatisk når maskinen starter opp.

For GitHub-handlinger med selvhostede løpere anbefales det å distribuere dem i Virtuelle Linux-maskiner med raske SSD-erFor å opprette en stor hurtigbufferkatalog dedikert til handlinger (språkavhengigheter, byggehurtigbuffere osv.), begrens antallet samtidige jobber for å unngå overbelastning av CPU og disk. Dra nytte av den offisielle hurtigbufferhandlingen med stier som ~/.cache/pip, ~/.npm o ~/.m2 Det utgjør en stor forskjell i tid.

I GitLab Runner, velg mellom skallutfører eller Docker Det avhenger av balansen mellom ytelse og isolasjon du trenger. Shell-eksekutoren er raskere fordi den kjører direkte på verten, men Docker-eksekutoren tilbyr rene og replikerbare miljøer. Du kan også konfigurere delt mellomlagring (lokal eller på S3) og justere maksimalt antall samtidige jobber for å dra nytte av maskinvaren uten å overbelaste den.

I alle disse tilfellene er det avgjørende å ha delte volumer for avhengighetsbufring samtidig som det forhindrer at arbeidsområder blir rotete mellom bygg. Kortvarige maskiner eller containere, som opprettes og ødelegges med hver pipeline eller gruppe av pipelines, reduserer i stor grad problemer med at «det fungerte i går, men det gjør det ikke i dag» forårsaket av rester av tidligere bygg.

Linux-serverytelse: CPU, minne, I/O og Docker

Uansett hvor optimaliserte skriptene dine er, vil du støte på endeløse køer og trege jobber hvis Linux-serveren som kjører pipelinen ikke har riktig størrelse. En rimelig typisk konfigurasjon for en maskin av gjennomsnittlig størrelse er... 4–8 vCPU-er og 8–16 GB RAM, med SSD-lagring (ideelt sett NVMe) og noe swap (2–4 GB) for å støtte topper uten å aggressivt drepe prosesser.

Filsystemet har også betydning. Bruk ext4 eller XFS med alternativet noatime I volumene der du kompilerer eller skriver logger, reduser unødvendig I/O. I tillegg må du montere en tmpfs for midlertidige filer eller kortvarige artefakter (for eksempel /mnt/ci-tmp) fremskynder intensiv drift og forhindrer at disken fylles opp med gjenværende filer mellom jobber.

Når det gjelder Docker, er daemonhygiene nøkkelen. Trygg og regelmessig fjerning av ubrukte bilder og volumer, samtidig som man opprettholder aktive basebilder, bidrar til å kontrollere diskplass og oppstartstiderKommandoer som docker system prune Med passende tidsfiltre tillater de rengjøring uten å overbelaste nylig brukte ressurser.

Hvis CI-en din er veldig containerintensiv, kan du også ty til speilposter For å unngå å stadig laste ned fra internett, bruk BuildKit for samtidighet og lagbuffering, og konfigurer til og med CPU-affiniteter (CPU-sett) eller dedikerte noder for de mest krevende utførerne, for å forhindre interferens mellom nærliggende arbeidsbelastninger. Forstå dessuten CPU-mikroarkitektur Det bidrar til å bedre dimensjonere ressurser for intensive CI-belastninger.

Sikkerhet i prosessen (DevSecOps) og distribusjoner på Linux

En rask, men usikker rørledning er en tikkende tidsbombe. Integrering av sikkerhet i selve rørledningen og Docker-containersikkerhet Det er allerede en standard i enhver DevSecOps-strategi, og Linux tilbyr mange verktøy for det.

Det første er å behandle hemmeligheter og legitimasjonsinformasjon håndteres med største forsiktighetDe skal aldri oppbevares i kode eller versjonerte konfigurasjonsfiler. I stedet lagres de i hemmelige administratorer (maskerte variabler i GitLab, krypterte hemmeligheter i GitHub, HashiCorp Vault osv.) og injiseres kun under utførelsen av jobben som trenger dem, med bruk av kortlivede tokens når det er mulig.

Et annet viktig lag er genereringen av SBOM (programvareliste) og artefaktsignering. Verktøy som Syft eller CycloneDX lar deg liste opp alle komponentene som er en del av et bilde eller en binærfil, mens Cosign eller andre verifiserbare signeringsløsninger sikrer at bare artefakter som har gått gjennom pipelinen og har blitt validert, distribueres.

I nettverks- og tilgangsdelen anbefales det å segmentere IC og produksjonsnettverkImplementer strenge brannmurer, revider utførelseslogger og roter påloggingsinformasjon regelmessig. Der SSH brukes, er det bedre å bruke sertifikater eller nøkler med utløpsdatoer enn statiske passord.

Ved distribusjon på Linux, strategier som Blå/grønn, bølgende og kanarigrønn De reduserer virkningen av distribusjonsfeil betraktelig. Å kjøre applikasjonen som en systemd-tjeneste, plassere en Nginx eller HAProxy foran den, og kontrollere trafikk mellom versjoner ved hjelp av helsesjekker, lar deg oppnå så godt som null nedetid under oppdateringer.

For eksempel, når du laster inn Nginx på nytt og starter tjenester på nytt med systemd ved hjelp av myke stoppsignaler (som SIGTERMMed rimelige ventetider kan du tømme aktive tilkoblinger før prosessen stopper, slik at brukeropplevelsen bevares mens du bytter versjon i bakgrunnen.

Observerbarhet, målinger og kostnader i Linux-pipelines

Når du har oppe og går rørledningene dine, er neste nivå mål dem og forstå hvor tid og ressurser gårDet er ikke nok å vite om en arbeidsflyt består eller mislykkes; du må overvåke varigheten av hvert trinn, køtiden, suksessraten, distribusjonsfrekvensen, treffraten for hurtigbufferen osv.

Det er vanlig å eksportere systemmålinger ved hjelp av node_exporterSentraliser logger med løsninger som ELK eller Loki, og visualiser alt i Grafana-dashboards. På denne måten kan du for eksempel oppdage om testfasen har økt i varighet med 30 % den siste uken, eller om jobber bruker for mye tid på å vente på en tilgjengelig utfører; overvåking av nettverkstrafikk Verktøy med åpen kildekode utfyller denne synligheten.

Det er også mulig å instrumentere selve pipelinen, for eksempel i GitHub Actions eller GitLab CI, for å å programmatisk måle hvor mange utførelser som har vært vellykkede, hvor lenge hver kjøring har vart, og hva den generelle statusen erEt skript som kaller leverandørens API, beregner det totale antallet kjøringer, antallet vellykkede kjøringer, antallet mislykkede kjøringer, suksessraten og gjennomsnittlig varighet, og lagrer alt i en JSON-fil (som pipeline-metrics.json) lar deg integrere disse målingene i rapporter eller dashbord.

Med den informasjonen kan du ta avgjørelser om størrelse og antall løpereNoen ganger er det bedre å ha flere små utførende enn noen få veldig store for å redusere ventetider. Autoskalerbarhet – for eksempel skybasert autoskalering eller dynamiske pools av Kubernetes-noder – bidrar til å absorbere toppaktivitet på dagtid og minimere underutnyttede ressurser om natten.

Disse fremgangsmåtene forbedrer ikke bare teamopplevelsen, men bidrar også til å justere infrastrukturkostnadene ved å kontrollere CPU-, minne- og spesielt lagringsforbruk, som har en tendens til å skyte i været med bilder og hurtigbuffere hvis det ikke rengjøres regelmessig og planlagt.

Å mestre både klassiske kommandolinjepiper og moderne CI/CD-piper i Linux gir en svært kraftig kombinasjon: Du kan automatisere alt fra enkle tekstfiltreringsoppgaver til komplekse byggings-, test- og distribusjonsprosesser. Vedlikeholdsvennlig, sikker og rask. Å forstå hvordan informasjon flyter mellom prosesser, hvordan avhengigheter mellomlagres, hvordan servere finjusteres og hvordan målinger og sikkerhet integreres, lar deg bygge arbeidsflyter som skaleres med teamet og prosjektene dine uten å bli en konstant flaskehals.