Комментарии 10
Какие преимущества описанный подход дает по сравнению со сборкой в Docker на базе фиксированного образа Alpine/Debian/Ubuntu/etc? (UPD: с зафиксированным срезом репозитария).
Какое лучшее решение, чтобы распространять динамические бинарники, собранные nix из закрытого кода (иначе ответ --- через nix же)? Здесь Docker (но см. выше и ниже), знаю, что есть nix bundle (нестандартно) и можно колдовать с patchelf (ненадежно).
Когда экспериментировал с dockerTools, был удручен тем, что в nixpkgs принято пихать в деривации (пакеты) все, что можно. В результате образ с clang+LLVM, который на базе Debian занимает ~600 МБ, на базе nixpkgs был 1.3 ГБ. Еще dockerTools не очень дружит с докерским кэшированием образов, по сравнению с Dockerfile нужны дополнительные движения.
Какие преимущества описанный подход дает по сравнению со сборкой в Docker на базе фиксированного образа Alpine/Debian/Ubuntu/etc? (UPD: с зафиксированным срезом репозитария).
Если мы не берём C/C++, у других языков часто бывает очень ооооочень много мелких библиотек, которые в репозитариях традиционных дистрибутивов отсутствуют. В случае Nix всё проще, поскольку derivations генерируются на лету.
Плюс, Nix позволяет проще совмещать сборку компонентов на разных языках. Гораздо приятнее, когда есть небольшая директория с кодом на Nix, чем куча лапши на make, shell и так далее.
Какое лучшее решение, чтобы распространять динамические бинарники, собранные nix из закрытого кода (иначе ответ — через nix же)?
Не очень понял вопрос. Если имеется ввиду, например, наш код, бинарники из которого мы хотим отдать на сторону, то здесь, как и всегда в мире линукса, путь полон боли и страданий :( Docker, AppImage, да хоть RPM с Deb или другие инструменты, но суть в итоге одна: упаковать бинарник с зависимостями и всё вместе поставлять.
Если речь идёт об установке чужого закрытого кода у себя, то Nix позволяет это делать. В Nixpkgs довольно много пакетов, которые ставятся из чужих бинарников напрямую. Patchelf вполне надёжен, если версия библиотек совпадает.
Когда экспериментировал с dockerTools, был удручен тем, что в nixpkgs принято пихать в деривации (пакеты) все, что можно. В результате образ с clang+LLVM, который на базе Debian занимает ~600 МБ, на базе nixpkgs был 1.3 ГБ.
Да, есть такая проблема. О жирных деревьях зависимостей я в следующей статье напишу :)
Если мы не берём C/C++, у других языков часто бывает очень ооооочень много мелких библиотек, которые в репозитариях традиционных дистрибутивов отсутствуют.
Как правило, у таких языков есть и свой пакетный менеджер, у которого lock-файл для воспроизводимости и автоматическая сборка пакетов, а нативные зависимости мы уже зафиксировали с дистрибутивом и его репозитарием.
Писать сборку чужих зависимостей на nix не очень круто, потому что окружение nix ни на что не похоже: во-первых, приходится вычищать #!/bin/bash из исходников, во-вторых, никто не тестировал результат, вдруг там притаился dlopen("/usr/lib/...").
Вопрос был про ту часть, где боль и страдание :(
Под хаком с patchelf я имел в виду заменять пути в nix store на FHS-пути. Да, это может работать, но надо именно что следить за версиями.
Как правило, у таких языков есть и свой пакетный менеджер, у которого lock-файл для воспроизводимости и автоматическая сборка пакетов, а нативные зависимости мы уже зафиксировали с дистрибутивом и его репозитарием.
Ага. Но если, например, проект на двух языках сразу, пакетных менеджеров становится уже два. Я не говорю, что надо всегда использовать Nix. Но в некоторых случаях его использование сильно упрощает жизнь.
Писать сборку чужих зависимостей на nix не очень круто, потому что окружение nix ни на что не похоже: во-первых, приходится вычищать #!/bin/bash из исходников, во-вторых, никто не тестировал результат, вдруг там притаился dlopen("/usr/lib/...").
Мне кажется, это два несвязанных утверждения. Собирать всё подряд Nix вполне можно. Но иногда очень больно и неоправданно. Универсального решения тут, как всегда, нет.
#!/bin/bash приходится вычищать не только в Nix (кстати, Nix это делает сам автомагически!). В FreeBSD, например, bash лежит в /usr/bin. А софт с dlopen() и хардкодом путей лучше просто выкинуть от греха подальше.
Мне как раз нравятся идеи Nix и надоело возиться с Docker'ом, который нужен только для вендоринга зависимостей (причем их не так много) и атомарной установки нужных версий СУБД. И проект как раз на разных языках. Но пока нет уверенности, что переход был бы оправдан.
Вот наш софт использует драйвера и библиотеки от вендора сетевой карты, исходники открыты. Собрать нужную их часть Nix --- раз плюнуть. Но если что-то пойдет не так, вендор скажет: есть поддержваемые дистрибутивы, есть спеки пакетов под них, а вы собрали непойми чем, отсюда все ваши беды. И придется доказывать, что проблема на их стороне (или нет).
Вызывает интерес вот еще какой разрез (с).
# Импортируем последнюю версию haskell.nix с GitHub и инициализируем Nixpkgs с её использованием.
haskellNix ? import (builtins.fetchTarball "https://github.com/input-output-hk/haskell.nix/archive/b0d03596f974131ab64d718b98e16f0be052d852.tar.gz") {}
Допустим, есть фронт и бэк в разных репозитариях, общаются через API, спецификация API находится в репозитарии бэка. По идеологии Nix фронт должен импортировать спецификацию из конкретного коммита бэкенда, чтобы сборка фронта была повторяемой. Допустим, делается фича, где меняется API, оба проекта заводят у себя feature branch, фронт должен поменять ссылку на коммит. Но ветка развивается, и каждый раз, когда бэкенд меняет API, фронт должен менять ссылку (и еще после слияния). По сути, на этом этапе воспроизводимость, которую дает Nix, только мешает. В случае Docker'а можно ставить образу тэг с именем ветки и всегда иметь образ "самый свежий из ветки", а в Nix?
Nix: воспроизводимая сборка