„BuildKit“: „Docker“ paslėptas brangakmenis, galintis sukurti beveik bet ką

BuildKit: paslėptas Docker brangakmenis, galintis sukurti beveik bet ką

Dauguma kūrėjų žino, kad „Docker“ yra konteinerio vykdymo laikas, kuris pakeitė programinės įrangos pristatymo būdą. Daug mažiau žino apie variklį, tyliai dūzgiantį po kiekvienos šiuolaikinės „Docker“ versijos paviršiumi – „BuildKit“, naujos kartos kūrimo sistemą, kuri buvo pristatoma kartu su „Docker“ nuo 18.09 versijos ir tapo numatytuoju „Docker 23.0“ pagrindu. Nors inžinieriai be galo ginčijasi dėl „Kubernetes“ konfigūracijų ir mikro paslaugų modelių, „BuildKit“ nuolat vystosi į vieną galingiausių ir lanksčiausių „DevOps“ ekosistemos kūrimo sistemų. Jei laikėte jį tik greitesniu dokerio kūrimu, paliksite milžiniškas galimybes. Įmonės, naudojančios didelio našumo CI / CD vamzdynus, sutrumpino kūrimo laiką 50–70 %, tiesiog suprasdamos, ką iš tikrųjų siūlo „BuildKit“ – ir tai tik pradžia.

Kuo „BuildKit“ iš esmės skiriasi nuo klasikinės „Builder“

Pradinis „Docker“ kūrimo variklis vykdė „Dockerfile“ instrukcijas nuosekliai, po vieną sluoksnį, nesuvokdamas, koks darbas gali būti saugiai atliekamas lygiagrečiai. „BuildKit“ pakeičia tą tiesinį vykdymo modelį nukreiptu acikliniu grafiku (DAG) – priklausomybės grafiku, kuris supranta, kurie kūrimo žingsniai priklauso vienas nuo kito, o kurie ne. Nepriklausomi etapai vykdomi vienu metu, nepanaudoti etapai visiškai praleidžiami, o visa konstrukcija tampa deklaratyviu to, ko norite, aprašymu, o ne privaloma veiksmų seka, kurią turite pakartoti tinkama tvarka.

Šis architektūrinis pokytis turi praktinių pasekmių, kurios viršija greitį. Kai kelių etapų „Dockerfile“ viename etape sukompiliuoja „Go“ dvejetainį failą, kitame atsisiunčia „Node.js“ priklausomybes, o trečiame surenka gamybinį vaizdą, „BuildKit“ gali vykdyti pirmuosius du etapus vienu metu. Konstravimas, kuris anksčiau užtrukdavo keturias minutes naudojant galingą CI bėgiką, dabar baigiamas per mažiau nei devyniasdešimt sekundžių. „Stripe“, „Shopify“ ir daugybė kitų didelio masto inžinierių komandų panašų pelną užfiksavo savo vidaus įrankių retrospektyvose. DAG modelis taip pat reiškia, kad „BuildKit“ gali generuoti labai tikslius kūrimo metaduomenis – pagrindą funkcijoms, tokioms kaip kilmės patvirtinimai ir programinės įrangos medžiagų sąskaitų generavimas (SBOM), kurios yra labai svarbios tiekimo grandinės saugumui.

Taip pat pasikeitė talpyklos negaliojimo veikimo principas. Klasikinis kūrėjas panaikino kiekvieną sluoksnį po bet kokia pakeista instrukcija. „BuildKit“ seka turinio maišą prie kiekvienos įvesties, todėl pakeitus komentarą „Dockerfile“ faile neišnyksta talpyklos įrašas, atitinkantis trisdešimties kompiliavimo minučių. Kai jūsų kūrimo talpykla yra skirtumas tarp penkių minučių ir keturiasdešimties minučių grįžtamojo ryšio jūsų inžinierių komandai, šis tikslumas yra daug svarbesnis, nei gali atrodyti iš pradžių.

Kelių platformų versijos: viena komanda, kiekviena architektūra

BuildKit vėliavėlė --platform ir QEMU integracija paverčia kažkada skausmingą kelių sistemų koordinavimo problemą į vieną komandą. Vykdant docker buildx build --platform linux/amd64,linux/arm64,linux/arm/v7 . iš vienos versijos iškvietimo lygiagrečiai sukuriami trys gamybai paruošti vaizdai. Ši galimybė tapo labai svarbi pramonei pereinant prie ARM – AWS Graviton3 egzemplioriai nuolat užtikrina 40 % geresnį kainos ir kokybės santykį atliekant tokius darbo krūvius kaip žiniatinklio aptarnavimas ir duomenų apdorojimas, o „Apple Silicon“ padarė ARM numatytuoju milijonų inžinierių kūrimo įrenginiu.

