BuildKit: Dockerjev skriti dragulj, ki lahko zgradi skoraj vse

BuildKit: Dockerjev skriti dragulj, ki lahko zgradi skoraj vse

Večina razvijalcev pozna Docker kot izvajalno okolje vsebnika, ki je spremenilo način pošiljanja programske opreme. Precej manj jih pozna mehanizem, ki tiho brni pod površjem vsake sodobne zgradbe Dockerja – BuildKit, sistem za gradnjo naslednje generacije, ki je bil dobavljen z Dockerjem od različice 18.09 in je postal privzeto zaledje v Dockerju 23.0. Medtem ko se inženirji neskončno prepirajo o konfiguracijah Kubernetes in vzorcih mikrostoritev, se BuildKit vztrajno razvija v enega najzmogljivejših, prilagodljivih gradbenih sistemov v ekosistemu DevOps. Če ste to obravnavali le kot hitrejšo gradnjo dockerja, puščate na mizi ogromno zmogljivosti. Podjetja, ki izvajajo visoko zmogljive cevovode CI/CD, so skrajšala čas gradnje za 50–70 % preprosto z razumevanjem, kaj BuildKit dejansko ponuja – in to je šele začetek.

V čem se BuildKit bistveno razlikuje od klasičnega graditelja

Izvirni gradbeni mehanizem Docker je izvajal navodila Dockerfile zaporedno, eno plast naenkrat, brez zavedanja o tem, katero delo se lahko varno izvaja vzporedno. BuildKit nadomešča ta linearni izvedbeni model z usmerjenim acikličnim grafom (DAG) – grafom odvisnosti, ki razume, kateri koraki gradnje so odvisni drug od drugega in kateri ne. Neodvisne stopnje se izvajajo sočasno, neuporabljene stopnje so v celoti preskočene in celotna zgradba postane deklarativni opis tega, kar želite, namesto imperativnega zaporedja korakov, ki jih morate navesti v pravilnem vrstnem redu.

Ta arhitekturni premik ima praktične posledice, ki presegajo hitrost. Ko večstopenjski Dockerfile prevede binarno datoteko Go v eni fazi, prenese odvisnosti Node.js v drugi in sestavi produkcijsko sliko v tretji, lahko BuildKit izvaja prvi dve stopnji hkrati. Gradnja, ki je prej trajala štiri minute na zmogljivem CI runnerju, se zdaj konča v manj kot devetdesetih sekundah. Stripe, Shopify in številne druge visoko obsežne inženirske ekipe so dokumentirale podobne pridobitve v svojih internih retrospektivah orodij. Model DAG prav tako pomeni, da lahko BuildKit ustvari zelo natančne metapodatke o gradnji – temelj za funkcije, kot so potrdila o poreklu in generiranje seznama materialov programske opreme (SBOM), ki so izjemno pomembni za varnost dobavne verige.

Prišlo je tudi do konceptualne spremembe v delovanju razveljavitve predpomnilnika. Klasični graditelj je razveljavil vsako plast pod vsakim spremenjenim navodilom. BuildKit sledi zgoščenim vrednostm vsebine pri vsakem vnosu, tako da spreminjanje komentarja v datoteki Dockerfile ne odnese vnosa v predpomnilnik, ki predstavlja trideset minut prevajanja. Ko je predpomnilnik gradnje razlika med petminutno in štiridesetminutno povratno zanko za vašo inženirsko ekipo, je ta natančnost pomembna veliko bolj, kot se morda zdi na začetku.

Zgradbe na več platformah: en ukaz, vsaka arhitektura

Zastavica --platform programa BuildKit in integracija QEMU spremenita nekoč bolečo težavo koordinacije več sistemov v en sam ukaz. Zagon docker buildx build --platform linux/amd64,linux/arm64,linux/arm/v7 . ustvari tri slike, pripravljene za proizvodnjo, vzporedno iz enega klica gradnje. Ta zmožnost je postala kritična, ko se industrija preusmerja k ARM – primerki AWS Graviton3 dosledno zagotavljajo 40 % boljšo cenovno zmogljivost pri delovnih obremenitvah, kot sta spletno streženje in obdelava podatkov, Apple Silicon pa je ARM naredil privzeti razvojni stroj za milijone inženirjev.

