BuildKit: Docker's Hidden Gem, რომელსაც შეუძლია თითქმის ყველაფრის აშენება

BuildKit: Docker's Hidden Gem, რომელსაც შეუძლია თითქმის ყველაფრის აშენება

დეველოპერების უმეტესობამ იცის Docker-ი, როგორც კონტეინერის გაშვების დრო, რომელმაც შეცვალა პროგრამული უზრუნველყოფის მიწოდება. გაცილებით ცოტამ იცის ძრავის შესახებ, რომელიც ჩუმად გუგუნებს Docker-ის ყველა თანამედროვე კონსტრუქციის ზედაპირზე - BuildKit, შემდეგი თაობის Build სისტემა, რომელიც მიწოდებულია Docker-ით 18.09 ვერსიიდან და გახდა ნაგულისხმევი გვერდი Docker 23.0-ში. მიუხედავად იმისა, რომ ინჟინრები გაუთავებლად კამათობენ Kubernetes-ის კონფიგურაციებისა და მიკროსერვისის შაბლონების შესახებ, BuildKit სტაბილურად ვითარდება DevOps ეკოსისტემაში ერთ-ერთ ყველაზე მძლავრ, მოქნილ კონსტრუქციულ სისტემაში. თუ თქვენ მას განიხილავთ როგორც უფრო სწრაფ docker build-ს, თქვენ ტოვებთ უზარმაზარ შესაძლებლობებს მაგიდაზე. კომპანიებმა, რომლებიც მართავენ მაღალი გამტარუნარიანობის CI/CD მილსადენებს, შეამცირეს მშენებლობის დრო 50-70%-ით, უბრალოდ იმის გაგებით, თუ რას გვთავაზობს BuildKit - და ეს მხოლოდ დასაწყისია.

რა განასხვავებს BuildKit-ს ძირეულად კლასიკური Builder-ისგან

ორიგინალური Docker build ძრავა ასრულებდა Dockerfile-ის ინსტრუქციებს თანმიმდევრულად, თითო ფენით, ყოველგვარი ცოდნის გარეშე, თუ რა სამუშაო შეიძლება მოხდეს უსაფრთხოდ პარალელურად. BuildKit ცვლის ამ ხაზოვანი შესრულების მოდელს მიმართული აციკლური გრაფიკით (DAG) - დამოკიდებულების გრაფიკი, რომელიც ესმის, თუ რომელი კონსტრუქციის ნაბიჯები ეყრდნობა ერთმანეთს და რომელი არა. დამოუკიდებელი ეტაპები შესრულებულია ერთდროულად, გამოუყენებელი ეტაპები მთლიანად გამოტოვებულია და მთელი კონსტრუქცია ხდება დეკლარაციული აღწერა იმისა, რაც გსურთ და არა იმპერატიული თანმიმდევრობით, რომელიც უნდა წაიკითხოთ სწორი თანმიმდევრობით.

ამ არქიტექტურულ ცვლილებას აქვს პრაქტიკული შედეგები, რომლებიც სცილდება სიჩქარეს. როდესაც მრავალსაფეხურიანი Dockerfile აგროვებს Go ბინარს ერთ ეტაპზე, ჩამოტვირთავს Node.js დამოკიდებულებებს მეორეში და აწყობს წარმოების სურათს მესამეში, BuildKit-ს შეუძლია პირველი ორი ეტაპის ერთდროულად გაშვება. კონსტრუქცია, რომელსაც ადრე ოთხი წუთი დასჭირდა ძლიერი CI მორბენალით, ახლა სრულდება ოთხმოცდაათ წამში. Stripe, Shopify და სხვა მაღალმასშტაბიანი საინჟინრო გუნდების რაოდენობამ დააფიქსირა მსგავსი მიღწევები მათი შიდა ხელსაწყოების რეტროსპექტივებში. DAG მოდელი ასევე ნიშნავს, რომ BuildKit-ს შეუძლია შექმნას უაღრესად ზუსტი კონსტრუქციის მეტამონაცემები - საფუძველი ისეთი ფუნქციებისთვის, როგორიცაა წარმოშობის ატესტაციები და პროგრამული უზრუნველყოფის მასალების (SBOM) გენერაცია, რომლებიც ძალიან მნიშვნელოვანია მიწოდების ჯაჭვის უსაფრთხოებისთვის.

