Что еще мне осваивать в nix?

chef/ansible/puppet/cfengine, которые с этой задачей справляются

4.2

4.2

4.2 :)

Кто из них стал декларативен и больше не требует репровизии, чтобы привести систему к описанному состоянию и без хлама?

А то последний раз, как я проверял, все они были неудобным декларативным синтаксисом над императивной как баш-портянка системой.

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

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

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

нинужна

Это моё удивленное лицо.

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

Нет там и распаковки всего в /, и оттого половины той императивщины, что и в других дистрах, а то и больше.

Плюс к этому никакие декларативные инструменты не решают проблем данных.

И мира во всем мире. Что ж теперь, каку всякую юзать псевдодекларативную?

Нет там распаковки всего в /

Я не понимаю, о чём ты.

Что ж теперь, каку всякую юзать псевдодекларативную?

Юзать наиболее простой и удобный инструмент для конкретной задачи.

Я не понимаю, о чём ты.

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

Юзать наиболее простой и удобный инструмент для конкретной задачи.

Bash-портянку, значит, раз декларативщину не хочешь =)

разрешающих проблемы типа обработки даунгрейда libc

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

Так что малую часть императивщины NixOS прячет на уровень ниже

Когда ты в декларативном конфиге указываешь, что у тебя должен стоять мускуль конкретной версии, система выполняет команду установки мускля средствами nix. Когда я в ansible указываю то же самое, система выполняет команду установки мускля средствами того дистрибутива, который имеется на конечном хосте. Вот и вся разница.

Bash-портянку, значит, раз декларативщину не хочешь

Когда в декларативном конфиге я указываю, что в зависимостях у сервиса такой-то список пакетов, система делает условный

if deps:
  for dep in deps:
    install dep

Я не за парадигмой гонюсь, а за надёжным и действенным способом управления.

система выполняет команду установки мускля средствами nix

Нет. Почитай про Nix, там нет этой вашей «установки».

ИИ вытеснит ленивых, кожаных мешков отовсюду быстро и беспощадно.

Когда Кармак на горе свистнет. Этот хайп-трейн ездит по кругу с 50х. Меняют машинистов, колесные пары, ширину колеи и т.д. «многочисленные параметры», не опускаясь до того, чтоб хотя бы дать непротиворечивое и нерекурсивное определение «что такое интеллект». Так и будет ездить, пока не начнут с определения предмета деятельности. Все остальное — коммерческий буллшыт.

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

новый слой

не позорься, почитай. не нужны никакие слои.

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

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

Чтобы изменить состояние системы, надо дать ей команду

В этом и суть. В nix состояние системы не меняется. Там каждый пакет, это система в себе, со своим набором зависимостей. Они изолированы друг от друга.

Вот есть система. Там стоит mariadb 10.5. Мне надо получить там maria 10.6. Я указываю это в конфиге.

Ansible: команда уходит на систему, там средствами пакетного менеджера запускается установка новой версии, пост-инсталл останавлиает старую базу, запускает новую, перезапускает все приложения, которые зависят от базы и которым требуется реконнект.

Nix: команда уходит на систему, читается новый конфиг, запускается build нового generation, потом switch на него, останавливается старая база, запускается новая, читается раздел конфига, указывающий на зависимые сервисы и они рестартятся.

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

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

В системе была одна версия пакета, стала другая версия пакета

Неа. Там ставятся обе версии пакетов и с ними можно хоть одновременно работать. Они не взаимозаменяются. Эти пакеты изолированы друг от друга.

система стала другой

Не стала, в этом и фича, что система не меняется. Там пакет каждый ставится отдельно со всеми своими зависимостями и систему не затрагивает. Это и называется изоляцией собственно. Эти зависимости и место занимают и линкуются каждые со своим пакетом. Например у вас стоит одна версия пакета, он занимает x места и y оперативной памяти. Допустим у вас стоят 2 версии пакета и вы работаете с ними одновременно. У вас будет занято примерно 2*x места и 2*y памяти. И так далее.

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

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