Preden je podpora za več platform BuildKit dozorela, je bilo vzdrževanje ločenih cevovodov gradnje za različne arhitekture resnično stroškovno mesto. Ekipe so vzdrževale več datotek Dockerfiles, izvajale ločene CI cevovode na različno arhitekturnih tekalnikih ali pa so preprosto pošiljale slike x86 povsod in plačale kazen za zmogljivost na infrastrukturi ARM. Z BuildKitom enkrat definirate svojo gradnjo in pustite sistemu, da transparentno obravnava kompilacijo, specifično za arhitekturo. Projekti Rust, ki zahtevajo navzkrižno prevajanje, projekti Go z odvisnostmi CGO, paketi Python z razširitvami C — BuildKit obravnava emulacijsko plast, ne da bi morali razumeti podrobnosti vsake ciljne platforme.

Praktična poslovna vrednost tukaj je merljiva. Ekipa, ki izvaja 200 vsebnikov na instancah AWS Graviton po 0,04 USD na uro vCPU v primerjavi z enakovrednim primerkom x86 po 0,056 USD na uro vCPE, prihrani približno 11.520 USD letno na 100 vCPU – izključno zaradi izbire prave arhitekture. Omogočanje dostopa do te izbire brez truda pri ponovnem inženiringu je natanko tista vrsta optimizacije infrastrukture, ki se takoj povrne.

Upravljanje skrivnosti brez uhajanja v slikovne plasti

Ena izmed najbolj podcenjenih funkcij BuildKita je API za skrivnosti. Klasični gradilnik Docker ni imel čistega načina za posredovanje poverilnic v gradnjo, ne da bi te poverilnice potencialno končale v sloju slike. Razvijalci so se temu izognili z večstopenjskimi izgradnjami, navodili ARG in skrbnim vrstnim redom, vendar je tveganje, da bi pomotoma zapekli ključ API ali zasebni ključ SSH v poslano sliko, ostalo neprijetno visoko. Varnostni skenerji redno najdejo trdo kodirane poverilnice v slikah vsebnikov, objavljenih v javnih registrih, in mnoga od teh uhajanj vodijo neposredno nazaj do nerodnega ravnanja s skrivnostmi med gradnjo.

BuildKit --secret vgradi občutljive podatke v gradbeno okolje kot začasno pot datotečnega sistema, ki obstaja samo za čas trajanja določenega ukaza RUN, ki to potrebuje, in se nikoli ne dotakne nobene slikovne plasti. Navodilo datoteke Dockerfile, kot je RUN --mount=type=secret,id=npmrc cat /run/secrets/npmrc > ~/.npmrc && npm install, daje procesu gradnje dostop do zasebnih poverilnic npm, ne da bi se te poverilnice kdaj pojavile na končni sliki ali kateri koli vmesni plasti. Isti vzorec deluje za poverilnice PyPI, nastavitve Maven, ključe SSH za zasebne repozitorije Git in vse druge občutljive materiale, ki jih zahteva vaš postopek gradnje.

Za ekipe, ki izdelujejo programsko opremo, ki se dotika reguliranih panog – platforme za zdravstveno varstvo, izdelki fintech, programska oprema za kadrovske zadeve – je razlika med »poverilnice morda na sliki« in »poverilnice dokazljivo ne morejo biti na sliki« razlika med uspešnostjo varnostne revizije in porabo treh tednov za popravljanje ugotovitev. Platforme, kot je Mewayz, ki poganja poslovne operacije za več kot 138.000 uporabnikov v panogah, kot so obračun plač, kadrovska služba in izdajanje računov, so odvisne od natanko te vrste dokazljive varnostne drže v svojih gradbenih in uvajalskih cevovodih, da ohranijo zaupanje, ki ga te stranke izkazujejo svojim občutljivim finančnim in kadrovskim podatkom.

