Обзор

werf позволяет работать со следующими сборочными бэкендами:

  • Docker — традиционный способ, использующий системный Docker Daemon.
  • Buildah — безопасная сборка без демона, поддерживает rootless-режим и полностью встроен в werf.

Необходимые требования и подготовка системы для работы со сборочными бэкендами описаны в разделе сайта Быстрый старт.

Docker

Сборочный бэкенд Docker требует Docker 19.03 или новее (Engine API 1.40 или новее) для сборки и запуска контейнеров. Команды, которым нужен бэкенд, отклоняют более старый API демона или демон, не ответивший за 10 секунд. Отсутствие запущенного демона допускается при инициализации; операция, которой он действительно нужен, всё равно завершится с ошибкой.

werf converge, werf plan, werf render, werf lint, werf helm get-autogenerated-values и werf bundle publish инициализируют бэкенд только при обработке образов. Проектам без образов и режиму --without-images Docker daemon не нужен. werf plan, werf render, werf lint и werf helm get-autogenerated-values также пропускают инициализацию с --stub-tags или локальным адресом репозитория. werf converge --use-plan и werf plan --show-plan тоже не требуют бэкенда. При обработке образов проверки API и ответа демона сохраняются, в том числе с --require-built-images и --use-build-report.

Команды, которые работают только с container registry (werf cleanup, werf purge, werf dismiss, werf managed-images, werf meta-repo), допускают старый, отсутствующий или неотвечающий Docker daemon. Настройки registry из демона пропускаются, если API демона не поддерживается, если имя хоста демона не разрешается, если соединение отклонено либо хост или сеть отключены или недоступны, если сокет или named pipe отсутствует, а также если демон принимает соединение, но не отвечает. Всё остальное возвращается пользователю: сокет, который текущему пользователю недоступен, ошибки аутентификации и авторизации, ошибки TLS, ошибки HTTP, некорректные ответы или ответы не от Engine API, а также неожиданные ошибки сервера. Эти команды могут запускать автоматическую очистку хоста, которой демон нужен. Ошибка такой очистки не влияет на результат самой команды.

При подключении через ssh:// используемый Docker-клиент может приводить некоторые ошибки удалённого Unix-сокета, включая отказ в доступе, к той же общей ошибке «не удалось подключиться», что и для отсутствующего сокета. Из-за этого существующего ограничения получение необязательных настроек может пропустить отказ в доступе к удалённому сокету как недоступный демон. Ошибки самой команды ssh остаются различимыми: отклонённое соединение, отключённый, недоступный или неразрешимый SSH-хост, отключённая сеть и таймаут пропускаются, а отказ в аутентификации SSH, локальные ошибки доступа к сокету и отсутствие Docker CLI на удалённом хосте возвращаются пользователю.

Buildah

На данный момент Buildah доступен только для пользователей Linux и Windows с включённой подсистемой WSL2. Для пользователей MacOS на данный момент предлагается использование виртуальной машины для запуска werf в режиме Buildah.

Buildah включается установкой переменной окружения WERF_BUILDAH_MODE в один из вариантов:

  • auto — автоматический выбор режима в зависимости от платформы и окружения;
  • native-chroot использует chroot-изоляцию для сборочных контейнеров;
  • native-rootless использует rootless-изоляцию для сборочных контейнеров. На этом уровне изоляции werf использует среду выполнения сборочных операций в контейнерах (runc, crun, kata или runsc).
export WERF_BUILDAH_MODE=auto

Конфигурация container registry

При использовании Buildah werf читает настройки container registry из registries.conf.

Для secure-зеркал docker.io также можно использовать опцию --container-registry-mirror и переменные окружения WERF_CONTAINER_REGISTRY_MIRROR_*. Зеркала, заданные таким способом, по умолчанию считаются secure (https) зеркалами. При необходимости для обращений к registry можно включить глобальный insecure-режим werf через --insecure-registry или --skip-tls-verify-registry.

Поддерживаются следующие пути в порядке приоритета:

  1. путь из переменной окружения CONTAINERS_REGISTRIES_CONF;
  2. ~/.config/containers/registries.conf;
  3. /etc/containers/registries.conf.

Если задан CONTAINERS_REGISTRIES_CONF, werf использует только этот файл и соседнюю директорию <path>.d.

Если CONTAINERS_REGISTRIES_CONF не задан, werf использует первый найденный файл из стандартных путей и соседнюю директорию <path>.d для этого файла.

werf использует из этой конфигурации:

  • зеркала для docker.io;
  • standalone insecure registries из [[registry]] insecure = true.

werf не парсит и не подменяет другие файлы container-конфигурации, например shortnames.conf.

Insecure-зеркало для docker.io не делает тот же host standalone insecure registry автоматически. Если один и тот же host должен использоваться и как зеркало docker.io, и как standalone insecure registry, его нужно описать двумя отдельными записями.

Драйвер хранилища

werf может использовать драйвер хранилища overlay или vfs:

  • overlay позволяет использовать файловую систему OverlayFS. Можно использовать либо встроенную в ядро Linux поддержку OverlayFS (если она доступна), либо реализацию fuse-overlayfs. Это рекомендуемый выбор по умолчанию.
  • vfs обеспечивает доступ к виртуальной файловой системе вместо OverlayFS. Эта файловая система уступает по производительности и требует привилегированного контейнера, поэтому ее не рекомендуется использовать. Однако в некоторых случаях она может пригодиться.

Как правило, достаточно использовать драйвер по умолчанию (overlay). Драйвер хранилища можно задать с помощью переменной окружения WERF_BUILDAH_STORAGE_DRIVER.

Ulimits

По умолчанию Buildah режим в werf наследует системные ulimits при запуске сборочных контейнеров. Пользователь может переопределить эти параметры с помощью переменной окружения WERF_BUILDAH_ULIMIT.

Формат WERF_BUILDAH_ULIMIT=type:softlimit[:hardlimit][,type:softlimit[:hardlimit],...] — конфигурация лимитов, указанные через запятую:

  • core: максимальный размер дампа ядра (ulimit -c).
  • cpu: максимальное время процессора (ulimit -t).
  • data: максимальный размер сегмента данных процесса (ulimit -d).
  • fsize: максимальный размер новых файлов (ulimit -f).
  • locks: максимальное количество блокировок файлов (ulimit -x).
  • memlock: максимальное количество заблокированной памяти (ulimit -l).
  • msgqueue: максимальное количество данных в очередях сообщений (ulimit -q).
  • nice: настройка “niceness” (nice -n, ulimit -e).
  • nofile: максимальное количество открытых файлов (ulimit -n).
  • nproc: максимальное количество процессов (ulimit -u).
  • rss: максимальный размер резидентного набора памяти процесса (ulimit -m).
  • rtprio: максимальный приоритет для реального времени (ulimit -r).
  • rttime: максимальное время реального исполнения между блокирующими системными вызовами.
  • sigpending: максимальное количество ожидающих сигналов (ulimit -i).
  • stack: максимальный размер стека (ulimit -s).