Разработчики проекта openSUSE представили релиз атомарно обновляемого дистрибутива openSUSE Leap Micro 6.0, предназначенного для создания микросервисов и для использования в качестве базовой системы для платформ виртуализации и контейнерной изоляции. Для загрузки доступны установочные сборки для архитектур x86_64 и ARM64 (Aarch64), а также готовые системные образы для систем виртуализации и raw-образы для копирования на носители...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61437
> предназначенного для создания микросервисовКаких именно микросервисов?
DNS-сервер, например.
Замечаю, как некоторые вопросы остаются не раскрытыми в описании MicroOS, из-за чего кто-то может даже не пробовать immutable систему. В частности это вопрос доустановки пакетов, настроек, сохранности "переменных" данных - баз данных, образов виртуальных машин, томов систем контейнеризации.Доустановка пакетов более чем возможна прямо в immutable os, тогда у вас будет некая своя версия, расходящаяся по составу с изначальной, авторы проекта планируют реализовать функционал, позволяющий отследить эту разницу, в целом конечно рекомендуется доустановить только самое необходимое, чего не оказалось в оригинале. Так же ПО и скрипты в /usr/local не затрагивает откат назад или обновление ОС.
Настройки в /etc тоже сохраняются благодаря применению оверлея, но там есть тонкость, что если внесли изменения, после них произошло обновление и последующая перезагрузка, то /etc будет по состоянию на момент последнего включения до того, т.е. последние изменения потеряться могут, или наоборот если было обновление и не перезагрузив внесли изменения в /etc
/home откат назад не затрагивает
/var вообще на отдельном разделе делает установщик, ставит на него nodatacow атрибут. Мне не нравится, что установщик забирает всё оставшееся место (под root раздел 20GB), поэтому вручную выделяю раздел под /var и ставлю атрибут nodatacow только на каталоги где будут (если будут) образы дисков KVM виртуалок, где будут тома контейнеров (если запущены под root, для podman они по умолчанию в home пользователя), для БД тоже так делать стоит, но на хосте в /var/lib их не храню
По сути термин immutable не совсем корректен и дает ложное представление, которое может отпугивать. Отличий в функциональности с не immutable версиями OpenSuse очень мало. Главные моменты с обновлением и с тем, что каталоги в root разделе почти все в режиме read only подключены (если подумать, то действительно, если не вопросы установки, обновления, удаления пакетов, /usr и т.д. не требуют прав записи)
Ты не задал главный вопрос. Сколько гигов обновлений потянет система в течение месяца? Он же атомарно-обновляемый.
> Ты не задал главный вопрос. Сколько гигов обновлений потянет система в течение
> месяца? Он же атомарно-обновляемый.Да, действительно не раскрыл ещё одно ложное представление, которое тоже отпугивает даже от изучения :) Представьте себе обычную систему с корнем на btrfs, где home и var согласно настройке пользователя не подвергаются "снапшотингу". Перед процедурой он делает снимок ФС, после чего производит обновление. Предположим, прилетело 200МБ обновлений, который распаковались в 300МБ занятого пространства, итого оказалось занятым 500МБ (ведь те 300МБ ничего не заменили собой из блоков ФС предыдущих, они в том снапшоте остались, работа copy-on-write). И вот это в целом то же самое, как происходит и так пугающее вас "страшное" атомарное обновление системы в "immutable" OpenSUSE MicroOS :)
Если у вас Leap в качестве базы, то еженочные автообновления с окном в 2 часа для авторебута не притянут за собой особенно много обновлений, а если у вас база это Tumbleweed (в котором rolling release модель и постоянный поток новых версий пакетов), то можно настроить на автообновление в 3 часа ночи по субботам с окном ребута после обновления в 10 минут (я так настроил у себя).
tldr: при обновлении не скачивается каждый раз целиком новая версия ОС, сохраняя в полном объеме занимаемого места целый ряд таких же полных версий ОС предыдущих, у нас есть btrfs и его механизм снапшотов. Даже то, что по умолчанию под root раздел инсталлятор автоматически выделяет всего 20ГБ и это с запасом, уже подсказывает это
Посмотрите daily stats ближайшей к вам Internet exchange point. Возможно, автообновления стоит сместить на отрезок между 4 и 7 часами.