Izvozi predpomnilnika: ustvarjanje hitrih cevovodov CI

Cevi CI so tiste, kjer je zmogljivost gradnje najpomembnejša in kjer je bila izkušnja privzete gradnje Docker v preteklosti najbolj boleča. Sveži izvajalci CI se običajno začnejo s praznimi predpomnilniki, kar pomeni, da vsak zagon cevovoda znova prevede vse od začetka. Za storitev Java s stotinami odvisnosti Maven, projekt Rust ali aplikacijo Python z obsežnimi izvornimi razširitvami to pomeni čas gradnje, merjen v desetinah minut in ne v sekundah. Poslovni stroški počasnega CI so ogromni – zmanjšana pogostost uvajanja, daljše povratne zanke in inženirji, ki brez dela čakajo na dokončanje cevovodov, preden se lahko združijo in gredo naprej.

Funkcija izvoza predpomnilnika BuildKit to reši z manifesti predpomnilnika, ki jih je mogoče izvoziti. Z uporabo --cache-to type=registry,ref=myregistry/myapp:cache in --cache-from type=registry,ref=myregistry/myapp:cache BuildKit potisne podroben posnetek predpomnilnika v register po vsaki gradnji in ga potegne na začetku naslednje. Predpomnilnik je naslovljen glede na vsebino, tako da se ponovno pridobijo le resnično spremenjene plasti. Ekipe, ki uporabljajo ta vzorec v GitHub Actions, GitLab CI in CircleCI, rutinsko skrajšajo čas cevovoda s petnajst minut na manj kot tri pri naslednjih zagonih. GitHubova lastna dokumentacija o naprednih delovnih procesih gradnje Docker močno priporoča ta vzorec ravno iz tega razloga.

Najhitrejša sestava je tista, ki je nikoli več ni treba zagnati. Večplastni sistem predpomnilnika, naslovljen na vsebino, BuildKit ne pospeši le gradenj – naredi celoten koncept »gradnje« pametnejši, tako da spremeni ponavljajoče se prevajanje v inkrementalno diff natanko tega, kar se je spremenilo.

Izvozi predpomnilnika se tudi čisto integrirajo z razvojnimi poteki dela v podružnicah. Svoj cevovod CI lahko konfigurirate tako, da se vrne iz predpomnilnika, specifičnega za vejo, v predpomnilnik glavne veje, ko predpomnilnik veje ne obstaja, kar pomeni, da nove veje takoj izkoristijo topel predpomnilnik, ki ga nabere vaša glavna razvojna linija. Inženirji prejmejo hitre povratne informacije od svoje prve objave na novi veji, namesto da čakajo na kazen hladnega zagona.

Včelje BuildKit: Gradnja onkraj datotek Docker

Morda najmanj znana zmožnost BuildKita je ta, da so Dockerfiles le ena možna vhodna oblika – ne edina. BuildKit ima priključno arhitekturo sprednjega dela, ki omogoča povsem prilagojene jezike in formate definicij gradnje. Vmesni del je določen z direktivo # syntax= na vrhu vaše gradbene datoteke, ki BuildKitu pove, naj potegne določeno vmesno sliko in jo uporabi za razčlenjevanje in izvajanje preostale datoteke.

Ta arhitektura je omogočila številne privlačne projekte. Integracija Buildpacks omogoča BuildKitu, da zgradi slike vsebnika iz izvorne kode aplikacije brez kakršne koli datoteke Dockerfile – zazna jezik, izbere ustrezne osnovne slike in samodejno sestavi vsebnik, pripravljen za proizvodnjo. HPC in znanstvene računalniške skupnosti so uporabile vmesnike po meri za opisovanje gradenj v jezikih, specifičnih za domeno, ki prevedejo do notranje predstavitve LLB (zgradba nizke ravni) BuildKit. Vmesnik sintakse docker/dockerfile:labs eksperimentira s funkcijami, kot je podpora za heredoc, nadzor --network na navodilo in izboljšani namigi za predpomnilnik, preden pristanejo v stabilni sintaksi Dockerfile.

