LINUX.ORG.RU

Оркестрация на POSIX shell

 


0

1

Как и с другими проектами, прежде чем браться за дело, создаю тред. Планирую начать разработку системы оркестрации на POSIX shell, система будет представлять собой сборочный цех дистрибутивов в готовые для загрузки образы raw, initramfs, iso и так далее. Образы будут создаваться из build-файлов, что-то вроде пакетного менеджера, только для дистрибутивов.

Зарубежные партнёры заприметившие проект booty даром выделили сервер (4 ядра 4 гига) для развития http://www.voglea.com/crux/crux_gnulinux/, где в качестве эксперимента я запустил ежедневную автосборку дистрибутивов CRUX из последних версий портов, т.е. сейчас там представлена версия CRUX 3.6 которая в стадии глубокого тестирования, но неофициально образ можно стянуть у меня. :}

Говоря о данной автосборке, выполняются два build-сценария, — staging, собирающий _только_ пакетную базу дистрибутива в iso образ, оно же stage3, и build-сценарий os, собирающий непосредственно готовый к загрузке и установке iso-образ дистрибутива. Образы доступны по ссылке выше.

Скрипты сборки пока-что представлены как шаблоны, тут и тут:

https://github.com/sp00f1ng/booty/blob/master/templates/crux_gnulinux-staging...

https://github.com/sp00f1ng/booty/blob/master/templates/crux_gnulinux-os/crux...

Для сборки систем будут использованы все мои другие проекты: booty + newkernel + cruxstrap.

Я хочу предложить «тупой» метод оркестрации, который в отличии от Ansible не приводит работающую систему к заданному виду из плейбука, а по-мужицки так kexec'ает initrd-образ с собранным в нём дистрибутивом. Тобишь, вы локально пишете сценарий (или плейбук) сборки, включая все необходимые настройки, затем запуском одной команды дистрибутив собирается в raw, initrd, iso и так далее, после чего загружается аки прошивка на удалённый хост и kexec'ается, выполняется перезагрузка системы в новое состояние.

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

Ну дополнительно прикручу синхронизацию локального корня системы с её удалённой версией, т.е. чтобы ради пары файлов не перезагружать всё целиком, а например залить обновление сайта. Просто помещаете файлы в локальный каталог system/rootfs-changes, и корень директории будет синхронизирован с удалённой версией. Вот.

Идеи, предложения?

★★★★★

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

спасибо, а вы случайно не сталкивались с проблемой загрузки больших initrd образов на железе из bios/uefi?

по началу когда разрабатывал booty, тоже думал initrd хватит всем (ц), потом оказалось что не на всех компьютерах возможно загрузиться в большой initrd. столкнулся с проблемой на AM4 на плате gigabyte ab350m-ds3h v2, при этом с той же флешки тот-же образ прекрасно загружается на FM2 сокете и на LGA 1151-v2 (H110).

ну в итоге пришлось допиливать ещё создание ISO образов и загрузочных носителей, чтобы загрузчики умели находить vmlinuz/initrd, писать навороченный init чтобы тот тоже смог найти образы систем на насителе (флешке) и уже в них загрузиться.

а не просто загрузился в initrd и либо получил систему в стадии initramfs, либо сделал switch_root, увы, это не сработает. кстати стадия initramfs это отдельная сущность скажем так, и после того как ты загрузился в систему, сделать switch_root ещё раз мне уже не удалось. система просто зависла. возможно init pid=1 не даёт, не знаю. не суть.

ну когда ты делаешь kexec -e, то проблем таких нет, можешь хоть 5гб засунуть в initrd, я так думаю это скорее особенность биосов, что у них стоит ограничение на загрузку образов. при чём у всех всё по-разному. опытным путём выяснил, что это около 512мб на моём гнилобайте.

ну декларалататилаварнававая конфигурация это конечно здорово, только вот users.users.root.openssh.authorizedKeys.keys такие вещи надо знать. в то время как на баш портянке любая домохозяйка знает, что надо сделать cat ~/.ssh/*.pub > rootfs/root/.ssh/authorized_keys.

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

networking.interfaces.ens3.useDHCP

ens3

ооо сколько боли предвкушаю я. :D установи лишний девайс и получи сломанную «прошивку».

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

спасибо, а вы случайно не сталкивались с проблемой загрузки больших initrd образов на железе из bios/uefi?

Для больших образов такой способ мягко говоря не рационален - это сразу минус куча оперативки. Для переразбить диск и поставить систему или накатить уже готовый образ из сети прямо на диск - да, то что нужно. Для NixOS можно собрать образ для чего угодно: https://github.com/nix-community/nixos-generators

только вот users.users.root.openssh.authorizedKeys.keys такие вещи надо знать

По опциям есть поиск: https://nixos.org/nixos/options.html#users.users

Если чего-то не хватает - никто не мешает запилить свои.

больше, чем умеет сам shell, ты всё равно не реализуешь.

На nix можно использовать любой язык/инструмент из nixpkgs.

ооо сколько боли предвкушаю я. :D установи лишний девайс и получи сломанную «прошивку».

Этот кусок конкретно для того что у Oracle Cloud, без него всё тоже будет работать. Для kexec конфиг в секции Repartitioning target system from kexec image.

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

https://github.com/nix-community/nixos-generators

снимаю шляпу.

ладно.

тогда последний недостаток: это NixOS, а не любой другой дистрибутив, который продпочтёт пользователь. :D

Spoofing ★★★★★ ()
Последнее исправление: Spoofing (всего исправлений: 1)