buildkit

شفرة المصدر الأخرى

0.17.0

تنزيل

BuildKit

BuildKit عبارة عن مجموعة أدوات لتحويل التعليمات البرمجية المصدر لإنشاء عناصر بطريقة فعالة ومعبرة وقابلة للتكرار.

الميزات الرئيسية:

جمع القمامة تلقائيا
تنسيقات الواجهة الأمامية القابلة للتمديد
حل التبعية المتزامنة
التخزين المؤقت الفعال للتعليمات
بناء استيراد/تصدير ذاكرة التخزين المؤقت
بناء الدعوات الوظيفية المتداخلة
العمال القابلة للتوزيع
تنسيقات إخراج متعددة
بنية قابلة للتوصيل
التنفيذ بدون امتيازات الجذر

اقرأ الاقتراح من moby/moby#32925

مشاركة مدونة تمهيدية https://blog.mobyproject.org/introducing-buildkit-17e056cc5317

انضم إلى قناة #buildkit على Docker Community Slack

ملحوظة

إذا كنت تزور هذا الريبو لاستخدام ميزات BuildKit فقط Dockerfile مثل RUN --mount=type=(bind|cache|tmpfs|secret|ssh) ، فيرجى الرجوع إلى مرجع Dockerfile.

ملحوظة

يستخدم docker build Buildx وBuildKit بشكل افتراضي منذ Docker Engine 23.0. لا تحتاج إلى قراءة هذا المستند إلا إذا كنت تريد استخدام الإصدار المستقل كامل الميزات من BuildKit.

يستخدم من قبل
بداية سريعة

الصورة/التسجيل
الدليل المحلي
قطران عامل الميناء
OCI كرة القطران
مخزن الصور المعبأة
إنشاء ملف Dockerfile باستخدام buildctl
بناء ملف Dockerfile باستخدام الواجهة الخارجية
إعداد لينكس
إعداد ويندوز
إعداد ماك
البناء من المصدر
استكشاف ليسانس الحقوق
استكشاف ملفات دوكر
الإخراج

مخبأ

مضمّن (ادفع الصورة وذاكرة التخزين المؤقت معًا)
التسجيل (ادفع الصورة وذاكرة التخزين المؤقت بشكل منفصل)
الدليل المحلي
ذاكرة التخزين المؤقت لإجراءات GitHub (تجريبية)
ذاكرة التخزين المؤقت S3 (تجريبية)
ذاكرة التخزين المؤقت لـ Azure Blob (تجريبية)
جمع القمامة
تصدير ذاكرة التخزين المؤقت
التجزئة متسقة

البيانات الوصفية
تفعيل مقبس Systemd
كشف BuildKit كخدمة TCP

موازنة التحميل

حاوية BuildKit

بودمان
نيردكتل
كوبيرنيتيس
بلا شيطان

دعم القياس عن بعد المفتوح
تشغيل BuildKit بدون امتيازات الجذر
بناء صور متعددة المنصات

ضوابط إخراج اللون
عدد أسطر السجل (للخطوات النشطة في وضع tty)
تكوين buildctl

المساهمة

يستخدم من قبل

يتم استخدام BuildKit في المشاريع التالية:

Moby & Docker ( DOCKER_BUILDKIT=1 docker build )
img
سحابة OpenFaaS
واجهة بناء الحاوية
خطوط أنابيب Tekton (قوالب البناء Knative سابقًا)
أداة البناء سانيك
vab
ريو
كيم
PouchContainer
عامل ميناء بيلكس
اوكتيتو كلاود
ملفات الأرض الأرضية
جيتبود
خنجر
envd
مستودع
مساحة الاسم
يونيكرافت
ديف زيرو
DCC

بداية سريعة

بالنسبة لعمليات نشر Kubernetes، راجع examples/kubernetes .

يتكون BuildKit من البرنامج buildkitd وعميل buildctl . بينما يتوفر عميل buildctl لأنظمة Linux وmacOS وWindows، فإن برنامج buildkitd متاح فقط لنظامي Linux و*Windows حاليًا.

تتوفر أحدث ثنائيات BuildKit هنا لأنظمة التشغيل Linux وmacOS وWindows.

إعداد لينكس

يتطلب البرنامج buildkitd تثبيت المكونات التالية:

رونك أو كرون
حاوية (إذا كنت تريد استخدام عامل حاوية)

بدء تشغيل برنامج buildkitd : أنت بحاجة إلى تشغيل buildkitd كمستخدم جذر على المضيف.

 $ سودو buildkitd

لتشغيل buildkitd كمستخدم غير جذري، راجع docs/rootless.md .

يدعم البرنامج الخفي buildkitd واجهتين خلفيتين عاملتين: OCI (runc) وcontainerd.

بشكل افتراضي، يتم استخدام عامل OCI (runc). يمكنك تعيين --oci-worker=false --containerd-worker=true لاستخدام العامل المحتوي على الحاوية.

نحن منفتحون على إضافة المزيد من الواجهات الخلفية.

لبدء البرنامج الخفي buildkitd باستخدام تنشيط مأخذ توصيل systemd، يمكنك تثبيت ملفات وحدة buildkit systemd. راجع تفعيل مأخذ توصيل Systemd

يستمع البرنامج الخفي buildkitd إلى gRPC API على /run/buildkit/buildkitd.sock افتراضيًا، ولكن يمكنك أيضًا استخدام مقابس TCP. راجع عرض BuildKit كخدمة TCP.

إعداد ويندوز

راجع التعليمات والملاحظات على docs/windows.md .

