Бросьте в меня тапком те, кто не сталкивался с ситуацией из разряда «А локально оно нормально работает» или «На проде ошибка, но на стейдже такого не было». Эти фразы стали мемами, но от этого не перестали быть болью для разработчиков и админов. И вот здесь на сцену выходит Nix — инструмент, который обещает революционизировать конфигурационный менеджмент. Полная воспроизводимость окружений, устранение дрейфа конфигураций и предсказуемость на всех этапах — звучит хорошо, не так ли? Давайте разберемся, почему Nix и NixOS набирают популярность в DevOps.
Парадокс: простота через сложность
В мире конфигурационного менеджмента Nix и NixOS воплощают принцип «простота через сложность», который лежит в основе их растущей популярности. На первый взгляд, эти инструменты могут показаться сложными, но в долгосрочной перспективе они значительно упрощают жизнь разработчиков и системных администраторов.
Философия Nix
Nix основан на принципах функционального программирования и декларативного подхода к управлению конфигурациями. Вместо последовательности команд для установки и настройки ПО, вы описываете желаемое состояние системы в виде конфигурационных файлов. Удобно? Вроде удобно.
Каждая конфигурация системы может быть точно воспроизведена на любом другом компьютере с NixOS. Обновления системы происходят атомарно, что исключает возможность оставить систему в несогласованном состоянии. Наконец, можно легко вернуться к предыдущей конфигурации системы в случае проблем.
NixOS предлагает еще и многоуровневую систему абстракции, чтобы работать на том уровне сложности, который более удобен. Новички могут использовать высокоуровневые абстракции для базовой настройки системы, а продвинутые пользователи — углубиться в более низкие уровни для тонкой настройки. Можно даже устроить небольшую админскую диктатуру и полностью контролировать систему, модифицируя низкоуровневые компоненты.
Я тут вижу плюс для новичков в том, что можно начать с базовых конфигураций, а по мере накопления опыта и уверенности усложнять задачи. Конечно, если в этом усложнении есть смысл.
Актуальность
Результаты ежегодного опроса сообщества Nix показывают, что больше половины юзеров используют его не более двух лет. А 39% — так и вовсе менее года. Кажется, плюсы для новичков, которые я назвал выше, вполне себе имеют место.
Источник.
Другой примечательный факт — 90% пользователей Nix также используют NixOS. Это указывает на тесную связь между инструментом управления пакетами и операционной системой, построенной на его принципах. Что касается опыта программирования, данные показывают небольшой перевес в сторону опытных разработчиков: более 51% респондентов программируют более 10 лет и только 3,2% вообще никогда не программировали. Делаю вывод, что Nix хоть и может быть дружелюбен к новичкам (но это не всегда так, ниже разберемся подробнее), все же привлекает больше специалистов со значительным опытом.
Источник.
Кстати, NixOS — штука точно не для всех, но если вы разработчик или настраиваете серверы, то эта ОС может стать вашим лучшим другом. Например, установка Emacs через Nix на Ubuntu позволяет пользователям легко выбирать конкретные версии и зависимости без риска конфликтов. С помощью команды nix-shell можно создать изолированную среду для каждого проекта, что особенно удобно, когда разные проекты требуют разные версии библиотек.
Мини-иллюстрация: сценарий миграции базы данных
Рассмотрим пример миграции базы данных с использованием традиционного подхода и Nix.
Традиционный подход выглядит так:
- установка инструмента миграции (например, Flyway),
- написание SQL-скриптов миграции,
- настройка окружения (переменные среды, конфигурационные файлы),
- выполнение миграции,
- обновление документации о текущем состоянии схемы.
Подход с использованием Nix:
{ config, pkgs, ... }:
{
services.postgresql = {
enable = true;
package = pkgs.postgresql_14;
ensureDatabases = [ "myapp" ];
ensureUsers = [
{ name = "myapp";
ensurePermissions = {
"DATABASE myapp" = "ALL PRIVILEGES";
};
}
];
};
systemd.services.db-migration = {
description = "Database migration for MyApp";
after = [ "postgresql.service" ];
wantedBy = [ "multi-user.target" ];
environment = {
PGUSER = "myapp";
PGDATABASE = "myapp";
};
script = ''
${pkgs.flyway}/bin/flyway migrate
'';
};
}
Этот пример показывает, как можно собрать все аспекты развертывания PostgreSQL, включая создание базы данных, пользователя и миграции через Flyway, в едином, лаконичном файле. Никакой возни с настройками вручную или случайными «оно работало у меня на локалке». Одна команда — и вся система настроена. Удобно? Еще как.
Но в этом и есть парадокс Nix: да, порог входа выше, и первые шаги потребуют времени. Однако награда — это упрощение рутины, стабильность и уверенность в том, что все корректно развернется.
Как работает магия Nix
Nix основан на принципах неизменяемости и декларативности. Давайте углубимся в основные концепции.
Центральный элемент архитектуры Nix — Nix Store. Это специальная директория, обычно расположенная в /nix/store. Она играет роль своеобразной базы данных графов, где каждый элемент представляет собой пакет или артефакт сборки.
После записи в Nix Store содержимое элемента никогда не изменяется. Каждый элемент имеет уникальный идентификатор, основанный на хеше его входных данных. А новые версии пакетов устанавливаются рядом со старыми, что обеспечивает атомарность обновлений и возможность мгновенного отката.
Воспроизводимость в контексте Nix означает, что из одних и тех же входных данных всегда получается одинаковый результат. Это достигается изоляцией сборки, детерминированными ссылками или контролем окружения. В первом случае Nix собирает пакеты в изолированной среде, исключая влияние недекларированных зависимостей. Во втором — все зависимости явно указываются в описании пакета. В третьем — Nix контролирует переменные окружения и другие факторы, которые могут повлиять на сборку.
Однако не все пакеты в Nixpkgs являются битово-идентичными при повторной сборке из-за источников недетерминизма. Ими могут оказаться порядок элементов в структурах данных или порядок чтения файлов с диска. Кажется, что это незначительная деталь. Но поверьте, как только дело дойдет до сложных CI/CD-пайплайнов или (тьфу-тьфу-тьфу) воспроизведении окружений для аудита, такие мелочи вызовут ту еще головную боль.
Мини-туториал: создание простого окружения
Для начала вот туториал по установке и настройке Nix. А теперь создадим простое окружение разработки.
Первым дело нужно создать файл default.nix со следующим содержимым:
with import <nixpkgs> {};
mkShell {
buildInputs = [
python3
nodejs
git
];
shellHook = ''
echo "Добро пожаловать в окружение разработки!"
echo "Доступные инструменты: Python, Node.js, Git"
'';
}
Запустите окружение командой:
bash
nix-shell
Теперь у вас есть изолированное окружение разработки, в котором Python, Node.js и Git готовы к работе.
Реальные кейсы использования Nix
Рассмотрим три примера компаний, которые успешно внедрили Nix в процессы разработки и инфраструктуру.
Tweag
Это консалтинговая компания в области разработки ПО. Она использует Nix для управления зависимостями в проектах клиентов, разработала ряд инструментов на основе Nix, включая Nixpkgs-update, и применяет Nix для создания воспроизводимых сред разработки.
Диаграмма демонстрирует, как Nix интегрируется с операционной системой, используя файлы как входные и выходные данные для построения конфигураций. Источник.
По словам Андреаса Херрмана, руководителя команды Scalable Build в Tweag, Nix применяет дисциплину управления памятью к развертыванию программного обеспечения. Пакеты разделены в файловой системе. Можно отслеживать ссылки между ними, выполнять сборку мусора, гарантировать, что установка никогда не будет в несогласованном состоянии.
Serokell
Компания специализируется на разработке программного обеспечения для научных исследований и анализа данных. Она использовала NixOS для настройки серверов для ML и обработки данных, а Nix — для управления зависимостями, автоматизации развертывания приложений и обеспечения воспроизводимости экспериментов в научных проектах.
Источник.
Как заявляет сама команда, развертывание новых ML-моделей получилось ускорить на 30%.
Mattermost
Это разработчик популярной платформы для командной коммуникации, который внедрил Nix в свой CI/CD для создания воспроизводимых сред сборки. Дополнительно в компании интегрировали Nix с Jenkins для автоматизации процесса CI/CD, а также применили Nix для управления зависимостями в проектах.
Команда Mattermost отмечает, что Nix позволяет явно указать все программные предпосылки, гарантируя, что приложения создаются и запускаются в согласованной среде независимо от того, где используется Nix.
Но не все так идеально
Хотя Nix и NixOS прям-таки на хайпе, у них есть свои подводные камни. Например, декларативный подход Nix к управлению конфигурациями и пакетами значительно отличается от традиционных систем Linux. Это требует от пользователей переосмысления привычных концепций управления системой. Проще говоря, новичкам может быть сложно.
Документацию Nix частенько критикуют за недостаточную структурированность, сложную терминологию и отсутствие понятных примеров для начинающих. Это тоже может отпугнуть новых пользователей, которые не получат быстрых ответов на вопросы.
Или новичков может сбить с толку наличие множества дополнительных инструментов, таких как Home-manager и Nix Flakes. Неясность в том, какие инструменты необходимы и как их правильно использовать, создает дополнительные барьеры для входа.
Несмотря на большой репозиторий пакетов, некоторое проприетарное или нишевое ПО может быть недоступно или плохо поддерживаться в Nix. Так что получить универсальный инструмент для всех-всех сценариев пока, увы, нельзя.
Наконец, подход Nix к изоляции пакетов может приводить к увеличению использования дискового пространства и некоторому снижению производительности по сравнению с более привычными системами управления пакетами.
Будущее Nix
Будущее Nix и NixOS туманно. С одной стороны, они набирают популярность среди разработчиков и админов. С другой, вопрос о выходе из «экосистемы для своих» все еще открыт.
Воспроизводимость, атомарность и изоляция — все это прекрасно для тех, кому нужны стабильность и контроль. Но для массового внедрения нужно решить несколько проблем: упростить вход для новичков, расширить поддержку проприетарного ПО и улучшить производительность.
Сообщество работает над улучшением документации, появляются user-friendly интерфейсы, а интеграции с CI/CD и контейнерными технологиями расширяются. Например, NixOS 24.05 показал серьезный прогресс: поддержка x86_64 и ARM64, установочные образы с KDE и GNOME, быстрый откат системы и установка индивидуальных пакетов.
Корпоративный сектор тоже проявляет интерес. Компании используют Nix для создания воспроизводимых сред разработки и управления сложными инфраструктурами. Для разработчиков это особенно привлекательно: гарантированное окружение, тестирование с легким откатом и полный контроль над зависимостями.
Готовы ли вы инвестировать время в изучение Nix? Делитесь мнением в комментариях!
Комментарии (36)
Jolt
05.02.2025 12:22Пробовал я недавно посидеть на Nix. Сначала тебе даже нравится, но очень раздражает что Home-manager и Nix Flakes ощущаются весьма чужеродно тому что было изначально. А сам язык хоть и весьма прост, но позволяет одно и то же записать разными способами, отчего только больше путает.
В итоге я посмотрел на то что получилось и задался вопросом: а действительно ли это стоит такой возни? Так ли часто тебе требуется с нуля восстанавливать дистрибутив? Так ли сложно через sway синхронизировать свои dotfiles в домашней директории и добиться весьма похожего эффекта?
danilasar
05.02.2025 12:22А если, например, речь идёт о компьютерном классе, где на всех машинах должна быть единая конфигурация, или если зачем-то нужно несколько идентичных экземпляров сервера? Не ручаюсь, но в данных примерах подход NixOS как будто бы выглядит достаточно убедительно.
vvzvlad
05.02.2025 12:22А если, например, речь идёт о компьютерном классе, где на всех машинах должна быть единая конфигурация
Загрузка по сети из одного образа решает задачу не хуже в рамках привычных инструментов.
shashurup
05.02.2025 12:22Вот поддержу, да. Ощущение такое, что эта вся огромная система написанная на этом языке постоянно в движении и никак не устаканится.
В итоге, каждый раз когда нужно сделать что-то не сильно сложное, типа локального шелла с выбранными питоновскими пакетами приходится копировать и править существующий конфиг, запомнить и воспроизвести по памяти так и не выходит.Особенно это хорошо видно когда пытаешься отладить какую-нибудь проблему - очень так непросто, много слоев всякого.
karavan_750
05.02.2025 12:22Осенью 19-го, преследуя интерес к проекту wireguard, искал дистрибутив, который уже рискнул предоставить пользователям поддержку новинки в протоколах VPN. Так я наткнулся на VyOS. Я уже не помню, нашел ли я в нем wireguard, но хорошо помню как меня восхитила декларативность его конфигурации и предоставление в консоли всех параметров какой-нибудь опции по двойной табуляции как в bash-completion, только гораздо жирнее. Так как VyOS ориентирован к использованию в качестве шлюза, а мне уже хотелось такое чудо на десктопе, то был найден NixOS и в декабре того же года установлен.
С тех пор эта ОС у меня основная -- на двух ноутах, на домашнем компьютере родственницы и на двух десятках личных серверов и виртуалок. Возможности атомарных изменений системы и откатов по необходимости позволяют решать любые проблемы на ПК родственницы, находясь за 1000 км от него.
Соглашусь, что порог входа достаточно высокий. Смог бы осилить эту ОС без бэкграунда в 10 лет знакомства с GNU/Linux? -- Я не знаю. Но NixOS использую находясь на уровне новичка в nix -- мне этого хватает для правки конфигураций, выискивая примеры в сети.
К слову, NixOS научил меня воспринимать ОС как набор конфигов, а не черную коробку, на которую ничего лишнего не поставить -- ибо мусор и страшно за стабильность.
dv0ich
05.02.2025 12:22В NixOS есть аналог USE-флагов Gentoo?
В NixOS можно сделать вроде
USE="-telemetry -gnome -akonadi -rust -vala" emerge -uDNva @world?dv0ich
05.02.2025 12:22Если что, я спрашиваю не из праздного любопытства, если в никсоси можно пересобрать мир и выпилить определённую функциональность из всех пакетов, то я бы попробовал. В генте, к сожалению, этот
USE=-rustне приводит к полному удалению раста из системы :(
funca
05.02.2025 12:22Полная воспроизводимость окружений,
Чем это лучше образа VM или докер?
Noah1
05.02.2025 12:22Никто в здравом уме не будет устанавливать каждый пакет в отдельной VM или контейнере, в nix любой пакет воспроизводим и изолирован, даже какой-нибудь neofetch.
vvzvlad
05.02.2025 12:22Никто в здравом уме не будет устанавливать каждый пакет в отдельной VM или контейнере
Ага, AppImage вам незнакомо? И докер, который именно что устанавливает каждый пакет в своем контейнере и который занял огромный кусок рынка, несмотря на оверхед.
m_ax1m
05.02.2025 12:22Я фанат nix. Рекомендовал бы просто nix flakes использовать на любом дистрибутиве, необязательно nixos. И это гораздо лучше докера, так как это ЯП с большим количеством библиотек и фреймворков. А ещё в никсе легко билдить докер образы, гораздо удобнее чем в Dokerfile. Для новичков документация не очень хорошая. Я бы рекомендовал просто понять основную концепцию, типо что делает функция derivation, структуру flake файла, и что все объекты типа pkgs.python просто указатель на путь в nix/store с папкой bin/python.
TIEugene
05.02.2025 12:22Судя по описанию - снова Поттеринг (дай бог ему здоровья).
Но - внезапно - не он.
dph
05.02.2025 12:22Но это скорее инструмент для развертывания окружения с нуля, не для обновления решения на продакшене, где декларативный стиль не спасает, увы. И тогда особой разницы с ансиблом или паппетом не заметно (ну, может код не такой кривой получается, но это уже надо вглубь погружаться).
Но нормальных инструментов для развертывания сложного продакшена без останова, увы, вообще нет на рынке. Все пытаются изображать декларативный стиль, хотя обычно важнее как раз сделать удобным императивный (
WebPrg
05.02.2025 12:22есть и давно, называется Erlang - hot code reload гарантирован без останова и отключения текущих клиентов
dph
05.02.2025 12:22Релоад кусочков кода в рамках одного сервиса - это достаточно просто и есть много где. И, в общем-то, нафиг не нужно.
Но это очень небольшая часть логики обновления сложного продукта.WebPrg
05.02.2025 12:22что значит "кусочков"? посмотрите внимательно на 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 ,как мне кажется, максимально были налажены процессы безшовного обновления кода даже в кластерах, причем из коробки и начиная с самых ранних версий ( это было обязательное требование дизайна системы с начала разработки языка).dph
05.02.2025 12:22Я все это знаю. Но это действительно не очень значимый плюс для выкладки больших систем, где нужно разбираться еще с миграцией баз данных, с нетривиальными миграциями на взаимодействий сервисов (для http это сделать легко, а вот для кафки - сложно), о чем, собственно и идет обсуждение в этой статье.
Для выкладки мало "выложить новый код", нужно еще разобраться с его независимым тестированием, канарейкой, контролем потребления ресурсов и так далее. Да, все эти задачи, конечно, можно решить и на эрланге/элексире. Но, увы, плюс "перезагрузка модулей" не перекрывает минусов экосистемы Erlang (неторопливое исполнение, редкие и дорогие разработчики, относительно бедная экосистема).
hogstaberg
05.02.2025 12:22Бросьте в меня тапком те, кто не сталкивался с ситуацией из разряда «А локально оно нормально работает
Вы сами попросили. Выбирайте какой тапочек: левый или правый=)
karavan_750
05.02.2025 12:22Выбирайте какой тапочек
Я тоже подумал, что люди с минимальным или отсутствующим опытом займутся тапко-закидательством.
hogstaberg
05.02.2025 12:22Или люди, которые понимают, что NixOS - плохо документированный и крайне специфичный предмет, который в 99% не серебряная пуля, а лишняя боль с поддержкой.
Ну или хотя бы просто те, кто понимает, что стейдж должен быть не просто примерно похож на прод. Он должен быть буквально копией нужного участка прода. Иначе ваш стейдж - просто массогабаритный макет.
dph
05.02.2025 12:22Ну, во многих реальных ситуациях, увы, можно сделать только массогабаритный макет.
Впрочем, обычно его и достаточно )
RranAmaru
05.02.2025 12:22Хотел было перейти, но не понравилось, что он все конфиги разных приложений конвертирует в свой формат. Иногда получается очень коряво. Например у emacs файл конфигурации - это программа на лиспе, в которой кроме установки различных переменных могут встречаться еще и фрагменты кода.
Если встречается какой-то нестандартный конфиг, то начинается квест "как сконвертировать это в nix". Думаю, было бы достаточно запоминать патчи (diff) конфигов, но нет, придумали свой формат (который, кстати, тоже программа на языке nix).
PS: Глубоко не копал, поправьте если не прав.
Noah1
05.02.2025 12:22Не обязательно. Большинство программ настраиваются через nix-опции, но если есть программа со сложным конфигом(vim, emacs), его можно писать стандартно отдельным файлом и привязать к билдам nix.
Из плюсов - не нужно думать о внешних менеджерах пакетов, любые плагины nix сам установит.
Из минусов - после редактирования конфигурации придется делать ребилд nix системы или home-manager, это просто занимает секунд 30.
Noah1
05.02.2025 12:22Неоднозначная мысль: NixOS это одновременно лучшая и худшая система для новичка.
Худшая - потому что всё очень сложно, нужно обладать бэкграундом разработчика, хреновая документация, многие просто плюнут и забьют.
Лучшая - потому что всё имеет смысл, всё настраивается в одном месте, отсутствие ада зависимостей by design, с Nix практически невозможно сломать систему, сделал что-то не так - откатился, варианта окирпичить систему просто нет, есть уверенность использовать это как рабочее место, без страха что вот завтра после обновления всё умрет.
Возможно, Linux изначально должен был работать по принципу, похожим на Nix.
Borelli
05.02.2025 12:22Ещё не пробовал 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 и отсутствие поддержки обновления до следующей версии с простотой пакетного менеджера.
kozlyuk
05.02.2025 12:22Воспроизводимость достигается тем, что прописывается конкретная версия пакетной базы прямо в тексте конфигурации (URL с коммитом) или рядом (flake.lock при использовании nix flakes). Где бы и когда бы Nix ни обрабатывал конфигурацию, он возьмет одни и те же версии. Обновление делается через обновление прописанной версии (вручную или через nix flake update) и пересборку конфигурации.
Nix сам является пакетным менеджером, у него своя пакетная база, так что говорим либо о замене CentOS на NixOS, либо об использовании Nix в CentOS параллельно со штатным управлением пакетами. В последнем случае все, установленное через Nix, будет жить в
/nixи не конфликтовать с системным. UPD: Правда, теряем генерацию конфигов сервисов из коробки, которая есть в NixOS; и с системным менеджером их придется дружить вручную. Однако для не-сервисов работет отлично.В Nix кастомная сборка будет частью конфигурации. Причем зачастую это будет не скрипт с нуля, а описание отличий от стандартной сборки (override), типа "возьми обычный Nginx, но исходники оттуда, флаги configure добавь такие".
vvzvlad
05.02.2025 12:22Кажется, что nix это отличная идея, сделанная с огромным геморроем. Плюсы есть, но вот стоит ли оно того — ой как зависит от ситуации. Похоже на переход с блокнота на vim — на vs code перейти просто, и плюшки понятны, а вот переход на vim потенциально может и обладает крутыми плюсами, но в процессе ты такого наешься, что не факт что оно в твоей ситуации того стоило.
Кроме того, три года назад, когда я пытался одну систему перенести на nix, воспроизводитмостью там и не пахло, на тесте все работало ок, на проде браузер крашился, хотя казалось бы, идентичность, воспроизводимость, вот это все. Может щас, с flake, получше стало.
unwrecker
А отличия от Антибла есть кроме как в синтаксисе?
Sild
Скорее, от паппета
Ансибл таки про применения набора действий на кластере, когда паппет точно так же описывает "желаемую" конфигурацию в декларативном стиле
unwrecker
Ну как бы Ансибл тоже в декларативном стиле. А уж на кластере или в отдельной машине - это как пожелаешь.
vvzvlad
Чтобы писать на ансибле в декларативном стиле, надо еще постараться, учитывая все сайд-эффекты команд и возможности отката. Чаще всего в среднем ансибле-скрипте декларативностью и не пахнет.
unwrecker
Хмм. Возможности отката - это интересно. В Ансибле я с таким не сталкивался. А в Nix оно прямо есть и работает?
Noah1
С ансиблом не знаком, но предположу что он полностью сконцентрирован на энтерпрайзе. Nix же вполне успешно можно использовать на домашней системе.
Kenya-West
Успешно пользуюсь Ansible для управления своей личной инфраструктурой. К этому инструменту я пришёл сам по себе, просто потому что понял, что так жить, вручную бегая по 15 серверам по всему миру, нельзя. Люди явно придумали что-то для этого. И ведь не ошибся!
Так что это инструмент для всех, не только для корпоратов.