А когда я ставлю какую-то версию пакета, система с точки зрения админа меняется. Вот раньше дефолт ссылался на program-X, стал ссылаться на program-Y. Что при этом стало с program-X, остался он в системе или лежит под другим симлинком, зависит он от чего-то или нет, что там с его библиотеками стало, или они аккуратно сложены в дебрях директорий с нечитаемыми названиями, мне совершенно не важно. Моя задача - получить систему с program-Y и она достигнута.

Уже десятки раз, наверное, писал на этом форуме и повторю ещё раз. NixOS - прекрасная задумка. Сферически в вакууме идеальная система. Но слишком сложная в конфигурации, когда дело доходит до практических админских задач. Я ни разу не жалею, что потратил полгода на её изучение, но увы я не готов внедрять её на боевых серверах.

Не надо мне пересказывать хендбук nixos

Не могу тебе пересказать, то что никогда в глаза не видел, просто использовал немного на практике.

Фишка в том, что при управлении конфигурацией серверов, мне почти никогда нет надобности в десяти версиях одних и тех же пакетов на одной машине

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

А когда я ставлю какую-то версию пакета, система с точки зрения админа меняется

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

Я очень рад что ты почти никогда с таким не сталкивался, это тот ещё гемморой.

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

Нет. Там нет дефолта.

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

Вот эти все нюансы реализации с точки зрения админа совершенно не важны

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

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

это всё не касается системы управления конфигурацией и конкретно обсуждаемого вопроса

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

О боже. Если я вижу, что после раскатки и/или обновления системы, увеличивается место, разумеется, я буду это учитывать. Разумеется, я буду чистить кеши пакетов или там запускать garabage-collector для nix. А что нужно сделать, чтобы динамическая линковка хоть как-то ощутимо увеличила потребление памяти, я в принципе не представляю. Ты сейчас про какие-то одноплатники с памятью, измеряемой байтами? Если мне придётся работать с такими системами, я задумаюсь об этом.

О да, а теперь загрузи быстренько 10.5 как было, ничего не трогая на диске. Даже на самом схожем примере че-то все пошло не так.

команда уходит на систему, читается новый конфиг, запускается build нового generation

Можно и так, если очень хочется, но обычно обирается новый generation, потом пушится на систему, потом «уходит команда» его активировать.

читается раздел конфига, указывающий на зависимые сервисы

Нет, ты Nix явно только на картинке видел с другого берега реки. Сервис, зависящий от нового MySQL — другой сервис, и перезапуск произойдёт поэтому. На этом уровне конфига больше нет, на целевой системе его и не было никогда, и ничего в рантайме его читать не лезет.

Как ты это дело не называй, с точки зрения админа происходит там одно и то же.

Велосипед едет, автомобиль едет, но надо быть совершенно пьяным, чтобы не заметить разницы.

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

С другого берега реки, да.

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

Не один и тот же, от слова совсем. Загрузи мне свою любимую систему в новый мажорный релиз, затем в старый, затем опять в новый, потом пошлангуй, почему в NixOS это 3xbootime, а в distroofchoice это заняло полчаса в одну сторону, а потом вообще сломалось. Ах да, «установка», любимое занятие тех, кому лишь бы кофе попить, пока репровизия.

В системе

Ну вот не верю я, что ты полгода потратил на изучение NixOS и все ещё оперируешь понятием «в системе».

О да, а теперь загрузи быстренько 10.5 как было, ничего не трогая на диске.

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

потом «уходит команда» его активировать.

А потом выполняются все те команды по установке, рестарте и прочему.

Сервис, зависящий от нового MySQL — другой сервис, и перезапуск произойдёт поэтому.

Сервис не зависит от нового MySQL. Он зависит от MySQL в принципе. Может находиться не на этой же машине.

Загрузи мне свою любимую систему в новый мажорный релиз, затем в старый, затем опять в новый

Зачем? Не, это конечно, круто, что так можно, но зачем? Ты только и делаешь, что сутками на боевых серверах туда-сюда грузишься,

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

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

Ты только и делаешь, что сутками на боевых серверах туда-сюда грузиться?

Да-да. Откатывать ненужно, бисектить регрессии между двумя мажорными релизами на тестовой машине ненужно, запускать только одну приложуху с патченной либо ненужно, что ещё ненужно? Репровизии ненужно, чистое состояние ненужно, декларативность ненужно. Вырисовывается закономерность — все, чего дистрв из прошлого века не могут из-за родовой травмы, все ненужно.

