BuildKit: Dockerin piilotettu helmi, joka voi rakentaa melkein mitä tahansa

BuildKit: Dockerin piilotettu helmi, joka voi rakentaa melkein mitä tahansa

Useimmat kehittäjät tietävät Dockerin kontin ajonaikana, joka muutti ohjelmistojen toimitustapoja. Paljon harvemmat tietävät moottorista, joka humisee hiljaa jokaisen nykyaikaisen Docker-version pinnan alla – BuildKit, seuraavan sukupolven koontijärjestelmä, joka on toimitettu Dockerin kanssa versiosta 18.09 lähtien ja josta tuli Docker 23.0:n oletustaustaohjelma. Vaikka insinöörit kiistelevät loputtomasti Kubernetes-kokoonpanoista ja mikropalvelumalleista, BuildKit on kehittynyt tasaisesti yhdeksi DevOps-ekosysteemin tehokkaimmista ja joustavimmista rakennusjärjestelmistä. Jos olet pitänyt sitä vain nopeampana docker-versiona, jätät valtavan kyvyn pöydälle. Yritykset, jotka käyttävät suuritehoisia CI/CD-putkia, ovat lyhentäneet rakennusaikoja 50–70 % yksinkertaisesti ymmärtämällä, mitä BuildKit tarjoaa – ja se on vasta alkua.

Mikä tekee BuildKitistä pohjimmiltaan erilaisen kuin klassinen Builder

Alkuperäinen Docker-rakennusmoottori suoritti Dockerfile-käskyt peräkkäin, kerros kerrallaan, tietämättä, mitä työtä voisi turvallisesti tapahtua rinnakkain. BuildKit korvaa tämän lineaarisen suoritusmallin suunnatulla asyklisellä graafilla (DAG) – riippuvuuskaaviolla, joka ymmärtää, mitkä rakennusvaiheet riippuvat toisistaan ​​ja mitkä eivät. Riippumattomat vaiheet suoritetaan samanaikaisesti, käyttämättömät vaiheet ohitetaan kokonaan, ja koko koontiversiosta tulee ilmoittava kuvaus siitä, mitä haluat, eikä pakollinen vaihesarja, joka sinun on toistettava oikeassa järjestyksessä.

Tällä arkkitehtonisella muutoksella on käytännön seurauksia, jotka ylittävät nopeuden. Kun monivaiheinen Docker-tiedosto kääntää Go-binaarin yhdessä vaiheessa, lataa Node.js-riippuvuudet toisessa ja kokoaa tuotantokuvan kolmannessa, BuildKit voi suorittaa kaksi ensimmäistä vaihetta samanaikaisesti. Rakennus, joka aiemmin kesti neljä minuuttia tehokkaalla CI-juoksilla, valmistuu nyt alle 90 sekunnissa. Stripe, Shopify ja monet muut korkean mittakaavan suunnittelutiimit ovat dokumentoineet samanlaisia ​​​​hyötyjä sisäisissä työkaluissaan. DAG-malli tarkoittaa myös sitä, että BuildKit voi luoda erittäin tarkkoja koontitietojen metatietoja – perustan ominaisuuksille, kuten alkuperätodistuksille ja ohjelmistoluetteloiden (SBOM) luomiselle, joilla on valtava merkitys toimitusketjun turvallisuuden kannalta.

Välimuistin mitätöinnin toiminnassa on myös käsitteellinen muutos. Klassinen rakentaja mitätöi jokaisen muutetun ohjeen alla olevan kerroksen. BuildKit seuraa sisällön hajautusarvoja jokaisessa syötteessä, joten kommentin muuttaminen Docker-tiedostossa ei räjäytä välimuistin merkintää, joka edustaa 30 minuutin kokoamista. Kun koontivälimuisti on ero viiden minuutin ja 40 minuutin palautesilmukan välillä insinööritiimillesi, tällä tarkkuudella on paljon enemmän merkitystä kuin aluksi saattaa näyttää.

Monikäyttöiset versiot: yksi komento, jokainen arkkitehtuuri

BuildKitin --platform-lippu ja QEMU-integrointi muuttavat entisen kipeän usean järjestelmän koordinointiongelman yhdeksi komennon. Ajo docker buildx build --platform linux/amd64,linux/arm64,linux/arm/v7 . tuottaa kolme tuotantovalmis kuvaa rinnakkain yhdestä koontiversiosta. Tästä ominaisuudesta on tullut kriittinen alan siirtyessä kohti ARM:a – AWS Graviton3 -esiintymät tarjoavat jatkuvasti 40 % paremman hinta-suorituskyvyn sellaisissa työkuormissa kuin verkkopalveluissa ja tietojenkäsittelyssä, ja Apple Silicon on tehnyt ARM:sta miljoonien insinöörien oletuskehityskoneen.