ასევე არის კონცეპტუალური ცვლილება, თუ როგორ მუშაობს ქეშის გაუქმება. კლასიკურმა მშენებელმა გააუქმა ყველა ფენა ნებისმიერი შეცვლილი ინსტრუქციის ქვემოთ. BuildKit თვალყურს ადევნებს შინაარსის ჰეშებს თითოეულ შეყვანაზე, ასე რომ, Dockerfile-ში კომენტარის შეცვლა არ აფუჭებს ქეში ჩანაწერს, რომელიც წარმოადგენს კომპილაციის ოცდაათ წუთს. როდესაც თქვენი საშენი ქეში არის განსხვავება ხუთწუთიან და ორმოცწუთიან უკუკავშირის მარყუჟს შორის თქვენი საინჟინრო გუნდისთვის, ეს სიზუსტე ბევრად უფრო მნიშვნელოვანია, ვიდრე თავიდან შეიძლება ჩანდეს.

მრავალპლატფორმული ნაგებობები: ერთი ბრძანება, ყოველი არქიტექტურა

BuildKit-ის --პლატფორმა დროშა და QEMU ინტეგრაცია გარდაქმნის იმას, რაც ოდესღაც მტკივნეული მრავალსისტემური კოორდინაციის პრობლემა იყო ერთ ბრძანებად. გაშვებული docker buildx build --პლატფორმა linux/amd64,linux/arm64,linux/arm/v7 . წარმოქმნის სამ სურათს, რომლებიც მზად არიან წარმოებისთვის პარალელურად, ერთი build-ის გამოძახებიდან. ეს შესაძლებლობა გახდა კრიტიკული, რადგან ინდუსტრია გადადის ARM-ზე — AWS Graviton3 ინსტანციები მუდმივად იძლევა 40%-ით უკეთეს ფასებს სამუშაო დატვირთვებზე, როგორიცაა ვებ სერვისი და მონაცემთა დამუშავება, ხოლო Apple Silicon-მა ARM აქცია ნაგულისხმევი განვითარების მანქანად მილიონობით ინჟინრისთვის.

სანამ BuildKit-ის მრავალ პლატფორმის მხარდაჭერა მომწიფდებოდა, სხვადასხვა არქიტექტურისთვის ცალკეული მილსადენების შენარჩუნება იყო რეალური ხარჯების ცენტრი. გუნდებმა ან შეინარჩუნეს რამდენიმე Dockerfiles, აწარმოეს ცალკეული CI მილსადენები სხვადასხვა არქიტექტურულ მორბენალებზე, ან უბრალოდ გაგზავნეს x86 სურათები ყველგან და გადაიხადეს შესრულების ჯარიმა ARM ინფრასტრუქტურაზე. BuildKit-ით თქვენ განსაზღვრავთ თქვენს კონსტრუქციას ერთხელ და აძლევთ სისტემას გამჭვირვალედ გაუმკლავდეს არქიტექტურის სპეციფიკურ კომპილაციას. Rust პროექტები, რომლებიც საჭიროებენ ჯვარედინი კომპილაციას, Go პროექტები CGO დამოკიდებულებით, Python პაკეტები C გაფართოებით — BuildKit ამუშავებს ემულაციის ფენას ყოველი სამიზნე პლატფორმის დეტალების გაგების გარეშე.

აქ ბიზნესის პრაქტიკული ღირებულება გაზომვადია. გუნდი, რომელიც მართავს 200 კონტეინერს AWS Graviton-ის ინსტანციებზე 0,04$-ით vCPU-საათში, x86-ის ეკვივალენტური ინსტანციის 0,056$-ით თითო vCPU-საათზე დაზოგავს დაახლოებით $11,520 ყოველწლიურად 100 vCPU-ზე – მხოლოდ სწორი არქიტექტურის არჩევით. ამ არჩევანის ხელმისაწვდომობა ხელახალი ინჟინერიის ძალისხმევის გარეშე არის ზუსტად ისეთი ინფრასტრუქტურის ოპტიმიზაცია, რომელიც დაუყოვნებლივ იხდის თავის თავს.

