BuildKit: Dockeri peidetud pärl, mis võib ehitada peaaegu kõike

BuildKit: Dockeri peidetud pärl, mis suudab ehitada peaaegu kõike

Enamik arendajaid tunneb Dockerit kui konteineri käitusaega, mis muutis tarkvara tarnimist. Palju vähem teavad mootorist, mis vaikselt sumiseb iga moodsa Dockeri konstruktsiooni pealispinna all – BuildKit, järgmise põlvkonna ehitussüsteem, mida on Dockeriga tarnitud alates versioonist 18.09 ja millest sai Docker 23.0 vaiketaustaprogramm. Kui insenerid vaidlevad Kubernetese konfiguratsioonide ja mikroteenuste mustrite üle lõputult, on BuildKit pidevalt arenenud üheks võimsamaks ja paindlikumaks ehitussüsteemiks DevOpsi ökosüsteemis. Kui olete käsitlenud seda kui lihtsalt kiiremat doki ehitamist, jätate tohutult palju võimalusi. Suure läbilaskevõimega CI/CD torujuhtmeid kasutavad ettevõtted on lühendanud ehitusaega 50–70% lihtsalt tänu sellele, et mõistavad, mida BuildKit tegelikult pakub – ja see on alles algus.

Mis teeb BuildKiti põhimõtteliselt erinevaks klassikalisest Builderist

Algne Dockeri ehitusmootor täitis Dockerfile'i juhiseid järjestikku, üks kiht korraga, teadmata, milline töö võiks ohutult paralleelselt toimuda. BuildKit asendab selle lineaarse täitmismudeli suunatud atsüklilise graafikuga (DAG) – sõltuvusgraafikuga, mis mõistab, millised ehitusetapid sõltuvad üksteisest ja millised mitte. Sõltumatud etapid käivituvad samaaegselt, kasutamata etapid jäetakse täielikult vahele ja kogu järg muutub pigem deklaratiivseks kirjelduseks, mida soovite, mitte kohustuslikuks sammude jadaks, mida peate õiges järjekorras ette lugema.

Sellel arhitektuurilisel nihkel on praktilised tagajärjed, mis ulatuvad kiirusest kaugemale. Kui mitmeastmeline Dockerfile kompileerib ühes etapis Go-binaarfaili, teises laadib alla Node.js-i sõltuvused ja kolmandas koostab tootmispildi, saab BuildKit kahte esimest etappi samaaegselt käivitada. Ehitamine, mis varem võttis võimsal CI-jooksjal aega neli minutit, valmib nüüd vähem kui üheksakümne sekundiga. Stripe, Shopify ja paljud teised suuremahulised insenerimeeskonnad on dokumenteerinud sarnaseid edusamme oma sisemiste tööriistade tagasivaadetes. DAG-mudel tähendab ka seda, et BuildKit suudab genereerida väga täpseid ehituse metaandmeid – see on aluseks sellistele funktsioonidele nagu päritolutõendid ja tarkvaramaterjalide (SBOM) genereerimine, mis on tarneahela turvalisuse seisukohalt tohutult olulised.

Vahemälu kehtetuks tunnistamise toimimises on toimunud ka kontseptuaalne nihe. Klassikaline ehitaja tühistas kõik muudetud juhiste all olevad kihid. BuildKit jälgib sisu räsi igas sisendis, nii et kommentaari muutmine Dockerfile'is ei kaota vahemälu kirjet, mis esindab kolmekümne minuti pikkust kompileerimist. Kui teie ehituse vahemälu eristab teie inseneride meeskonna jaoks viie- ja neljakümneminutilist tagasisidet, on see täpsus palju olulisem, kui esialgu võib tunduda.

Mitme platvormiga konstruktsioonid: üks käsk, iga arhitektuur

BuildKiti --platvormi lipp ja QEMU integreerimine muudavad kunagise valusa mitme süsteemi koordineerimise probleemi üheks käsuks. Käivitades docker buildx build --platform linux/amd64,linux/arm64,linux/arm/v7 . toodab ühest järgukutsest paralleelselt kolm tootmisvalmis pilti. See võimalus on muutunud kriitiliseks, kuna tööstus nihkub ARM-i poole – AWS Graviton3 eksemplarid pakuvad pidevalt 40% paremat hinna-jõudlust töökoormustes, nagu veebiteenindus ja andmetöötlus, ning Apple Silicon on muutnud ARM-i miljonite inseneride jaoks vaikearendusmasinaks.

