BuildKit: схаваная жамчужына Docker, з якой можна пабудаваць практычна ўсё

BuildKit: схаваная жамчужына Докера, якая можа стварыць амаль што заўгодна

Большасць распрацоўшчыкаў ведаюць Docker як асяроддзе выканання кантэйнера, якое змяніла спосаб дастаўкі праграмнага забеспячэння. Значна менш ведаюць пра рухавік, які ціха гудзе пад паверхняй кожнай сучаснай зборкі Docker — BuildKit, сістэму зборкі наступнага пакалення, якая пастаўляецца з Docker з версіі 18.09 і стала бэкэндам па змаўчанні ў Docker 23.0. Пакуль інжынеры бясконца спрачаюцца аб канфігурацыях Kubernetes і шаблонах мікрасэрвісаў, BuildKit няўхільна развіваецца ў адну з самых магутных і гнуткіх сістэм зборкі ў экасістэме DevOps. Калі вы разглядалі гэта як больш хуткую зборку докера, вы пакідаеце на стале велізарныя магчымасці. Кампаніі, якія працуюць з высокапрапускнымі канвеерамі CI/CD, скарацілі час зборкі на 50–70%, проста разумеючы, што насамрэч прапануе BuildKit — і гэта толькі пачатак.

Чым BuildKit прынцыпова адрозніваецца ад класічнага канструктара

Арыгінальны рухавік зборкі Docker выконваў інструкцыі Dockerfile паслядоўна, адзін пласт за раз, без усведамлення таго, якая праца можа бяспечна адбывацца паралельна. BuildKit замяняе гэтую лінейную мадэль выканання накіраваным ацыклічным графам (DAG) — графам залежнасцей, які разумее, якія этапы зборкі залежаць адзін ад аднаго, а якія не. Незалежныя этапы выконваюцца адначасова, нявыкарыстаныя этапы цалкам прапускаюцца, і ўся зборка становіцца дэкларатыўным апісаннем таго, што вы хочаце, а не абавязковай паслядоўнасцю крокаў, якія вы павінны прачытаць у правільным парадку.

Гэты архітэктурны зрух мае практычныя наступствы, якія выходзяць за рамкі хуткасці. Калі шматступенны файл Dockerfile кампілюе двайковы файл Go на адным этапе, спампоўвае залежнасці Node.js на другім і збірае працоўны вобраз на трэцім, BuildKit можа запускаць першыя два этапы адначасова. Зборка, якая раней займала чатыры хвіліны на магутным бегуне CI, цяпер завяршаецца менш чым за дзевяноста секунд. Stripe, Shopify і мноства іншых буйных каманд інжынераў задакументавалі падобныя поспехі ў сваіх рэтраспектывах унутраных інструментаў. Мадэль DAG таксама азначае, што BuildKit можа ствараць вельмі дакладныя метаданыя зборкі — аснову для такіх функцый, як атэстацыі паходжання і генерацыя спісу матэрыялаў праграмнага забеспячэння (SBOM), якія вельмі важныя для бяспекі ланцужкоў паставак.

Таксама адбыліся канцэптуальныя змены ў тым, як працуе ануляванне кэша. Класічны канструктар зрабіў несапраўдным кожны пласт пад любой змененай інструкцыяй. BuildKit адсочвае хэшы змесціва пры кожным уводзе, таму змяненне каментарыя ў файле Dockerfile не губляе запіс у кэшы, які прадстаўляе трыццаць хвілін кампіляцыі. Калі ваш кэш зборкі - гэта розніца паміж пяціхвілінным і саракахвілінным цыклам зваротнай сувязі для вашай каманды інжынераў, гэтая дакладнасць мае значна большае значэнне, чым можа здацца на першы погляд.

Мультыплатформенныя зборкі: адна каманда, кожная архітэктура

BuildKit і інтэграцыя QEMU ператвараюць тое, што калісьці было балючай праблемай шматсістэмнай каардынацыі, у адну каманду. Запуск docker buildx build --platform linux/amd64,linux/arm64,linux/arm/v7 . стварае тры вобразы, гатовыя да вытворчасці, паралельна з аднаго выкліку зборкі. Гэта магчымасць стала крытычна важнай, калі індустрыя пераходзіць да ARM — асобнікі AWS Graviton3 стабільна забяспечваюць на 40 % лепшую цану-прадукцыйнасць пры такіх працоўных нагрузках, як вэб-абслугоўванне і апрацоўка даных, а Apple Silicon зрабіла ARM машынай для распрацоўкі па змаўчанні для мільёнаў інжынераў.