إعداد ماك

صيغة Homebrew (غير رسمية) متاحة لنظام التشغيل macOS.

 مجموعة أدوات تثبيت المشروب $

لا تحتوي صيغة Homebrew على البرنامج الخفي ( buildkitd ).

على سبيل المثال، يمكن استخدام Lima لتشغيل البرنامج الخفي داخل جهاز Linux VM.

 قالب بدء تثبيت مشروب limalimactl://buildkitexport BUILDKIT_HOST="unix://$HOME/.lima/buildkit/sock/buildkitd.sock"

البناء من المصدر

لإنشاء BuildKit من المصدر، راجع .github/CONTRIBUTING.md .

للحصول على مرجع buildctl ، راجع هذا المستند.

استكشاف ليسانس الحقوق

تعتمد إصدارات BuildKit على تنسيق ثنائي وسيط يسمى LLB يُستخدم لتحديد الرسم البياني للتبعية للعمليات التي تقوم بتشغيل جزء من البناء الخاص بك. tl;dr: LLB هو لـ Dockerfile ما هو LLVM IR لـ C.

تم تنظيمها كرسائل Protobuf
قابلة للتنفيذ بشكل متزامن
قابلة للتخزين المؤقت بكفاءة
محايدة للبائع (أي يمكن تنفيذ اللغات غير Dockerfile بسهولة)

راجع solver/pb/ops.proto للحصول على تعريف التنسيق، وراجع ./examples/README.md على سبيل المثال تطبيقات LLB.

حاليًا، تم تطبيق اللغات عالية المستوى التالية لبرنامج LLB:

Dockerfile (راجع استكشاف ملفات Dockerfiles)
حزم البناء
ملف وهمي
ملف جوكر
بلدر (Pkgfile)
هلب
ايرثفيل (الأرضي)
رصيف الشحن (الصدأ)
لا شيء
موبي (بايثون)
إنفد (ستارلارك)
دهن
باس
كرافت.يامل (يونيكرافت)
r2d4/llb (بوابة JSON)
(افتح العلاقات العامة لإضافة لغتك الخاصة)

استكشاف ملفات دوكر

الواجهات الأمامية هي مكونات تعمل داخل BuildKit وتحول أي تعريف بناء إلى LLB. توجد واجهة أمامية خاصة تسمى البوابة ( gateway.v0 ) تسمح باستخدام أي صورة كواجهة أمامية.

أثناء التطوير، تعد الواجهة الأمامية لـ Dockerfile ( dockerfile.v0 ) أيضًا جزءًا من BuildKit repo. سيتم نقل هذا في المستقبل، ويمكن إنشاء ملفات Dockerfiles باستخدام صورة خارجية.

إنشاء ملف Dockerfile باستخدام `buildctl`

 buildctl
     --frontend=dockerfile.v0
     --السياق المحلي=.
     --local dockerfile=.# orbuildctl build
     --frontend=dockerfile.v0
     --السياق المحلي=.
     --ملف الإرساء المحلي = .
     --opt target=foo
     --opt build-arg:foo=bar

--local يعرض ملفات المصدر المحلية من العميل إلى المنشئ. context وملف dockerfile هما الأسماء التي تبحث عنها واجهة Dockerfile الأمامية لسياق البناء وموقع Dockerfile.

إذا كان لملف Dockerfile اسم ملف مختلف، فيمكن تحديده باستخدام --opt filename=./Dockerfile-alternative .

بناء ملف Dockerfile باستخدام الواجهة الخارجية

يتم دفع الإصدارات الخارجية من الواجهة الأمامية لـ Dockerfile إلى https://hub.docker.com/r/docker/dockerfile-upstream و https://hub.docker.com/r/docker/dockerfile ويمكن استخدامها مع الواجهة الأمامية للبوابة . مصدر الواجهة الأمامية الخارجية موجود حاليًا في ./frontend/dockerfile/cmd/dockerfile-frontend ولكنه سينتقل خارج هذا المستودع في المستقبل (#163). للإنشاء التلقائي من الفرع الرئيسي لهذا المستودع docker/dockerfile-upstream:master أو docker/dockerfile-upstream:master-labs يمكن استخدام الصورة.

 buildctl
     --بوابة الواجهة الأمامية.v0
     --opt source=docker/dockerfile
     --السياق المحلي=.
     --ملف الإرساء المحلي = .
buildctl
     --بوابة الواجهة الأمامية.v0
     --opt source=docker/dockerfile
     --opt context=https://github.com/moby/moby.git
     --opt build-arg:APT_MIRROR=cdn-fastly.deb.debian.org

الإخراج

افتراضيًا، ستبقى نتيجة البناء وذاكرة التخزين المؤقت المتوسطة داخليًا فقط في BuildKit. يجب تحديد الإخراج لاسترداد النتيجة.

الصورة/التسجيل

 buildctl build ... --output type=image,name=docker.io/username/image,push=true

لتصدير الصورة إلى سجلات متعددة:

 buildctl build ... --output type=image،"name=docker.io/username/image,docker.io/username2/image2"،push=true

لتصدير ذاكرة التخزين المؤقت المضمنة بالصورة ودفعها إلى التسجيل معًا، اكتب registry مطلوب لاستيراد ذاكرة التخزين المؤقت، يجب عليك تحديد --export-cache type=inline و --import-cache type=registry,ref=... . لتصدير ذاكرة التخزين المؤقت إلى محلي مباشرة، يجب عليك تحديد --export-cache type=local . التفاصيل في تصدير ذاكرة التخزين المؤقت.

 بناء ctl ...
  --output type=image,name=docker.io/username/image,push=true
   --export-cache type=inline
   --import-cache type=registry,ref=docker.io/username/image