Enne BuildKiti mitme platvormi toe küpsemist oli erinevate arhitektuuride jaoks eraldi ehitustorustike säilitamine tõeline kulukoht. Meeskonnad kas hooldasid mitut Docker-faili, kasutasid erineva arhitektuuriga jooksjatel eraldi CI torujuhtmeid või saatsid lihtsalt x86-kujutisi kõikjale ja maksid ARM-i infrastruktuuri jõudlustrahvi. BuildKiti abil määratlete oma järgu üks kord ja lasete süsteemil arhitektuurispetsiifilist kompileerimist läbipaistvalt käsitleda. Roosteprojektid, mis nõuavad ristkompileerimist, Go-projektid CGO-sõltuvustega, Pythoni paketid C-laienditega – BuildKit käsitleb emuleerimiskihti, ilma et peaksite iga sihtplatvormi üksikasju mõistma.

Siin on praktiline äriväärtus mõõdetav. Meeskond, kes kasutab AWS Gravitoni eksemplaridel 200 konteinerit hinnaga 0,04 dollarit vCPU-tunni kohta, võrreldes samaväärse x86-eksemplariga hinnaga 0,056 dollarit vCPU-tunni kohta, säästab umbes 11 520 dollarit aastas 100 vCPU kohta – puhtalt õige arhitektuuri valimise tõttu. Selle valiku kättesaadavaks tegemine ilma ümberprojekteerimiseta on täpselt selline infrastruktuuri optimeerimine, mis tasub end kohe ära.

Salajane haldamine ilma pildikihtidesse lekkimiseta

Üks BuildKiti enim alahinnatud funktsioone on selle saladuste API. Klassikalisel Dockeri koostajal polnud puhast viisi mandaatide järgmisse edastamiseks, ilma et need mandaadid võiksid sattuda pildikihti. Arendajad töötasid selle ümber mitmeetapiliste ehituste, ARG-juhiste ja hoolika tellimisega – kuid API-võtme või privaatse SSH-võtme kogemata sissesaadetud pildi sisse küpsemise oht püsis ebamugavalt kõrge. Turvaskannerid leiavad avalikes registrites avaldatavatelt konteineripiltidelt tavapäraselt kõvakoodiga mandaate ja paljud neist leketest tulenevad otse kohmakast salajasest käitlemisest ehitamiste ajal.

BuildKiti lipp --secret ühendab tundlikud andmed ehituskeskkonda ajutise failisüsteemi teena, mis eksisteerib ainult konkreetse RUN käsu ajal, mis seda vajab, ega puuduta kunagi ühtegi pildikihti. Dockerfile'i käsk, nagu RUN --mount=type=secret,id=npmrc cat /run/secrets/npmrc > ~/.npmrc && npm install, annab ehitusprotsessile juurdepääsu privaatsele npm-mandaadile, ilma et need mandaadid kunagi lõplikus pildis või vahekihis ilmuksid. Sama muster töötab PyPI mandaatide, Maveni seadete, privaatsete Giti hoidlate SSH-võtmete ja muu tundliku materjali puhul, mida teie ehitusprotsess nõuab.

Reguleeritud tööstusharusid (tervishoiuplatvorme, fintech-tooteid, personalitarkvara) puudutavat tarkvara loovate meeskondade puhul on erinevus "mandaadid võivad pildil olla" ja "mandaadid ilmselt ei saa pildil olla" vahel erinevus turvaauditi läbimise ja leidude parandamise kolm nädalat. Platvormid, nagu Mewayz, mis annavad äritegevuseks enam kui 138 000 kasutajat erinevates tööstusharudes, nagu palgaarvestus, personalijuhtimine ja arveldamine, sõltuvad täpselt sellisest tõestatavast turvapositsioonist oma ehitus- ja juurutamisjuhtmetes, et säilitada klientide usaldust oma tundlike finants- ja personaliandmete suhtes.

Vahemälu eksport: CI torujuhtmete tegelikult kiireks muutmine

