رجل
v1.23.2
ويجب استيفاء الشروط التالية:
الأمر متروك لك للعثور على أداة التشغيل الآلي التي تناسب احتياجاتك بشكل أفضل. نوصي باستخدام نظام CI/CD حديث مثل سير عمل GitHub أو GitLab CI. نظرًا لأننا (المؤلفون) نستخدم GitLab CI، فقد تم تصميم الأمثلة التالية خصيصًا لهذا النظام الأساسي المحدد ولكن المبادئ الأساسية يجب أن تنطبق في أي مكان آخر ويتم الاحتفاظ بالأمثلة بسيطة بما فيه الكفاية، حتى تتمكن من المتابعة، حتى بدون أي التجارب السابقة مع هذه المنصة المحددة. في حالة الشك، قم بزيارة الصفحة المرجعية gitlab-ci.yml للحصول على نظرة عامة شاملة حول الكلمات الرئيسية لـ GitLab CI.
جيتلاب-ci.yml:
# define a job for building the containers
build-container :
stage : container-build
# run parallel builds for the desired architectures
parallel :
matrix :
- ARCH : amd64
- ARCH : arm64
tags :
# run each build on a suitable, preconfigured runner (must match the target architecture)
- runner-${ARCH}
image :
name : gcr.io/kaniko-project/executor:debug
entrypoint : [""]
script :
# build the container image for the current arch using kaniko
- >-
/kaniko/executor --context "${CI_PROJECT_DIR}" --dockerfile
"${CI_PROJECT_DIR}/Dockerfile" # push the image to the GitLab container
registry, add the current arch as tag. --destination
"${CI_REGISTRY_IMAGE}:${ARCH}" جيتلاب-ci.yml:
# define a job for creating and pushing a merged manifest
merge-manifests :
stage : container-build
# all containers must be build before merging them
# alternatively the job may be configured to run in a later stage
needs :
- job : container-build
artifacts : false
tags :
# may run on any architecture supported by manifest-tool image
- runner-xyz
image :
name : mplatform/manifest-tool:alpine
entrypoint : [""]
script :
- >-
manifest-tool # authorize against your container registry
--username=${CI_REGISTRY_USER} --password=${CI_REGISTRY_PASSWORD} push
from-args # define the architectures you want to merge --platforms
linux/amd64,linux/arm64 # "ARCH" will be automatically replaced by
manifest-tool # with the appropriate arch from the platform definitions
--template ${CI_REGISTRY_IMAGE}:ARCH # The name of the final, combined
image which will be pushed to your registry --target ${CI_REGISTRY_IMAGE} من أجل التبسيط، امتنعنا عمدًا عن استخدام الصور ذات العلامات ذات الإصدارات (سيتم وضع علامة على جميع الإصدارات على أنها "الأحدث") في الأمثلة السابقة، حيث نشعر أن هذا يضيف إلى الكثير من التعليمات البرمجية الخاصة بالنظام الأساسي وسير العمل.
ومع ذلك، بالنسبة لأي شخص مهتم بكيفية تعاملنا مع الإصدارات (الديناميكية) في GitLab، فإليك ملخصًا قصيرًا:
CI_COMMIT_TAG المحدد مسبقًا في GitLab عند تشغيل مسار العلامات.needs في وظائف الإنشاء والدمج وفقًا لذلك)، والتي ستعين العلامة على latest عند التشغيل على الفرع الافتراضي، إلى تجزئة الالتزام عند تشغيلها على فروع أخرى وإلى علامة الإصدار عند تشغيلها على خط أنابيب العلامات.جيتلاب-ci.yml:
container-get-tag :
stage : pre-container-build-stage
tags :
- runner-xyz
image : busybox
script :
# All other branches are tagged with the currently built commit SHA hash
- |
# If pipeline runs on the default branch: Set tag to "latest"
if test "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH"; then
tag="latest"
# If pipeline is a tag pipeline, set tag to the git commit tag
elif test -n "$CI_COMMIT_TAG"; then
tag="$CI_COMMIT_TAG"
# Else set the tag to the git commit sha
else
tag="$CI_COMMIT_SHA"
fi
- echo "tag=$tag" > build.env
# parse tag to the build and merge jobs.
# See: https://docs.gitlab.com/ee/ci/variables/#pass-an-environment-variable-to-another-job
artifacts :
reports :
dotenv : build.env تشمل الأدوات المماثلة ما يلي:
تقوم كل هذه الأدوات بإنشاء صور حاوية بطرق مختلفة.
يمكن أن يعمل 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.
عند التقاط لقطة، تتضمن خوارزميات التجزئة الخاصة بـ kaniko (أو في حالة --snapshot-mode=time ، استخدم فقط) mtime الملف لتحديد ما إذا كان الملف قد تغير. لسوء الحظ، هناك تأخير بين وقت إجراء التغييرات على الملف ووقت تحديث mtime . هذا يعنى:
--snapshot-mode=time )، قد تفوت kaniko التغييرات التي أدخلتها أوامر RUN بالكامل.--snapshot-mode=full )، ما إذا كان kaniko سيضيف طبقة أم لا في الحالة التي يقوم فيها أمر RUN بتعديل ملف ولكن لا تتغير المحتويات ، فهو أمر غير حتمي من الناحية النظرية. وهذا لا يؤثر على المحتويات التي ستظل صحيحة، ولكنه يؤثر على عدد الطبقات.لاحظ أن هذه القضايا نظرية حاليًا فقط. إذا رأيت هذه المشكلة تحدث، يرجى فتح مشكلة.
--chown دعم chown يدعم Kaniko حاليًا أمر COPY --chown و ADD --chown Dockerfile. لا يدعم RUN --chown .
