Colaboot

CoLaBoot (Compressed Layers Boot) - система загрузки, при которой корневая файловая система может быть представлена в виде отдельных функциональных сжатых слоёв.

Основные идеи:

• корневая файловая система собирается из отдельных слоёв в OverlayFS, и при этом каждый образ слоя сжат в SquashFS.
• использование слоёв позволяет нарезать файловую систему функциональными слоями, используя "наследственность" и "переиспользование":

Допустим, у нас есть слой базовой системы. Поверх него мы можем сделать небольшие дополнительные слои installer, rescue, и слой побольше live-system. А поверх live-system еще extended-live-system с тяжёлыми мультимедиа и офисными пакетами. И всё это в сумме займёт меньше места, чем набор "самостоятельных" образов.

• использование squashfs минимизирует используемую для кеширования образов слоёв память, а так же позволяет монтировать слои непосредственно с места, где они расположены.
• образы слоёв могут как скачиваться по сети (http/ftp/tftp/...), так и монтироваться напрямую с локальных носителей (cdrom/hdd). Или скачиваться с cdrom, чтобы не держать его в использовании. Или монтироваться напрямую с NFS/iSCSI. Как удобно, в общем.
• слои могут быть optional - очень удобно для накатывания оперативных обновлений, которых может и не быть. Выпустили ISO с инсталлятором, а последние обновления ищутся при загрузке хоста на ftp.altlinux.org, а если не нашлись (интернета нет) - ничего страшного, продолжим без них.
• стремительность разработки: оперативные изменения могут вноситься только в последний, относительно небольшой по размеру слой, и цикл "нашли проблему - пофиксили слой - экспортировали слой в squashfs - перезагрузили тестовую виртуалку - проверили" реально укладывается в пределах одной минуты.
• полное разделение собственно системы от используемой версии ядра и всех его модулей - загрузочные модули встраиваются в initrd или подключаются к нему отдельной initramfs по ситуации, полный набор модулей подключается как отдельный слой, совершенно независимый от остальной системы. Таким образом, необходимость обновить ядро не затрагивает все остальные слои (похоже на контейнерную виртуализацию, системе в контейнере всё равно, что там за ядро в хост-системе), так же, используемая система не ограничивается ALTLinux. Главное, чтобы была совместима с ядром.
• слои можно делать вручную. Но вообще в качестве источников слоёв крайне органически подходит Докер, он сам основан на той же идеологии. При использовании драйвера хранения overlay/overlay2 каждый образ Докера легко экспортируется в отдельный образ слоя.
• возможность использования уже готовых докерных образов, коих миллиарды - главное, чтобы /sbin/init было и желательно udev.
• просто создано для тощих клиентов! (собственно, для них изначально и разрабатывалось).

Текущая реализация

пакеты с базовой, но работоспособной (у меня уже в продакшене) реализацией отправились в Сизиф:

• make-initrd-colaboot с соответствующей фичей для Make-initrd (по мотивам make-initrd-netboot),
• colaboot-utils cо скриптами для изготовления образов слоёв и образов с модулями ядра.

Там же и немного документации ([1][2]), и разнообразные примеры изготовления-использования ([3][4]).

Quckstart

(на примере сборки образа ISO. Для загрузки по сети всё то же самое, только нужна будет инфраструктура для этой загрузки - DHCP сервер, HTTP/TFTP/etc; и модули для сетевой карты, а не устройства CDROM)

1. Первым делом нам нужны образы слоёв корневой файловой системы (может быть и в единственном числе). Штатным способом образы добываются из Докера, с помощью скрипта docker2squash. Но можно так же вручную сжать какую-то директорию с помощью mksquashfs, или взять уже готовый образ (убедитесь, что его модули будет совместимы по версии ядра).
   Если вы экспортируете образ Докера, и это не base image, вам необходимо так же экспортировать всех его предков - или вручную вызывая скрипт для каждого образа, или воспользовавшись режимом chain. В случае, если вы хотите получить один неделимый образ, при экспорте можно объеденить образ Докера со всеми его предками, использовав режим merged.

   # docker2squash altlinux-p8-clb-base
   # docker2squash altlinux-p8-clb-network
   