Да развіцця мультыплатформеннай падтрымкі BuildKit падтрыманне асобных канвеераў зборкі для розных архітэктур было сапраўдным цэнтрам выдаткаў. Каманды альбо падтрымлівалі некалькі файлаў Docker, запускалі асобныя канвееры CI на раннерах з рознай архітэктурай, альбо проста рассылалі паўсюль выявы x86 і плацілі пагаршэнне прадукцыйнасці інфраструктуры ARM. З BuildKit вы вызначаеце сваю зборку адзін раз і дазваляеце сістэме празрыста апрацоўваць кампіляцыю ў залежнасці ад архітэктуры. Праекты Rust, якія патрабуюць крос-кампіляцыі, праекты Go з залежнасцямі CGO, пакеты Python з пашырэннямі C — BuildKit апрацоўвае ўзровень эмуляцыі, не патрабуючы ад вас разумення дэталяў кожнай мэтавай платформы.

Практычная каштоўнасць бізнесу тут вымерная. Каманда, якая запускае 200 кантэйнераў на асобніках AWS Graviton па цане 0,04 даляра за гадзіну vCPU супраць эквівалентнага асобніка x86 па цане 0,056 даляра за гадзіну віртуальнага працэсара, штогод эканоміць прыкладна 11 520 долараў ЗША на 100 віртуальных працэсараў — выключна дзякуючы выбару правільнай архітэктуры. Зрабіць гэты выбар даступным без намаганняў па рэінжынірынгу - гэта менавіта тая аптымізацыя інфраструктуры, якая неадкладна акупляе сябе.

Кіраванне сакрэтамі без уцечкі ў пласты выявы

Адной з найбольш недаацэненых функцый BuildKit з'яўляецца яго сакрэтны API. Класічны канструктар Docker не меў чыстага спосабу перадачы ўліковых даных у зборку без таго, каб гэтыя ўліковыя даныя патэнцыйна апынуліся на ўзроўні выявы. Распрацоўшчыкі абышлі гэта з дапамогай шматэтапнай зборкі, інструкцый ARG і ўважлівага ўпарадкавання — але рызыка выпадковага запякання ключа API або прыватнага ключа SSH у дастаўленым вобразе заставаўся вельмі высокім. Сканеры бяспекі рэгулярна знаходзяць жорстка закодаваныя ўліковыя даныя ў выявах кантэйнераў, апублікаваных у публічных рэестрах, і многія з гэтых уцечак прасочваюць непасрэдна да няўмелага апрацоўкі сакрэтаў падчас зборкі.

Флаг --secret у

BuildKit мантуе канфідэнцыяльныя даныя ў асяроддзе зборкі ў выглядзе часовага шляху да файлавай сістэмы, які існуе толькі на час выканання пэўнай інструкцыі RUN, якой яны неабходныя, і ніколі не закранае любы пласт выявы. Інструкцыя Dockerfile накшталт RUN --mount=type=secret,id=npmrc cat /run/secrets/npmrc > ~/.npmrc && npm install дае працэсу зборкі доступ да прыватных уліковых дадзеных npm без таго, каб гэтыя ўліковыя даныя ніколі не з'яўляліся ў канчатковым малюнку або на любым прамежкавым узроўні. Той жа шаблон працуе для ўліковых даных PyPI, налад Maven, ключоў SSH для прыватных сховішчаў Git і любога іншага канфідэнцыяльнага матэрыялу, які патрабуе ваш працэс зборкі.

Для каманд, якія ствараюць праграмнае забеспячэнне, якое закранае рэгуляваныя галіны — платформы аховы здароўя, фінтэх-прадукты, праграмнае забеспячэнне для кадраў — розніца паміж «уліковыя даныя могуць быць на вобразе» і «ўліковыя даныя, як даказана, не могуць быць у вобразе» заключаецца ў розніцы паміж праходжаннем аўдыту бяспекі і выдаткаваннем трох тыдняў на выпраўленне вынікаў. Такія платформы, як Mewayz, якія кіруюць бізнес-аперацыямі для больш чым 138 000 карыстальнікаў у такіх галінах, як разлікі заработнай платы, кадры і выстаўленне рахункаў, залежаць менавіта ад такога даказальнага стану бяспекі ў канвееры зборкі і разгортвання, каб захаваць давер кліентаў да сваіх канфідэнцыяльных фінансавых і персанальных даных.

Экспарт кэша: стварэнне канвеераў CI насамрэч хуткім

