README-ru.md

PKCI

Pumped Kaniko Container Image for Continuous Integration

Pumped Kaniko Container Image or Pumped Kaniko for Continuous Integration
Прокачанный образ контейнера Kaniko или Прокачанная Kaniko для непрерывной интеграции

Описание

Это альтернативный образ контейнера kaniko, дополненный установленными утилитами busybox, bash, jq и прочими полезностями.

kaniko — это инструмент для создания образов контейнеров из Dockerfile внутри контейнера или кластера kubernetes.

kaniko не зависит от демона Docker и выполняет каждую команду в Dockerfile полностью в пользовательском пространстве. Это позволяет создавать образы контейнеров в средах, которые не могут легко или безопасно запускать демон Docker, например в стандартном кластере kubernetes.

Причина появления PKCI — это необходимость выполнить дополнительную логику внутри контейнера при сборке образа. Оригинальный образ kaniko поставляется на основе scratch-образа, а только отладочный контейнер содержит всего лишь один busybox.

Одного busybox оказалось недостаточно в связи с этим и появился данный контейнер, что решает задачи:

• В оригинальном отладочном контейнере используется устаревший busybox 1.32.0
• busybox установлен по пути /busybox, что иногда вызывает проблему на некоторых CRI и при использовании ключа --cleanup (когда вы создаете больше одного образа), kaniko по умолчанию исключает только каталог /kaniko, а все остальные пути исключаются по параметру VOLUME в Dockerfile. VOLUME может быть проигнорирован вашим CRI и проблема решается только использованием ключа --ignore-path /busybox, что не очевидно.
  В связи с этим все бинарные файлы размещены в каталоге /kaniko/bin
• Когда вы хотите не только собрать контейнер, но еще опубликовать README.md в реестр контейнеров или проверить Dockerfile при помощи hadolint, вам следует запустить отдельное задание в сборочной линии, а это ожидание создания очередного pod и клонирования репозитория, объединив все необходимые для разработки и публикации контейнеров утилиты в один образ, мы очень хорошо выигрываем в скорости выполнения сборочной линии
• Как оказалось, многим разработчикам непривычно работать с busybox и его реализацией sh (Bourne SHell), что порой вызывает трудности в освоении. По этому в контейнер был добавлен bash (Bourne Again SHell) для большего удобства
• Контейнер укомплектован статичными версиями утилит, т.е. утилитами которые не имеют динамических зависимостей к библиотекам, благодаря чему удалось сохранить базовый scratch образ. А именно это:
  • Bash - https://github.com/robxu9/bash-static
  • OpenSSL - https://github.com/ep76/docker-openssl-static
  • Curl - https://github.com/moparisthebest/static-curl
• Довольно частый случай, когда необходимо обратится в какой нибудь API и получить или отправить данные, при этом необходимо удобство в работе с JSON структурами. По этому в образ по умолчанию добавлен знакомый всем curl и jq

Образы контейнера

Существует 3 версии контейнера, стандартный, slim и extra. Стандартный образ имеет тег latest , а альтернативные версии slim-latest и extra-latest соответственно.

Также образы доступны из трёх реестров контейнеров:

• ghcr.io/woozymasta/pkci
  latest, slim-latest, extra-latest
• quay.io/woozymasta/pkci
  latest, slim-latest, extra-latest
• docker.io/woozymasta/pkci
  latest, slim-latest, extra-latest

Размер образов

• pkci:slim — 19M
• pkci:normal — 84M
• pkci:extra — 164M

Важно знать

⚠️ Важно
Ознакомьтесь с этим разделом перед началом использования

UPX

Для сжатия бинарных файлов в проекте используется UPX, это позволяет сократить размер образов в 2.5 раза, но теоретически может помешать вам, по причинам:

• могут быть окружения, в которых самораспаковывающиеся сжатые исполняемые файлы запрещены
• UPX не поддерживает некоторые платформы
• есть очень небольшая вероятность того, что сжатый двоичный файл может иметь некоторую форму ошибки, связанной со сжатием

Bash и утилиты