Ennen kuin BuildKitin usean alustan tuki kypsyi, erillisten rakennusputkien ylläpito eri arkkitehtuureille oli todellinen kustannuspaikka. Tiimit joko ylläpisivät useita Docker-tiedostoja, käyttivät erillisiä CI-putkistoja eri arkkitehtuurin juoksujärjestelmissä tai yksinkertaisesti toimittivat x86-kuvia kaikkialle ja maksoivat ARM-infrastruktuurin suorituskykysakon. BuildKitin avulla määrität koontiversiosi kerran ja annat järjestelmän käsitellä arkkitehtuurikohtaista käännöstä avoimesti. Ristikääntämistä vaativat ruosteprojektit, CGO-riippuvuuksia sisältävät Go-projektit, C-laajennuksella varustetut Python-paketit – BuildKit käsittelee emulointikerroksen ilman, että sinun tarvitsee ymmärtää kunkin kohdealustan yksityiskohtia.

Käytännön liiketoiminnan arvo on tässä mitattavissa. Tiimi, joka käyttää 200 konttia AWS Graviton -esiintymissä hintaan 0,04 dollaria vCPU-tuntia kohti verrattuna vastaavaan x86-ilmentymään 0,056 dollaria vCPU-tuntia kohti, säästää noin 11 520 dollaria vuodessa 100 vCPU:ta kohti – pelkästään oikean arkkitehtuurin valinnasta. Tämän valinnan tekeminen saataville ilman uudelleensuunnittelua on juuri sellaista infrastruktuurin optimointia, joka maksaa itsensä takaisin välittömästi.

Salainen hallinta ilman vuotoa kuvakerroksiin

Yksi BuildKitin aliarvostetuimmista ominaisuuksista on sen Secrets API. Klassisella Docker-rakennustyökalulla ei ollut puhdasta tapaa siirtää valtuustietoja koontiversioon ilman, että kyseiset tunnistetiedot mahdollisesti päätyisivät kuvakerrokseen. Kehittäjät kiertävät tämän monivaiheisilla koontiversioilla, ARG-ohjeilla ja huolellisella tilaamisella – mutta riski API-avaimen tai yksityisen SSH-avaimen vahingossa leipomisesta lähetettyyn kuvaan pysyi epämiellyttävänä korkeana. Suojausskannerit löytävät rutiininomaisesti kovakoodattuja valtuustietoja julkisiin rekistereihin julkaistuista säilökuvista, ja monet näistä vuodoista juontavat suoraan kömpelöön salaiseen käsittelyyn rakennusten aikana.

BuildKitin --secret-merkki liittää arkaluontoiset tiedot rakennusympäristöön väliaikaisena tiedostojärjestelmäpoluna, joka on olemassa vain sen tarvitsevan RUN-käskyn ajan, eikä se koskaan kosketa mitään kuvakerrosta. Dockerfile-käsky, kuten RUN --mount=type=secret,id=npmrc cat /run/secrets/npmrc > ~/.npmrc && npm install, antaa rakennusprosessille pääsyn yksityisiin npm-tunnistetietoihin ilman, että nämä tunnistetiedot näkyvät lopullisessa kuvassa tai missään välikerroksessa. Sama malli toimii PyPI-tunnistetiedoissa, Maven-asetuksissa, yksityisten Git-tietovarastojen SSH-avaimissa ja muussa arkaluontoisessa materiaalissa, jota rakennusprosessisi vaatii.

Tiimeille, jotka rakentavat ohjelmistoja, jotka koskevat säänneltyjä toimialoja – terveydenhuollon alustoja, fintech-tuotteita, HR-ohjelmistoja – ero "valtuustiedot saattavat olla kuvassa" ja "tunnistetiedot eivät välttämättä ole kuvassa" välillä on ero tietoturvatarkastuksen läpäisyn ja kolmen viikon ajan havaintojen korjaamisen välillä. Mewayzin kaltaiset alustat, jotka toimivat yli 138 000 käyttäjän liiketoiminnassa eri aloilla, kuten palkanlaskennassa, henkilöstöhallinnossa ja laskutuksessa, riippuvat juuri tällaisesta todistettavasta tietoturva-asennosta rakennus- ja käyttöönottoputkissaan, jotta asiakkaat voivat säilyttää luottamuksensa arkaluonteisiin talous- ja henkilöstötietoihinsa.