Канвееры CI - гэта тое, дзе прадукцыйнасць зборкі мае найбольшае значэнне і дзе вопыт зборкі Docker па змаўчанні быў найбольш балючым. Свежыя праграмы CI звычайна пачынаюцца з пустых кэшаў, што азначае, што кожны запуск канвеера перакампілюе ўсё з нуля. Для сэрвісу Java з сотнямі залежнасцей Maven, праекта Rust або прыкладання Python з вялікімі ўласнымі пашырэннямі гэта азначае, што час зборкі вымяраецца дзесяткамі хвілін, а не секундамі. Бізнэс-кошт павольнай CI велізарны — меншая частата разгортвання, больш доўгія цыклы зваротнай сувязі і інжынеры, якія сядзяць без справы ў чаканні завяршэння канвеераў, перш чым яны змогуць аб'яднацца і рухацца далей.

Функцыя экспарту кэша BuildKit вырашае гэтую праблему з дапамогай экспартаваных маніфестаў кэша. Выкарыстоўваючы --cache-to type=registry,ref=myregistry/myapp:cache і --cache-from type=registry,ref=myregistry/myapp:cache, BuildKit адпраўляе падрабязны здымак кэша ў рэестр пасля кожнай зборкі і выцягвае яго ў пачатку наступнай. Кэш адрасаваны па змесціву, таму паўторна атрымліваюцца толькі сапраўды змененыя пласты. Каманды, якія выкарыстоўваюць гэты шаблон у GitHub Actions, GitLab CI і CircleCI, звычайна скарачаюць час канвеера з пятнаццаці хвілін да менш чым трох пры наступных запусках. Уласная дакументацыя GitHub аб пашыраных працоўных працэсах зборкі Docker настойліва рэкамендуе гэты шаблон менавіта па гэтай прычыне.

Самая хуткая зборка - гэта тая, якую вам больш ніколі не трэба запускаць. Шматслойная сістэма кэша з адрасам змесціва BuildKit не проста паскарае зборку - яна робіць усю канцэпцыю "зборкі" разумнейшай, ператвараючы паўторную кампіляцыю ў паступовую розніцу менавіта таго, што змянілася.

Экспарт кэша таксама чыста інтэгруецца з працоўнымі працэсамі распрацоўкі на аснове галін. Вы можаце наладзіць свой канвеер CI на вяртанне з кэша філіяла ў галоўны кэш філіяла, калі кэш філіяла не існуе, што азначае, што новыя філіялы адразу ж атрымліваюць выгаду ад цёплага кэша, назапашанага вашай асноўнай лініяй распрацоўкі. Інжынеры атрымліваюць хуткую зваротную сувязь ад самага першага фіксавання новай галінкі, а не чакаюць штрафу за халодны запуск.

Вонкавыя інтэрфейсы BuildKit: стварэнне па-за файламі Docker

Магчыма, найменш вядомай магчымасцю BuildKit з'яўляецца тое, што файлы Docker з'яўляюцца толькі адным з магчымых уваходных фарматаў, а не адзіным. BuildKit мае падключаемую інтэрфейсную архітэктуру, якая дазваляе цалкам індывідуальныя мовы і фарматы азначэння зборкі. Інтэрфейс вызначаецца дырэктывай # syntax= уверсе вашага файла зборкі, якая загадвае BuildKit атрымаць пэўны вобраз інтэрфейсу і выкарыстоўваць яго для аналізу і выканання астатняй часткі файла.

Гэтая архітэктура дазволіла ажыццявіць некалькі пераканаўчых праектаў. Інтэграцыя Buildpacks дазваляе BuildKit ствараць вобразы кантэйнераў з зыходнага кода прыкладання наогул без усялякага Dockerfile — ён вызначае мову, выбірае адпаведныя базавыя вобразы і аўтаматычна збірае кантэйнер, гатовы да вытворчасці. HPC і навуковыя вылічальныя супольнасці выкарыстоўвалі карыстальніцкія інтэрфейсы для апісання зборак на даменна-спецыфічных мовах, якія кампілююцца да ўнутранага прадстаўлення LLB (нізкаўзроўневая зборка) BuildKit. Сінтаксіс інтэрфейсу docker/dockerfile:labs эксперыментуе з такімі функцыямі, як падтрымка heredoc, кіраванне --network для кожнай інструкцыі і палепшаныя падказкі кэша, перш чым яны перайдуць у стабільны сінтаксіс Dockerfile.