المفاتيح التي يدعمها إخراج الصورة:

name= : تحديد اسم (أسماء) الصورة
push=true : ادفع بعد إنشاء الصورة
push-by-digest=true : ادفع الصورة غير المسماة
registry.insecure=true : اضغط إلى تسجيل HTTP غير الآمن
oci-mediatypes=true : استخدم أنواع وسائط OCI في تكوين JSON بدلاً من Docker's
unpack=true : فك ضغط الصورة بعد الإنشاء (للاستخدام مع الحاوية)
dangling-name-prefix= : اسم الصورة prefix@ ، يُستخدم للصور المجهولة
name-canonical=true : أضف اسمًا أساسيًا إضافيًا name@
compression= : اختر نوع الضغط للطبقات التي تم إنشاؤها حديثًا وتخزينها مؤقتًا، gzip هي القيمة الافتراضية. يجب استخدام estargz مع oci-mediatypes=true .
compression-level= : مستوى الضغط لـ gzip وestargz (0-9) وzstd (0-22)
rewrite-timestamp=true : أعد كتابة الطوابع الزمنية للملف إلى قيمة SOURCE_DATE_EPOCH . راجع docs/build-repro.md لمعرفة كيفية تحديد قيمة SOURCE_DATE_EPOCH .
force-compression=true : تطبيق خيار compression بقوة على جميع الطبقات (بما في ذلك الطبقات الموجودة بالفعل)
store=true : قم بتخزين الصور الناتجة في مخزن الصور الخاص بالعامل (على سبيل المثال، الحاوية) وكذلك التأكد من أن الصورة تحتوي على جميع النقط في مخزن المحتوى ( true افتراضي). يتم تجاهله إذا لم يكن لدى العامل مخزن صور (على سبيل المثال، عامل OCI).
annotation.= : إرفاق تعليق توضيحي key value المعنيين بالصورة المضمنة

باستخدام صيغ الجملة الموسعة، annotation-.= و annotation[].= وكلاهما مدمج مع annotation-[].= ، يسمح بتكوين مكان إرفاق التعليق التوضيحي بالضبط.
يحدد الكائن الذي سيتم إرفاقه به، ويمكن أن يكون أيًا من manifest (الافتراضي)، manifest-descriptor ، index ، index-descriptor
يحدد الكائنات التي سيتم إرفاقها بها (افتراضيًا، الكل)، وهو نفس المفتاح الذي تم تمريره إلى platform opt، راجع docs/multi-platform.md .
راجع docs/annotations.md لمزيد من التفاصيل.

إذا كانت بيانات الاعتماد مطلوبة، فسيحاول buildctl قراءة ملف تكوين Docker $DOCKER_CONFIG/config.json . $DOCKER_CONFIG الافتراضي هو ~/.docker .

الدليل المحلي

سيقوم العميل المحلي بنسخ الملفات مباشرة إلى العميل. يعد هذا مفيدًا إذا تم استخدام BuildKit لإنشاء شيء آخر غير صور الحاوية.

 buildctl build ... --output type=local,dest=path/to/output-dir

لتصدير ملفات محددة، استخدم تصميمات متعددة المراحل بمرحلة أولية وانسخ الملفات المطلوبة إلى تلك المرحلة باستخدام COPY --from .

 ...من البداية كـ testresultCOPY --from=builder /usr/src/app/testresult.xml .
...

 buildctl build ... --opt target=testresult --output type=local,dest=path/to/output-dir

من خلال إنشاء منصات متعددة، سيتم إنشاء مجلد فرعي يطابق كل منصة مستهدفة في الدليل الوجهة:

 من Busybox AS buildARG TARGETOSARG TARGETARCHRUN mkdir /out && echo foo > /out/hello-$TARGETOS-$TARGETARCHFROMخدشCOPY --from=build /out /

 بناء $ buildctl
   --الواجهة الأمامية dockerfile.v0
   --opt Platform=linux/amd64,linux/arm64
   --output type=local,dest=./bin/release

شجرة $ ./bin
./بن/
└── الافراج
    ├── linux_amd64
    │ └── مرحبا لينكس-amd64
    └── linux_arm64
        └── مرحبا لينكس-arm64

يمكنك ضبط platform-split=false لدمج الملفات من جميع الأنظمة الأساسية معًا في نفس الدليل:

 بناء $ buildctl
   --الواجهة الأمامية dockerfile.v0
   --opt Platform=linux/amd64,linux/arm64
   --نوع الإخراج=local,dest=./bin/release,platform-split=false

شجرة $ ./bin
./بن/
└── الافراج
    ├── مرحبا لينكس-amd64
    └── مرحبا لينكس-arm64

يشبه مُصدِّر القطران المُصدِّر المحلي ولكنه ينقل الملفات من خلال كرة القطران.

 buildctl build... --output type=tar,dest=out.tar
buildctl build... --output type=tar > out.tar

قطران عامل الميناء

 # كرة القطران المصدرة متوافقة أيضًا مع OCI specbuildctl build ... --output type=docker,name=myimage | تحميل عامل ميناء

OCI كرة القطران

 buildctl build ... --output type=oci,dest=path/to/output.tar
buildctl build... --output type=oci >output.tar

مخزن الصور المعبأة

يجب استخدام عامل الحاوية

 buildctl build ... --output type=image,name=docker.io/username/image
CTR --namespace=buildkit Images ls