А потом выполняются все те команды по установке, рестарте и прочему.

На картинке. В моей NixOS нет команд по установке и нет команд по рестарт. системд видит новый юнит обратной зависимости в /etc и перезапускает по факту его замены ее вместе с мускулем. В твоей, внезапно, есть. Где ты взял свою NixOS? Где там эти команды?

Сервис не зависит от нового MySQL. Он зависит от MySQL в принципе.

С другого берега реки.

Ты системный администратор 20 века. Ты оперируешь инстансами, системами и во всем видишь текущее состояние и шаги по переводу в новое состояние. Пишешь, вместо описания результата, императивные хэндбуки, мнишь их «конфигурация и», в них вручную прописываешь действия по подтиранию части хвостов от прошлых деплоев и рассказываешь, что репровизии не нужны. У тебя, походу, нет стейджа, задач разработки, потребности в гибкости, дальнейшего желания перебороть синдром утенка — ничего этого нет, только суровый прод да твёрдое знание, в какое место бить кайлом, чтобы переводить его из состояния А в состояние Б. Ну и жгучее желание делать эти глубоко императивные действия через слой псевдожекларативной абстракции, а также здоровое подозрение, что это какая-то фигня и можно правильно. Знать бы еще, что ты там такое крутил вместо NixOS, что там были «установка» «в систему» и команды по перезапуску сервисов, но это уже не так интересно. Живи в своём мире, даже в нем ты все ещё впереди большинства, может даже на десятилетия.

на тестовой машине

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

Репровизии ненужно

Я уже писал, для этого есть другие инструменты.

чистое состояние ненужно

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

декларативность ненужно

Конфиги системы управлением конфигурацией вполне себе декларативны, насколько это возможно. Не менее, чем конфиги nix.

Вырисовывается закономерность

На практике существуют инструменты, которые проще в обращении и настройке, чем NixOS для многих задач.

В моей NixOS нет команд по установке и нет команд по рестарт.

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

nix-channel --update
nix-env --upgrade
systemctl daemon-reload
systemctl restart nix-daemon # А вот тут nix-daemon тоже ничего не делает. Ни одной команды не выполняет.

nixos-rebuild switch # что является по сути несколькими командами.

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

На тебе набор ссылок, с подробным планом прохождения, выбери >направление и учи что не знаешь:

roadmap.sh

Спасибо огромное! Очень полезно оказалось! Хоть на стену вешай!

nix-channel --update
nix-env --upgrade
systemctl daemon-reload
systemctl restart nix-daemon # А вот тут nix-daemon тоже ничего не делает. Ни одной команды не выполняет.

Ты нагуглил пример не от NixOS, я при обновлении ничего из этого не запускаю, и другим не надо. Ты ещё вызовы vi и git приплети, тоже команды.

Но это же не команды, да. Это другое.

Ты начинаешь понимать.

Команды, меняющие состояние системы, только внутри activation в самом конце nixos-rebuild switch. Они же исполняются при загрузке, невероятно императивно. Шах и мат, и в NixOS тоже выполняются команды, я посрамлен (на самом деле нет).

Не позорься, почитай как NixOS работает.

Ты нагуглил пример не от NixOS

Я не гуглил. Я взял примеры из памяти по работе с nix.

Команды, меняющие состояние системы

Если система стала вести себя по-другому, значит её состояние изменилось. Можно сколько угодно говорить о том, что состояние осталось тем же, появилось новое состояние, на которое ты переключился, сути это не меняет. С точки зрения админа, состояние стало другим. Система стала вести себя иначе(выполнять новые версии утилит). И сделано это было с помощью выполнения определённых команд. Будь то консольные команды или же «запускаемое при старте/демоном/ещё как-нибудь». Выполняется вполне конкретный код с вполне конкретными if'ами и вполне конкретными циклами.

Давай сойдёмся на следующем.

В случае с Nix запуск активации выполнением команд приводит систему в другое состояние, соответствующее новому конфигу. Есть там «установка», что такое «в системе» — оставим за бортом.

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

а также всей прошлой истории всех прошлых активацией всех прошлых плейбуков