Možnost definiranja lastnega vmesnika prav tako pomeni, da organizacijam z neobičajnimi zahtevami glede gradnje ni treba izbirati med "vključevanjem vsega v sintakso Dockerfile" in "popolnoma opustitvijo vsebnikov". Vdelana programska oprema FPGA, slike vdelanih sistemov ali specializirani vsebniki modelov ML, ki sestavljajo skupino, lahko opišejo svojo zgradbo z izrazi, ki so smiselni za njihovo domeno, medtem ko še vedno proizvajajo standardne slike vsebnikov, skladne z OCI, ki se uporabljajo kjer koli, kjer se izvajajo vsebniki. Ta razširljivost je resnična arhitekturna prednost pred gradbenimi sistemi, ki svojo vhodno obliko obravnavajo kot fiksno.

Izvor in SBOM: Gradnja za svet po sončnem vetru

Varnost dobavne verige programske opreme se je po vdoru SolarWinds leta 2020 in ranljivosti Log4Shell leta 2021 premaknila s teoretičnega pomisleka na prednostno nalogo na ravni odbora. Izvršni ukaz vlade ZDA 14028 o kibernetski varnosti, izdan maja 2021, je predpisal popis materiala za programsko opremo za zvezne izvajalce. Potrdila o poreklu BuildKita in funkcije generiranja SBOM so neposreden odgovor na to regulativno in varnostno okolje.

Z zastavicama --provenance=true in --sbom=true BuildKit ustvari kriptografsko podpisana potrdila, ki natančno opisujejo, kaj je šlo v sliko vsebnika – katere osnovne slike so bile uporabljene, katera navodila Dockerfile so bila izvedena, katere izvorne datoteke so bile prisotne in katere zunanje odvisnosti so bile pridobljene. Ta potrdila sledijo ogrodju SLSA (Supply-chain Levels for Software Artifacts) in formatu potrdil in-toto, zaradi česar jih strojno preverijo mehanizmi pravilnikov, kot sta Sigstore's Cosign in OPA (Open Policy Agent).

Praktični potek dela, ki ga to omogoča, je videti takole:

1. Razvijalec potiska kodo; Cevovod CI sproži gradnjo BuildKit z omogočenim izvorom.
2. BuildKit ustvari podpisan SBOM s seznamom vseh komponent in njihovih različic.
3. SBOM je objavljen v registru vsebnikov skupaj s slikovnim manifestom.
4. Krmilniki za sprejem v gruči Kubernetes preverijo poreklo, preden dovolijo uvedbo.
5. Skenerji ranljivosti poizvedujejo po SBOM, da prepoznajo prizadete slike, ko so razkriti novi CVE.

Ekipe, ki izvajajo ta celoten cevovod, se lahko na razkritje ranljivosti odzovejo v urah in ne dnevih, saj imajo natančen, strojno berljiv zemljevid vsake komponente v vsakem delujočem vsebniku. Za podjetja, kot je Mewayz, ki se globoko integrirajo v operativne poteke dela strank – vodenje obračuna plač, upravljanje podatkov o voznem parku, obdelava računov – je zmožnost dokazovanja stroge dobavne verige, ki jo je mogoče preveriti, čedalje bolj predpogoj za prodajne pogovore v podjetjih, ne le nekaj, kar je lepo imeti.

Kako začeti: od privzetih sestav do naprednih cevovodov

BuildKit se že izvaja v vašem okolju Docker, če uporabljate novejšo različico — Docker 23.0 in jo pozneje omogočite privzeto. Prvi praktični korak za večino ekip je omogočanje vtičnika Docker Buildx, ki razkrije celoten nabor funkcij BuildKita prek podukaza docker buildx. Zagon docker buildx create --use nastavi primerek graditelja BuildKit z več zmogljivostmi kot privzeti gonilnik. Od tam je smiselno postopno sprejemanje naprednih funkcij, namesto da bi poskušali sprejeti vse naenkrat.