2. Далее, делаем initrd с поддержкой colaboot (надо не забыть сначала установить пакет make-initrd-colaboot). Загляните в конфиг /etc/initrd.mk.d/colaboot.mk.example, всё ли в нём устраивает. Основная идея - класть в сам initrd как можно меньше модулей для универсальности и минимизации его размера, а все необходимые по ситуации модули предоставлять в качестве дополнительной initramfs.

   # make-initrd -N -c /etc/initrd.mk.d/colaboot.mk.example -b ./ 2>mkinitrd.log
   

3. Теперь нам нужен образ initramfs с модулями ядра для обретения устройства /dev/sr0 в загружаемой системе. Для QEMU подойдёт такой вот список модулейcdrom.modlist, для железного хоста он может отличаться (а выяснить точный их список всегда можно с помощью make-initrd guess-modules /dev/sr0.
   Для приготовления такого образа воспользуемся скриптом modlist2image:

    # modlist2image `uname -r` cpio /path/to/cdrom.modlist
   

и полученный результат переименовываем по схеме 8.3 (только буквы-цыфры), чтобы isolinux его осилило. Например, в cdrommod.img.

1. Делаем директорию с проектом ISO (у вас должен быть установлен syslinux и mkisofs), кладём туда:
   • isolinux.bin, isolinux.cfg, и всякую syslinux-специфику (вроде menu.c32).
   • vmlinuz и initrd.img (который с фичей colaboot), эти имена файлов тоже в формате 8.3
   • дополнительные initramfs (в нашем случае - вышесделанный cdrommod.img)
   • все образы слоёв, полученный на первом этапе. Если слоёв несколько, должен быть так же создан файл манифеста с описанием их порядка загрузки (вроде такого), а если слой только один, то его можно описать в манифесте как единственный слой, или обойтись вообще без манифеста, указав путь к образу такого слоя в параметре загрузки root=. И, скорее всего, вам так же понадобится слой с полным необходимым набором модулей ядра (а не только требуемых для загрузки, как в initramfs).
2. Отредактируйте isolinux.cfg под ваши нужды, правильно указав имена файлов для ядра, initrd, дополнительных initramfs, и параметр root=. Например:

   LABEL CLB-TEST
   MENU LABEL CLB TEST
       KERNEL vmlinuz
       INITRD initrd.img,cdrommod.img
       APPEND root=file:///sr0/clb-test.manifest rootdelay=5

3. Изготавливаем из директории проекта образ iso:

   # mkisofs -o clb-test.iso -b isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -J -r /path/to/iso-project-dir
   

Референсный образец демо-ISO можно скачать здесь.

Зачем слои?

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

Так, в моих примерах:

• был изначальный-неделимый base, от которого произошёл network (ума не приложу, зачем нужен без-сетевой хост, так что наверное имело бы смысл как раз network сделать базовым, ну да ладно).
• network породил xorg. А почему их не объеденить? network уже сам по себе пригоден в качестве самостоятельной минимальной системы, для быстрого обзора загруженного хоста например, и может быть родителем для всяких rescue, server и прочих образов-без-гуи. Поэтому отдельно.
• xorg сам по себе не особо полезен, но является универсальным родителем для:
  • rdp-shell
  • firefox kiosk
  • lightdm
• а поверх lightdm, который сам по себе - тоже бесполезный-универсальный-родитель, всякие xfce/lxde/fluxbox.

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

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

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

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

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

Ну и можно представить сценарий, когда слои не нужны - финальный там образ какой-то неделимой системы... ну ок, можно делать и такие, или экспортируя готовый base image, или в режиме merge объеденяя какой-то целевой слой со всеми его родительскими. Или вообще натравить mksquashfs на любую директорию с готовой системой вручную. Или взять готовый live.squash (или как он там называется) с официальных ISO-образов. Только нужно убедиться, что в таком монолитном образе есть все необходимые модули для вашего ядра и вашего хоста.