Этот пункт зависит от конкретных таск. Не всегда такое утверждение справедливо.

Но в целом соглашусь.

А что нужно сделать, чтобы динамическая линковка хоть как-то ощутимо увеличила потребление памяти, я в принципе не представляю

Достаточно использовать несколько пакетов с одной библиотекой в зависимостях. Каждый пакет из этих будет грузить эту библиотеку отдельно для себя. Для каждого пакета будет загружаться в память свой набор зависимостей. Каждый же пакет слинкован со своим набором зависимостей. Для одного или двух это не страшно, но когда у вас их 100, 200, 500 или больше это нарастает как снежный ком.

• Ты говоришь о запущенных одновременно сервисах? Я не представляю, сколько должно быть запущенно одновременных процессов, чтобы это стало заметно.
• Обычно сервера делятся по типу. На одной группе серверов запущен один сервис, на другой второй, и так далее. Добавим к этому процессы мониторинга, разнообразную управлялку и подобное. Так или иначе получает относительно небольшое количество процессов, одновременно запущенных в системе.
• Специально для примера возьму «неправильный сервер»(один из моих личных, где на одной машине целая пачка всякого разного относительно нагруженного).

  └─> dpkg -l | grep -E '^ii' | wc -l
  1287
  └─> netstat -untpl | grep -E '(tcp|udp)' | wc -l
  64
  └─> ps waux | wc -l
  165
  └─> free -h
                 total        used        free      shared  buff/cache   available
  Mem:           1,9Gi       1,3Gi        68Mi        77Mi       537Mi       383Mi
  Swap:          2,0Gi       5,0Mi       1,9Gi
  └─> uptime
   09:48:36 up 65 days, 19:49,  7 users,  load average: 3,09, 2,16, 2,14
  

  Это почти дефолтный Debian. Динамическая линковка. Я не вижу сверхкритичного перерасхода памяти. С учётом количества запущенных процессов - вполне нормальная нагрузка.

Ты говоришь о запущенных одновременно сервисах?

О любом софте. Например весь софт на си и софт на с++ использует glibc. Для каждой библиотеки или программы где glibc в качестве зависимости, линкуется с отдельным экземплятором glibc. Что означает что для каждого используемого пакета загружается glibc в память. У тебя может быть мало сервисов, но много библиотек, которые грузятся в память.

Это почти дефолтный Debian. Динамическая линковка

Это показывает что ты не понимаешь о чем говоришь. Динамическая линковка в Debian не тащит с собой весь набор зависимостей для каждого пакета, а использует общий.

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

Ну так я о том же и говорю. Никакого оверхеда нет.

Потому что в Debian это по другому сделано. В Nix это больше похоже на то как в винде, когда каждая программа тащит с собой весь набор зависимостей.

Что за страшилки ты заставляешь нас выслушивать?

Если все они юзают одну и ту же версию библиотеки, то как раз будет экономия памяти.

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

Если все они юзают одну и ту же версию библиотеки, то как раз будет экономия памяти.

Это работает не так в nix. Даже если у них одна версия библиотеки, то линковка происходит с отдельным экзеплятором библиотеки. Предположим у тебя есть 500 программ, у которых в зависимостях одна версия библиотеки. Эта библиотека будет скачана 500 раз, то есть для каждого пакета отдельно. И линковка будет происходить отдельно для каждого пакета. И в память будет грузится отдельный экземплятор библиотеки для каждого из этих 500 пакетов.

Врать запрещено правилами форума.

В Nix обычная динамическая линковка, ты описываешь статическую.

Открой хэндбук и прочитай. Неломаемость обеспечивается именно такой избыточностью. Не про статическую. А именно про динамическую, в этом и ужас.

https://nixos.org/guides/how-nix-works.html

Я-то как факт знаю, что у меня есть NixOS-системы с одним экземпляром libc на тысячу её обратных зависимостей, а вот ты покажи мне, где ты берёшь такие хендбуки, где в них определение «неломаемости», где в «хендбуке» написан такой бред про обязательную дупликацию зависимостей и как у меня тогда ОС в 2ГБ влезает.

https://nixos.org/guides/how-nix-works.html

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

Ищи ещё, я подожду.