Обзор

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

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

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

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).