LINUX.ORG.RU

ROSA ABF 2.0

 , , ,


1

3

Компания «РОСА» объявляет об обновлении среды разработки и сборки свободного программного обеспечения ROSA Automatic Build Farm (ABF) до версии 2.0. Система получила более 100 различных улучшений, которые помогут разработчикам и мейнтейнерам более эффективно управлять жизненным циклом дистрибутивов (от создания исходного кода до сборки ISO-образов).

Последнее время развитие ROSA ABF идет в двух основных направлениях: расширение функционала системы хранения исходного кода и развитие подсистемы сборки пакетов. Среди основных нововведений версии 2.0. можно отметить следующие функции:

REST API
Благодаря REST API, каждый может использовать ABF как платформу для своих приложений и сервисов, а также автоматизировать рутинные операции. Документацию по REST API вы можете найти на специальном сайте для разработчиков: http://abf-doc.rosalinux.ru/.

Pull Request
Функция Pull Request позволяет предложить изменения в git-репозитории других участников. После отправки такого запроса, все заинтересованные участники могут видеть, обсуждать и, при необходимости, редактировать код. Причем инструмент эффективен для проектов любого масштаба. Чтобы воспользоваться Pull Request, сделайте клон (форк) проекта, внесите в него правки, а затем предложите их в основную ветку, создав запрос на включение изменений из своего проекта. При этом никаких прав на основной проект не предоставляется и не требуется.

Построчное комментирование кода
Поскольку во время работы с кодом невозможно обойтись без обсуждений, в ABF 2.0 включена поддержка Github Flavored Markdown — простого языка разметки. Вместе с возможностью обсуждать каждую строчку кода, он предоставляет команде разработчиков хороший инструмент для дискуссий.

Трекер с реакцией на изменение кода
Под реакцией на изменения исходного кода мы подразумеваем отображение в задаче следующих данных:

  • информация о сделанных изменениях в исходном коде, если в коммите был указан номер задачи;
  • информация о других задачах и запросах на изменения исходного кода, если в них ссылались на данную.

Теперь в задаче можно увидеть всю информацию о ней: обсуждения, коммиты, связанные задачи и запросы на изменения исходного кода (Pull Request).

Git через ssh
Наверное, самая ожидаемая функция ROSA ABF. Во-первых, она избавляет разработчика от необходимости вводить пароль для совершения каждой операции. Во-вторых, снимает ограничение на объем передаваемых данных. И, в-третьих, это классический вариант работы с удаленным сервером Git.

Подсистема сборки пакетов
Обновленная подсистема получила полноценную поддержку сборки пакетов под разные дистрибутивы и повышенный уровень безопасности. Были устранены неявные зависимости между сборками, поскольку для каждой из них теперь используется чистая виртуальная машина. Также добавлены новые возможности по работе со сборочными заданиями и проведена унификация рабочих инструментов. Теперь стало возможно отменить уже собирающиеся задание и стал доступен автоматически обновляемый общий лог процесса.

Что ещё нового в ROSA ABF 2.0:

  • возможность сравнения произвольных коммитов и веток в веб-интерфейсе;
  • почтовые оповещения по различным аспектам системы и гибкие возможности настройки таких оповещений;
  • механизм массовых сборок;
  • официальный и ещё два неофициальных консольных клиента;
  • страница релизов исходного кода проекта;
  • информационные бюллетени;
  • расширенные возможности у персональных репозиториев;
  • подробная техническая документация.

Подробный список изменений на английском языке вы можете прочесть в блоге проекта ABF: http://abf-blog.rosalinux.ru/post/48772687862/abf-long-road-to-2-0

Отрадно констатировать тот факт, что сообщество регулярно пополняет экосистему Automatic Build Farm новыми инструментами, позволяющими существенно сократить рутинные операции и получить подробные данные о состоянии пакетной базы. Например:

URPM-Repoclosure (отвечает за замкнутость репозитория по зависимостям);
ABI Compliance Checker (анализирует совместимость версий С/C++ библиотек);
Upstream Tracker (инструмент мониторинга и анализа библиотек в Upstream);
Updates Tracker (определяет устаревшие пакеты по сравнение с Upstream или другими дистрибутивами);
PkgDiff (показывает изменения в пакетах).

ROSA ABF 2.0 является открытым проектом и мы приглашаем всех желающих принять участие в нем. Разработчики могут воспользоваться обширной документацией по системе.

На текущий момент ABF как платформу для разработки своих дистрибутивов использует не только компания РОСА, но и OpenMandriva и Conectiva. В качестве экспериментов на ABF также собраны AltLinux, Fedora, OpenSuse, Scientific Linux, RHEL.

Исходный код

Документация по ABF на английском языке

Обсуждение проекта

Служба поддержки

Краткое руководство по работе в системе ROSA ABF

>>> Подробности



Проверено: Aceler ()
Последнее исправление: cetjs2 (всего исправлений: 6)

Ответ на: комментарий от dearboy

То, что VM чистая, для сборки пакета не играет роли, ведь в этой системе все равно установлено больше пакетов, чем в базовом chroot, а значит данные из нее могут повлиять на сборку и она перестанет быть повторяемой, то есть на разных виртуальных машинах мы будет получать разные пакеты из одного исходного кода, что неприемлемо.

Поэтому для чистой сборки пакета используются рекомендуемые инструменты дистрибутива: для RHEL - mock, для ROSA/Mandriva — mock-urpmi.

Зачем тогда использовать виртуальные машины? От чистой виртуальной машины требуется отсутствие закладок и проблем, которые могли быть оставлены предыдущей сборкой. Также один воркер может управлять различными виртуальными машинами, что полезно в случае поддержки сразу нескольких дистрибутивов(как в нашем случае). К примеру, есть 10 воркеров - они универсальны. Пришло 2 задания на Rosa и 2 на RHEL, он их все одновременно и будет собирать. Придеть 10 заданий для Rosa, все 10 воркеров будут собирать Rosa, 10 на RHEL - все 10 RHEL. Это очень удобно. Ранее нам приходилось заранее определять тип виртуальной машине и было запущено, скажем, 7 воркеров ROSA и 3 RHEL. И если, скажем, на RHEL возникла очередь из 100 пакетов, а на ROSA свободно, эти ресурсы все равно не могли быть использованы и все собиралось на 3 машинах, когда остальные 7 простаивали.

Плюс мы благодаря временным виртуальным машинам в случае, если сборка пакета зависла, он будет автоматически уничтожен по истечению 12 часов или по запросу от пользователя в веб-интерфейсе, так как мы всегда сохраняем контроль на уровне управления виртуальной машиной. При этом следующие задание воркер будет готов принять сразу же без какого-либо вмешательства с нашей стороны.

anonymous
()
Ответ на: комментарий от k0da

OBS Готовит buildroot вне машины. VM только собирает. chroot там не нужен.

У каждого свой подход. Наш состоит в том, чтобы по максимуму использовать родные инструменты платформы, которые часто предоставляют довольно интересные возможности.

Не вижу ничего плохого ни в подходе OBS, ни в подходе ABF — у проблемы обычно несколько вариантов решения.

anonymous
()
Ответ на: комментарий от anonymous

С этого момента прошу подробнее.

1) Какие именно закладки вы закладываете в свои чистые виртуальные машины? 2) Какие именно изменения в системе может провести СШРУТОВАННЫЙ процесс? 3)От чего одной виртуалке не собрать бы с десяток различных по мантейнеру но одинаковых по АРХИТЕКТУРЕ сборок? 4) Почему бы не собрать нативную архитектуру просто в сшруте, без использования виртуальной прослойки. 5) Чем не угодил куему?

anonymous
()
Ответ на: комментарий от anonymous