Välimuistin vienti: CI-putkien tekeminen todella nopeiksi

CI-putkien rakennussuorituskyky on tärkeintä ja Dockerin oletuskoontiversio on historiallisesti ollut tuskallisin. Tuoreet CI-ajot alkavat yleensä tyhjillä välimuistilla, mikä tarkoittaa, että jokainen liukuhihnaajo kääntää kaiken uudelleen alusta. Java-palvelussa, jossa on satoja Maven-riippuvuuksia, Rust-projektissa tai Python-sovelluksessa, jossa on raskaita alkuperäisiä laajennuksia, tämä tarkoittaa rakennusaikoja, jotka mitataan kymmenissä minuuteissa sekuntien sijaan. Hitaan CI:n liiketoimintakustannukset ovat valtavat – pienempi käyttöönottotiheys, pidemmät palautesilmukat ja insinöörit odottavat putkien valmistumista ennen kuin ne voivat yhdistää ja jatkaa.

BuildKitin välimuistin vientiominaisuus ratkaisee tämän vietävissä välimuistiluetteloissa. Käyttämällä --cache-to type=registry,ref=myregistry/myapp:cache- ja --cache-from type=registry,ref=myregistry/myapp:cache-komentoja BuildKit lähettää yksityiskohtaisen välimuistin tilannevedoksen rekisteriin jokaisen koonnon jälkeen ja vetää sen seuraavan koon alussa. Välimuisti on sisällölle osoitettu, joten vain aidosti muuttuneet tasot haetaan uudelleen. Tiimit, jotka käyttävät tätä mallia GitHub Actionsissa, GitLab CI:ssä ja CircleCI:ssä, lyhensivät rutiininomaisesti putkilinjan ajat viidestätoista minuutista alle kolmeen seuraavissa ajoissa. GitHubin oma dokumentaatio edistyneistä Docker-koontityönkuluista suosittelee voimakkaasti tätä mallia juuri tästä syystä.

Nopein koontiversio on se, jota sinun ei tarvitse suorittaa enää koskaan. BuildKitin kerroksittainen, sisältöön kohdistettu välimuistijärjestelmä ei vain nopeuta koontiversioita – se tekee koko "koonti"-konseptista älykkäämmän ja muuttaa toistuvan käännöksen asteittaiseksi erotukseksi siitä, mikä on muuttunut.

Välimuistin vienti integroituu myös selkeästi haarapohjaisiin kehitystyönkulkuihin. Voit määrittää CI-liukuhihnasi palaamaan haarakohtaisesta välimuistista päähaaran välimuistiin, kun haaravälimuistia ei ole, mikä tarkoittaa, että uudet haarat hyötyvät välittömästi pääkehityslinjasi keräämästä lämpimästä välimuistista. Insinöörit saavat nopeaa palautetta heti ensimmäisestä sitoutumisestaan uuteen haaraan sen sijaan, että he odottaisivat kylmäkäynnistysrangaistusta.

BuildKit-käyttöliittymät: rakentaminen Docker-tiedostojen lisäksi

Ehkä BuildKitin vähiten tunnettu ominaisuus on se, että Docker-tiedostot ovat vain yksi mahdollinen syöttömuoto – ei ainoa. BuildKitissä on liitettävä käyttöliittymä, joka mahdollistaa täysin mukautetut koontimäärityskielet ja -muodot. Käyttöliittymän määrittää koontitiedoston yläreunassa oleva # syntax=-käsky, joka käskee BuildKitiä hakemaan tietyn käyttöliittymän kuvan ja käyttämään sitä tiedoston muun osan jäsentämiseen ja suorittamiseen.

Tämä arkkitehtuuri on mahdollistanut useita kiinnostavia projekteja. BuildPacks-integroinnin avulla BuildKit voi rakentaa säilökuvia sovelluksen lähdekoodista ilman Docker-tiedostoa – se tunnistaa kielen, valitsee sopivat peruskuvat ja kokoaa tuotantovalmiuden säilön automaattisesti. HPC- ja tieteelliset laskentayhteisöt ovat käyttäneet mukautettuja käyttöliittymiä kuvaamaan koontiversioita toimialuekohtaisilla kielillä, jotka käännetään BuildKitin sisäiseen LLB-esitykseen (Low-Level Build). docker/dockerfile:labs-syntaksin käyttöliittymä kokeilee ominaisuuksia, kuten heredoc-tukea, --network-ohjausta käskykohtaisesti ja parannettuja välimuistivinkkejä, ennen kuin ne laskeutuvat vakaaseen Dockerfile-syntaksiin.

