Notamock
Содержание
Notamock — набор утилит, создающих окружения для сборки rpm пакетов
Частично пересекается по задачам с mock, отсюда и название.
- notamock - утилита для запуска одиночного процесса локальной сборки проекта
- notamocks - (+ s - множественное число) утилита для запуска локальной массовой сборки проектов с использованием notamock
- notamockc - (+ c - от chroot) утилита для создания контейнеров аналогично тому как делает notamock, но запустить в нем можно любую команду, по умолчанию bash
- notamockd - (+ d - от daemon) утилита для создания контейнеров для сборки с abf
- notamocka - (+ a - от abf) скрипт запуска abf билдеров в контейнере, используется только внутри контейнера в отличии от остальных утилит находится в отдельном пакете notamock-abf
Общая идея проекта отличающая его от mock заключается в использовании слоеных контейнеров, где нижний слой со стандартной рутфс общий для всех запущенных сборочных процессов сколько бы их ни было. Примерно аналогично работает докер. Это позволяет увеличить среднюю скорость сборки, за счет того, что минимальное окружение всегда готово и требуется установить только сборочные зависимости.
Общее
- все утилиты требуют прав root, связано c использованием монтирований. Далее по тексту su, sudo опускаются.
- все утилиты имеют общий конфигурационный файл, по умолчанию это /etc/notamock.cfg (можно использовать собственные с ключом --config /путь/файл.cfg)
- все утилиты имеют встроенный --help
- все утилиты, запущенные с одним конфигом, будут использовать одни и те же базовые rootfs. Такие rootfs создаются по одной для каждой платформы и многократно переиспользуются. Например при запуске notamockd создается контейнер использующий такую rootfs, билдеры в контейнере используют notamock, каждый процесс которого, в свою очередь, также будет использовать ровно ту же базовую rootfs. Количество rootfs соответствует количеству поддерживаемых платформ и никак не зависит от количества процессов notamock, контейнеров и билдеров.
- для пересоздания базовой rootfs нужно запустить любую из утилит с ключом -u в момент, когда rootfs не используется другими утилитами notamock. Для обновления rootfs ничего дополнительно делать не нужно.
notamock
Скрипт в первую очередь предназначен для локальной сборки проектов с abf. Но может собрать и по src.rpm. Например для локальной пересборки текущей версии lsof можно использовать такие команды:
dnf install abb notamock abb clone lsof cd lsof notamock
Первая сборка будет достаточно продолжительной, так как создается rootfs. Последующие сборки в том числе и других проектов, будут значительно быстрее. notamock как и остальные утилиты проекта имеет встроенный --help, кроме параметров в справке можно переопределить любое значение установленное в /etc/notamock.cfg в cmdline notamock, например:
notamock BUILD_cmd="abb build -ba" RPMSAVE=yes
Наиболее полезные, на мой взгляд, опции:
- -v - более подробный выхлоп
- -r - сборка для платформы отличной от текущей, например: -r 2023.1
- -e - остановка в сборочном контейнере перед запуском BUILD_cmd, можно править спек и запускать сборку с abb build. Полезно когда сборка падает. Два важных момента:
- не работает совместно с ключом -v
- измененный вами спек при выходе из этого режима (exit) не сохранится, но можно сделать копию спека с другим именем она сохранится.
- RPMSAVE=yes - заставит сохранить все скачанные сборочные зависимости во внутренний репозиторий notamock. Этот репозиторий подключается всегда, но пакеты попадают в этот реп только при наличии RPMSAVE=yes. То есть достаточно добавить при сборке конкретного проекта один раз и для последующих сборок зависимости будут устанавливаться из локального репозитория.
- REUSABLE=yes - заставит notamock использовать один и тот же контейнер с установленными BR для каждой сборки проекта. То есть это максимально быстрая сборка при работе над одним проектом. Важно:
- контейнер будет сброшен если запустить сборку без REUSABLE=yes
- контейнер будет сброшен если запустить сборку другого проекта
- PM_config=/home/user/dnf.conf - сборка с подменой конфига пакетного менеджера
- TMPD=/путь/папка - использовать указанный каталог вместо /tmp/notamock, полезно для гигантских проектов для сборки которых не достаточно размера /tmp хоста.
Более подробно в notamock --help и cat /etc/notamock.cfg. В notamock.cfg вынесено достаточно много настроек, например можно перевести сборку с dnf на yum только изменениями в этом конфиге.
notamocks
Утилита для локальных массбилдов с notamock. Сборки идут параллельно в несколько процессов. Для запуска массбилда вам нужен каталог в котором находятся папки с git проектами с abf.io или сделанными в том же формате. В простейшем виде достаточно запустить в этом каталоге:
notamocks
Полезные опции:
- -p - количество параллельно запускаемых сборок
- -s - не собирать проекты, который уже собраны
- -n или --chain сборка по цепочке, все что собралось за итерацию добавляется во временный реп и запускается следующая итерация с подключением этого репа, так до тех пор пока не соберется все.
- -l -каталог для логов
Для notamocks тоже можно передавать параметры из конфига в формате КЛЮЧ=ЗНАЧЕНИЕ, а также ключи notamock, которые будут переданы в каждое сборочное задание notamock.
notamockd
Утилита собирает контейнеры для запуска в них builder-c. Это программа, которая забирает сборочные задания с abf и возвращает собранное. В отличии от mock notamock может в одном контейнере собирать несколько заданий, для того чтобы использовать такую возможность в пакет notamock-abf входят модифицированные для сборки с notamock сборочные скрипты для builder-c.
Notamockd имеет два режима работы.
- Основной, notamockd создает контейнер и сразу запускает в нем необходимое количество билдеров.
- notamockd создает образ для docker, а контейнер запускает докер.
Основной режим
В основном режиме работы нужно передать один обязательный параметр - abf токен сборщика с ключом -t.
notamockd -t <TOKEN>
Такая команда запустит контейнер с одним билдером, с hostname в качестве имени билдера.
Полезные опции:
- -p - количество билдеров
- -b - имя для билдера, если их больше одного будут называться имя_1, имя_2, имя_3 и т.д.
- -B - внешний каталог, который пробрасывается в контейнер для того, чтобы сборки шли в нем.
- --watch - запуск в режиме мониторинга, можно передать количество строк для просмотра лога каждого билдера, например: --watch 10
- --tmux - запуск с tmux внутри контейнера, имеет смысл совместно с --watch, полезно для дебага.
Если не указать внешний каталог для сборки (ключ -B), сборки будут идти в /tmp контейнера размер которого установит systemd-nspawn, а это, если не ошибаюсь, 20% от ОЗУ. Альтернативный способ увеличить пространство для сборок - переключить с systemd-nspawn на встроенный в notamock способ использующий chroot - CHROOT=INTERNAL, в таком случае для сборок будет доступно все пространство /tmp хоста. Дополнительно можно указать TMPD=/папка/на/диске если нужно чтобы контейнеры вообще не использовали /tmp системы.
Образ для докера
dnf install docker systemctl start docker notamockd --docker -b имя_для_билдера docker image ls # находим свой образ docker run -it --rm --privileged -e BUILD_TOKEN="ABF_TOKEN" -e PARALLEL=3 -v /tmp:/tmp <docker image ID>
Внимание: без -v /хост/папка/:/tmp работать не будет из-за необходимости монтирования overlayfs внутри контейнера.
notamockc
Если вам понадобилась rootfs, не обязательно качать с ABF или собирать, просто запустите:
notamockc
или
notamockc -r 2023.1
Можно передать команду:
notamockc -r 2023.1 -- dnf provides thunderbird
Команда будет выполнена в chroot с rosa2023.1
С ключом --name или -n создаются именованные контейнеры:
notamockc -n my_container
которые сохраняют изменения между запусками.
Если нужно сохранять контейнеры и между перезагрузками хоста, дополнительно нужно указывать TMPD=/папка/на/диске, в параметрах notamockc или в /etc/notamock.cfg
Если вам нужен контейнер для работы над каким-то проектом, вероятно вам понадобится пробросить внутрь контейнера необходимые для работы файлы. Для этого удобно использовать параметр BIND:
notamockc BIND='/home/user/project::/root/project'
можно добавить параметры монтирования:
notamockc BIND='/home/user/project::/root/project::ro::noexec'
Аналогично вместо папки можно монтировать образы, squashfs архивы или разделы на диске. С той лишь разницей, что это будет не mount -o bind, а настоящее монтирование. Параметр может быть использован как из командной строки так и в конфигурационных файлах, также доступен и для notamock.
notamock + svace
Notamock можно использовать для сборки под svace для дальнейшего статического анализа кода.
На хостовую систему необходимо распаковать архив со svace, например, в /home/usert/svace/svace-3.4.240312-x64-linux.
Делаем конфиг /etc/notamock-dnf.conf:
[main] gpgcheck=0 best=True skip_if_unavailable=False keepcache=True reposdir='' [rosa-contrib] name=rosa-contrib baseurl=http://abf-downloads.rosalinux.ru/rosa$releasever/repository/$arch/contrib/release/ gpgcheck=0 [rosa-main] name=rosa-main baseurl=http://abf-downloads.rosalinux.ru/rosa$releasever/repository/$arch/main/release/ gpgcheck=0
Делаем конфиг notamock /etc/notamock.d/svace:
PM_config=/etc/notamock-dnf.conf BUILD_cmd='/opt/svace/bin/svace init && /opt/svace/bin/svace build rpmbuild -ba *.spec --define=\"_sourcedir '"$INTERNAL_DIR"'\" --define=\"_topdir '"$INTERNAL_DIR"'\"' BIND_SOURCE=yes BIND='/home/usert/svace/svace-3.4.240312-x64-linux:/opt/svace:ro'
Запускаем сборку:
sudo notamock -r 2021.15 name-X-Y.src.rpm
Результаты будут в name/.svace-dir относительно текущей папки, в которой запускали notamock. Далее нужно запускать svace analyze папки .svace-dir, можно на другом хосте, предварительно передав ее на него.