საიდუმლო მართვა გამოსახულების ფენებში გაჟონვის გარეშე

BuildKit-ის ერთ-ერთი ყველაზე დაუფასებელი ფუნქცია მისი საიდუმლოების APIა. Docker-ის კლასიკურ შემქმნელს არ ჰქონდა სუფთა გზა, რომ გადასცემდა რწმუნებათა სიგელები ბილდში, თუ ეს სერთიფიკატები პოტენციურად გამოსახულების შრეში არ დასრულდებოდა. დეველოპერები ამაზე მუშაობდნენ მრავალსაფეხურიანი კონსტრუქციებით, ARG ინსტრუქციებით და ფრთხილად შეკვეთით — მაგრამ API გასაღების ან პირადი SSH გასაღების შემთხვევით გამოცხობის რისკი გაგზავნილ სურათში არასასიამოვნოდ მაღალი რჩებოდა. უსაფრთხოების სკანერები რეგულარულად პოულობენ მყარი კოდირებულ სერთიფიკატებს კონტეინერების სურათებში, რომლებიც გამოქვეყნებულია საჯარო რეესტრებში და ბევრი ასეთი გაჟონვა უშუალოდ უბრუნდება უხერხულ საიდუმლო დამუშავებას აგების დროს.

BuildKit-ის --secret დროშა ათავსებს სენსიტიურ მონაცემებს build-ის გარემოში, როგორც დროებითი ფაილური სისტემის გზა, რომელიც არსებობს მხოლოდ კონკრეტული RUN ინსტრუქციის ხანგრძლივობის განმავლობაში, რომელსაც ეს სჭირდება და არასოდეს ეხება სურათის არცერთ ფენას. Dockerfile-ის ინსტრუქცია, როგორიცაა RUN --mount=type=secret,id=npmrc cat /run/secrets/npmrc > ~/.npmrc && npm install აძლევს build პროცესის წვდომას პირად npm სერთიფიკატებზე ისე, რომ ეს სერთიფიკატები არ გამოჩნდეს საბოლოო სურათზე ან რაიმე შუალედურ ფენაში. იგივე ნიმუში მუშაობს PyPI სერთიფიკატებისთვის, Maven პარამეტრებისთვის, SSH გასაღებებისთვის პირადი Git საცავებისთვის და ნებისმიერი სხვა მგრძნობიარე მასალისთვის, რომელსაც თქვენი მშენებლობის პროცესი მოითხოვს.

პროგრამების შემქმნელი გუნდებისთვის, რომლებიც ეხება რეგულირებულ ინდუსტრიებს - ჯანდაცვის პლატფორმებს, ფინტექს პროდუქტების, HR პროგრამული უზრუნველყოფის - განსხვავება "სარწმუნოების მტკიცებულება შეიძლება იყოს სურათზე" და "სარწმუნოების მტკიცებულება არ შეიძლება იყოს სურათზე" არის განსხვავება უსაფრთხოების აუდიტის ჩაბარებასა და დასკვნების გამოსასწორებლად სამი კვირის დახარჯვას შორის. პლატფორმები, როგორიცაა Mewayz, რომელიც ახორციელებს ბიზნეს ოპერაციებს 138000-ზე მეტი მომხმარებლისთვის სხვადასხვა ინდუსტრიებში, როგორიცაა სახელფასო, HR და ინვოისის შედგენა, დამოკიდებულია ზუსტად ასეთ დადასტურებულ უსაფრთხოების პოზაზე მათი კონსტრუქციისა და განლაგების მილსადენებში, რათა შეინარჩუნონ ნდობა ამ მომხმარებლების მიმართ მათი მგრძნობიარე ფინანსური და პერსონალის მონაცემებზე.

ქეშის ექსპორტი: CI მილსადენების რეალურად სწრაფი შექმნა