لتغيير مساحة الاسم الحاوية، تحتاج إلى تغيير worker.containerd.namespace في /etc/buildkit/buildkitd.toml .

مخبأ

لإظهار ذاكرة التخزين المؤقت للبناء المحلي ( /var/lib/buildkit ):

 buildctl دو -v

لتقليم ذاكرة التخزين المؤقت للبناء المحلي:

 buildctl

جمع القمامة

راجع ./docs/buildkitd.toml.md .

تصدير ذاكرة التخزين المؤقت

يدعم BuildKit مصدري ذاكرة التخزين المؤقت التالية:

inline : قم بتضمين ذاكرة التخزين المؤقت في الصورة، ثم ادفعها إلى السجل معًا
registry : ادفع الصورة وذاكرة التخزين المؤقت بشكل منفصل
local : تصدير إلى دليل محلي
gha : تصدير إلى ذاكرة التخزين المؤقت لإجراءات GitHub

في معظم الحالات، تريد استخدام مُصدِّر ذاكرة التخزين inline . ومع ذلك، لاحظ أن مُصدِّر ذاكرة التخزين inline يدعم فقط وضع ذاكرة التخزين min . لتمكين وضع ذاكرة التخزين max ، ادفع الصورة وذاكرة التخزين المؤقت بشكل منفصل باستخدام مُصدّر ذاكرة التخزين registry .

يقوم كل من المصدرين inline registry بتخزين ذاكرة التخزين المؤقت في السجل. لاستيراد ذاكرة التخزين المؤقت، يعد type=registry كافيًا لكليهما، حيث إن تحديد تنسيق ذاكرة التخزين المؤقت ليس ضروريًا.

مضمّن (ادفع الصورة وذاكرة التخزين المؤقت معًا)

 بناء ctl ...
   --output type=image,name=docker.io/username/image,push=true
   --export-cache type=inline
   --import-cache type=registry,ref=docker.io/username/image

لاحظ أنه لا يتم استيراد ذاكرة التخزين المؤقت المضمنة ما لم يتم توفير --import-cache type=registry,ref=...

تقوم ذاكرة التخزين المؤقت المضمنة بتضمين بيانات تعريف ذاكرة التخزين المؤقت في تكوين الصورة. سيتم ترك الطبقات الموجودة في الصورة دون تغيير مقارنةً بالصورة التي لا تحتوي على معلومات ذاكرة تخزين مؤقت.

يتطلب BuildKit المدمج في Docker ( DOCKER_BUILDKIT=1 docker build ) و docker buildx تحديد --build-arg BUILDKIT_INLINE_CACHE=1 لتمكين مُصدّر ذاكرة التخزين inline . ومع ذلك، فإن buildctl المستقل لا يتطلب --opt build-arg:BUILDKIT_INLINE_CACHE=1 ويتم تجاهل build-arg ببساطة.

التسجيل (ادفع الصورة وذاكرة التخزين المؤقت بشكل منفصل)

 بناء ctl ...
   --نوع الإخراج = الصورة، الاسم = المضيف المحلي: 5000/myrepo: الصورة، الدفع = صحيح
   --export-cache type=registry,ref=localhost:5000/myrepo:buildcache
   --import-cache type=registry,ref=localhost:5000/myrepo:buildcache

--export-cache :

type=registry
mode= : تحديد طبقات ذاكرة التخزين المؤقت للتصدير (الافتراضي: min )

min : تصدير طبقات الصورة الناتجة فقط
max : تصدير جميع طبقات جميع الخطوات المتوسطة

ref= : حدد مرجع المستودع لتخزين ذاكرة التخزين المؤقت، على سبيل المثال docker.io/user/image:tag
image-manifest= : ما إذا كان سيتم تصدير بيان ذاكرة التخزين المؤقت كبيان صورة متوافق مع OCI بدلاً من قائمة/فهرس البيان (الافتراضي: false ، يجب استخدامه مع oci-mediatypes=true )
oci-mediatypes= : ما إذا كان سيتم استخدام أنواع وسائط OCI في البيانات المُصدَّرة (الافتراضي: true ، منذ الإصدار BuildKit v0.8 )
compression= : اختر نوع الضغط للطبقات التي تم إنشاؤها حديثًا وتخزينها مؤقتًا، gzip هي القيمة الافتراضية. يجب استخدام estargz وzstd مع oci-mediatypes=true
compression-level= : اختر مستوى الضغط لـ gzip وestargz (0-9) وzstd (0-22)
force-compression=true : تطبيق خيار compression بالقوة على جميع الطبقات
ignore-error= : تحديد ما إذا كان سيتم تجاهل الخطأ في حالة فشل تصدير ذاكرة التخزين المؤقت (الافتراضي: false )

--import-cache :

type=registry
ref= : حدد مرجع المستودع لاسترداد ذاكرة التخزين المؤقت منه، على سبيل المثال docker.io/user/image:tag

الدليل المحلي

 buildctl build ... --export-cache type=local,dest=path/to/output-dir
buildctl build ... --import-cache type=local,src=path/to/input-dir

يتوافق تخطيط الدليل مع OCI Image Spec v1.0.

--export-cache :

type=local
mode= : تحديد طبقات ذاكرة التخزين المؤقت للتصدير (الافتراضي: min )

min : تصدير طبقات الصورة الناتجة فقط
max : تصدير جميع طبقات جميع الخطوات المتوسطة

