werf · ilya-lesikov · Apr 28, 2023 · Apr 28, 2023
diff --git a/docs/_data/sidebars/_documentation.yml b/docs/_data/sidebars/_documentation.yml
@@ -49,9 +49,6 @@ entries:
               - title: Build process
                 url: /usage/build/process.html
 
-              - title: Run in containers
-                url: /usage/build/run_in_containers.html
-
           - title: Deploy
             f:
               - title: Overview
@@ -183,9 +180,6 @@ entries:
               - title: Сборочный процесс
                 url: /usage/build/process.html
 
-              - title: Работа в контейнерах
-                url: /usage/build/run_in_containers.html
-
           - title: Развертывание
             f:
               - title: Обзор

diff --git a/docs/_data/sidebars/documentation.yml b/docs/_data/sidebars/documentation.yml
@@ -687,9 +687,6 @@ entries:
               - title: Build process
                 url: /usage/build/process.html
 
-              - title: Run in containers
-                url: /usage/build/run_in_containers.html
-
           - title: Deploy
             f:
               - title: Overview
@@ -821,9 +818,6 @@ entries:
               - title: Сборочный процесс
                 url: /usage/build/process.html
 
-              - title: Работа в контейнерах
-                url: /usage/build/run_in_containers.html
-
           - title: Развертывание
             f:
               - title: Обзор

diff --git a/docs/pages_en/usage/build/process.md b/docs/pages_en/usage/build/process.md
@@ -304,65 +304,7 @@ werf converge --repo registry.mydomain.org/repo --synchronization :local
 
 > **NOTE:** This method is only suitable if all werf runs are triggered by the same runner in your CI/CD system.
 