Магчымасць вызначаць свой уласны інтэрфейс таксама азначае, што арганізацыям з незвычайнымі патрабаваннямі да зборкі не трэба выбіраць паміж "увесці ўсё ў сінтаксіс Dockerfile" і "цалкам адмовіцца ад кантэйнераў". Прашыўка FPGA, якая стварае каманду, вобразы ўбудаваных сістэм або спецыялізаваныя кантэйнеры мадэляў ML могуць апісаць сваю зборку ў тэрмінах, якія маюць сэнс для іх дамена, і пры гэтым ствараць стандартныя вобразы кантэйнераў, сумяшчальныя з OCI, якія разгортваюцца ўсюды, дзе працуюць кантэйнеры. Такая пашыральнасць з'яўляецца сапраўднай архітэктурнай перавагай перад сістэмамі зборкі, якія разглядаюць фармат уводу як фіксаваны.

Паходжанне і SBOM: будаўніцтва для свету пасля SolarWinds

Бяспека ланцужкоў паставак праграмнага забеспячэння перайшла з тэарэтычнай заклапочанасці да прыярытэту на ўзроўні савета дырэктараў пасля ўзлому SolarWinds у 2020 г. і ўразлівасці Log4Shell у 2021 г. Распараджэнне ўрада ЗША 14028 па кібербяспецы, выдадзенае ў траўні 2021 г., абавязвае федэральным падрадчыкам складаць спіс матэрыялаў для праграмнага забеспячэння. Атэстацыі паходжання BuildKit і функцыі генерацыі SBOM з'яўляюцца прамым адказам на гэты ландшафт рэгулявання і бяспекі.

З дапамогай сцяжкоў --provenance=true і --sbom=true BuildKit стварае атэстацыі з крыптаграфічным подпісам, якія дакладна апісваюць, што ўвайшло ў вобраз кантэйнера — якія базавыя выявы выкарыстоўваліся, якія інструкцыі Dockerfile выконваліся, якія зыходныя файлы прысутнічалі і якія знешнія залежнасці былі атрыманы. Гэтыя атэстацыі прытрымліваюцца структуры SLSA (Узроўні ланцужкі паставак для праграмных артэфактаў) і фармату атэстацыі in-toto, што робіць іх машынна правяранымі механізмамі палітыкі, такімі як Cosign ад Sigstore і OPA (Агент адкрытай палітыкі).

Практычны працоўны працэс, які гэта дазваляе, выглядае так:

1. Распрацоўшчык прасоўвае код; Канвеер CI запускае зборку BuildKit з уключаным паходжаннем.
2. BuildKit стварае падпісаны SBOM са спісам усіх кампанентаў і іх версій.
3. SBOM публікуецца ў рэестры кантэйнераў разам з маніфестам выявы.
4. Кантролеры доступу ў кластары Kubernetes правяраюць паходжанне, перш чым дазволіць разгортванне.
5. Сканеры ўразлівасцей запытваюць SBOM, каб ідэнтыфікаваць закранутыя выявы, калі раскрываюцца новыя CVE.

Каманды, якія рэалізуюць гэты поўны канвеер, могуць рэагаваць на раскрыццё ўразлівасцей за некалькі гадзін, а не за дні, таму што ў іх ёсць дакладная машыначытэльная карта кожнага кампанента ў кожным запушчаным кантэйнеры. Для такіх прадпрыемстваў, як Mewayz, якія глыбока інтэгруюцца ў аперацыйныя працоўныя працэсы кліентаў — налічэнне заработнай платы, кіраванне данымі аўтапарка, апрацоўка рахункаў-фактур — здольнасць прадэманстраваць строгі ланцужок паставак, які падлягае праверцы, усё часцей становіцца неабходнай умовай для размоваў па продажах прадпрыемстваў, а не проста прыемна мець.

Пачатак працы: ад зборак па змаўчанні да пашыраных канвеераў

BuildKit ужо працуе ў вашым асяроддзі Docker, калі вы выкарыстоўваеце апошнюю версію — Docker 23.0 і больш познюю версію ўключыце па змаўчанні. Першым практычным крокам для большасці каманд з'яўляецца ўключэнне плагіна Docker Buildx, які адкрывае поўны набор функцый BuildKit праз падкаманду docker buildx. Запуск docker buildx create --use стварае асобнік канструктара BuildKit з большымі магчымасцямі, чым драйвер па змаўчанні. З гэтага моманту паступовае прыняцце пашыраных функцый мае сэнс, а не спроба пераняць усё адразу.

