мужчина
v1.23.2
Должны быть соблюдены следующие условия:
Вам решать, найти инструмент автоматизации, который лучше всего соответствует вашим потребностям. Мы рекомендуем использовать современную систему CI/CD, например рабочие процессы GitHub или GitLab CI. Поскольку мы (авторы) используем GitLab CI, следующие примеры адаптированы для этой конкретной платформы, но основные принципы должны применяться везде, а примеры остаются достаточно простыми, чтобы вы могли следовать им даже без каких-либо действий. предыдущий опыт работы с этой конкретной платформой. Если у вас есть сомнения, посетите справочную страницу gitlab-ci.yml, чтобы получить полный обзор ключевых слов GitLab CI.
gitlab-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}" gitlab-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 при запуске конвейера тегов.needs заданий сборки и слияния), которое установит тег на latest при запуске в ветке по умолчанию. к хешу фиксации при запуске в других ветвях и к тегу выпуска при запуске в конвейере тегов.gitlab-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 ) может работать в контейнере от имени пользователя без полномочий root, но для создания вложенных контейнеров требуется отключить seccomp и AppArmor. kaniko на самом деле не создает вложенные контейнеры, поэтому не требует отключения seccomp и AppArmor. BuildKit поддерживает «кросс-сборку» многоархивных контейнеров с помощью QEMU.
orca-build зависит от runc для сборки образов из Dockerfiles, которые не могут работать внутри контейнера (по причинам, аналогичным img выше). kaniko не использует runc , поэтому не требует использования методов распределения имен ядра. Однако orca-build не требуется Docker или какой-либо привилегированный демон (поэтому сборки можно выполнять совершенно без привилегий).
umoci работает без каких-либо привилегий, а также не имеет ограничений на извлечение корневой файловой системы (хотя это требует дополнительной обработки, если ваша файловая система достаточно сложна). Однако у него нет инструментов сборки, подобных Dockerfile (это инструмент немного более низкого уровня, который можно использовать для сборки таких сборщиков, например orca-build ).
Buildah специализируется на создании изображений OCI. Команды Buildah копируют все команды, которые находятся в Dockerfile. Это позволяет создавать образы с Dockerfiles и без них, не требуя при этом каких-либо привилегий root. Конечная цель Buildah — предоставить низкоуровневый интерфейс coreutils для создания образов. Гибкость создания образов без Dockerfiles позволяет интегрировать другие языки сценариев в процесс сборки. Buildah следует простой модели fork-exec и не запускается как демон, но основан на комплексном API в golang, который можно использовать в других инструментах.
FTL и Bazel стремятся добиться максимально быстрого создания образов Docker для подмножества образов. Их можно рассматривать как «быстрый путь» для особого случая, который можно использовать в сочетании с поддержкой общих Dockerfiles, предоставляемых kaniko.
Группа kaniko-users в Google
Чтобы внести свой вклад в kaniko, смотрите DEVELOPMENT.md и CONTRIBUTING.md.
При создании снимка алгоритмы хэширования kaniko включают (или, в случае --snapshot-mode=time , используют только) mtime файла, чтобы определить, изменился ли файл. К сожалению, между внесением изменений в файл и обновлением mtime существует задержка. Это означает:
--snapshot-mode=time ) kaniko может полностью пропустить изменения, внесенные командами RUN .--snapshot-mode=full ) теоретически недетерминировано, добавит ли kaniko слой в случае, когда команда RUN изменяет файл , но содержимое не меняется. Это не влияет на содержимое , которое по-прежнему будет правильным, но влияет на количество слоев.Обратите внимание, что эти вопросы в настоящее время являются только теоретическими. Если вы видите, что эта проблема возникает, пожалуйста, откройте проблему.
--chown поддержка Kaniko в настоящее время поддерживает команды COPY --chown и ADD --chown Dockerfile. Он не поддерживает RUN --chown .
