LINUX.ORG.RU

Как собирают свои дистрибутивы большие мальчики?

 , ,


0

2

Я хочу собирать миниатюрные livecd образы с помощью CI/CD, поэтому у меня как говорится встал вопрос. Как собираются крупные дистрибутивы аля debian или ubuntu?

Как это вижу я:

где-то в гитлабе хранятся исходники, потом через ci/cd собирается iso образ и пушится на релиз сервер. Но вот только как это происходит? iso билдится где-то в контейнере? как собирается новый релиз? а главное чем? должен же быть какой-то автоматизированный билдер.

Я нигде не могу найти примера как собирать дистрибутив из исходников в ci/cd. Везде одни примеры с archiso или ему подобных систем.

Было бы неплохо иметь возможность собирать минимально рабочий дистрибутив в docker, podman или даже vagrant контейнере. Как вариант можно засунуть buildroot в контейнер, но это костыль как по мне.

Хочется иметь флоу аля:

пушнул код в ветку –> тригернулся пайплайн –> собрался nightly build iso

сделал релиз тег –> тригернулся пайплайн –> собрался релиз

Может есть какой-то признанный индустрией стандарт сборки или типа того? Как это работает у больших мальчиков?


Сколько модных слов и всё бесполезное.

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

Из бинарных пакетов уже собирается iso, думаю алгоритм там простой (сам установщик в готовом для запуска виде + рядом кладётся локальная репа с нужными пакетами, взятыми из обычной репы в инете).

iso релизов собираются скорее всего ручным запуском сборочного скрипта в организационно-запланированный момент времени.

nightly тупо раз в сутки каким-нить кроном. Пересборку iso по триггеру обновления пакетов вряд ли кто-то делает, такой роллинг-установщик никому не нужен.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 3)
Ответ на: комментарий от firkax

Для этой сборки есть какая-то инфраструктура, и я практически уверен что никаких гитлабов и подобного им хлама там нет.

Хорошо, а что за инфраструктура должна быть? Есть какие нибудь мысли по этому поводу? Вряд ли такие крупные дистры собираются на одной машине одного сисадмина

Unixson
() автор топика

Вот почитай:

Если кратко, то в начале через debootstrap ставится базовая система из пакетов в официальном репозитории.

Потому в установленную систему вносятся правки для запуска в liveCD режиме.

Потом из этого собирается squaashfs образ.

squashfs образ, файл ядра копируется в директорию на основе которой будет собираться iso образ, сюда же помещаются файлы загрузчиков и конфигурационные файлы для них. Собирается initramfs со скриптами для запуска из ISO образа.

Через mkisofs вызывается сборки iso файла с параметрами вызова загрузчиков.

Готово.

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

Но мне такой флоу не подходит

Чем именно? У тебя будут точно такие же этапы.

  1. установка в директорию базовой системы.
  2. Сборки squashfs
  3. Подготовка директории для iso
  4. сборка iso

Вариативно только то, что ты будешь ещё запихивать в squashfs и скрипты запуска в initramfs.

Всё остальное точно так же.

Видимо все таки придется пихать buildroot в контейнер.

Зачем?

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

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

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

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

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

А что команды в chroot ты выполнять не умеешь?

Т.е. /mnt/root/build.sh

cd /src/package
./configure
make
make install
chroot /mnt/root /build.sh

Но так, как хочешь ты у тебя в системе даже в chroot будут установлены и сборочные зависимости.

Поэтому тебе нужно как-то собирать пакеты программ, которые ты будешь ставить в собираемую систему твоего LiveCD.

Если ты хочешь конечно получить минимальную систему.

Плюс в make install можно ставить пакеты относительно другой директории.

Т.е. условно ты в chroot собираешь систему, но относительно корня chroot ты ставишь собранные программы в другую директорию.

Посмотри справку по make и прочим сборочным системам, в зависимости от того какая используется в приложении, которое ты собрался компилировать.

Но, вообще, собирать LiveCD компилируя все программы смысла нет.

Плюс при такой сборке тебе ещё нужно как-то проверять, что скомпилированное приложение будет корректно работать с теми версиями библиотек, что ты собрал.

Это уже систему тестирования ты сам будешь писать.