Razumna pot sprejetja za ekipo, ki trenutno izvaja osnovne priklice docker build, je videti tako, da bi najprej dodali izvoze predpomnilnika v CI – to zagotavlja takojšnje, merljive izboljšave hitrosti z minimalno spremembo konfiguracije. Zgradbe za več platform postanejo dragocene, ko ekipa začne ciljati na infrastrukturo ARM. Skrivno namestitev je vredno sprejeti vsakič, ko se zasebni registri paketov ali ključi SSH pojavijo v kontekstu gradnje. Potrdila o poreklu je smiselno omogočiti, kadar je zaradi zahtev skladnosti ali zahtev strank podjetja potrebna dokumentacija dobavne verige.

Globlja lekcija BuildKita je premišljena gradnja. Ne glede na to, ali pošiljate vsebnik za mikrostoritev, končno točko sklepanja strojnega učenja ali zapleteno platformo, kot je Mewayzova zbirka 207 poslovnih modulov, gradbeni proces ni formalnost, s katero se mudi na poti do uvajanja – je inženirski artefakt, ki odraža kakovost, varnostno držo in operativno zrelost vsega, kar izhaja iz njega. BuildKit vam ponuja orodja, s katerimi naredite ta artefakt odličen. Vprašanje je le, ali si vzamete čas za njihovo uporabo.

Pogosto zastavljena vprašanja

Kaj je BuildKit in kako se razlikuje od klasičnega sistema gradnje Docker?

BuildKit je Dockerjev gradbeni mehanizem naslednje generacije, predstavljen v Dockerju 18.09 in privzeti v Dockerju 23.0. Za razliko od klasičnega graditelja BuildKit podpira izvajanje vzporednih slojev, napredne strategije predpomnjenja, namestitev skrivnosti in gradnje na več platformah. Proces gradnje obravnava kot usmerjeni aciklični graf (DAG), kar omogoča pametnejšo razrešitev odvisnosti in dramatično hitrejše čase gradnje za kompleksne, večstopenjske datoteke Docker.

Ali moram namestiti kaj dodatnega, da začnem uporabljati BuildKit z Dockerjem?

Če uporabljate Docker 23.0 ali novejšo različico, dodatna namestitev ni potrebna — BuildKit je privzeto omogočen. V starejših različicah ga lahko aktivirate tako, da nastavite spremenljivko okolja DOCKER_BUILDKIT=1, preden zaženete ukaze za gradnjo. Za napredne primere uporabe, kot so predpomnilniki za oddaljene gradnje ali gradnje za več platform, boste morda želeli konfigurirati namenski primerek graditelja Buildx z uporabo docker buildx create.

Ali je mogoče BuildKit uporabiti za izdelavo artefaktov, ki presegajo standardne slike vsebnika?

Da, in to je ena najbolj premalo cenjenih zmogljivosti BuildKita. Z uporabo vmesnikov po meri in zastavice --output lahko BuildKit izdela neobdelane binarne datoteke, arhive, statična spletna mesta in druge poljubne artefakte datotek — ne le slike OCI. Zaradi tega je stroj za gradnjo splošnega namena, ki se naravno prilega poliglotskim monoreposom in zapletenim cevovodom CI, kjer različne ekipe potrebujejo različne izhodne formate iz enotne verige orodij.

Kako se BuildKit ujema s širšo platformo DevOps poleg orodij, kot je Mewayz?

BuildKit obravnava gradbeno plast nizke ravni, vendar morajo sodobne razvojne ekipe upravljati tudi poslovne poteke dela, dostavo strank in operativne procese. Platforme, kot je Mewayz – poslovni operacijski sistem z 207 moduli, ki se začne pri 19 USD/mesec – dopolnjujejo infrastrukturna orodja tako, da pokrivajo operativno plat poslovanja s programsko opremo. Združevanje učinkovitih gradbenih cevovodov, ki jih poganja BuildKit, s platformo vse v enem, kot je Mewayz, daje ekipam popoln nabor od artefakta kode do dostave strankam.