В контейнере используется набор утилит из busybox и bash — это не тоже самое, что и GNU core utilities, будьте внимательны при написании скриптов, поведение или параметры привычных утилит таких как grep, sed, readlink и подобных может отличатся от того, что имеется в вашей системе.

Shebang

Старайтесь не использовать стандартный shebang (к примеру #!/usr/bin/env bash) или запускать сценарии через интерпретатор по стандартному пути (к примеру /bin/bash script.sh).

В контейнере для простоты и удобства существуют символьные ссылки:

• /bin/sh → /kaniko/bin/sh
• /bin/bash → /kaniko/bin/bash
• /usr/bin/env → /kaniko/bin/env

Но они размещены за границами исключений, и при выполнении очистки окружения (--cleanup) будут удалены. Так как это стандартные системные каталоги, мы не можем исключать их глобально, так как это может нарушить целостность и качество сборки в некоторых случаях.

Просто примите это как правило и используйте shebang вида #!/kaniko/bin/bash или вызывайте интерпретатор по пути /kaniko/bin/bash script.sh

Path

Переменная окружения PATH по умолчанию установлена в значение /usr/local/bin:/kaniko/bin:/kaniko. При этом каталог /usr/local/bin не существует в образе, по умолчанию все бинарные файлы будут использоваться из /kaniko/bin и /kaniko пока не появится /usr/local/bin

Executor

По умолчанию в стандартном образе бинарный файл kaniko называется executor и расположен по пути /kaniko/executor. Что бы не нарушать совместимость, это сохранено как есть, но для удобства также создана символическая ссылка /kaniko/bin/kaniko ссылающаяся на /kaniko/executor

Docker credential helpers

• docker-credential-acr-env
• docker-credential-gcr
• docker-credential-ecr-login

Эти утилиты используются тех же версий и с тем же наименованием как в составе оригинального образа kaniko. Сделано это для соблюдения обратной совместимости, но их расположение перемещено в общий каталог бинарных файлов /kaniko/bin. По этому будьте осторожны, вызывайте их по новому абсолютному пути или используйте просто имя для получения их из $PATH

• /kaniko/docker-credential-acr-env → /kaniko/docker-credential-acr-env или docker-credential-acr-env
• /kaniko/docker-credential-gcr → /kaniko/docker-credential-gcr или docker-credential-gcr
• /kaniko/docker-credential-ecr-login → /kaniko/docker-credential-ecr-login или docker-credential-ecr-login

Trivy

ℹ️ Информация
Только для extra редакции образа. Только в нем используется trivy

Каталог /contrib перемещен в /kaniko/contrib, по этому при использовании шаблона для формирования отчета указывайте абсолютный путь к файлу, к примеру /kaniko/contrib/junit.tpl

Каталог для кеширования также перемещен в /kaniko/.cache и установлена переменная окружения TRIVY_CACHE_DIR=/kaniko/.cache

Образ не имеет в себе встроенной базы уязвимостей для trivy, по этому для больших проектов или команд следует задуматься о развертывании отдельного сервера Trivy в общей сети со сборочными агентами или собирать по расписанию (раз в 6-12 часов) образ с дополнительным слоем хранящим базу, подробнее здесь

Как это использовать

Образ контейнера поставляется в трех редакциях slim, normal и extra в виду того, что предполагается три основных сценария применения.

Конечно же в вашем случае это может быть абсолютно свой уникальный сценарий который решает именно ваши задачи.

Slim редакция

Это легковесная версия образа, всего 19M, учитывая то что сама kaniko имеет размер около 34M. Также здесь имеется еще набор утилит busybox, bash, curl, jq, hadolint и docker-pushrm, которые привносят большую свободу для автоматизации накладывая при этом скоромный дополнительный объем к размеру образа. Да, именно 19M против 34M в оригинале, а всё это лагодаря UPX сжатию бинарных файлов.

Проверь, собери и задокументируй

Данная редакция подойдет для целей:

• Реализовать сценарий автоматики на bash/sh с использованием утилит из комплекта busybox
• Для работы с JSON и API предоставлены curl и jq, при помощи которых вы можете удобно получить необходимую информацию, к примеру версию зависимости из github API и передать её как ARG в ваш Dockerfile не захламляя его лишней логикой или уведомить внешнюю систему о событии вызвав какой нибудь webhook или API запрос.
• Перед сборкой проанализировать Dockerfile при помощи hadolint и отправить отчет с статусом анализа при помощи curl в какую нибудь внешнюю систему, к примеру sonarqube
• Естественно собрать и опубликовать образ контейнера при помощи kaniko, это наша исходная задача
• И в завершении, после успешной публикации образа контейнера, хорошо будет обновить описание для него. Опубликуем README.md или подобный файл в поддерживаемый реестр контейнеров (dockerhub, projectquay, quay и harbor) при помощи docker-pushrm

Normal редакция

В отличии от slim версии, размер этого образа уже имеет заметные 84M. Данная в первую очередь редакция имеет набор утилит нацеленных на безопасность, утилиты cosign и notary-signer помогут вам подписать ваш образ, а openssl это полноценная криптографическая библиотека которая поможет вам в решении многих задач криптографии.

Шаблонизируй, проверь, собери, подпиши и задокументируй

Данная редакция подойдет для тех же целей, что и slim версия и дополнительно:

• Утилита crane позволит мутировать, анализировать образы и работать с уже опубликованными образами.
• Для решения криптографических задач вы сможете использовать cosign, notary-signer и openssl
• Вы сможете шаблонизировать ваши Dockerfile или markdown документы при помощи templar, который предоставляет Jinja2 подобный синтаксис
• Используя утилиту tokei вы сможете проанализировать размер вашего проекта, количество строк кода и комментариев по типам файлов и языкам программирования
• Утилита mdtohtml позволит вам конвертировать markdown документы в HTML. Это может пригодится к примеру перед публикацией вашего README.md написанном используя GFM в реестр контейнеров projectquay или quay который поддерживает только commonmark, т.е. такие элементы как таблицы просто не будут отображаться корректно, но опубликовав HTML вы получите ожидаемый результат.
• Для авторизации в GCR, ACR и ECR имеются соответствующие утилиты как и в оригинальном образе kaniko

Extra редакция

Редакция extra — это самая прокачанная версия образа размером аж в 164M. Да, этот образ действительно получился большой, на столько же большой как и его возможности, а именно это непрерывная интеграция с оркестраторами контейнеров на базе kubernetes и безопасность размещаемых в нем ресурсов.

Шаблонизируй, проверь, собери, подпиши, задокументируй, проанализируй и разверни

В этой редакции есть всё что было в normal и slim, а еще:

• Имеется yq — процессор командной строки для работы с YAML, JSON и XML.
• Для более серьезной шаблонизации проекта вы можете использовать gomplate
• При помощи trivy вы можете просканировать итоговый собранный образ на наличие CVE, проанализировать git репозиторий проекта на утечку токенов или паролей или даже проверить конфигурацию вашего kubernetes кластера.
• Перед применением YAML манифестов, kustomize и helm-чартов в кластер kubernetes вы можете предварительно проверить их при помощи утилит kube-linter и kubesec
• Для доставки приложений в кластер имеется как уже знакомые всем kubectl и helm, так и более универсальные инструменты jsonnet-bundler и tanka для описания конфигурации приложений при помощи jsonnet

Компоненты контейнеров

Slim	Normal (+Slim)	Extra (+Normal)
kaniko 1.8.1	cosign 1.9.0	yq 4.25.2
busybox 1.34.1	notary 0.7.0	gomplate 3.11.1
bash 5.1.016-1.2.3	openssl 3.0.3	trivy 0.29.2
curl 7.83.1	crane 0.9.0	kube-linter 0.3.0
jq 1.6	mdtohtml latest	kubesec 2.11.4
hadolint 2.10.0	templar 0.5.1	kubectl 1.24.1
docker-pushrm 1.8.1	tokei 12.1.2	helm 3.9.0
Утилиты	docker-credential-acr-env docker-credential-gcr docker-credential-ecr-login	jsonnet-bundler 0.5.1
		tanka 0.22.1