dest= : الدليل الوجهة لمصدر ذاكرة التخزين المؤقت
tag= : حدد علامة مخصصة للصورة للكتابة إلى الفهرس المحلي (الافتراضي: latest )
image-manifest= : ما إذا كان سيتم تصدير بيان ذاكرة التخزين المؤقت كبيان صورة متوافق مع OCI بدلاً من قائمة/فهرس البيان (الافتراضي: false ، يجب استخدامه مع oci-mediatypes=true )
oci-mediatypes= : ما إذا كان سيتم استخدام أنواع وسائط OCI في البيانات المُصدَّرة ( true افتراضي، منذ v0.8 من BuildKit)
compression= : اختر نوع الضغط للطبقات التي تم إنشاؤها حديثًا وتخزينها مؤقتًا، gzip هي القيمة الافتراضية. يجب استخدام estargz وzstd مع oci-mediatypes=true .
compression-level= : مستوى الضغط لـ gzip وestargz (0-9) وzstd (0-22)
force-compression=true : تطبيق خيار compression بالقوة على جميع الطبقات
ignore-error= : تحديد ما إذا كان سيتم تجاهل الخطأ في حالة فشل تصدير ذاكرة التخزين المؤقت (الافتراضي: false )

--import-cache :

type=local
src= : الدليل المصدر لمستورد ذاكرة التخزين المؤقت
tag= : حدد علامة مخصصة للصورة لقراءتها من الفهرس المحلي (الافتراضي: latest )
digest=sha256: : حدد ملخصًا صريحًا لقائمة البيانات المراد استيرادها

ذاكرة التخزين المؤقت لإجراءات GitHub (تجريبية)

 بناء ctl ...
   --output type=image,name=docker.io/username/image,push=true
   --export-cache type=gha
   --import-cache type=gha

تقوم ذاكرة التخزين المؤقت لـ GitHub Actions بحفظ بيانات تعريف ذاكرة التخزين المؤقت والطبقات في خدمة ذاكرة التخزين المؤقت الخاصة بـ GitHub. يبلغ الحد الأقصى لحجم ذاكرة التخزين المؤقت هذه حاليًا 10 جيجابايت والتي تتم مشاركتها عبر ذاكرات تخزين مؤقت مختلفة في الريبو. إذا تجاوزت هذا الحد، فسيقوم GitHub بحفظ ذاكرة التخزين المؤقت الخاصة بك ولكنه سيبدأ في إزالة ذاكرة التخزين المؤقت حتى يصبح الحجم الإجمالي أقل من 10 جيجابايت. يمكن أن تؤدي إعادة تدوير ذاكرة التخزين المؤقت في كثير من الأحيان إلى إبطاء أوقات التشغيل بشكل عام.

على غرار استخدام الإجراءات/ذاكرة التخزين المؤقت، يتم تحديد نطاق ذاكرات التخزين المؤقت حسب الفرع، مع إتاحة الفروع الافتراضية والهدف لكل فرع.

السمات التالية مطلوبة للمصادقة مقابل واجهة برمجة تطبيقات خدمة GitHub Actions Cache:

url : عنوان URL لخادم ذاكرة التخزين المؤقت (الافتراضي $ACTIONS_CACHE_URL )
token : رمز الوصول (الافتراضي $ACTIONS_RUNTIME_TOKEN )

يمكن استخدام هذا النوع من ذاكرة التخزين المؤقت مع Docker Build Push Action حيث سيتم تعيين url والرمز token تلقائيًا. لاستخدام هذه الواجهة الخلفية في خطوة run مضمّنة، يجب عليك تضمين Crazy-max/ghaction-github-runtime في سير عملك لكشف وقت التشغيل.

--export-cache :

type=gha
mode= : تحديد طبقات ذاكرة التخزين المؤقت للتصدير (الافتراضي: min )

min : تصدير طبقات الصورة الناتجة فقط
max : تصدير جميع طبقات جميع الخطوات المتوسطة

scope= : ينتمي كائن ذاكرة التخزين المؤقت للنطاق ( buildkit الافتراضية)
ignore-error= : تحديد ما إذا كان سيتم تجاهل الخطأ في حالة فشل تصدير ذاكرة التخزين المؤقت (الافتراضي: false )
timeout= : يحدد مدة المهلة لتصدير ذاكرة التخزين المؤقت (الافتراضي: 10m )

--import-cache :

type=gha
scope= : ينتمي كائن ذاكرة التخزين المؤقت للنطاق ( buildkit الافتراضية)
timeout= : يحدد مدة المهلة لاستيراد ذاكرة التخزين المؤقت (الافتراضي: 10m )

ذاكرة التخزين المؤقت S3 (تجريبية)

 بناء ctl ...
   --output type=image,name=docker.io/username/image,push=true
   --export-cache type=s3,region=eu-west-1,bucket=my_bucket,name=my_image
   --import-cache type=s3,region=eu-west-1,bucket=my_bucket,name=my_image

السمات التالية مطلوبة:

bucket : دلو AWS S3 (الافتراضي: $AWS_BUCKET )
region : منطقة AWS (الافتراضي: $AWS_REGION )

مواقع التخزين:

النقط: s3://// ، الافتراضي: s3:///blobs/
البيانات: s3://// ، الافتراضي: s3:///manifests/

تكوين S3:

blobs_prefix : بادئة عامة لتخزين/قراءة النقط على s3 (الافتراضي: blobs/ )
manifests_prefix : بادئة عامة لتخزين/قراءة البيانات على s3 (الافتراضي: manifests/ )
endpoint_url : حدد نقطة نهاية S3 محددة (الافتراضي: فارغ)
use_path_style : إذا تم ضبطه على true ، ضع اسم المجموعة في عنوان URL بدلاً من اسم المضيف (الافتراضي: false )

