kaniko تنزيل - kaniko تنزيل كود المصدر

kaniko

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

v1.23.2

تنزيل

kaniko - بناء الصور في Kubernetes

ملاحظة: kaniko ليس أحد منتجات Google المدعومة رسميًا

القيود والمزالق

ويجب استيفاء الشروط التالية:

أنت بحاجة إلى الوصول إلى أجهزة البناء التي تقوم بتشغيل البنى المطلوبة (تشغيل Kaniko في أحد المحاكي، على سبيل المثال، QEMU يجب أن يكون ممكنًا أيضًا ولكنه يتجاوز نطاق هذه الوثائق). هذا شيء يجب أخذه في الاعتبار عند استخدام أدوات بناء SaaS مثل github.com أو gitlab.com، والتي في وقت كتابة هذا التقرير لم تكن تدعم أي مشغلات SaaS غير x86_64 (GitHub،GitLab)، لذا كن مستعدًا لإحضار أدواتك الخاصة الآلات (GitHub،GitLab.
يجب أن تكون Kaniko قادرة على العمل على البنى المطلوبة. في وقت كتابة هذا التقرير، كانت حاوية Kaniko الرسمية تدعم linux/amd64 وlinux/arm64 وlinux/s390x وlinux/ppc64le (وليس على الصور *-debug).
يجب أن يكون سجل الحاوية الذي تختاره متوافقًا مع OCIv1 أو Docker v2.2.

مثال على خط أنابيب CI (GitLab)

الأمر متروك لك للعثور على أداة التشغيل الآلي التي تناسب احتياجاتك بشكل أفضل. نوصي باستخدام نظام CI/CD حديث مثل سير عمل GitHub أو GitLab CI. نظرًا لأننا (المؤلفون) نستخدم GitLab CI، فقد تم تصميم الأمثلة التالية خصيصًا لهذا النظام الأساسي المحدد ولكن المبادئ الأساسية يجب أن تنطبق في أي مكان آخر ويتم الاحتفاظ بالأمثلة بسيطة بما فيه الكفاية، حتى تتمكن من المتابعة، حتى بدون أي التجارب السابقة مع هذه المنصة المحددة. في حالة الشك، قم بزيارة الصفحة المرجعية gitlab-ci.yml للحصول على نظرة عامة شاملة حول الكلمات الأساسية لـ GitLab CI.

بناء صور الحاوية المنفصلة

جيتلاب-ci.yml:

 # تحديد وظيفة لبناء الحاوية - حاوية البناء: المرحلة: حاوية البناء
  # تشغيل بنيات متوازية للبنيات المطلوبة
  بالتوازي :مصفوفة:
      - القوس: amd64 - القوس: الذراع 64
  العلامات:# تشغيل كل بناء على عداء مناسب تم تكوينه مسبقًا (يجب أن يتطابق مع البنية المستهدفة)- runner-${ARCH}
  الصورة: الاسم: gcr.io/kaniko-project/executor:debugentrypoint: [""]
  script:# أنشئ صورة الحاوية للقوس الحالي باستخدام kaniko- >- /kaniko/executor --context "${CI_PROJECT_DIR}" --dockerfile "${CI_PROJECT_DIR}/Dockerfile" # ادفع الصورة إلى سجل حاوية GitLab، أضف القوس الحالي كعلامة. --الوجهة "${CI_REGISTRY_IMAGE}:${ARCH}"

دمج بيانات الحاوية

جيتلاب-ci.yml:

 # تحديد مهمة لإنشاء ودفع بيان مدمج مدمج: المرحلة: حاوية بناء
  # يجب بناء كافة الحاويات قبل دمجها
  # وبدلاً من ذلك، قد يتم تكوين المهمة لتعمل في مرحلة لاحقة
  الاحتياجات:
    - الوظيفة: مصنوعات بناء الحاوية: كاذبة
  العلامات:# قد تعمل على أي بنية تدعمها صورة أداة البيان- عداء-xyz
  الصورة: الاسم: mplatform/manifest-tool:alpineentrypoint: [""]
  البرنامج النصي:
    ->- أداة البيان # التفويض ضد سجل الحاوية الخاص بك --username=${CI_REGISTRY_USER} --password=${CI_REGISTRY_PASSWORD} Push from-args # تحديد البنيات التي تريد دمجها --platforms linux/amd64,linux/arm64 # سيتم استبدال "ARCH" تلقائيًا بأداة البيان # مع القوس المناسب من تعريفات النظام الأساسي --template ${CI_REGISTRY_IMAGE}:ARCH # اسم الصورة النهائية المدمجة التي سيتم دفعها إلى السجل الخاص بك --target ${CI_REGISTRY_IMAGE}

في ملاحظة إضافة العلامات ذات الإصدار

من أجل التبسيط، امتنعنا عمدًا عن استخدام الصور ذات العلامات ذات الإصدارات (سيتم وضع علامة على جميع الإصدارات على أنها "الأحدث") في الأمثلة السابقة، حيث نشعر أن هذا يضيف إلى الكثير من التعليمات البرمجية الخاصة بالنظام الأساسي وسير العمل.

ومع ذلك، لأي شخص مهتم بكيفية تعاملنا مع الإصدارات (الديناميكية) في GitLab، إليك ملخص قصير:

إذا كنت مهتمًا فقط بإنشاء الإصدارات الموسومة، فيمكنك ببساطة استخدام متغير CI_COMMIT_TAG المحدد مسبقًا في GitLab عند تشغيل مسار العلامات.
عندما ترغب (مثلنا) في إنشاء صور حاوية بالإضافة إلى ذلك خارج الإصدارات، تصبح الأمور أكثر فوضوية بعض الشيء. في حالتنا، أضفنا وظيفة إضافية يتم تشغيلها قبل وظائف الإنشاء والدمج (لا تنس توسيع قسم needs في وظائف الإنشاء والدمج وفقًا لذلك)، والتي ستعين العلامة على latest عند التشغيل على الفرع الافتراضي، إلى تجزئة الالتزام عند تشغيلها على فروع أخرى وإلى علامة الإصدار عند تشغيلها على خط أنابيب العلامات.

جيتلاب-ci.yml:

 الحصول على علامة الحاوية: المرحلة: مرحلة ما قبل بناء الحاوية
  العلامات:
    - عداء XYZ
  الصورة: صندوق مشغول
  script:# يتم وضع علامة على جميع الفروع الأخرى بتجزئة SHA المضمنة حاليًا- |      # إذا كان خط الأنابيب يعمل على الفرع الافتراضي: اضبط العلامة على "الأحدث" if test "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH"; ثم tag="latest" # إذا كان خط الأنابيب عبارة عن خط أنابيب علامات، فقم بتعيين العلامة على علامة التزام git elif test -n "$CI_COMMIT_TAG"; ثم tag="$CI_COMMIT_TAG" # وإلا قم بتعيين العلامة على git الالتزام sha else tag="$CI_COMMIT_SHA" fi - echo "tag=$tag" > build.env
  # علامة التحليل لبناء ودمج المهام.
  # راجع: https://docs.gitlab.com/ee/ci/variables/#pass-an-environment-variable-to-another-job
  المصنوعات اليدوية: التقارير: dotenv: build.env

مقارنة مع أدوات أخرى

تشمل الأدوات المماثلة ما يلي:

BuildKit
img
orca-build
umoci
buildah
FTL
قواعد بازل_docker

تقوم كل هذه الأدوات بإنشاء صور حاوية بطرق مختلفة.

يمكن أن يعمل BuildKit (و img ) كمستخدم غير جذر من داخل الحاوية ولكنه يتطلب تعطيل seccomp وAppArmor لإنشاء حاويات متداخلة. لا يقوم kaniko فعليًا بإنشاء حاويات متداخلة، لذلك لا يتطلب تعطيل seccomp وAppArmor. يدعم BuildKit الحاويات متعددة الأقواس "المتقاطعة" من خلال الاستفادة من QEMU.

يعتمد orca-build على runc لإنشاء صور من Dockerfiles، والتي لا يمكن تشغيلها داخل حاوية (لأسباب مشابهة لـ img أعلاه). لا يستخدم kaniko runc لذا فهو لا يتطلب استخدام تقنيات مسافة أسماء kernel. ومع ذلك، لا يتطلب orca-build وجود Docker أو أي برنامج خفي ذي امتيازات (لذلك يمكن تنفيذ عمليات البناء بالكامل دون امتياز).

يعمل umoci بدون أي امتيازات، كما أنه ليس لديه أي قيود على استخراج نظام الملفات الجذر (على الرغم من أنه يتطلب معالجة إضافية إذا كان نظام الملفات الخاص بك معقدًا بما فيه الكفاية). ومع ذلك، فهو لا يحتوي على أدوات بناء تشبه Dockerfile (إنها أداة ذات مستوى أقل قليلاً يمكن استخدامها لبناء مثل هذه الأدوات - مثل orca-build ).

Buildah متخصص في بناء صور OCI. أوامر Buildah تكرر كافة الأوامر الموجودة في ملف Dockerfile. يتيح ذلك إنشاء صور باستخدام ملفات Dockerfiles وبدونها دون الحاجة إلى أي امتيازات جذر. الهدف النهائي لـ Buildah هو توفير واجهة أساسية ذات مستوى أدنى لإنشاء الصور. تسمح مرونة إنشاء الصور بدون Dockerfiles بدمج لغات البرمجة النصية الأخرى في عملية الإنشاء. يتبع Buildah نموذجًا بسيطًا fork-exec ولا يعمل كبرنامج خفي ولكنه يعتمد على واجهة برمجة تطبيقات شاملة في golang، والتي يمكن بيعها إلى أدوات أخرى.

تهدف FTL و Bazel إلى تحقيق أسرع إنشاء ممكن لصور Docker لمجموعة فرعية من الصور. يمكن اعتبارها "مسارًا سريعًا" خاصًا يمكن استخدامه جنبًا إلى جنب مع الدعم الذي يوفره Dockerfiles kaniko العام.

مجتمع

مجموعة جوجل لمستخدمي كانيكو

للمساهمة في كانيكو، راجع DEVELOPMENT.md و CONTRIBUTING.md.

القيود

mtime والتقاط الصور

عند التقاط لقطة، تتضمن خوارزميات التجزئة الخاصة بـ kaniko (أو في حالة --snapshot-mode=time ، استخدم فقط) mtime الملف لتحديد ما إذا كان الملف قد تغير. لسوء الحظ، هناك تأخير بين وقت إجراء التغييرات على الملف ووقت تحديث mtime . هذا يعنى:

مع وضع اللقطة المؤقتة ( --snapshot-mode=time )، قد تفوت kaniko التغييرات التي أدخلتها أوامر RUN بالكامل.
باستخدام وضع اللقطة الافتراضي ( --snapshot-mode=full )، ما إذا كان kaniko سيضيف طبقة أم لا في الحالة التي يقوم فيها أمر RUN بتعديل ملف ولكن لا تتغير المحتويات ، فهو أمر غير حتمي من الناحية النظرية. وهذا لا يؤثر على المحتويات التي ستظل صحيحة، ولكنه يؤثر على عدد الطبقات.

لاحظ أن هذه القضايا نظرية حاليًا فقط. إذا رأيت هذه المشكلة تحدث، يرجى فتح مشكلة.