1) Какие именно закладки вы закладываете в свои чистые виртуальные машины?

Мы — никаких, напротив мы боремся против закладок, которые могут оставить пользователи. Вот мой ответ в предыдущем комментарии:

От чистой виртуальной машины требуется отсутствие закладок и проблем, которые могли быть оставлены предыдущей сборкой.

Не вижу, где бы я писал, что мы вставляем закладки.

2) Какие именно изменения в системе может провести СШРУТОВАННЫЙ процесс?

Надо понимать, что chroot — не панацея. Существуют возможности его обхода, к тому же не стоит забывать про возможность атаки, к примеру, на ядро системы.

Система сборки — это выполнение произвольного пользовательского кода, при этом при свободной регистрации, использующей только почту, ни о каком кредите доверии к пользователям в плане безопасности быть не может, мы должны сами позаботиться об этом.

Собственно во многом из-за проблем с chroot появились виртуализация на уровне операционной системы и именно ей, а не chroot доверяют многие комнании, к примеру, предоставляющие хостинг. Второе ее достоинство виртуализации - лимитирование ресурсов, что тоже важно.

До сих пор наиболее безопасной средой для выполнения произвольного кода считается полная виртуалиация. Вкупе с другими ее достоинствами: не требуется специальное ядро, поддержка любого дистрибутива без изменений мы решили остановиться именно на ней.

Чтобы предотвратить споры по поводу безопасности chroot и неумении его готовить, просто покажите мне более или менее крупную компанию, которое предоставим вам площадку с полным доступом внутри chroot, а не в виртуализации.

3)От чего одной виртуалке не собрать бы с десяток различных по мантейнеру но одинаковых по АРХИТЕКТУРЕ сборок?

По причинам, описанным выше. В целях безопасности каждая сборка выполняется в гарантированно чистом окружении. Мы считаем, что одного chroot-а, чтобы гарантировать это, недостаточно. О причинах выше.

4) Почему бы не собрать нативную архитектуру просто в сшруте, без использования виртуальной прослойки.

Безопасность, проблемы с поддержкой множества дистрибутивов, проблемы с обновлением таких chroot-ов, отсутствие возможности сборки родными инструментами дистрибутива, одна сборка может захватить все ресурсы сервера.

В случае успешной атаки мы получим захваченный сервер, а не временную виртуальную машину, которая будет уничтожана меньше, чем за 12 часов и никак не повлияет ни на предыдущие, ни на следующие, ни на соседние сборки.

5) Чем не угодил куему?

А чем не угодил VirtualBox? У нас есть отличный пример его работы с недоверенным кодом и сотнями тысячими задач в месяц: http://travis-ci.org/. Наша архитектура сделана на основе их опыта и с использованием тех же инструменов.

Лично против ни Qemu, ни KVM ничего против не имеем. Просто выбраный нами инструмент http://vagrantup.com/ на текущий момент не имеет их поддержки.

Если речь про Qemu в конексте ARM, то мы ведем работы в этом направлении и обязательно о них расскажем в будущем. Использование VirtualBox пока не выглядит серьезным препятствием для этих целей.

anonymous
()
Ответ на: комментарий от anonymous

5)А чем не угодил виртуалбокс?

Мне лично виртуалбокс не угодил плотностью упаковки виртуалных машин. Вам - скорее всего поддержкой армов.

Если говорить о сборке «вражеского кода вражеским инструментом» - использование виртуалки вполне резонно. Если же говорить о системе сборки вообще - вполне вероятен вариант сборки вашего кода вашим же инструментом, как к примеру работают веб-сборщики thinstation. Вопрос о сшруте связан именно с такими случаями.

Очистка виртуалок в принципе не такая уж и сложнаяя задача, но почему бы не подсунуть пользователю его же виртуалку без каких либо дополнительных манипуляций?

Ну и вопрос доверия. Он, кстати, взаимен.

anonymous
()
Ответ на: комментарий от anonymous