مصادقة AWS:

إن أبسط طريقة هي استخدام ملف تعريف مثيل IAM. الخيارات الأخرى هي:

أي نظام يستخدم متغيرات البيئة/ملفات التكوين المدعومة بواسطة AWS Go SDK. يجب أن يكون التكوين متاحًا لبرنامج buildkit الخفي، وليس للعميل.
باستخدام السمات التالية:

access_key_id : معرف مفتاح الوصول
secret_access_key : مفتاح الوصول السري
session_token : رمز الجلسة

--export-cache :

type=s3
mode= : تحديد طبقات ذاكرة التخزين المؤقت للتصدير (الافتراضي: min )

min : تصدير طبقات الصورة الناتجة فقط
max : تصدير جميع طبقات جميع الخطوات المتوسطة

prefix= : قم بتعيين البادئة العامة لتخزين/قراءة الملفات على s3 (الافتراضي: فارغ)
name= : حدد اسم البيان المراد استخدامه ( buildkit الافتراضية)

يمكن تحديد أسماء بيانات متعددة في نفس الوقت، مفصولة بـ ; . حالة الاستخدام القياسية هي استخدام git sha1 كاسم، واسم الفرع كنسخة مكررة، وتحميل كليهما باستخدام أمرين import-cache .

ignore-error= : تحديد ما إذا كان سيتم تجاهل الخطأ في حالة فشل تصدير ذاكرة التخزين المؤقت (الافتراضي: false )
touch_refresh=24h : بدلاً من تحميلها مرة أخرى عندما لا يتم تغييرها، سيتم "لمس" ملفات blobs على s3 كل touch_refresh ، الافتراضي هو 24 ساعة. ونتيجة لذلك، يمكن تعيين سياسة انتهاء الصلاحية في حاوية S3 لتنظيف الملفات غير المفيدة تلقائيًا. تتم إعادة كتابة ملفات البيانات بشكل منهجي، وليس هناك حاجة للمسها.
upload_parallelism=4 : تغير هذه المعلمة عدد الطبقات التي تم تحميلها إلى s3 بالتوازي. يتم تحميل كل طبقة فردية باستخدام 5 سلاسل رسائل، باستخدام مدير التحميل الذي توفره AWS SDK.

--import-cache :

type=s3
prefix= : قم بتعيين البادئة العامة لتخزين/قراءة الملفات على s3 (الافتراضي: فارغ)
blobs_prefix= : تعيين البادئة العامة لتخزين/قراءة النقط على s3 (الافتراضي: blobs/ )
manifests_prefix= : تعيين البادئة العامة لتخزين/قراءة البيانات على s3 (الافتراضي: manifests/ )
name= : اسم البيان المطلوب استخدامه ( buildkit الافتراضي)

ذاكرة التخزين المؤقت لـ Azure Blob (تجريبية)

 بناء ctl ...
   --output type=image,name=docker.io/username/image,push=true
   --export-cache type=azblob,account_url=https://myaccount.blob.core.windows.net,name=my_image
   --import-cache type=azblob,account_url=https://myaccount.blob.core.windows.net,name=my_image

السمات التالية مطلوبة:

account_url : عنوان URL لحساب Azure Blob Storage (الافتراضي: $BUILDKIT_AZURE_STORAGE_ACCOUNT_URL )

مواقع التخزين:

النقط: /// ، الافتراضي: //blobs/
البيانات: /// ، الافتراضي: //manifests/

تكوين تخزين Azure Blob:

container : اسم حاوية Azure Blob Storage (الافتراضي: buildkit-cache أو $BUILDKIT_AZURE_STORAGE_CONTAINER إذا تم تعيينه)
blobs_prefix : بادئة عامة لتخزين/قراءة النقط في حاوية تخزين Azure Blob ( ) (الافتراضي: blobs/ )
manifests_prefix : البادئة العامة لتخزين/قراءة الكائنات الثنائية الكبيرة في حاوية تخزين Azure Blob ( ) (الافتراضي: manifests/ )

مصادقة تخزين Azure Blob:

هناك خياران مدعومان لمصادقة Azure Blob Storage:

أي نظام يستخدم متغيرات البيئة المدعومة بواسطة Azure SDK for Go. يجب أن يكون التكوين متاحًا لبرنامج buildkit الخفي، وليس للعميل.
مفتاح الوصول السري، باستخدام السمة secret_access_key لتحديد مفتاح الحساب الأساسي أو الثانوي لحساب Azure Blob Storage الخاص بك. مفاتيح حساب Azure Blob Storage

ملحوظة

يمكن أيضًا تحديد اسم الحساب باستخدام سمة account_name (أو $BUILDKIT_AZURE_STORAGE_ACCOUNT_NAME ) إذا لم يكن جزءًا من مضيف عنوان URL للحساب.

--export-cache :

type=azblob
mode= : تحديد طبقات ذاكرة التخزين المؤقت للتصدير (الافتراضي: min )

min : تصدير طبقات الصورة الناتجة فقط
max : تصدير جميع طبقات جميع الخطوات المتوسطة

prefix= : قم بتعيين البادئة العامة لتخزين/قراءة الملفات في حاوية تخزين Azure Blob ( ) (الافتراضي: فارغ)
name= : حدد اسم البيان المراد استخدامه (الافتراضي: buildkit )