Prieš subrendus „BuildKit“ kelių platformų palaikymui, atskirų skirtingų architektūrų kūrimo vamzdynų palaikymas buvo tikras išlaidų centras. Komandos arba prižiūrėjo kelis „Dockerfiles“, naudojo atskirus CI vamzdynus skirtingos architektūros bėgikams arba tiesiog visur siuntė x86 vaizdus ir sumokėjo baudą už ARM infrastruktūrą. Naudodami „BuildKit“ vieną kartą apibrėžiate savo versiją ir leidžiate sistemai skaidriai tvarkyti konkrečios architektūros kompiliavimą. „Rust“ projektai, kuriems reikalingas kryžminis kompiliavimas, „Go“ projektai su CGO priklausomybėmis, „Python“ paketai su C plėtiniais – „BuildKit“ tvarko emuliacijos sluoksnį, nereikalaujant, kad jūs suprastumėte kiekvienos tikslinės platformos detales.

Praktinė verslo vertė čia yra išmatuojama. Komanda, naudojanti 200 konteinerių AWS Graviton egzemplioriuose už 0,04 USD už vCPU valandą, palyginti su lygiaverčiu x86 egzemplioriumi už 0,056 USD už vCPU valandą, kasmet sutaupo maždaug 11 520 USD už 100 vCPU – vien dėl tinkamos architektūros pasirinkimo. Padaryti šį pasirinkimą prieinamą be pertvarkymo pastangų yra būtent toks infrastruktūros optimizavimas, kuris iš karto atsiperka.

Slaptas valdymas nepatenkant į vaizdo sluoksnius

Viena iš labiausiai neįvertintų „BuildKit“ funkcijų yra jos paslapčių API. Klasikinis „Docker“ kūrėjas neturėjo aiškaus būdo perduoti kredencialus į kūrimą, kai tie kredencialai galėjo patekti į vaizdo sluoksnį. Kūrėjai tai išsprendė su kelių etapų kūrimu, ARG instrukcijomis ir kruopščiu užsakymu, tačiau rizika, kad API raktas ar privatus SSH raktas bus netyčia įterptas į išsiųstą vaizdą, išliko nepatogiai didelė. Apsaugos skaitytuvai reguliariai randa užkoduotus kredencialus konteinerių vaizduose, paskelbtuose viešuosiuose registruose, o daugelis tų nutekėjimų tiesiogiai siejami su nerangiu slaptu tvarkymu kūrimo metu.

BuildKit vėliavėlė --secret įtraukia neskelbtinus duomenis į kūrimo aplinką kaip laikiną failų sistemos kelią, kuris egzistuoja tik tam tikros RUN komandos, kuriai jos reikia, ir niekada nepaliečia jokio vaizdo sluoksnio. „Dockerfile“ instrukcija, pvz., RUN --mount=type=secret,id=npmrc cat /run/secrets/npmrc > ~/.npmrc && npm install, kūrimo procesui suteikia prieigą prie privačių npm kredencialų, tų kredencialų niekada nepasirodžius galutiniame vaizde ar bet kuriame tarpiniame sluoksnyje. Tas pats modelis veikia naudojant PyPI kredencialus, „Maven“ nustatymus, privačių „Git“ saugyklų SSH raktus ir bet kokią kitą jautrią medžiagą, kurios reikia jūsų kūrimo procesui.

Komandos, kuriančios programinę įrangą, liečiančią reguliuojamas pramonės šakas – sveikatos priežiūros platformas, „fintech“ produktus, žmogiškųjų išteklių programinę įrangą – skirtumas tarp „kredencialų gali būti vaizde“ ir „kredencialų tikriausiai negali būti vaizde“ yra skirtumas tarp saugos audito atlikimo ir trijų savaičių ištaisymo. Tokios platformos kaip „Mewayz“, kurios teikia verslo operacijas daugiau nei 138 000 naudotojų įvairiose pramonės šakose, pvz., darbo užmokesčio, personalo ir sąskaitų faktūrų išrašymo srityse, priklauso būtent nuo tokios įrodomos saugos pozicijos kūrimo ir diegimo vamzdynuose, kad išlaikytų klientų pasitikėjimą savo jautriais finansiniais ir personalo duomenimis.

