| 1.8, Аноним (8), 09:27, 26/06/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
> предназначенного для создания микросервисов
Каких именно микросервисов?
| | |
| 1.10, rinat85 (ok), 11:43, 26/06/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Замечаю, как некоторые вопросы остаются не раскрытыми в описании 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 и т.д. не требуют прав записи)
| | |
| |
| 2.11, Аноним (-), 13:33, 26/06/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ты не задал главный вопрос. Сколько гигов обновлений потянет система в течение месяца? Он же атомарно-обновляемый.
| | |
| |
| 3.12, rinat85 (ok), 00:42, 27/06/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Ты не задал главный вопрос. Сколько гигов обновлений потянет система в течение
> месяца? Он же атомарно-обновляемый.
Да, действительно не раскрыл ещё одно ложное представление, которое тоже отпугивает даже от изучения :) Представьте себе обычную систему с корнем на btrfs, где home и var согласно настройке пользователя не подвергаются "снапшотингу". Перед процедурой он делает снимок ФС, после чего производит обновление. Предположим, прилетело 200МБ обновлений, который распаковались в 300МБ занятого пространства, итого оказалось занятым 500МБ (ведь те 300МБ ничего не заменили собой из блоков ФС предыдущих, они в том снапшоте остались, работа copy-on-write). И вот это в целом то же самое, как происходит и так пугающее вас "страшное" атомарное обновление системы в "immutable" OpenSUSE MicroOS :)
Если у вас Leap в качестве базы, то еженочные автообновления с окном в 2 часа для авторебута не притянут за собой особенно много обновлений, а если у вас база это Tumbleweed (в котором rolling release модель и постоянный поток новых версий пакетов), то можно настроить на автообновление в 3 часа ночи по субботам с окном ребута после обновления в 10 минут (я так настроил у себя).
tldr: при обновлении не скачивается каждый раз целиком новая версия ОС, сохраняя в полном объеме занимаемого места целый ряд таких же полных версий ОС предыдущих, у нас есть btrfs и его механизм снапшотов. Даже то, что по умолчанию под root раздел инсталлятор автоматически выделяет всего 20ГБ и это с запасом, уже подсказывает это
| | |
| |
| 4.15, Аноним (-), 13:52, 27/06/2024 [^] [^^] [^^^] [ответить]
| +/– |
Посмотрите daily stats ближайшей к вам Internet exchange point. Возможно, автообновления стоит сместить на отрезок между 4 и 7 часами.
| | |
|
|
|
|