CI მილსადენები არის იქ, სადაც კონსტრუქციის შესრულება ყველაზე მნიშვნელოვანია და სადაც ნაგულისხმევი Docker build გამოცდილება ისტორიულად ყველაზე მტკივნეული იყო. ახალი 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 build-ის სამუშაო ნაკადების შესახებ მკაცრად გირჩევთ ამ შაბლონს ზუსტად ამ მიზეზით.

ყველაზე სწრაფი კონსტრუქცია არის ის, რომლის გაშვება აღარასოდეს მოგიწევთ. BuildKit-ის ფენიანი, კონტენტ-მისამართიანი ქეში სისტემა არ აჩქარებს მხოლოდ აშენებებს — ის უფრო ჭკვიანს ხდის "build"-ის მთელ კონცეფციას, აქცევს განმეორებით კომპილაციას მატულ განსხვავებულად, რაც შეიცვალა ზუსტად.

ქეშის ექსპორტი ასევე ინტეგრირდება ფილიალებზე დაფუძნებულ განვითარების სამუშაო პროცესებთან. თქვენ შეგიძლიათ დააკონფიგურიროთ თქვენი CI მილსადენი, რათა დაბრუნდეს ფილიალის სპეციფიკური ქეშიდან მთავარ განშტოების ქეშში, როდესაც არ არსებობს ფილიალის ქეში, რაც ნიშნავს, რომ ახალი ფილიალები დაუყოვნებლივ სარგებლობენ თქვენი მთავარი განვითარების ხაზის მიერ დაგროვილი თბილი ქეშით. ინჟინრები იღებენ სწრაფ გამოხმაურებას ახალ ფილიალზე პირველივე ვალდებულებიდან, ვიდრე ცივი დაწყების ჯარიმას დაელოდონ.

BuildKit Frontends: Building Beyond Dockerfiles

BuildKit-ის ყველაზე ნაკლებად ცნობილი შესაძლებლობა არის ის, რომ Dockerfiles არის მხოლოდ ერთი შესაძლო შეყვანის ფორმატი - არა ერთადერთი. BuildKit-ს აქვს ჩამრთველი წინა ნაწილის არქიტექტურა, რომელიც საშუალებას იძლევა მთლიანად პერსონალური კონსტრუქციის განსაზღვრის ენები და ფორმატები. წინა ნაწილი მითითებულია # syntax= დირექტივით თქვენი build ფაილის ზედა ნაწილში, რომელიც ეუბნება BuildKit-ს, ამოიღოს კონკრეტული წინა ნაწილის სურათი და გამოიყენოს იგი დანარჩენი ფაილის გასაანალიზებლად და შესასრულებლად.

ამ არქიტექტურამ ჩართო რამდენიმე დამაჯერებელი პროექტი. Buildpacks-ის ინტეგრაცია საშუალებას აძლევს BuildKit-ს შექმნას კონტეინერის სურათები პროგრამის წყაროს კოდიდან Dockerfile-ის გარეშე – ის აღმოაჩენს ენას, ირჩევს შესაბამის საბაზისო სურათებს და ავტომატურად აწყობს წარმოებისთვის მზა კონტეინერს. HPC და სამეცნიერო გამოთვლითი საზოგადოებები იყენებდნენ მორგებულ ფრონტენტებს დომენის სპეციფიკურ ენებზე კონსტრუქციების აღსაწერად, რომლებიც შედგენილია BuildKit-ის შიდა LLB (დაბალი დონის Build) წარმომადგენლობით. docker/dockerfile:labs სინტაქსის წინა ნაწილი ექსპერიმენტებს ატარებს ისეთი ფუნქციებით, როგორიცაა heredoc მხარდაჭერა, --network კონტროლი თითო ინსტრუქციაზე და გაძლიერებული ქეში მინიშნებები, სანამ ისინი მოხვდებიან სტაბილურ Dockerfile სინტაქსში.