يمكن تحديد أسماء بيانات متعددة في نفس الوقت، مفصولة بـ ; . حالة الاستخدام القياسية هي استخدام git sha1 كاسم، واسم الفرع كنسخة مكررة، وتحميل كليهما باستخدام أمرين import-cache .

ignore-error= : تحديد ما إذا كان سيتم تجاهل الخطأ في حالة فشل تصدير ذاكرة التخزين المؤقت (الافتراضي: false )

--import-cache :

type=azblob
prefix= : قم بتعيين البادئة العامة لتخزين/قراءة الملفات في حاوية تخزين Azure Blob ( ) (الافتراضي: فارغ)
blobs_prefix= : قم بتعيين البادئة العامة لتخزين/قراءة النقط في حاوية تخزين Azure Blob ( ) (الافتراضي: blobs/ )
manifests_prefix= : قم بتعيين البادئة العامة لتخزين/قراءة البيانات في حاوية تخزين Azure Blob ( ) (الافتراضي: manifests/ )
name= : اسم البيان المطلوب استخدامه (الافتراضي: buildkit )

التجزئة متسقة

إذا كان لديك العديد من مثيلات برنامج BuildKit الخفي، ولكنك لا تريد استخدام التسجيل لمشاركة ذاكرة التخزين المؤقت عبر المجموعة، ففكر في موازنة التحميل من جانب العميل باستخدام التجزئة المتسقة.

راجع ./examples/kubernetes/consistenthash .

البيانات الوصفية