Talpyklos eksportavimas: CI vamzdynų iš tikrųjų greitas

CI konvejeriai yra ta vieta, kur kūrimo našumas yra svarbiausias ir kur numatytoji „Docker“ kūrimo patirtis istoriškai buvo skausmingiausia. Nauji CI paleidikliai paprastai pradeda nuo tuščių talpyklų, o tai reiškia, kad kiekvienas dujotiekio paleidimas viską sukompiliuoja nuo nulio. „Java“ paslaugai su šimtais „Maven“ priklausomybių, „Rust“ projektui arba „Python“ programai su sunkiais vietiniais plėtiniais tai reiškia, kad kūrimo laikas matuojamas dešimtimis minučių, o ne sekundėmis. Lėtos CI verslo sąnaudos yra milžiniškos – sumažintas diegimo dažnis, ilgesnės grįžtamojo ryšio linijos ir inžinieriai, sėdintys nedirbantys ir laukiantys, kol bus baigti vamzdynai, kad galėtų sujungti ir judėti toliau.

„BuildKit“ talpyklos eksportavimo funkcija tai išsprendžia naudojant eksportuojamus talpyklos aprašus. Naudodama ---cache-to type=registry,ref=myregistry/myapp:cache ir --cache-from type=registry,ref=myregistry/myapp:cache, „BuildKit“ nusiunčia išsamią talpyklos momentinę kopiją registrui po kiekvieno kūrimo ir ištraukia ją kitos versijos pradžioje. Talpykla yra skirta turiniui, todėl iš naujo gaunami tik iš tikrųjų pakeisti sluoksniai. Komandos, naudojančios šį šabloną „GitHub Actions“, „GitLab CI“ ir „CircleCI“, sekančiose operacijose reguliariai sutrumpina dujotiekio laiką nuo penkiolikos minučių iki mažiau nei trijų. „GitHub“ dokumentacijoje apie išplėstines „Docker“ kūrimo darbo eigas šis modelis labai rekomenduojamas būtent dėl šios priežasties.

Greičiausias kūrimas yra tas, kurio jums niekada nebereikės paleisti. „BuildKit“ daugiasluoksnė, į turinį nukreipta talpyklos sistema ne tik pagreitina kūrimą – ji daro visą „kūrimo“ koncepciją išmanesnę, kartojamą kompiliaciją paversdama laipsnišku skirtumu to, kas pasikeitė.

Talpyklos eksportavimas taip pat puikiai integruojamas su šakomis pagrįstomis kūrimo darbo eigomis. Galite sukonfigūruoti savo CI konfigūraciją, kad iš konkrečios šakos talpyklos pereitų į pagrindinę šakos talpyklą, kai šakos talpyklos nėra, o tai reiškia, kad nauji atšakai iš karto gauna naudos iš pagrindinės kūrimo linijos sukauptos šiltos talpyklos. Inžinieriai gauna greitą grįžtamąjį ryšį nuo pat pirmojo įsipareigojimo naujoje šakoje, o ne laukti nuobaudos už šaltą startą.

BuildKit sąsajos: kūrimas ne tik Dockerfiles

Turbūt mažiausiai žinoma BuildKit galimybė yra ta, kad Dockerfiles yra tik vienas galimas įvesties formatas – ne vienintelis. „BuildKit“ turi prijungiamą sąsajos architektūrą, leidžiančią visiškai pasirinktines kūrimo apibrėžimo kalbas ir formatus. Frontend nurodoma direktyva # syntax= jūsų kūrimo failo viršuje, kuri nurodo „BuildKit“ ištraukti tam tikrą sąsajos vaizdą ir naudoti jį analizuoti bei vykdyti likusią failo dalį.

Ši architektūra įgalino keletą patrauklių projektų. „Buildpacks“ integracija leidžia „BuildKit“ kurti konteinerio vaizdus iš programos šaltinio kodo be jokio „Dockerfile“ – aptinka kalbą, parenka tinkamus bazinius vaizdus ir automatiškai surenka gamybai paruoštą konteinerį. HPC ir mokslinio skaičiavimo bendruomenės naudojo pasirinktines sąsajas, kad apibūdintų konkrečias domeno kalbas, kurios sudaromos iki vidinio BuildKit LLB (žemo lygio kūrimo) atvaizdavimo. docker/dockerfile:labs sintaksės sąsaja eksperimentuoja su tokiomis funkcijomis kaip heredoc palaikymas, --network valdymas pagal instrukcijas ir patobulintos talpyklos užuominos, kol jos patenka į stabilią Dockerfile sintaksę.