Разумны шлях прыняцця для каманды, якая зараз выконвае асноўныя выклікі docker build, выглядае як спачатку дадаць экспарт кэша ў CI — гэта забяспечвае імгненнае, вымернае паляпшэнне хуткасці з мінімальнымі зменамі канфігурацыі. Мультыплатформенныя зборкі становяцца каштоўнымі, калі каманда пачынае арыентавацца на інфраструктуру ARM. Сакрэтнае мантаванне варта выкарыстоўваць кожны раз, калі прыватныя рэестры пакетаў або ключы SSH з'яўляюцца ў кантэксце зборкі. Атэстацыі паходжання мае сэнс уключаць, калі патрабаванні адпаведнасці або патрабаванні карпаратыўных кліентаў патрабуюць дакументацыі ланцужкі паставак.

Больш глыбокі ўрок BuildKit датычыцца наўмыснага будаўніцтва. Незалежна ад таго, адпраўляеце вы кантэйнер для мікрасэрвіса, канчатковай кропкі вываду машыннага навучання або складанай платформы, такой як набор з 207 бізнес-модуляў Mewayz, працэс зборкі - гэта не фармальнасць, якую вы спяшаецеся выконваць на шляху да разгортвання, - гэта інжынерны артэфакт, які адлюстроўвае якасць, стан бяспекі і эксплуатацыйную сталасць усяго, што з яго пастаўляецца. BuildKit дае вам інструменты, каб зрабіць гэты артэфакт выдатным. Пытанне проста ў тым, ці знайшлі вы час на іх выкарыстанне.

Часта задаюць пытанні

Што такое BuildKit і чым ён адрозніваецца ад класічнай сістэмы зборкі Docker?

BuildKit - гэта механізм зборкі Docker наступнага пакалення, прадстаўлены ў Docker 18.09 і зроблены па змаўчанні ў Docker 23.0. У адрозненне ад класічнага канструктара, BuildKit падтрымлівае выкананне паралельнага ўзроўню, пашыраныя стратэгіі кэшавання, мантаванне сакрэтаў і кросплатформенныя зборкі. Ён разглядае працэс зборкі як накіраваны ацыклічны граф (DAG), забяспечваючы больш разумнае вырашэнне залежнасцей і значна скарачаючы час зборкі для складаных шматэтапных файлаў Docker.

Ці трэба мне ўсталёўваць што-небудзь дадатковае, каб пачаць выкарыстоўваць BuildKit з Docker?

Калі вы выкарыстоўваеце Docker 23.0 або больш позняй версіі, дадатковая ўстаноўка не патрабуецца — BuildKit уключаны па змаўчанні. У старых версіях вы можаце актываваць яго, усталяваўшы зменную асяроддзя DOCKER_BUILDKIT=1 перад выкананнем каманд зборкі. Для прасунутых выпадкаў выкарыстання, такіх як аддаленыя кэшы зборак або мультыплатформенныя зборкі, вы можаце наладзіць спецыяльны асобнік Buildx buildr з дапамогай docker buildx create.

Ці можна выкарыстоўваць BuildKit для стварэння артэфактаў, акрамя стандартных вобразаў кантэйнераў?

Так, і гэта адна з самых недаацэненых магчымасцей BuildKit. Выкарыстоўваючы карыстальніцкі інтэрфейс і сцяг --output, BuildKit можа ствараць неапрацаваныя двайковыя файлы, архівы, статычныя вэб-сайты і іншыя адвольныя артэфакты файлаў — не толькі выявы OCI. Гэта робіць яго механізмам зборкі агульнага прызначэння, які натуральна ўпісваецца ў паліглот-манарэпазіцыі і складаныя канвееры CI, дзе розным камандам патрэбныя розныя фарматы вываду з уніфікаванай ланцужка інструментаў.

Як BuildKit упісваецца ў больш шырокую платформу DevOps разам з такімі інструментамі, як Mewayz?

BuildKit апрацоўвае нізкаўзроўневы ўзровень зборкі, але сучасныя каманды распрацоўшчыкаў таксама павінны кіраваць бізнес-працоўнымі працэсамі, дастаўкай кліентам і аперацыйнымі працэсамі. Такія платформы, як Mewayz — 207-модульная бізнес-АС ад 19 долараў у месяц — дапаўняюць інфраструктурныя інструменты, ахопліваючы аператыўны бок праграмнага забеспячэння. Спалучэнне эфектыўных канвеераў зборкі на базе BuildKit з платформай "усё ў адным", такой як Mewayz, дае камандам поўны набор ад артэфактаў кода да дастаўкі кліентам.