Комментарии 51
А отличия от Антибла есть кроме как в синтаксисе?
Скорее, от паппета
Ансибл таки про применения набора действий на кластере, когда паппет точно так же описывает "желаемую" конфигурацию в декларативном стиле
Ну как бы Ансибл тоже в декларативном стиле. А уж на кластере или в отдельной машине - это как пожелаешь.
Чтобы писать на ансибле в декларативном стиле, надо еще постараться, учитывая все сайд-эффекты команд и возможности отката. Чаще всего в среднем ансибле-скрипте декларативностью и не пахнет.
Хмм. Возможности отката - это интересно. В Ансибле я с таким не сталкивался. А в Nix оно прямо есть и работает?
Заложено в Nix by-design, и стабильно работает, выбираешь или через команду nixos-rebuild switch --rollback, либо через бут-меню (grub или systemd-boot, на выбор).
home-manager давно не тыкал, кажется там похожая ситуация (home-manager - это nix-конфигуратор для индивиуально пользовательских настроек)
И да, я не проверял на всяких хитрых сервисах типа Nextcloud (на форумах nix писали, что это приложение очень stateful с точки зрения внутреннего устройства) и т.п., где на nix к сожалению можно написать лишь обертки для инициализации, но в целом в масштабах домашней/рабочей пользовательской системы, простого сервера, откат работает безотказно (надёжность самого компьютерного оборудования на моей работе иногда ниже чем у Nix)
При этом да, nix-collect-garbage -d от рута или через sudo удаляет все деривации (артефакты nix, содержащие приложения, библиотеки и так далее), которые не привязаны к текущему поколению и больше нигде не используются. Так что после этой команды rollback'нуться будет уже нельзя
У Ansible нет состояния. Простой пример, где декларативность хромает:
Создаётся конфигурация, описывающая файл конфига. Выполняется синхронизация.
Файл конфига удаляется из конфигурации. Выполняется синхронизация.
В итоге синхронизация выполнена. Файл на машине есть, а в конфигурации его нет.
Можно писать отдельный пункт в конфигурации про явное удаление файла, но это уже почти императивное указание.
Эта проблема решена в альтернативных инструментах, имеющих состояние (Salt, Terraform).
С ансиблом не знаком, но предположу что он полностью сконцентрирован на энтерпрайзе. Nix же вполне успешно можно использовать на домашней системе.
Успешно пользуюсь Ansible для управления своей личной инфраструктурой. К этому инструменту я пришёл сам по себе, просто потому что понял, что так жить, вручную бегая по 15 серверам по всему миру, нельзя. Люди явно придумали что-то для этого. И ведь не ошибся!
Так что это инструмент для всех, не только для корпоратов.
Пробовал я недавно посидеть на Nix. Сначала тебе даже нравится, но очень раздражает что Home-manager и Nix Flakes ощущаются весьма чужеродно тому что было изначально. А сам язык хоть и весьма прост, но позволяет одно и то же записать разными способами, отчего только больше путает.
В итоге я посмотрел на то что получилось и задался вопросом: а действительно ли это стоит такой возни? Так ли часто тебе требуется с нуля восстанавливать дистрибутив? Так ли сложно через sway синхронизировать свои dotfiles в домашней директории и добиться весьма похожего эффекта?
А если, например, речь идёт о компьютерном классе, где на всех машинах должна быть единая конфигурация, или если зачем-то нужно несколько идентичных экземпляров сервера? Не ручаюсь, но в данных примерах подход NixOS как будто бы выглядит достаточно убедительно.
А если, например, речь идёт о компьютерном классе, где на всех машинах должна быть единая конфигурация
Загрузка по сети из одного образа решает задачу не хуже в рамках привычных инструментов.
Загрузка по сети одного образа требует, внезапно, загрузки всего образа. (Либо, если мы говорим о diff-синхронизации, требуется такая же инфраструктура, как собственно и nix)
А теперь, внимание, сеть в компьютерном классе это не сеть дата-центра. И если необходимо обновить конфигурацию, а не строить ее с нуля, то nix это классный инструмент.
Второе, даже если мы используем diff-копирование, если мы при настройке образа что-то ненароком "испортили", то велкам необходимость делать полные бекапы оригинального образа
Вот поддержу, да. Ощущение такое, что эта вся огромная система написанная на этом языке постоянно в движении и никак не устаканится.
В итоге, каждый раз когда нужно сделать что-то не сильно сложное, типа локального шелла с выбранными питоновскими пакетами приходится копировать и править существующий конфиг, запомнить и воспроизвести по памяти так и не выходит.
Особенно это хорошо видно когда пытаешься отладить какую-нибудь проблему - очень так непросто, много слоев всякого.
Осенью 19-го, преследуя интерес к проекту wireguard, искал дистрибутив, который уже рискнул предоставить пользователям поддержку новинки в протоколах VPN. Так я наткнулся на VyOS. Я уже не помню, нашел ли я в нем wireguard, но хорошо помню как меня восхитила декларативность его конфигурации и предоставление в консоли всех параметров какой-нибудь опции по двойной табуляции как в bash-completion, только гораздо жирнее. Так как VyOS ориентирован к использованию в качестве шлюза, а мне уже хотелось такое чудо на десктопе, то был найден NixOS и в декабре того же года установлен.
С тех пор эта ОС у меня основная -- на двух ноутах, на домашнем компьютере родственницы и на двух десятках личных серверов и виртуалок. Возможности атомарных изменений системы и откатов по необходимости позволяют решать любые проблемы на ПК родственницы, находясь за 1000 км от него.
Соглашусь, что порог входа достаточно высокий. Смог бы осилить эту ОС без бэкграунда в 10 лет знакомства с GNU/Linux? -- Я не знаю. Но NixOS использую находясь на уровне новичка в nix -- мне этого хватает для правки конфигураций, выискивая примеры в сети.
К слову, NixOS научил меня воспринимать ОС как набор конфигов, а не черную коробку, на которую ничего лишнего не поставить -- ибо мусор и страшно за стабильность.
В NixOS есть аналог USE-флагов Gentoo?
В NixOS можно сделать вроде USE="-telemetry -gnome -akonadi -rust -vala" emerge -uDNva @world ?
Если что, я спрашиваю не из праздного любопытства, если в никсоси можно пересобрать мир и выпилить определённую функциональность из всех пакетов, то я бы попробовал. В генте, к сожалению, этот USE=-rust не приводит к полному удалению раста из системы :(
Глобально нет. Но можно сделать поддержку флагов у каждого пакета / модуля.
Да, есть, но пользуются ими прям не очень активно и это не глобальные флаги, а над каждым пакетом (деривацией) отдельно. Ключевые слова тут override и overrideFlags над деривацией.
Кроме того, при желании технически можно скопировать определение пакета из search.nixos.org -> Source и затем изменить процедуру сборки через модификацию buildPhase
Полная воспроизводимость окружений,
Чем это лучше образа VM или докер?
Никто в здравом уме не будет устанавливать каждый пакет в отдельной VM или контейнере, в nix любой пакет воспроизводим и изолирован, даже какой-нибудь neofetch.
Никто в здравом уме не будет устанавливать каждый пакет в отдельной VM или контейнере
Ага, AppImage вам незнакомо? И докер, который именно что устанавливает каждый пакет в своем контейнере и который занял огромный кусок рынка, несмотря на оверхед.
*Виндовые вайбы*
В nix изоляция пакетов достигается не через копирование, а по сути через указание кто что видит. Это может быть копирование, но это может быть hard-linking.
Поэтому если разработчик хочет установить/запустить две версии библиотеки/программы, это сработает, и не потребует переупаковки всего и вся, эта "переупаковка" уже зашита в nix и она не кушает все доступное место
Повторить ещё раз?
Докер используется для своей задачи - для деплоя конкретных сервисов.
Отдельные пакеты ты не будешь устанавливать в отдельных контейнерах.
А AppImage никто не пользуется.
Повторить ещё раз?
Докер используется для своей задачи - для деплоя конкретных сервисов.
Отдельные пакеты ты не будешь устанавливать в отдельных контейнерах, в этом нет смысла и никто так не делает.
А AppImage никто не пользуется
Я фанат nix. Рекомендовал бы просто nix flakes использовать на любом дистрибутиве, необязательно nixos. И это гораздо лучше докера, так как это ЯП с большим количеством библиотек и фреймворков. А ещё в никсе легко билдить докер образы, гораздо удобнее чем в Dokerfile. Для новичков документация не очень хорошая. Я бы рекомендовал просто понять основную концепцию, типо что делает функция derivation, структуру flake файла, и что все объекты типа pkgs.python просто указатель на путь в nix/store с папкой bin/python.
NixOS очень сильно порадовал меня своей концепцией. Но она распространяется на GUI. А как быть, например, в серверной "minimal" комплектации? Например, при разворачивании у хостера?
Я подобных материалов не нашёл. Впрочем, я даже не знаю, как такой запрос вообще сформулировать...
А как быть, например, в серверной "minimal" комплектации? Например, при разворачивании у хостера?
Непонятно в чем суть вопроса. Все отлично работает при развертывании на хостингах. Есть только нюансы в развертывании -- если хостер не предоставляет ISO NixOS или отсутствует вариант подключения своего ISO, то приходится ухищряться с установкой на стороне и дальнейшим копированием блочного устройства на хостинг.
Здесь подробный гайд по установке NixOS на любом хостинге:
https://www.youtube.com/watch?v=4sypfTBuEbA
Репозиторий из видео:
https://github.com/nix-community/nixos-anywhere
Я рекомендую просто закачать в клауд провайдеры ванильный образ nixos, если его там нет. А дальше можно декларативно определять все у себя в репозитории . Например: nixos-rebuild test --flake github..myrepo#host1 --target-host root@ip_address. В этой команде, мы говорим обновить хост с никсос в соответствии с конфигурацией, описанной в нашем репозитории (flake.nix), и сервер обновится не выключаясь по ssh, типа как в терраформ.Никс - это хороший клей между другими девопс штуками
Судя по описанию - снова Поттеринг (дай бог ему здоровья).
Но - внезапно - не он.
Но это скорее инструмент для развертывания окружения с нуля, не для обновления решения на продакшене, где декларативный стиль не спасает, увы. И тогда особой разницы с ансиблом или паппетом не заметно (ну, может код не такой кривой получается, но это уже надо вглубь погружаться).
Но нормальных инструментов для развертывания сложного продакшена без останова, увы, вообще нет на рынке. Все пытаются изображать декларативный стиль, хотя обычно важнее как раз сделать удобным императивный (
есть и давно, называется Erlang - hot code reload гарантирован без останова и отключения текущих клиентов
Релоад кусочков кода в рамках одного сервиса - это достаточно просто и есть много где. И, в общем-то, нафиг не нужно.
Но это очень небольшая часть логики обновления сложного продукта.
что значит "кусочков"? посмотрите внимательно на Erlang/Elixir, там полностью все модули всего проекта (сервиса) могут быть обновлены без разрыва соединения текущих клиентов и без остановки работы и полностью прозрачно для пользователя. Если упрощенно то все текущие подключения остаются на старом коде (по-умолчанию, если специально не запрограммированна альтернативная логика), а новые включаются на обновленную версию... это касается и всяких серверов с web-socket'ами и интеркоммуникации процессов, и сессий и т.д.
Где-то была очень крутая и подробная презентация в YT, но её сейчас не найду - поэтому дам такой линк 'Elixir Distributed Node Clustering with Raft Consensus in ExVenture' (https://www.youtube.com/watch?v=rxFlKhWzthw). А вообще можно нагуглить на тему 'hot code reload' и 'libcluster' и т.д.
Конечно универсальных 'пуль' не бывает, но у Erlang/Elixir ,как мне кажется, максимально были налажены процессы безшовного обновления кода даже в кластерах, причем из коробки и начиная с самых ранних версий ( это было обязательное требование дизайна системы с начала разработки языка).
Я все это знаю. Но это действительно не очень значимый плюс для выкладки больших систем, где нужно разбираться еще с миграцией баз данных, с нетривиальными миграциями на взаимодействий сервисов (для http это сделать легко, а вот для кафки - сложно), о чем, собственно и идет обсуждение в этой статье.
Для выкладки мало "выложить новый код", нужно еще разобраться с его независимым тестированием, канарейкой, контролем потребления ресурсов и так далее. Да, все эти задачи, конечно, можно решить и на эрланге/элексире. Но, увы, плюс "перезагрузка модулей" не перекрывает минусов экосистемы Erlang (неторопливое исполнение, редкие и дорогие разработчики, относительно бедная экосистема).
Бросьте в меня тапком те, кто не сталкивался с ситуацией из разряда «А локально оно нормально работает
Вы сами попросили. Выбирайте какой тапочек: левый или правый=)
Выбирайте какой тапочек
Я тоже подумал, что люди с минимальным или отсутствующим опытом займутся тапко-закидательством.
Или люди, которые понимают, что NixOS - плохо документированный и крайне специфичный предмет, который в 99% не серебряная пуля, а лишняя боль с поддержкой.
Ну или хотя бы просто те, кто понимает, что стейдж должен быть не просто примерно похож на прод. Он должен быть буквально копией нужного участка прода. Иначе ваш стейдж - просто массогабаритный макет.
Хотел было перейти, но не понравилось, что он все конфиги разных приложений конвертирует в свой формат. Иногда получается очень коряво. Например у emacs файл конфигурации - это программа на лиспе, в которой кроме установки различных переменных могут встречаться еще и фрагменты кода.
Если встречается какой-то нестандартный конфиг, то начинается квест "как сконвертировать это в nix". Думаю, было бы достаточно запоминать патчи (diff) конфигов, но нет, придумали свой формат (который, кстати, тоже программа на языке nix).
PS: Глубоко не копал, поправьте если не прав.
Не обязательно. Большинство программ настраиваются через nix-опции, но если есть программа со сложным конфигом(vim, emacs), его можно писать стандартно отдельным файлом и привязать к билдам nix.
Из плюсов - не нужно думать о внешних менеджерах пакетов, любые плагины nix сам установит.
Из минусов - после редактирования конфигурации придется делать ребилд nix системы или home-manager, это просто занимает секунд 30.
Неоднозначная мысль: NixOS это одновременно лучшая и худшая система для новичка.
Худшая - потому что всё очень сложно, нужно обладать бэкграундом разработчика, хреновая документация, многие просто плюнут и забьют.
Лучшая - потому что всё имеет смысл, всё настраивается в одном месте, отсутствие ада зависимостей by design, с Nix практически невозможно сломать систему, сделал что-то не так - откатился, варианта окирпичить систему просто нет, есть уверенность использовать это как рабочее место, без страха что вот завтра после обновления всё умрет.
Возможно, Linux изначально должен был работать по принципу, похожим на Nix.
Ещё не пробовал nix, но на ум приходят примеры из жизни, с которыми не просто было бы описать, чего надо.
А пакеты окружения тоже через nix описывать? Вот поставил VDS с CentOS 9, зашёл и сделал yum upgrade. И каких-то 302 пакета обновились, включая ядро, сертификаты и таймзоны. А в nix для воспроизводимости это все надо перепечатывать в кастомный код? Там же ещё зависимости. И делая yum upgrade/yum update в разное время на разных серверах мы получим немного разный набор пакетов и их версий.
Ещё пример - есть CentOS 6.6, репозитории которого уехали в vault. А надо обновить пакет. Nix сам разрулит эти танцы с repo и прочим?
Вот поставил nginx (из repo nginx), но оказалось, что geoip модуль не доступен по умолчанию. Всё, садимся за исходники tar.gz, ./configure с кучей опций, make install и отсутствие поддержки обновления до следующей версии с простотой пакетного менеджера.
Воспроизводимость достигается тем, что прописывается конкретная версия пакетной базы прямо в тексте конфигурации (URL с коммитом) или рядом (flake.lock при использовании nix flakes). Где бы и когда бы Nix ни обрабатывал конфигурацию, он возьмет одни и те же версии. Обновление делается через обновление прописанной версии (вручную или через nix flake update) и пересборку конфигурации.
Nix сам является пакетным менеджером, у него своя пакетная база, так что говорим либо о замене CentOS на NixOS, либо об использовании Nix в CentOS параллельно со штатным управлением пакетами. В последнем случае все, установленное через Nix, будет жить в
/nixи не конфликтовать с системным. UPD: Правда, теряем генерацию конфигов сервисов из коробки, которая есть в NixOS; и с системным менеджером их придется дружить вручную. Однако для не-сервисов работет отлично.В Nix кастомная сборка будет частью конфигурации. Причем зачастую это будет не скрипт с нуля, а описание отличий от стандартной сборки (override), типа "возьми обычный Nginx, но исходники оттуда, флаги configure добавь такие".
Кажется, что nix это отличная идея, сделанная с огромным геморроем. Плюсы есть, но вот стоит ли оно того — ой как зависит от ситуации. Похоже на переход с блокнота на vim — на vs code перейти просто, и плюшки понятны, а вот переход на vim потенциально может и обладает крутыми плюсами, но в процессе ты такого наешься, что не факт что оно в твоей ситуации того стоило.
Кроме того, три года назад, когда я пытался одну систему перенести на nix, воспроизводитмостью там и не пахло, на тесте все работало ок, на проде браузер крашился, хотя казалось бы, идентичность, воспроизводимость, вот это все. Может щас, с flake, получше стало.
Мы недавно перешли на https://www.jetify.com/devbox + https://direnv.net для быстрого создания окружения локально и на CI. Там под капотом тоже Nix, но напрямую с ним не приходится взаимодействовать. Вот и получается тот самый вариант для новичков.
Пока что проблем особых не наблюдается. Полет нормальный. А вот удобство возросло многократно. Перешел в другую директорию и сразу получил рабочую среду под конкретный проект.
Но мы то простые сайтоделы. Нам много не надо)
После установки NixOS на ПК, пропал страх что-нибудь сломать, появилось желание экспериментировать. В любое время всегда можно вернуть состояние когда "все работало".
Почему Nix и NixOS становятся популярнее? Золото в мире конфигурационного менеджмента