Galimybė apibrėžti savo sąsają taip pat reiškia, kad organizacijoms, kurioms taikomi neįprasti kūrimo reikalavimai, nereikia rinktis tarp „viską perkelti į Dockerfile sintaksę“ arba „visiškai atsisakyti konteinerių“. Komanda, kurianti FPGA programinę-aparatinę įrangą, įterptųjų sistemų vaizdus arba specializuotus ML modelio konteinerius, gali apibūdinti savo kūrimą tokiais terminais, kurie yra tinkami jų domenui, tačiau vis tiek gamina standartinius su OCI suderinamus konteinerių vaizdus, ​​​​kurie naudojami visur, kur veikia konteineriai. Šis išplečiamumas yra tikras architektūrinis pranašumas, palyginti su kūrimo sistemomis, kuriose įvesties formatas laikomas fiksuotu.

Provenance ir SBOM: kūrimas pasauliui po saulės vėjų

Po SolarWinds pažeidimo 2020 m. ir Log4Shell pažeidžiamumo 2021 m. programinės įrangos tiekimo grandinės saugumas nuo teorinio susirūpinimo perėjo prie plokštės lygio. „BuildKit“ kilmės patvirtinimai ir SBOM generavimo funkcijos yra tiesioginis atsakas į šią reguliavimo ir saugumo aplinką.

Naudodama žymas --provenance=true ir --sbom=true, „BuildKit“ generuoja kriptografiškai pasirašytus patvirtinimus, kuriuose tiksliai aprašoma, kas pateko į sudėtinio rodinio vaizdą – kurie pagrindiniai vaizdai buvo naudojami, kurios „Dockerfile“ instrukcijos buvo vykdomos, kokie šaltinio failai buvo ir kokios išorinės priklausomybės buvo gautos. Šie patvirtinimai atitinka SLSA (Supply-chain Levels for Software Artefacts) sistemą ir in-toto patvirtinimo formatą, todėl juos galima automatiniu būdu patikrinti politikos varikliais, pvz., „Sigstore's Cosign“ ir OPA (Open Policy Agent).

Praktinė darbo eiga, kurią tai įgalina, atrodo taip:

1. Kūrėjas siunčia kodą; CI vamzdynas suaktyvina „BuildKit“ kūrimą su įjungta kilme.
2. BuildKit generuoja pasirašytą SBOM, kuriame pateikiami visi komponentai ir jų versijos.
3. SBOM paskelbiamas sudėtinio rodinio registre kartu su vaizdo aprašu.
4. Priėmimo valdikliai „Kubernetes“ klasteryje patikrina kilmę prieš leisdami diegti.
5. Pažeidžiamumo skaitytuvai pateikia užklausą SBOM, kad nustatytų paveiktus vaizdus, kai atskleidžiami nauji CVE.

Komandos, diegiančios šį visą procesą, gali reaguoti į pažeidžiamumo atskleidimą per valandas, o ne dienas, nes turi tikslų, mašininiu būdu nuskaitomą kiekvieno komponento žemėlapį kiekviename veikiančiame konteineryje. Tokioms įmonėms kaip „Mewayz“, kurios giliai integruojasi į klientų darbo eigą – atlyginimų apskaičiavimą, transporto parko duomenų tvarkymą, sąskaitų faktūrų apdorojimą – galimybė pademonstruoti tikslią, audituojamą tiekimo grandinę tampa vis labiau būtina sąlyga įmonės pokalbiams apie pardavimą, o ne tik malonus turėti.

Pradžia: nuo numatytųjų versijų iki išplėstinių vamzdynų

BuildKit jau veikia jūsų Docker aplinkoje, jei naudojate naujausią versiją – Docker 23.0 ir naujesnę versiją įgalinkite pagal numatytuosius nustatymus. Pirmasis praktiškas daugelio komandų žingsnis yra įgalinti „Docker Buildx“ papildinį, kuris atskleidžia visą „BuildKit“ funkcijų rinkinį per docker buildx antrinę komandą. Vykdant docker buildx create --use nustatomas BuildKit kūrimo priemonės egzempliorius, turintis daugiau galimybių nei numatytoji tvarkyklė. Iš čia prasminga laipsniškas išplėstinių funkcijų pritaikymas, o ne bandymas pritaikyti viską iš karto.