Мне лично виртуалбокс не угодил плотностью упаковки виртуалных машин

У нас этой проблемы нет, так как каждой такой виртуальной машине выделено значительные ресурсы, в итого на мощном сервере: 128 ГБ ОП, два физических процессора по 6 ядер с HT (итого 24 ядра) запускатся, к примеру, всего 8 сборочных клиентов, каждый из которых одновременно манипулирует 1 виртуальной машиной, при этом виртуальная машина запускатся только на момент задания и останавливается после его выполнения.

Очистка виртуалок в принципе не такая уж и сложнаяя задача, но почему бы не подсунуть пользователю его же виртуалку без каких либо дополнительных манипуляций?

Потому как у нас нет пользовательских виртуальных машин. У нас есть сборочные клиенты, у которых строго очерчен круг задач, а все предосторожности направлены на выполнении ими этих целей и непригодность для остальных. У нас нет задачи запоминать изменения, что сделаны, наоборот - все должны стартовать с единой контролируемой точки, ведь задача сборки: эталонная повторяемая сборка в чистой, безопасной и доверенной среде.

Именно поэтому мы так облачились в два уровня: сначала chroot, отвечающий за чистоту и повторяемость, а потом виртуальная машина, отвечающая за доверенность и безопасность среды.

В вашем же варианте нам пришлось бы хранить для каждого пользователя по несколько виртуальных машин для разных дистрибутивов, при чем учитывая, что серверов несколько, на каждом из них по копии. И еще в случае проблем разбираться с индивидуальной пользовательской конфигурацией, хотя предполагается как раз, что сборки не должны отличаться, то есть должны быть повторяемы. Аналогично непонятно, как быть, если требуется обновить систему.

Все изменения, что требуется для того, чтобы собрать пакет, должны быть описаны в спеке. Если спек содержит всю необходимую информацию, то пакет соберется без каких-либо проблем что на машине пользователя, что на ABF, что у другого пользователя. В этом плане сборка на чистой виртуальной машине с использованием chroot — то, что нужно.

Ну и вопрос доверия. Он, кстати, взаимен.

Совершенно верно, поэтому у нас весь код открыт до последних мелочей, а результаты сборки всегда можно повторить локально с помощью родных инструментов платформы и сравнить, для этого не требуется даже вникать в код ABF: собрали локально, собрали на ABF — сравнили результаты.

За ABF как сервис по адресу http://abf.rosalinux.ru/ стоит конкретное юридическое лицо и конкретные люди, что подтвержденно SSL-сертификатом бизнес-уровня. Нам в отличие от в целом анонимных пользователей есть что терять.

Если же говорить о системе сборки вообще - вполне вероятен вариант сборки вашего кода вашим же инструментом, как к примеру работают веб-сборщики thinstation. Вопрос о сшруте связан именно с такими случаями.

Проекты, что обитают у нас в системе, превращаются в пакеты с помощью различных компиляторов и с использованием различных библиотек, которые разработчик может сам выбрать из доступных в целевом дистрибутиве. В этом плане никак ограничений конкретно ABF не накладывает.

Возможно, я некорректно понял ваш пример, поэтому заранее прошу прощения, если он выпал из контекста.

anonymous
()
Ответ на: комментарий от anonymous

За ABF ... стоит конкретное юридическое лицо и конкретные люди, что подтвержденно SSL-сертификатом бизнес-уровня.

... сказал anonymous. :)

Skull ★★★★★
()
Ответ на: комментарий от k0da

Не выдергивайте без контекста. У OBS есть разные типы воркеров: - чрутовые. Тут в случае kiwi вообще чрут в чруте. А виртуалка целиком даже opensuse. - kvm - etc. Так же с недавнего времени есть возможность создания базового снапшота.

anonymous
()
Ответ на: комментарий от anonymous

Ага, а еще z/VM, lxc и т.д. Но публичные хосты на KVM и Xen

k0da
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.