-## Configuring the build backend
-
-<!-- reference: https://werf.io/documentation/v1.2/advanced/buildah_mode.html -->
-
-werf supports Docker Server or Buildah as backend for building images. Buildah provides full containerization and layer-by-layer Dockerfile builds with caching of all intermediate layers into the container registry. Docker Server is currently the default backend.
-
-> **NOTE:** The Buildah backend does not currently support storing images locally, only [storing images in the container registry](#layer-by-layer-image-caching) is supported.
-
-### Docker
-
-Docker Server is currently the default backend and no additional configuration is required.
-
-### Buildah
-
-> **NOTE:** Buildah is currently only available to Linux users and Windows users with the WSL2 subsystem enabled. For macOS, we suggest using a virtual machine to run werf in Buildah mode.
-
-werf uses Buildah in rootless mode to build images without a Docker server. Buildah is built into the werf binary. You can find the host system requirements to run werf with the Buildah backend [in the installation instructions](/installation.html).
-
-Buildah can be enabled by setting the `WERF_BUILDAH_MODE` environment variable to one of the options: `auto`, `native-chroot`, `native-rootless`. Most users only have to set `WERF_BUILDAH_MODE=auto` to enable Buildah mode.
-
-#### Level of assembly isolation
-
-By default, in `auto` mode, werf automatically sets the isolation level depending on the platform and environment.
-
-2 types of assembly container isolation are supported:
-1. Chroot is an option that does not use the container runtime; it can be enabled as follows: `WERF_BUILDAH_MODE=native-chroot`.
-2. Rootless is an option involving container runtime (crun or runc or kata or runsc must be installed on the system); it can be enabled as follows: `WERF_BUILAH_MODE=native-rootless`.
-
-#### Storage driver
-
-werf supports the `overlay` or `vfs` storage driver:
-
-* `overlay` allows you to use the OverlayFS filesystem. You can either use the Linux kernel's built-in support for OverlayFS (if available) or you can use the fuse-overlayfs implementation. This is the recommended default choice.
-* `vfs` provides access to a virtual filesystem instead of OverlayFS. This file system is inferior in performance and requires a privileged container, so it is not recommended. However, it may be useful in some cases.
-
-Generally, the default driver (`overlay`) is enough. The storage driver can be set using the `WERF_BUILDAH_STORAGE_DRIVER` environment variable.
-
-#### Ulimits
-
-By default, the Buildah mode in werf inherits system ulimits when the build containers are started. The user can override these parameters using the `WERF_BUILDAH_ULIMIT` environment variable.
-
-The format of `WERF_BUILDAH_ULIMIT=type=softlimit[:hardlimit][,type=softlimit[:hardlimit],...]` is comma-separated limit values:
-* "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).
-
-### Multiplatform builds
+## Multiplatform builds
 
 Multiplatform builds use the cross-platform instruction execution mechanics provided by the [Linux kernel](https://en.wikipedia.org/wiki/Binfmt_misc) and the QEMU emulator. The easiest way to register emulators for most architectures on your host system is to use the `qemu-user-static` image:
 

diff --git a/docs/pages_en/usage/build/run_in_containers.md b/docs/pages_en/usage/build/run_in_containers.md
diff --git a/docs/pages_ru/usage/build/process.md b/docs/pages_ru/usage/build/process.md
@@ -304,65 +304,7 @@ werf converge --repo registry.mydomain.org/repo --synchronization :local
 
 > **ЗАМЕЧАНИЕ:** Данный способ подходит лишь в том случае, если в вашей CI/CD системе все запуски werf происходят с одного и того же раннера.
 
-## Настройка сборочного бэкенда
-
-<!-- прим. для перевода: на основе https://werf.io/documentation/v1.2/advanced/buildah_mode.html -->
-
-werf поддерживает использование Docker-сервер или Buildah в качестве бекенда для сборки образов. Buildah обеспечивает полноценную работу в контейнерах и послойную сборку Dockerfile'ов с кешированием всех промежуточных слоёв в container registry. Docker-сервер на данный момент является бекэндом, используемым по умолчанию.
-
-> **ЗАМЕЧАНИЕ:** Сборочный бекэнд Buildah на данный момент не поддерживает хранение образов локально, поддерживается только [хранение образов в container registry](#послойное-кэширование-образов).
-
-### Docker
-
-Docker-сервер на данный момент является бекэндом, используемым по умолчанию, и никакая дополнительная настройка не требуется.
-
-### Buildah
-
-> **ЗАМЕЧАНИЕ:** На данный момент Buildah доступен только для пользователей Linux и Windows с включённой подсистемой WSL2. Для пользователей macOS предлагается использование виртуальной машины для запуска werf в режиме Buildah.
-
-Для сборки без Docker-сервера werf использует Buildah в rootless-режиме. Buildah встроен в бинарник werf. Требования к хост-системе для запуска werf с бэкендом Buildah можно найти [в инструкциях по установке](/installation.html).
-
-Buildah включается установкой переменной окружения `WERF_BUILDAH_MODE` в один из вариантов: `auto`, `native-chroot`, `native-rootless`. Большинству пользователей для включения режима Buildah достаточно установить `WERF_BUILDAH_MODE=auto`.
-
-#### Уровень изоляции сборки
-
-По умолчанию в режиме `auto` werf автоматически выбирает уровень изоляции в зависимости от платформы и окружения.
-
-Поддерживается 2 варианта изоляции сборочных контейнеров:
-1. Chroot — вариант без использования container runtime, включается переменной окружения `WERF_BUILDAH_MODE=native-chroot`.
-2. Rootless — вариант с использованием container runtime (в системе должен быть установлен crun, или runc, или kata, или runsc), включается переменной окружения `WERF_BUILAH_MODE=native-rootless`.
-
-#### Драйвер хранилища
-
-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).
-
-### Мультиплатформенная сборка
+## Мультиплатформенная сборка
 
 Мультиплатформенная сборка использует механизмы кроссплатформенного исполнения инструкций, предоставляемые [ядром Linux](https://en.wikipedia.org/wiki/Binfmt_misc) и эмулятором QEMU. Самый простой способ зарегистрировать в хост-системе эмуляторы для большинства архитектур — воспользоваться образом `qemu-user-static`: