PastorDi в 14:32, 23 апреля 2025

2025-04-23T14:32:42Z

← Предыдущая версия		Версия от 17:32, 23 апреля 2025
Строка 1:		Строка 1:
			Notamock — набор утилит, создающих окружения для сборки rpm пакетов в Rosa Linux.

	=== Notamock ~~— набор утилит, создающих окружения для сборки rpm пакетов~~ ===		=== Notamock ===
	Частично пересекается по задачам с mock, отсюда и название.		Частично пересекается по задачам с mock, отсюда и название.

Betcher: /* Общее */

2025-03-28T07:05:31Z

Общее

← Предыдущая версия		Версия от 10:05, 28 марта 2025
Строка 13:		Строка 13:
	==== Общее ====		==== Общее ====
	* все утилиты требуют прав root, связано c использованием монтирований. Далее по тексту su, sudo опускаются.		* все утилиты требуют прав root, связано c использованием монтирований. Далее по тексту su, sudo опускаются.
	* все утилиты имеют общий конфигурационный файл, по умолчанию это /etc/notamock.cfg (можно использовать собственные с ключом --config /путь/файл.cfg)		* все утилиты имеют общий конфигурационный файл, по умолчанию это /etc/notamock.cfg (можно использовать собственные с ключом --config /путь/файл.cfg), а также файлы в /etc/notamock.d/
	* все утилиты имеют встроенный --help		* все утилиты имеют встроенный --help
	* все утилиты, запущенные с одним конфигом, будут использовать одни и те же базовые rootfs. Такие rootfs создаются по одной для каждой платформы и многократно переиспользуются. Например при запуске notamockd создается контейнер использующий такую rootfs, билдеры в контейнере используют notamock, каждый процесс которого, в свою очередь, также будет использовать ровно ту же базовую rootfs. Количество rootfs соответствует количеству поддерживаемых платформ и никак не зависит от количества процессов notamock, контейнеров и билдеров.		* все утилиты, запущенные с одним конфигом, будут использовать одни и те же базовые rootfs. Такие rootfs создаются по одной для каждой платформы и многократно переиспользуются. Например при запуске notamockd создается контейнер использующий такую rootfs, билдеры в контейнере используют notamock, каждый процесс которого, в свою очередь, также будет использовать ровно ту же базовую rootfs. Количество rootfs соответствует количеству поддерживаемых платформ и никак не зависит от количества процессов notamock, контейнеров и билдеров.

Betcher в 06:54, 28 марта 2025

2025-03-28T06:54:45Z

Внесённые изменения

Betcher: Новая страница: « = Notamock = Материал из Rosalab Wiki Перейти к: навигация, поиск == Содержание == * 1 Notamock — набор утилит, создающих окружения для сборки rpm пакетов 1.1 Общее 1.2 notamock 1.3 notamocks 1.4 notamockd * 1.4.1 Основной режим * 1.4.2 Образ для докера 1.5 notamockc 1.6 notamock + svace = Notamock — набор...»

2025-03-28T06:47:31Z

Новая страница: « = Notamock = Материал из Rosalab Wiki Перейти к: навигация, поиск == Содержание == * 1 Notamock — набор утилит, создающих окружения для сборки rpm пакетов ** 1.1 Общее ** 1.2 notamock ** 1.3 notamocks ** 1.4 notamockd *** 1.4.1 Основной режим *** 1.4.2 Образ для докера ** 1.5 notamockc ** 1.6 notamock + svace = Notamock — набор...»

Новая страница

= Notamock =
Материал из Rosalab Wiki

Перейти к: навигация, поиск

== Содержание ==

* 1 Notamock — набор утилит, создающих окружения для сборки rpm пакетов
** 1.1 Общее
** 1.2 notamock
** 1.3 notamocks
** 1.4 notamockd
*** 1.4.1 Основной режим
*** 1.4.2 Образ для докера
** 1.5 notamockc
** 1.6 notamock + svace

= 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, например, в <code>/home/usert/svace/svace-3.4.240312-x64-linux</code>.

Делаем конфиг <code>/etc/notamock-dnf.conf</code>:
[main]
gpgcheck=0
best=True
skip_if_unavailable=False
keepcache=True
reposdir=<nowiki>''</nowiki>

[rosa-contrib]
name=rosa-contrib
baseurl=<nowiki>http://abf-downloads.rosalinux.ru/rosa$releasever/repository/$arch/contrib/release/</nowiki>
gpgcheck=0

[rosa-main]
name=rosa-main
baseurl=<nowiki>http://abf-downloads.rosalinux.ru/rosa$releasever/repository/$arch/main/release/</nowiki>
gpgcheck=0
Делаем конфиг notamock <code>/etc/notamock.d/svace</code>:
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, можно на другом хосте, предварительно передав ее на него.

Источник — «<nowiki>http://wiki.rosalab.ru/ru/index.php?title=Notamock&oldid=21132»</nowiki>

Notamock - История изменений

PastorDi в 14:32, 23 апреля 2025

Betcher: /* Общее */

Betcher в 06:54, 28 марта 2025