თქვენი ფრონტენდის განსაზღვრის შესაძლებლობა ასევე ნიშნავს იმას, რომ ორგანიზაციებს, რომლებსაც აქვთ უჩვეულო კონსტრუქციის მოთხოვნები, არ უნდა აირჩიონ „ყველაფერი Dockerfile-ის სინტაქსში ჩასმა“ და „კონტეინერების მთლიანად მიტოვება“ შორის. გუნდის შექმნის FPGA firmware, ჩაშენებული სისტემების სურათებს ან სპეციალიზებულ ML მოდელის კონტეინერებს შეუძლიათ აღწერონ თავიანთი კონსტრუქცია მათი დომენისთვის აზრის მქონე ტერმინებით, თუმცა აწარმოებენ სტანდარტულ OCI-თან შესაბამის კონტეინერ სურათებს, რომლებიც განლაგებულია კონტეინერების ნებისმიერ ადგილას. ეს გაფართოება არის ნამდვილი არქიტექტურული უპირატესობა კონსტრუქციულ სისტემებთან შედარებით, რომლებიც შეყვანის ფორმატს ფიქსირებულად თვლიან.

წარმოშობა და SBOM: შენობა პოსტ-მზის ქარის სამყაროსთვის

პროგრამული უზრუნველყოფის მიწოდების ჯაჭვის უსაფრთხოება თეორიული საზრუნადან გადავიდა საბჭოს დონის პრიორიტეტზე 2020 წელს SolarWinds-ის დარღვევის და 2021 წელს Log4Shell დაუცველობის შემდეგ. აშშ-ის მთავრობის აღმასრულებელი ბრძანება 14028 კიბერუსაფრთხოების შესახებ, გამოცემული 2021 წლის მაისში, ფედერალური მასალების კონტრაქტორები პროგრამული უზრუნველყოფის მანდატით. BuildKit-ის წარმოშობის ატესტაციები და SBOM-ის გენერირების მახასიათებლები არის პირდაპირი პასუხი ამ მარეგულირებელ და უსაფრთხოების ლანდშაფტზე.

--provenance=true და --sbom=true დროშებით, BuildKit აწარმოებს კრიპტოგრაფიულად ხელმოწერილ ატესტებს, რომლებიც ზუსტად აღწერს იმას, თუ რა შევიდა კონტეინერის სურათში — რომელი ძირითადი სურათები იყო გამოყენებული, რომელი Dockerfile ინსტრუქციები შესრულდა, რომელი წყაროს ფაილები იყო დამოკიდებულები და რა იყო გარე ფაილები. ეს ატესტაციები მიჰყვება SLSA-ს (Supply-chain Levels for Software Artifacts) ჩარჩოს და in-toto ატესტაციის ფორმატს, რაც მათ მანქანაში გადამოწმებას ხდის პოლიტიკის ძრავებით, როგორიცაა Sigstore's Cosign და OPA (Open Policy Agent).

პრაქტიკული სამუშაო პროცესი, რომლის საშუალებითაც შესაძლებელია, ასე გამოიყურება:

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 კლავიშები გამოჩნდება build კონტექსტში. წარმოშობის ატესტაციას აქვს აზრი, რომ ჩართოს, როდესაც შესაბამისობის მოთხოვნები ან საწარმოს მომხმარებელთა მოთხოვნები საჭიროებს მიწოდების ჯაჭვის დოკუმენტაციას.

BuildKit-ის უფრო ღრმა გაკვეთილი არის განზრახ აშენება. მიუხედავად იმისა, აგზავნით კონტეინერს მიკროსერვისისთვის, მანქანათმცოდნეობის დასკვნის საბოლოო წერტილისთვის, თუ კომპლექსურ პლატფორმას, როგორიცაა Mewayz-ის 207 ბიზნეს მოდული, აწყობის პროცესი არ არის ფორმალობა, რომელსაც ჩქარობთ განლაგების გზაზე – ეს არის საინჟინრო არტეფაქტი, რომელიც ასახავს მის ხარისხს, უსაფრთხოების მდგომარეობას და ოპერაციულ სიმწიფეს. BuildKit გაძლევთ ინსტრუმენტებს, რომ ეს არტეფაქტი შესანიშნავი გახადოთ. უბრალოდ საკითხავია, უთმობთ თუ არა დროს მათ გამოყენებას.

