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.
• просто создано для тощих клиентов! (собственно, для них изначально и разрабатывалось).

Зачем слои?

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

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

• был изначальный-неделимый 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-образов. Только нужно убедиться, что в таком монолитном образе есть все необходимые модули для вашего ядра и вашего хоста.