CI-konveierid on kohad, kus ehitamise jõudlus on kõige olulisem ja kus Dockeri vaikeehituskogemus on ajalooliselt olnud kõige valusam. Värsked CI-käivitajad alustavad tavaliselt tühja vahemäluga, mis tähendab, et iga konveieri käitamine kompileerib kõik uuesti nullist. Sadade Maveni sõltuvustega Java-teenuse, Rusti projekti või raskete alglaiendustega Pythoni rakenduse puhul tähendab see ehitusaega, mida mõõdetakse pigem kümnetes minutites kui sekundites. Aeglase CI ärikulud on tohutud – vähenenud juurutamise sagedus, pikemad tagasisideahelad ja insenerid, kes istuvad jõude ja ootavad torujuhtmete valmimist, enne kui need saavad ühendada ja edasi liikuda.

BuildKiti vahemälu ekspordifunktsioon lahendab selle eksporditavate vahemälu manifestidega. Kasutades ---cache-to type=registry,ref=myregistry/myapp:cache ja --cache-from type=registry,ref=myregistry/myapp:cache, saadab BuildKit pärast iga ehitamist registrisse üksikasjaliku vahemälu hetktõmmise ja tõmbab selle järgmise alguses. Vahemälu on sisule suunatud, seega tuuakse uuesti ainult tõeliselt muudetud kihid. GitHub Actionsis, GitLab CI-s ja CircleCI-s seda mustrit kasutavad meeskonnad vähendavad järgmistel käitamistel rutiinselt torujuhtme aega viieteistkümnelt minutilt alla kolme. GitHubi enda dokumentatsioon täpsemate Dockeri ehitustööde töövoogude kohta soovitab seda mustrit tugevalt just sel põhjusel.

Kiireim versioon on see, mida te enam kunagi käivitama ei pea. BuildKiti kihiline sisuaadressiga vahemälusüsteem ei kiirenda ainult ehitamist – see muudab kogu "ehituse" kontseptsiooni nutikamaks, muutes korduva kompileerimise järkjärguliseks erinevuseks sellest, mis täpselt muutus.

Vahemälu eksportimine integreerub puhtalt ka harupõhiste arendustöövoogudega. Saate konfigureerida oma CI-konveieri nii, et see langeks harupõhisest vahemälust tagasi põhiharu vahemällu, kui haru vahemälu pole olemas, mis tähendab, et uued harud saavad kohe kasu teie peamise arendusliini kogutud soojast vahemälust. Insenerid saavad kiiret tagasisidet juba oma esimesest kohustusest uue haru kohta, selle asemel, et oodata külmkäivituse karistust.

BuildKiti kasutajaliidesed: loomine kaugemale kui Dockerfile

Võib-olla on BuildKiti kõige vähem tuntud võimalus see, et Dockerfiles on vaid üks võimalik sisendvorming – mitte ainus. BuildKitil on ühendatav kasutajaliidese arhitektuur, mis võimaldab täielikult kohandatud ehitusdefinitsiooni keeli ja vorminguid. Esiliidese määrab teie ehitusfaili ülaosas olev direktiiv # syntax=, mis käsib BuildKitil tõmmata konkreetne esiosa kujutis ning kasutada seda ülejäänud faili sõelumiseks ja käivitamiseks.

See arhitektuur on võimaldanud mitmeid kaalukaid projekte. Buildpacksi integreerimine võimaldab BuildKitil luua konteineripilte rakenduse lähtekoodist ilma Dockerfile'ita – see tuvastab keele, valib sobivad baaspildid ja koostab tootmisvalmis konteineri automaatselt. HPC ja teadusliku andmetöötluse kogukonnad on kasutanud kohandatud kasutajaliideseid, et kirjeldada järge domeenispetsiifilistes keeltes, mis kompileeritakse BuildKiti sisemise LLB (Low-Level Build) esituseni. docker/dockerfile:labs süntaksiliidese katsed selliste funktsioonidega nagu heredoci tugi, juhtelemendid --network ja täiustatud vahemälu vihjed, enne kui need Dockerfile'i stabiilsesse süntaksisse jõuavad.