لإخراج بيانات تعريف البناء مثل ملخص الصورة، قم بتمرير علامة --metadata-file . ستتم كتابة البيانات الوصفية ككائن JSON إلى الملف المحدد. يجب أن يكون دليل الملف المحدد موجودًا بالفعل وقابلاً للكتابة.

 buildctl build... --metadata-file metadata.json

 جك '.' metadata.json

 { "containerimage.config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66"، "containerimage.descriptor": {"annotations": { "config.digest": f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66"، "org.opencontainers.image.created": " 2022-02-08T21:28:03Z"}"،digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3"، "mediaType": "application/vnd.oci.image.manifest.v1+json"، "size": "50 6
  }, "containerimage.digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3"}

تفعيل مقبس Systemd

في الأنظمة المستندة إلى Systemd، يمكنك التواصل مع البرنامج الخفي عبر تنشيط مقبس Systemd، استخدم buildkitd --addr fd:// . يمكنك العثور على أمثلة لاستخدام تنشيط مأخذ توصيل Systemd مع BuildKit وSystemd في ./examples/systemd .

كشف BuildKit كخدمة TCP

يمكن لبرنامج buildkitd الاستماع إلى واجهة برمجة تطبيقات gRPC على مقبس TCP.

يوصى بشدة بإنشاء شهادات TLS لكل من البرنامج الخفي والعميل (mTLS). يعد تمكين TCP بدون mTLS أمرًا خطيرًا لأن حاويات المنفذ (المعروفة أيضًا باسم حاويات Dockerfile RUN ) يمكنها الاتصال بـ BuildKit API أيضًا.

 buildkitd
   --addr tcp://0.0.0.0:1234
   --tlscacert /path/to/ca.pem
   --tlscert /path/to/cert.pem
   --tlskey /path/to/key.pem

 buildctl
   --addr tcp://example.com:1234
   --tlscacert /path/to/ca.pem
   --tlscert /path/to/clientcert.pem
   --tlskey /path/to/clientkey.pem
   يبني ...

موازنة التحميل

يمكن استدعاء buildctl build مقابل تحميل برامج buildkitd المتوازنة بشكل عشوائي.

راجع أيضًا التجزئة المتسقة لموازنة التحميل من جانب العميل.

حاوية BuildKit

يمكن أيضًا استخدام BuildKit عن طريق تشغيل البرنامج الخفي buildkitd داخل حاوية Docker والوصول إليه عن بُعد.

نحن نقدم صور الحاوية كـ moby/buildkit :

moby/buildkit:latest : تم إنشاؤه من أحدث إصدار منتظم
moby/buildkit:rootless : نفس latest ولكنه يعمل كمستخدم لا يتمتع بأي امتيازات، راجع docs/rootless.md
moby/buildkit:master : تم إنشاؤه من الفرع الرئيسي
moby/buildkit:master-rootless : مثل master ولكنه يعمل كمستخدم لا يتمتع بأي امتيازات، راجع docs/rootless.md

لتشغيل البرنامج الخفي في حاوية:

 تشغيل عامل الميناء -d --اسم buildkitd --privileged moby/buildkit:latestexport BUILDKIT_HOST=docker-container://buildkitd
بناء buildctl - مساعدة

بودمان

للاتصال ببرنامج BuildKit الخفي الذي يعمل في حاوية Podman، استخدم podman-container:// بدلاً من docker-container:// .

 podman run -d --name buildkitd --privileged moby/buildkit:latest
buildctl --addr=podman-container://buildkitd build --frontend dockerfile.v0 --local context=. --ملف الإرساء المحلي = . --نوع الإخراج = oci | تحميل بودمان foo

sudo غير مطلوب.

نيردكتل

للاتصال بعفريت BuildKit الذي يعمل في حاوية Nerdctl، استخدم nerdctl-container:// بدلاً من docker-container:// .

 Nerdctl run -d --name buildkitd --privileged moby/buildkit:latest
buildctl --addr=nerdctl-container://buildkitd build --frontend dockerfile.v0 --local context=. --ملف الإرساء المحلي = . --نوع الإخراج = oci | تحميل nerdctl

sudo غير مطلوب.

كوبيرنيتيس

بالنسبة لعمليات نشر Kubernetes، راجع examples/kubernetes .

بلا شيطان

لتشغيل العميل والبرنامج الخفي سريع الزوال في حاوية واحدة ("الوضع غير الخفي"):

 تشغيل عامل الميناء
     -هو - هي
     --rm
     --متميز
     -v /path/to/dir:/tmp/work
     --entrypoint buildctl-daemonless.sh
     موبي/Buildkit:ماستر
         يبني
         --الواجهة الأمامية dockerfile.v0
         --local context=/tmp/work
         --local dockerfile=/tmp/work

أو

 تشغيل عامل الميناء
     -هو - هي
     --rm
     --security-opt seccomp=unconfined
     --security-opt apparmor=unconfined
     -e BUILDKITD_FLAGS=--oci-worker-no-process-sandbox
     -v /path/to/dir:/tmp/work
     --entrypoint buildctl-daemonless.sh
     moby/buildkit:master-rootless
         يبني
         --الواجهة الأمامية
         ملف الإرساء.v0
         --local context=/tmp/work
         --local dockerfile=/tmp/work

دعم القياس عن بعد المفتوح

يدعم BuildKit OpenTelemetry لأوامر buildkitd gRPC API وأوامر buildctl. لالتقاط التتبع لـ Jaeger، قم بتعيين متغير البيئة JAEGER_TRACE على عنوان المجموعة.

 docker run -d -p6831:6831/udp -p16686:16686 jaegertracing/all-in-one:latestexport JAEGER_TRACE=0.0.0.0:6831# أعد تشغيل buildkitd وbuildctl حتى يعرفوا JAEGER_TRACE# يجب تتبع أي أمر buildctl إلى http:/ /127.0.0.1:16686/

على نظام التشغيل Windows، إذا كنت تقوم بتشغيل Jaeger خارج حاوية، jaeger-all-in-one.exe ، فاضبط متغير البيئة setx -m JAEGER_TRACE "0.0.0.0:6831" ، وأعد تشغيل buildkitd في محطة جديدة وسيتم حذف الآثار يتم جمعها تلقائيا.

تشغيل BuildKit بدون امتيازات الجذر

يرجى الرجوع إلى docs/rootless.md .

بناء صور متعددة المنصات

يرجى الرجوع إلى docs/multi-platform.md .

تكوين `buildctl`

ضوابط إخراج اللون

يتمتع buildctl بدعم تعديل الألوان المستخدمة لإخراج المعلومات إلى الجهاز. يمكنك تعيين متغير البيئة BUILDKIT_COLORS على شيء مثل run=green:warning=yellow:error=red:cancel=255,165,0 لتعيين الألوان التي ترغب في استخدامها. سيؤدي ضبط NO_COLOR على أي شيء إلى تعطيل أي مخرجات ملونة على النحو الموصى به بواسطة no-color.org.

سيتم الإبلاغ عن أخطاء التحليل ولكن سيتم تجاهلها. سيؤدي هذا إلى استخدام قيم الألوان الافتراضية عند الحاجة.

قائمة الألوان المحددة مسبقًا.

عدد أسطر السجل (للخطوات النشطة في وضع tty)

يمكنك تغيير عدد أسطر السجل المرئية للخطوات النشطة في وضع tty عن طريق تعيين BUILDKIT_TTY_LOG_LINES على رقم (الافتراضي: 6).

المساهمة

هل تريد المساهمة في BuildKit؟ مذهل! يمكنك العثور على معلومات حول المساهمة في هذا المشروع في CONTRIBUTING.md

يوسع

معلومات إضافية

الإصدار 0.17.0
النوع شفرة المصدر الأخرى
وقت التحديث 2024-11-05
الحجم
اللغة الصينية المبسطة

تطبيقات ذات صلة

نوصي لك

أخبار ذات صلة الكل

تعليقات المستخدمين

buildkit

BuildKit

يستخدم من قبل

بداية سريعة

إعداد لينكس

إعداد ويندوز

إعداد ماك

البناء من المصدر

استكشاف ليسانس الحقوق

استكشاف ملفات دوكر

إنشاء ملف Dockerfile باستخدام buildctl

بناء ملف Dockerfile باستخدام الواجهة الخارجية

الإخراج

الصورة/التسجيل

الدليل المحلي

قطران عامل الميناء

OCI كرة القطران

مخزن الصور المعبأة

مخبأ

جمع القمامة

تصدير ذاكرة التخزين المؤقت

مضمّن (ادفع الصورة وذاكرة التخزين المؤقت معًا)

التسجيل (ادفع الصورة وذاكرة التخزين المؤقت بشكل منفصل)

الدليل المحلي

ذاكرة التخزين المؤقت لإجراءات GitHub (تجريبية)

ذاكرة التخزين المؤقت S3 (تجريبية)

ذاكرة التخزين المؤقت لـ Azure Blob (تجريبية)

التجزئة متسقة

البيانات الوصفية

تفعيل مقبس Systemd

كشف BuildKit كخدمة TCP

موازنة التحميل

حاوية BuildKit

بودمان

نيردكتل

كوبيرنيتيس

بلا شيطان

دعم القياس عن بعد المفتوح

تشغيل BuildKit بدون امتيازات الجذر

بناء صور متعددة المنصات

تكوين buildctl

ضوابط إخراج اللون

عدد أسطر السجل (للخطوات النشطة في وضع tty)

المساهمة

إنشاء ملف Dockerfile باستخدام `buildctl`

تكوين `buildctl`