kaniko
v1.23.2
Должны быть соблюдены следующие условия:
Вам необходим доступ к машинам сборки, на которых работают нужные архитектуры (запуск Kaniko в эмуляторе, например QEMU, также возможен, но выходит за рамки этой документации). Об этом следует помнить при использовании инструментов сборки SaaS, таких как github.com или gitlab.com, из которых на момент написания статьи ни один из них не поддерживает какие-либо исполнители SaaS, отличные от x86_64 (GitHub, GitLab), поэтому будьте готовы принести свои собственные машины (GitHub, GitLab.
Канико должен иметь возможность работать на желаемой архитектуре. На момент написания официальный контейнер Kaniko поддерживает linux/amd64, linux/arm64, linux/s390x и linux/ppc64le (не в образах *-debug).
Выбранный вами реестр контейнеров должен быть совместим с OCIv1 или Docker v2.2.
Вам решать, найти инструмент автоматизации, который лучше всего соответствует вашим потребностям. Мы рекомендуем использовать современную систему CI/CD, например рабочие процессы GitHub или GitLab CI. Поскольку мы (авторы) используем GitLab CI, следующие примеры адаптированы для этой конкретной платформы, но основные принципы должны применяться везде, а примеры остаются достаточно простыми, чтобы вы могли следовать им даже без каких-либо действий. предыдущий опыт работы с этой конкретной платформой. Если у вас есть сомнения, посетите справочную страницу gitlab-ci.yml, чтобы получить полный обзор ключевых слов GitLab CI.
gitlab-ci.yml:
# определить задание для сборки контейнеровbuild-container: stage:Container-build
# запускаем параллельные сборки для нужных архитектур
параллель:матрица:
- АРКА: amd64 - АРКА: Arm64
tags:# запускайте каждую сборку на подходящем, предварительно настроенном раннере (должен соответствовать целевой архитектуре) - runner-${ARCH}
изображение:имя: gcr.io/kaniko-project/executor:debugentrypoint: [""]
script:# создайте образ контейнера для текущей арки, используя kaniko- >- /kaniko/executor --context "${CI_PROJECT_DIR}" --dockerfile "${CI_PROJECT_DIR}/Dockerfile" # отправим образ в реестр контейнеров GitLab, добавить текущую арку как тег. --destination "${CI_REGISTRY_IMAGE}:${ARCH}"gitlab-ci.yml:
# определить задание для создания и отправки объединенного манифестаmerge-manifests: stage:Container-build
# все контейнеры должны быть собраны перед их объединением
# альтернативно задание можно настроить для запуска на более позднем этапе
потребности:
- задание: артефакты сборки контейнера: false
tags:# может работать на любой архитектуре, поддерживаемой манифестом-tool image-runner-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 при запуске в ветке по умолчанию. к хешу фиксации при запуске в других ветвях и к тегу выпуска при запуске в конвейере тегов.
gitlab-ci.yml:
контейнер-получить-тег: этап: этап предварительной сборки-контейнера
теги:
- бегун-xyz
изображение: busybox
script:# Все остальные ветки помечены текущим хэшем SHA коммита- | # Если конвейер работает в ветке по умолчанию: установите тег «latest», если тест «$CI_COMMIT_BRANCH» == «$CI_DEFAULT_BRANCH»; then tag="latest" # Если конвейер является конвейером тегов, установите тег в тег git commit elif test -n "$CI_COMMIT_TAG"; then tag="$CI_COMMIT_TAG" # Иначе установите тег в git commit 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
изображение
косатка-сборка
умочи
строить
сверхсветовая скорость
Базель Rules_docker
Все эти инструменты создают образы контейнеров разными подходами.
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 .
Канико — создание образов контейнеров в Kubernetes без Docker.