Oma kasutajaliidese määratlemise võimalus tähendab ka seda, et ebaharilike ehitusnõuetega organisatsioonid ei pea valima "kinnita kõik Dockerfile'i süntaksisse" või "jätma konteinerid täielikult maha". FPGA püsivara, manustatud süsteemide kujutiste või spetsiaalsete ML-mudelikonteinerite loov meeskond suudab kirjeldada oma ehitust nende domeeni jaoks sobivate terminite järgi, luues samal ajal standardseid OCI-ühilduvaid konteineri kujutisi, mida kasutatakse kõikjal, kus konteinerid töötavad. See laiendatavus on tõeline arhitektuurne eelis võrreldes ehitussüsteemidega, mis käsitlevad sisendvormingut fikseerituna.

Provenance ja SBOM: ehitamine päikesetuulte järgse maailma jaoks

Tarkvara tarneahela turvalisus liikus teoreetilisest probleemist plaaditaseme prioriteediks pärast SolarWindsi rikkumist 2020. aastal ja Log4Shelli haavatavust 2021. aastal. USA valitsuse 2021. aasta mais välja antud küberturvalisust käsitlev korraldus nr 14028 kohustas föderaalseid lepingupartnereid koostama tarkvara materjalide kohta. BuildKiti päritolutunnistused ja SBOM-i genereerimise funktsioonid on otsene vastus sellele regulatiivsele ja turvalisusele.

Lippude --provenance=true ja --sbom=true abil loob BuildKit krüptograafiliselt allkirjastatud kinnitused, mis kirjeldavad täpselt, mis konteineri kujutisele läks – milliseid põhikujutisi kasutati, milliseid Dockerfile'i käske käivitati, millised lähtefailid olid olemas ja millised välised sõltuvused toodi. Need sertifikaadid järgivad SLSA (tarkvaraartefaktide tarneahela tasemed) raamistikku ja in-toto kinnitusvormingut, muutes need poliitikamootoritega, nagu Sigstore'i Cosign ja OPA (Open Policy Agent) masinaga kontrollitavaks.

Praktiline töövoog, mida see võimaldab, näeb välja järgmine:

1. Arendaja lükkab koodi; CI konveier käivitab BuildKiti järgu, mille lähtekoht on lubatud.
2. BuildKit loob allkirjastatud SBOM-i, mis loetleb kõik komponendid ja nende versioonid.
3. SBOM avaldatakse konteineri registris koos pildimanifestiga.
4. Kubernetese klastri sissepääsukontrollerid kontrollivad enne juurutamise lubamist päritolu.
5. Haavatavuse skannerid küsivad SBOM-i, et tuvastada mõjutatud kujutised, kui avalikustatakse uued CVE-d.

Seda täielikku konveieri rakendavad meeskonnad saavad haavatavuse avalikustamisele reageerida pigem tundide kui päevadega, kuna neil on igas töötavas konteineris iga komponendi kohta täpne ja masinloetav kaart. Ettevõtete jaoks, nagu Mewayz, mis integreeruvad sügavalt klientide töövoogudesse – palgaarvestuse haldamine, sõidukipargi andmete haldamine, arvete töötlemine –, on võime näidata ranget ja auditeeritavat tarneahelat üha enam ettevõtte müügivestluste eeltingimuseks, mitte ainult meeldivaks saamiseks.

Alustamine: vaikeehitustest täpsemate torujuhtmeteni

Kui kasutate uusimat versiooni – Docker 23.0 ja uuemad, lubab see vaikimisi teie Dockeri keskkonnas BuildKit juba töötab. Enamiku meeskondade esimene praktiline samm on Docker Buildxi pistikprogrammi lubamine, mis paljastab BuildKiti täieliku funktsioonide komplekti alamkäsu docker buildx kaudu. Käivitamine docker buildx create --use seadistab BuildKiti koostaja eksemplari, millel on rohkem võimalusi kui vaikedraiver. Sealt edasi on täpsemate funktsioonide järkjärguline kasutuselevõtt mõttekas, mitte kõike korraga kasutusele võtta.