ხშირად დასმული კითხვები

რა არის BuildKit და რით განსხვავდება ის კლასიკური Docker build სისტემისგან?

BuildKit არის Docker-ის შემდეგი თაობის ძრავა, რომელიც დაინერგა Docker 18.09-ში და ნაგულისხმევი გახდა Docker 23.0-ში. კლასიკური მშენებლისგან განსხვავებით, BuildKit მხარს უჭერს პარალელური ფენის შესრულებას, მოწინავე ქეშირების სტრატეგიებს, საიდუმლოების მონტაჟს და კროს-პლატფორმულ შენობებს. ის განიხილავს შექმნის პროცესს, როგორც მიმართულ აციკლურ გრაფიკს (DAG), რაც საშუალებას აძლევს დამოკიდებულების უფრო ჭკვიანურ გარჩევადობას და მკვეთრად სწრაფ აშენებას რთული, მრავალსაფეხურიანი Dockerfiles-ისთვის.

დამატებითი რამის დაყენება მჭირდება, რომ დავიწყო BuildKit Docker-თან ერთად?

დამატებითი ინსტალაცია არ არის საჭირო, თუ თქვენ იყენებთ Docker 23.0 ან უფრო ახალ ვერსიას — BuildKit ჩართულია ნაგულისხმევად. ძველ ვერსიებზე შეგიძლიათ გაააქტიუროთ ის გარემოს ცვლადის დაყენებით DOCKER_BUILDKIT=1 თქვენი build ბრძანებების გაშვებამდე. გაფართოებული გამოყენების შემთხვევებისთვის, როგორიცაა დისტანციური აშენების ქეშები ან მრავალპლატფორმიანი ნაგებობები, შეიძლება დაგჭირდეთ სპეციალური Buildx-ის შემქმნელის მაგალითის კონფიგურაცია docker buildx create გამოყენებით.

შეიძლება თუ არა BuildKit-ის გამოყენება სტანდარტული კონტეინერის სურათების მიღმა არტეფაქტების შესაქმნელად?

დიახ, და ეს არის BuildKit-ის ერთ-ერთი ყველაზე დაუფასებელი შესაძლებლობები. მორგებული ფრონტენტებისა და --output დროშის გამოყენებით, BuildKit-ს შეუძლია შექმნას ნედლეული ორობითი ფაილები, tarballs, სტატიკური ვებსაიტები და სხვა თვითნებური ფაილური არტეფაქტები — არა მხოლოდ OCI სურათები. ეს აქცევს მას ზოგადი დანიშნულების კონსტრუქციულ ძრავად, რომელიც ბუნებრივად ჯდება პოლიგლოტ მონორეპოსა და კომპლექსურ CI მილსადენებში, სადაც სხვადასხვა გუნდს სჭირდება სხვადასხვა გამომავალი ფორმატები ერთიანი ხელსაწყოების ჯაჭვიდან.

როგორ ჯდება BuildKit უფრო ფართო DevOps პლატფორმაში Mewayz-ის მსგავს ინსტრუმენტებთან ერთად?

BuildKit ამუშავებს დაბალი დონის Build ფენას, მაგრამ თანამედროვე განვითარების გუნდებს ასევე სჭირდებათ ბიზნეს სამუშაოების, კლიენტების მიწოდებისა და ოპერაციული პროცესების მართვა. პლატფორმები, როგორიცაა Mewayz — 207 მოდულიანი ბიზნეს ოპერაციული სისტემა, რომელიც იწყება $19/თვეში — ავსებს ინფრასტრუქტურის ინსტრუმენტებს პროგრამული უზრუნველყოფის ბიზნესის ოპერაციული მხარის დაფარვით. ეფექტური სამშენებლო მილსადენების დაწყვილება BuildKit-ის მიერ მომუშავე ერთ-ერთ პლატფორმასთან, როგორიცაა Mewayz, აძლევს გუნდებს სრულ დასტას კოდის არტეფაქტიდან კლიენტის მიწოდებამდე.