ПРИМЕЧАНИЕ: werf поддерживает сборку образов с использованием Docker-сервера или с использованием Buildah. Поддерживается сборка как Dockerfile-образов, так и stapel-образов через Buildah.

Для сборки без Docker-сервера werf использует встроенный Buildah в rootless-режиме.

Системные требования

Требования к хост-системе для запуска werf в Buildah-режиме без Docker/Kubernetes можно найти в инструкциях по установке. А для запуска werf в Kubernetes или в Docker-контейнерах требования следующие:

  • Если ваше ядро Linux версии 5.13+ (в некоторых дистрибутивах 5.11+) рекомендуется режим работы через модуль ядра overlay:
    • Убедитесь, что модуль ядра overlay загружен с lsmod | grep overlay.
    • Убедитесь, что настройка ядра CONFIG_USER_NS=y включена в вашем ядре с помощью grep CONFIG_USER_NS /boot/config-VERSION.
    • При использовании ядра в debian-системах команда sysctl kernel.unprivileged_userns_clone должна вернуть 1. В ином случае выполните: 
      echo 'kernel.unprivileged_userns_clone = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
    • Команда sysctl user.max_user_namespaces должна вернуть по меньшей мере 15000. В ином случае выполните: 
      echo 'user.max_user_namespaces = 15000' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
  • Если ядро более старое или у вас не получается активировать модуль ядра overlay, то установите fuse-overlayfs, который обычно доступен в репозиториях вашего дистрибутива. В крайнем случае может быть использован драйвер хранилища vfs.

Включение Buildah

Buildah включается установкой переменной окружения WERF_BUILDAH_MODE в один из вариантов: auto, native-chroot, native-rootless. Большинству пользователей для включения режима Buildah достаточно установить WERF_BUILDAH_MODE=auto.

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

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

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

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”: maximum core dump size (ulimit -c)
  • “cpu”: maximum CPU time (ulimit -t)
  • “data”: maximum size of a process’s data segment (ulimit -d)
  • “fsize”: maximum size of new files (ulimit -f)
  • “locks”: maximum number of file locks (ulimit -x)
  • “memlock”: maximum amount of locked memory (ulimit -l)
  • “msgqueue”: maximum amount of data in message queues (ulimit -q)
  • “nice”: niceness adjustment (nice -n, ulimit -e)
  • “nofile”: maximum number of open files (ulimit -n)
  • “nproc”: maximum number of processes (ulimit -u)
  • “rss”: maximum size of a process’s (ulimit -m)
  • “rtprio”: maximum real-time scheduling priority (ulimit -r)
  • “rttime”: maximum amount of real-time execution between blocking syscalls
  • “sigpending”: maximum number of pending signals (ulimit -i)
  • “stack”: maximum stack size (ulimit -s)