Mahdollisuus määritellä oma käyttöliittymä tarkoittaa myös sitä, että organisaatioiden, joilla on epätavallisia rakennusvaatimuksia, ei tarvitse valita "suunnittele kaikki Dockerfile-syntaksiin" tai "hylkää säilöt kokonaan". Tiimi rakentaa FPGA-laiteohjelmistoa, sulautettujen järjestelmien kuvia tai erikoistuneita ML-mallisäilöjä, jotka voivat kuvata kokoonpanoaan toimialueensa kannalta järkevillä termeillä, mutta silti tuottaa standardinmukaisia ​​OCI-yhteensopivia säilökuvia, jotka otetaan käyttöön kaikkialla, missä säilöt toimivat. Tämä laajennettavuus on todellinen arkkitehtoninen etu verrattuna koontijärjestelmiin, jotka käsittelevät syöttömuotoaan kiinteänä.

Lähtöpaikka ja SBOM: rakentaminen aurinkotuulien jälkeistä maailmaa varten

Ohjelmiston toimitusketjun turvallisuus siirtyi teoreettisesta huolenaiheesta korttitason prioriteettiin SolarWinds-murron vuonna 2020 ja Log4Shell-haavoittuvuuden jälkeen vuonna 2021. Yhdysvaltain hallituksen kyberturvallisuutta koskeva toimeenpanomääräys 14028, joka annettiin toukokuussa 2021, velvoitti ohjelmistosopimusten laatimaan liittovaltion sopimusasiakirjoja. BuildKitin alkuperätodistukset ja SBOM-sukupolven ominaisuudet ovat suora vastaus tähän sääntely- ja turvallisuusympäristöön.

Lippujen --provenance=true ja --sbom=true avulla BuildKit luo kryptografisesti allekirjoitettuja todistuksia, jotka kuvaavat tarkalleen, mitä säilökuvaan meni – mitä peruskuvia käytettiin, mitkä Dockerfile-käskyt suoritettiin, mitkä lähdetiedostot olivat mukana ja mitä ulkoisia riippuvuuksia haettiin. Nämä todistukset noudattavat SLSA-kehystä (Supply-chain Levels for Software Artifacts) ja in-toto-todistusmuotoa, joten ne ovat koneellisesti tarkistettavissa käytäntömoottoreilla, kuten Sigstoren Cosignilla ja OPA:lla (Open Policy Agent).

Tämän mahdollistama käytännön työnkulku näyttää tältä:

1. Kehittäjä työntää koodia; CI-putki käynnistää BuildKit-koontiversion, jonka alkuperä on käytössä.
2. BuildKit luo allekirjoitetun SBOM:n, jossa luetellaan kaikki komponentit ja niiden versiot.
3. SBOM julkaistaan säilörekisteriin kuvaluettelon rinnalla.
4. Kubernetes-klusterin pääsyohjaimet varmistavat alkuperän ennen käyttöönoton sallimista.
5. Haavoittuvuusskannerit kysyvät SBOM:lta tunnistaakseen vaikutuksen kohteena olevat kuvat, kun uusia CVE:itä paljastetaan.

Tämän täyden prosessin toteuttavat tiimit voivat reagoida haavoittuvuuksien paljastukseen tunneissa eikä päivissä, koska niillä on tarkka, koneellisesti luettava kartta jokaisesta käynnissä olevasta säiliöstä. Mewayzin kaltaisille yrityksille, jotka integroituvat syvästi asiakkaiden operatiivisiin työnkulkuihin – palkanlaskentaan, kalustotietojen hallintaan, laskujen käsittelyyn – kyky osoittaa tiukka, tarkastettava toimitusketju on yhä useammin edellytys yrityksen myyntikeskusteluille, ei vain mukavaa saada.

Aloitus: oletuskokonaisuuksista edistyneisiin putkilinjoihin

BuildKit on jo käynnissä Docker-ympäristössäsi, jos käytät uusinta versiota – Docker 23.0 ja uudemmat versiot ovat oletuksena käytössä. Ensimmäinen käytännön askel useimmille tiimeille on ottaa käyttöön Docker Buildx -laajennus, joka paljastaa BuildKitin täyden ominaisuusjoukon docker buildx -alikomennon kautta. Ajo docker buildx create --use määrittää BuildKit-rakennustyökalun ilmentymän, jolla on enemmän ominaisuuksia kuin oletusohjain. Tästä eteenpäin edistyneiden ominaisuuksien asteittainen käyttöönotto on järkevää sen sijaan, että yritettäisiin ottaa kaikki käyttöön kerralla.