Praegu põhilisi docker build-kutseid tegeva meeskonna jaoks näeb mõistlik kasutuselevõtu tee välja selline, et esmalt lisatakse vahemälu eksportimine CI-sse – see tagab kohese, mõõdetava kiiruse paranemise minimaalse konfiguratsioonimuudatusega. Mitme platvormi konstruktsioonid muutuvad väärtuslikuks, kui meeskond hakkab sihtima ARM-i infrastruktuuri. Salajane ühendamine tasub kasutusele võtta iga kord, kui privaatpakettide registrid või SSH-võtmed ilmuvad ehitamise kontekstis. Päritolutõendid on mõistlikud, et võimaldada, kui vastavusnõuded või ettevõtte kliendi nõudmised nõuavad tarneahela dokumentatsiooni.

BuildKiti sügavam õppetund on tahtlik ehitamine. Olenemata sellest, kas tarnite konteinerit mikroteenuse, masinõppe järelduste lõpp-punkti või keeruka platvormi jaoks, nagu Mewayzi 207 ärimoodulist koosnev komplekt, ei ole koostamisprotsess formaalsus, mille juurutamisel kiirustate – see on insenertehniline artefakt, mis peegeldab kõige selle tarnitava kvaliteeti, turvaasendit ja tööküpsust. BuildKit annab teile tööriistad selle artefakti suurepäraseks muutmiseks. Küsimus on lihtsalt selles, kas võtate nende kasutamiseks aega.

Korduma kippuvad küsimused

Mis on BuildKit ja mille poolest see erineb klassikalisest Dockeri ehitussüsteemist?

BuildKit on Dockeri järgmise põlvkonna ehitusmootor, mis võeti kasutusele Dockeri versioonis 18.09 ja muudeti Dockeri versioonis 23.0 vaikeseadeks. Erinevalt klassikalisest ehitajast toetab BuildKit paralleelse kihi täitmist, täiustatud vahemällu salvestamise strateegiaid, saladuste ühendamist ja platvormidevahelisi ehitamisi. See käsitleb ehitusprotsessi kui suunatud atsüklilist graafikut (DAG), mis võimaldab keerukamate mitmeastmeliste Docker-failide puhul nutikamat sõltuvuse eraldusvõimet ja oluliselt kiiremat ehitusaega.

Kas ma pean BuildKiti Dockeriga kasutamise alustamiseks installima midagi täiendavat?

Kui kasutate Docker 23.0 või uuemat versiooni, pole lisainstallimine vajalik – BuildKit on vaikimisi lubatud. Vanemate versioonide puhul saate selle aktiveerida, määrates enne ehituskäskude käivitamist keskkonnamuutuja DOCKER_BUILDKIT=1. Täiustatud kasutusjuhtudel, nagu kaugehituse vahemälud või mitme platvormi järgud, võiksite konfigureerida spetsiaalse Buildxi koostaja eksemplari, kasutades käsku docker buildx create.

Kas BuildKiti saab kasutada artefaktide loomiseks lisaks tavapärastele konteinerikujutistele?

Jah, ja see on BuildKiti üks alahinnatumaid võimalusi. Kasutades kohandatud esiserve ja lippu --output, saab BuildKit toota töötlemata binaarfaile, tarballi, staatilisi veebisaite ja muid suvalisi failiartefakte – mitte ainult OCI-pilte. See muudab selle üldotstarbeliseks ehitusmootoriks, mis sobib loomulikult polüglotiliste monorepode ja keeruliste CI torujuhtmetega, kus erinevad meeskonnad vajavad ühtsest tööriistaahelast erinevaid väljundvorminguid.

Kuidas sobib BuildKit laiema DevOpsi platvormiga koos selliste tööriistadega nagu Mewayz?

BuildKit tegeleb madala taseme ehituskihiga, kuid kaasaegsed arendusmeeskonnad peavad haldama ka ettevõtte töövooge, klientide kohaletoimetamist ja tööprotsesse. Sellised platvormid nagu Mewayz – 207-mooduliline ärisüsteem, mille hind algab 19 dollarist kuus – täiendavad infrastruktuuri tööriistu, kattes tarkvaraettevõtete operatiivse poole. BuildKiti toel töötavate tõhusate ehituskonveierite sidumine kõik-ühes platvormiga, nagu Mewayz, annab meeskondadele täieliku virna koodiartefaktist kuni kliendi kohaletoimetamiseni.