Воспроизводимая система сборки пользовательских дистрибутивов для Linux - PullRequest
5 голосов
/ 22 августа 2009

Проблема

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

Каждый тип сервера - это в основном пользовательский дистрибутив. Индивидуальные настройки включают в себя изменения в исходных пакетах (другие исходные версии, параметры сборки, исправления и т. Д.) И, возможно, некоторые дополнительные пользовательские пакеты.

Например, мне нужен сервер с последней версией OpenLDAP slapd, скомпилированной с конкретными параметрами и некоторыми исправлениями. И вот тут все усложняется.

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

Требования к решению

Вид неопределенный. Я хочу подготовить все необходимое для создания своего собственного дистрибутива, дать ему имя (например, ldap-server) и дать это имя автоматизированной системе сборки в любое время, когда мне потребуется воспроизвести сборку.

Я думаю, это то, что должно иметь сообщество Gengoo или LFS. Также я видел такие проекты, как ALT Linux Hasher , Fedora Mock, Debian pbuilder / sbuild, но никогда не использовал ни один из них.

Есть идеи?

Заранее спасибо!

Ответы [ 5 ]

5 голосов
/ 21 марта 2011

Вы также можете использовать менеджер задач Nix и систему сборки Hydra для своей задачи.

  • Nix - это чисто функциональный менеджер пакетов.

  • Hydra - это система непрерывной сборки на основе Nix. (AFAIU, при необходимости выполняется перестройка зависимых пакетов.)

Nix может отслеживать не только зависимости пакетов и их модификацию, но и конфигурацию вашего хоста - чтобы обеспечить откат до согласованных предыдущих состояний. (Это идея NixOS , дистрибутива Linux на основе Nix.)

Также есть:

  • Disnix , система развертывания распределенных сервисов на основе Nix.
4 голосов
/ 22 августа 2009

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

  1. Чтобы автоматизировать сборку дистрибутива, я использовал XML-определение порядка и зависимостей сборки и сценарий GNU Make для построения параллельных независимых веток и построения бинарных пакетов. Результат, полученный из XML + shell-script + немного python + Make / Autotools, представлял собой полный набор специального набора «базовых» инструментов, а затем и дополнений.

  2. Вторым шагом была установка этих двоичных / сырых каталогов сборки в систему. Я использовал installwatch (я думаю), чтобы использовать inotify, чтобы следить за тем, куда все было установлено. Затем я выводил XML этого вместе с зависимостями любых двоичных файлов.

  3. После этого у меня был манифест сборки (XML) и для каждого пакета XML-файл со сведениями об установленных пакетах. Затем я создал инструмент для преобразования XML и двоичных файлов на месте в различные форматы (RPM и т. Д.)

  4. Теперь (используйте свое воображение) У меня есть скрипт установки для автоматизации сборки, тонны метаданных о собранных пакетах и ​​их зависимостях, а также метод превращения этих метаданных в развертываемые пакеты

  5. Затем я сделал build-скрипты для различных серверов, от glib up :) ... и запустил эти сборки. Система знала, какие пакеты /./ configure были общими и разделяла эти пакеты. Это оставило меня с
    o Репо под названием / common
    o Репо для каждого типа сборки и архитектуры

  6. Несколько сценариев / rsync-over-ssh и сценариев управления исправлениями, и вы ушли.

очевидно это очень грубый обзор моего подхода к созданию нескольких дистрибутивов для общей среды. Некоторые пакеты были метапакетами, которые влияли на дерево исходных текстов (но рассматривались как обычные пакеты как время сборки. Одним из примеров был метапакет, который запускался первым и применял исправления к ядру).

Тогда возникает вопрос автоматизации цепочки инструментов.

Все началось с LFS ... но, как видите, дела пошли немного авантюрно.

Суть в том, что это было очень весело , но я просто бросил все это для BSD и Fedora.

Такие вещи, как Suse Build Service могут представлять интерес. Совершенствование поиска и компиляции стабильных исходных кодов сделает вещи проще! Вам даже не нужно создавать что-либо, связанное с Suse.

1 голос
/ 19 декабря 2012

На всякий случай, еще один ответ на аналогичный набор проблем стал доступен после первоначального вопроса: mkimage-profile , который основан на связке инструментов ALT Linux, связанной с дистрибутивом, но дополняет ее инструмент управления конфигурацией изображения , который пытается сделать возникающие вилки минималистичными и лаконичными . К настоящему времени он официально документирован на русском языке (это было мое решение по нескольким причинам), но сам код довольно хорошо прокомментирован на английском языке.

Чтобы почувствовать приближение, см., Например, conf.d / server.mk :

distro/.server-base: distro/.installer use/syslinux/ui/menu use/memtest
    @$(call add,BASE_LISTS,server-base openssh)

distro/server-nano: distro/.server-base \
    use/cleanup/x11-alterator use/bootloader/lilo +power
    @$(call add,BASE_LISTS,$(call tags,server network))
    @$(call add,BASE_PACKAGES,dhcpcd cpio)

distro/server-mini: distro/.server-base use/server/mini use/cleanup/x11-alterator
    @$(call set,KFLAVOURS,el-smp)

Существует некоторая поддержка OpenVZ шаблонных кешей, VM изображений, ARM / PPC arches, git (как при фиксации этапов профиля, генерируемого с помощью содержательные описания) и графическое дерево конфигурации , среди прочих.

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

Существует предварительная поддержка образов netinstall размером от ~ 17 МБ ( пример ).

Мне также было бы интересно узнать ваши конкретные причины, по которым ALT нецелесообразно - конечно, есть некоторые известные, но ваши могут быть новыми для меня :-) PS: особенно когда вы более или менее готовы пойти так далеко, как LFS.

PS2: вы можете опробовать эту штуку в режиме реального времени с live-builder.iso в системе с 4 ГБ ОЗУ и DHCP-подключением к Интернету через Интернет, просто войдите как altlinux , cd / usr / share / mkimage-profile и make server-mini.iso

1 голос
/ 21 марта 2011

ALTLinux girar-builder - это система (внутри которой используется хешер ) для перекомпоновки пакетов и поддержки согласованного хранилища пакетов. Hasher - это инструмент для изоляции процессов сборки, так что все требования могут быть точно «отслежены», так что есть некоторые гарантии в отношении воспроизводимости процесса сборки.

Помимо прочего, girar-builder делает проверки зависимостей при добавлении (обновлении, удалении) вновь созданного пакета в хранилище, так что новый пакет не будет принят, если он нарушит зависимости другие пакеты, если только другие зависимые пакеты также не добавлены в ту же задачу сборки (= транзакция изменения репо) и перестроены после нового пакета. Это ситуация, которую часто можно наблюдать, обсуждая ( пример с депо, сломанным из-за исчезновения символа в общей библиотеке , пример удаления пакета ) в Список рассылки разработчиков ALTLinux ( английская копия списка ): «обнаружены НОВЫЕ неудовлетворенные зависимости». Чтобы продолжить, зависимые пакеты должны быть добавлены сопровождающими к этой задаче.

girar-builder также выполняет тест установки для новых пакетов, просто чтобы назвать другую проверку, выполненную git.alt (girar-bulder).

Чтобы быть уверенным, что сборка пакетов может быть воспроизведена в текущем состоянии хранилища пакетов, время от времени (довольно регулярно) проверяется, что каждый пакет в хранилище (называемый Sisyphus *) 1022 *) можно восстановить в текущий момент - отчет о состоянии теста на восстановление , журналы последнего теста на восстановление для пакета .

0 голосов
/ 21 марта 2011

Я не знаю много об этом, но я думаю Suse Studio стоит посмотреть.

...