Kohtuullinen käyttöönottopolku tällä hetkellä docker build -peruskutsuja tekevälle tiimille näyttää olevan välimuistin viennin lisääminen ensin CI:hen – tämä parantaa välittömiä, mitattavissa olevia nopeusparannuksia minimaalisella konfiguraatiomuutoksella. Monialustaisista koontiversioista tulee arvokkaita, kun tiimi alkaa kohdistaa ARM-infrastruktuuriin. Salainen asennus kannattaa ottaa käyttöön aina, kun yksityiset pakettirekisterit tai SSH-avaimet ilmestyvät rakennuskontekstiin. Alkuperätodistukset ovat järkevää, kun toimitusketjun asiakirjat ovat tarpeen, kun vaatimustenmukaisuusvaatimukset tai yritysasiakkaiden vaatimukset edellyttävät.

BuildKitin syvemmällä oppitunnilla on kyse tietoisesta rakentamisesta. Toimitatpa sitten konttia mikropalveluun, koneoppimispäätepäätepisteeseen tai monimutkaiseen alustaan, kuten Mewayzin 207 liiketoimintamoduulin sarjaan, rakennusprosessi ei ole muodollisuus, jonka läpi kiirehdit matkalla käyttöönottoon – se on tekninen artefakti, joka heijastaa kaiken lähetettävän tuotteen laatua, turva-asentoa ja toimintakykyä. BuildKit antaa sinulle työkalut tehdäksesi tästä esineestä erinomaisen. Kysymys on vain siitä, käytätkö aikaa niiden käyttöön.

Usein kysytyt kysymykset

Mikä BuildKit on ja miten se eroaa perinteisestä Docker-koontijärjestelmästä?

BuildKit on Dockerin seuraavan sukupolven koontimoottori, joka esiteltiin Docker 18.09:ssä ja tehtiin oletusarvoksi Docker 23.0:ssa. Toisin kuin klassinen rakentaja, BuildKit tukee rinnakkaista kerrosten suorittamista, edistyneitä välimuististrategioita, salaisuuksien asentamista ja monialustaisia ​​koontiversioita. Se käsittelee rakennusprosessia suunnattuna asyklisenä graafina (DAG), mikä mahdollistaa älykkäämmän riippuvuusratkaisun ja dramaattisesti nopeammat rakennusajat monimutkaisille, monivaiheisille Docker-tiedostoille.

Onko minun asennettava jotain ylimääräistä, jotta voin aloittaa BuildKitin käytön Dockerin kanssa?

Lisäasennusta ei tarvita, jos käytössäsi on Docker 23.0 tai uudempi – BuildKit on oletuksena käytössä. Vanhemmissa versioissa voit aktivoida sen asettamalla ympäristömuuttujan DOCKER_BUILDKIT=1 ennen koontikomentojen suorittamista. Edistyneitä käyttötapauksia varten, kuten etäkoontivälimuistit tai usean alustan koontiversiot, sinun kannattaa määrittää erillinen Buildx-rakennusinstanssi käyttämällä docker buildx create -toimintoa.

Voidaanko BuildKitillä luoda artefakteja tavallisten säilökuvien lisäksi?

Kyllä, ja tämä on yksi BuildKitin aliarvostetuimmista ominaisuuksista. Mukautettujen käyttöliittymien ja --output-lipun avulla BuildKit voi tuottaa raakoja binaareja, tarball-tiedostoja, staattisia verkkosivustoja ja muita mielivaltaisia ​​tiedostoartefakteja – ei vain OCI-kuvia. Tämä tekee siitä yleiskäyttöisen rakennusmoottorin, joka sopii luonnollisesti monikielisiin monorepoihin ja monimutkaisiin CI-putkiin, joissa eri tiimit tarvitsevat erilaisia tulostusmuotoja yhtenäisestä työkaluketjusta.

Miten BuildKit sopii laajempaan DevOps-alustaan Mewayzin kaltaisten työkalujen rinnalle?

BuildKit hoitaa matalan tason koontikerroksen, mutta nykyaikaisten kehitystiimien on myös hallittava liiketoiminnan työnkulkuja, asiakastoimituksia ja toimintaprosesseja. Alustat, kuten Mewayz – 207 moduulin yrityskäyttöjärjestelmä alkaen 19 $/kk – täydentävät infrastruktuurityökaluja kattamalla ohjelmistoyritysten operatiivisen puolen. Kun yhdistät tehokkaat BuildKitin tuottamat rakennusputket Mewayzin kaltaiseen all-in-one-alustaan, tiimit saavat täydellisen pinon koodiartefaktista asiakastoimitukseen.