Pagrįstas priėmimo būdas komandai, šiuo metu atliekančiai pagrindines docker build iškvietes, atrodo, kad pirmiausia reikia pridėti talpyklos eksportavimą į CI – taip greitai ir išmatuojamomis spartos patobulinimais su minimaliais konfigūracijos pakeitimais. Kelių platformų versijos tampa vertingos, kai komanda pradeda taikyti ARM infrastruktūrą. Slaptą montavimą verta naudoti kiekvieną kartą, kai kūrimo kontekste atsiranda privatūs paketų registrai arba SSH raktai. Kilmės liudijimai yra prasmingi, kai dėl atitikties reikalavimų arba įmonės klientų reikalavimų reikia pateikti tiekimo grandinės dokumentus.

Gilesnė „BuildKit“ pamoka yra apie sąmoningą kūrimą. Nesvarbu, ar siunčiate konteinerį mikropaslaugai, mašininio mokymosi išvados galutiniam taškui ar sudėtingai platformai, tokiai kaip „Mewayz“ 207 verslo modulių rinkinys, kūrimo procesas nėra formalumas, kurį skubate diegti – tai inžinerinis artefaktas, atspindintis visko, kas išsiunčiama, kokybę, saugumą ir veikimo brandą. „BuildKit“ suteikia jums įrankių, kad šis artefaktas būtų puikus. Kyla klausimas, ar skiriate laiko jas naudoti.

Dažniausiai užduodami klausimai

Kas yra „BuildKit“ ir kuo jis skiriasi nuo klasikinės „Docker“ kūrimo sistemos?

BuildKit yra naujos kartos „Docker“ kūrimo variklis, pristatytas „Docker 18.09“ versijoje ir nustatytas kaip numatytasis „Docker 23.0“. Skirtingai nuo klasikinio kūrėjo, „BuildKit“ palaiko lygiagretųjį sluoksnių vykdymą, pažangias talpyklos strategijas, paslapčių diegimą ir kelių platformų kūrimą. Jis traktuoja kūrimo procesą kaip nukreiptą aciklinį grafiką (DAG), leidžiantį pažangesnę priklausomybės skyrą ir žymiai greitesnį sudėtingų kelių etapų Docker failų kūrimo laiką.

Ar man reikia įdiegti ką nors papildomai, kad pradėčiau naudoti „BuildKit“ su „Docker“?

Jei naudojate „Docker 23.0“ arba naujesnę versiją, papildomo diegimo nereikia – „BuildKit“ įjungta pagal numatytuosius nustatymus. Senesnėse versijose galite jį suaktyvinti nustatydami aplinkos kintamąjį DOCKER_BUILDKIT=1 prieš paleisdami kūrimo komandas. Išplėstinio naudojimo atvejais, pvz., nuotolinės kūrimo talpyklos arba kelių platformų versijos, galbūt norėsite sukonfigūruoti skirtą „Buildx“ kūrimo priemonės egzempliorių naudodami docker buildx create.

Ar galima naudoti „BuildKit“ kuriant artefaktus už standartinių sudėtinio rodinio vaizdų?

Taip, ir tai yra vienas iš labiausiai neįvertintų BuildKit galimybių. Naudodamas pasirinktines sąsajas ir žymą --output, „BuildKit“ gali sukurti neapdorotus dvejetainius failus, tarballus, statines svetaines ir kitus savavališkus failų artefaktus – ne tik OCI vaizdus. Dėl to jis yra bendrosios paskirties kūrimo variklis, kuris natūraliai tinka daugiažodžiams monoreposams ir sudėtingiems CI vamzdynams, kur skirtingoms komandoms reikia skirtingų išvesties formatų iš vieningos įrankių grandinės.

Kaip „BuildKit“ tinka platesnėje „DevOps“ platformoje kartu su įrankiais, pvz., „Mewayz“?

BuildKit tvarko žemo lygio kūrimo lygmenį, tačiau šiuolaikinės kūrimo komandos taip pat turi valdyti verslo darbo eigą, klientų pristatymą ir veiklos procesus. Tokios platformos kaip Mewayz – 207 modulių verslo OS nuo 19 USD/mėn. – papildo infrastruktūros įrankius, apimančius programinės įrangos verslo operatyvinę pusę. Sujungus efektyvius „BuildKit“ kūrimo vamzdynus su „viskas viename“ platforma, tokia kaip „Mewayz“, komandoms suteikiamas visas krūvas nuo kodo artefakto iki pristatymo klientams.