kostik87 ★★★★★
()
Последнее исправление: kostik87 (всего исправлений: 1)
Ответ на: комментарий от kostik87

А что команды в chroot ты выполнять не умеешь?

Такое решение не маштабируется. Я хочу чтобы можно было собирать хоть в travis ci, хоть в gitlab, хоть на локальных машинах. Причем не факт что у сторонних разработчиков будет стоять линукс. Поэтому нужна изоляция. Плюс никто не будет ставить зависимости и компиляторы отдельно.

Но, вообще, собирать LiveCD компилируя все программы смысла нет.

Почему же нет? Мы сейчас говорим про имейдж где будет от силы ядро, инит и баш. Плюс а если я хочу вносить свои изменения которые не пойдут в апстрим? Я не особо хочу доверять каким-то сторонним мейнтейнерам. Легче сделать монорепу со всем необходимым

Но в целом я понял

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

Почему же нет? Мы сейчас говорим про имейдж где будет от силы ядро, инит и баш.

А что для запуска bash не нужны glibc, coreutils, binutils и прочие утилиты и библиотеки для работы этих утилит? То, что программа скомпилировалась с определённой библиотекой не говорит ровным счётом ничего о том, что она будет запускаться и корректно работать с этой версией библиотеки. При компиляции проверяется корректность входных и выходных параметров по числу и типу. А работу программы ты можешь проверить только посредством тестирования. Ты можешь использовать утилиты busybox - в нём как раз есть минимально необходимый набор функциональных блоков для запуска BASH, который там тоже свой встроенный. Но минималистичный. Для запуска полноценного GNU Bash тебе придётся собрать всю необходимую обвязку.

Я хочу чтобы можно было собирать хоть в travis ci, хоть в gitlab, хоть на локальных машинах.

В gitlab есть для этого gitlab-runner. Скажи пожалуйста, а зачем разработчику собирать что-то на своей машине?

оэтому нужна изоляция. Плюс никто не будет ставить зависимости и компиляторы отдельно.

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

Плюс а если я хочу вносить свои изменения которые не пойдут в апстрим?

Это делается патчами на исходные коды.

Я не особо хочу доверять каким-то сторонним мейнтейнерам.

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

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

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

установка в директорию базовой системы. Сборки squashfs Подготовка директории для iso сборка iso

Это как раз то что я и буду делать по итогу. Buildroot как раз делает это все, только в автоматическом режиме.

Unixson
() автор топика
Ответ на: комментарий от kostik87

Для запуска полноценного GNU Bash тебе придётся собрать всю необходимую обвязку.

Естественно, по мимо того же bash, должны собраться и все его зависимости и обвязки.

В gitlab есть для этого gitlab-runner. Скажи пожалуйста, а зачем разработчику собирать что-то на своей машине?

К примеру для дебага внутри виртуальной машины. Считай как симулятор у xcode. (Кстати было бы неплохо сделать какой нибудь плагин для intellij idea. Написал какую-то часть системы или внес правки, нажал кнопку и тут же проверил)

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

К примеру для дебага внутри виртуальной машины.

debug должен производиться в среде разработки программиста, далее код заливается в git.

И в gitlab посредством CI/CD проводятся тесты на корректность входных и выходных параметров функций и методов разрабатываемого приложения. Если они прошли успешно производится компиляция приложения и проводятся функциональные тесты уже на основе входных и выходных данных по взаимодействию с прочими компонентами системы.

Если все тесты прошли успешно - всё собирается в тестовый релиз и тестовый релиз передаётся тестировщикам.

kostik87 ★★★★★
()
Последнее исправление: kostik87 (всего исправлений: 1)
Ответ на: комментарий от kostik87

это понятно, понятное дело что в CI/CD должны быть unit тесты. но перед тем как отдавать тестировщикам, нужно самому тоже хотя бы поверхностно потыкать, провести smoke тесты, оценить usability и т.д. Ну и в целом посмотреть на работу со стороны, так сказать с высоты птичьего полета. Так сказать drink your own poison.

Да и я на 146% уверен что можно прокинуть дебагер из виртуальной машины в ide.

Unixson
() автор топика
Последнее исправление: Unixson (всего исправлений: 1)