История изменений

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

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

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

То же самое. Разницы никакой, всё работает.

Для того, чтобы гарантировать воспроизводимость, нужно использовать менеджер пакетов, который её гарантирует, и не использовать такие команды, как, например, wget a.com/file.txt, где file.txt может изменятся.

Вот в этом и косяк. На одной тачке сборка может пройти, а на другой – нет. Я понимаю, что многим на это по боку, но контейнеры часто используются как финальный артефакт из CI при сборке кода. И здесь повторяемость и воспроизводимость очень важны.

Modus полезен, когда нужна логика поверх менеджера пакетов. Скажем, шаблон докерфайла OpenJDK использует AWK скрипты и фильтры JQ, чтобы описать эту логику. Эквивалентный Modusfile гораздо короче и исполняется быстрее.

Да, я понимаю. Это такой небольшой скриптовый язычок поверх сборки контейнеров, который позволяет делать зашибись. Мы никсом похожее делаем.

Все сценарии в Modus исполняются внутри контейнера, и есть поддержка multi-stage builds

👍

Мы сейчас думаем в каком направлении развивать проект, т.ч. если бы Вы могли сказать какие ограничения докерфайлов и Nix вызывают неудобства, это было бы очень полезно!

Dockerfile просто убоги и ограниченны, и для чего-то сложнее скачать базовый образ и добавить в него бинарник их использовать бесполезно.

На Nix у нас сейчас полный CI, через него идёт сборка софта и оборачивание его в контейнер с помощью dockerTools.

Основные проблемы для нас:

• Довольно высокий порог вхождения, из-за чего разобраться в проблемах Nix могут наверное три человека из всей компании. Это большая проблема.
• Мало документации. Это часть проблемы выше, но стоит упомянуть отдельно.
• Разные совсем странные баги, которые непонятно как чинить. Например, никс любит закэшировать и использовать старые derivations, хотя надо использовать новые. Т.е. это следствие всей архитектуры этой приблуды.
• Кривая работа за пределами NixOS. Особенно на маках. К самим контейнерам это прямого отношения не имеет, но тем не менее, часть команды любят маки и для них что-то связанное с CI сделать – геморрой лютый.

Что бы я хотел от идеальной штуки для сборки образов:

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

Думаю, тут весьма заметно, что всё это имеет отношение к работе в CI, и это основное направление где меня интересуют такие инструменты.

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

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

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

То же самое. Разницы никакой, всё работает.

Для того, чтобы гарантировать воспроизводимость, нужно использовать менеджер пакетов, который её гарантирует, и не использовать такие команды, как, например, wget a.com/file.txt, где file.txt может изменятся.

Вот в этом и косяк. На одной тачке сборка может пройти, а на другой – нет. Я понимаю, что многим на это по боку, но контейнеры часто используются как финальный артефакт из CI при сборке кода. И здесь повторяемость и воспроизводимость очень важны.

Modus полезен, когда нужна логика поверх менеджера пакетов. Скажем, шаблон докерфайла OpenJDK использует AWK скрипты и фильтры JQ, чтобы описать эту логику. Эквивалентный Modusfile гораздо короче и исполняется быстрее.

Да, я понимаю. Это такой небольшой скриптовый язычок поверх сборки контейнеров, который позволяет делать зашибись. Мы никсом похожее делаем.

Все сценарии в Modus исполняются внутри контейнера, и есть поддержка multi-stage builds

👍

Мы сейчас думаем в каком направлении развивать проект, т.ч. если бы Вы могли сказать какие ограничения докерфайлов и Nix вызывают неудобства, это было бы очень полезно!

Dockerfile просто убоги и ограниченны, и для чего-то сложнее скачать базовый образ и добавить в него бинарник их использовать бесполезно.

На Nix у нас сейчас полный CI, через него идёт сборка софта и оборачивание его в контейнер с помощью dockerTools.

Основные проблемы для нас:

• Довольно высокий порог вхождения, из-за чего разобраться в проблемах Nix могут наверное три человека из всей компании. Это большая проблема.
• Мало документации. Это часть проблемы выше, но стоит упомянуть отдельно.
• Разные совсем странные баги, которые непонятно как чинить. Например, никс любит закэшировать и использовать старые derivations, хотя надо использовать новые. Т.е. это следствие всей архитектуры этой приблуды.
• Кривая работа за пределами NixOS. Особенно на маках. К самим контейнерам это прямого отношения не имеет, но тем не менее, часть команды любят маки и для них что-то связанное с CI сделать – геморрой лютый.

Что бы я хотел от идеальной штуки для сборки образов:

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

Думаю, тут весьма заметно, что всё это имеет отношение к работе в CI, и это основное направление где меня интересуют такие инструменты.

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

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

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

То же самое. Разницы никакой, всё работает.

Для того, чтобы гарантировать воспроизводимость, нужно использовать менеджер пакетов, который её гарантирует, и не использовать такие команды, как, например, wget a.com/file.txt, где file.txt может изменятся.

Вот в этом и косяк. На одной тачке сборка может пройти, а на другой – нет. Я понимаю, что многим на это по боку, но контейнеры часто используются как финальный артефакт из CI при сборке кода. И здесь повторяемость и воспроизводимость очень важны.

Modus полезен, когда нужна логика поверх менеджера пакетов. Скажем, шаблон докерфайла OpenJDK использует AWK скрипты и фильтры JQ, чтобы описать эту логику. Эквивалентный Modusfile гораздо короче и исполняется быстрее.

Да, я понимаю. Это такой небольшой скриптовый язычок поверх сборки контейнеров, который позволяет делать зашибись. Мы никсом похожее делаем.

Все сценарии в Modus исполняются внутри контейнера, и есть поддержка multi-stage builds

👍

Мы сейчас думаем в каком направлении развивать проект, т.ч. если бы Вы могли сказать какие ограничения докерфайлов и Nix вызывают неудобства, это было бы очень полезно!

Dockerfile просто убоги и ограниченны, и для чего-то сложнее скачать базовый образ и добавить в него бинарник их использовать бесполезно.

На Nix у нас сейчас полный CI, через него идёт сборка софта и оборачивание его в контейнер с помощью dockerTools.

Основные проблемы для нас:

• Довольно высокий порог вхождения, из-за чего разобраться в проблемах Nix могут наверное три человека из всей компании. Это большая проблема.
• Мало документации. Это часть проблемы выше, но стоит упомянуть отдельно.
• Разные совсем странные баги, которые непонятно как чинить. Например, никс любит закэшировать и использовать старые derivations, хотя надо использовать новые. Т.е. это следствие всей архитектуры этой приблуды.
• Кривая работа за пределами NixOS. Особенно на маках. К самим контейнерам это прямого отношения не имеет, но тем не менее, часть команды любят маки и для них что-то связанное с CI сделать – большая проблема.

Что бы я хотел от идеальной штуки для сборки образов:

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

Думаю, тут весьма заметно, что всё это имеет отношение к работе в CI, и это основное направление где меня интересуют такие инструменты.

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

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

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

То же самое. Разницы никакой, всё работает.

Для того, чтобы гарантировать воспроизводимость, нужно использовать менеджер пакетов, который её гарантирует, и не использовать такие команды, как, например, wget a.com/file.txt, где file.txt может изменятся.

Вот в этом и косяк. На одной тачке сборка может пройти, а на другой – нет. Я понимаю, что многим на это по боку, но контейнеры часто используются как финальный артефакт из CI при сборке кода. И здесь повторяемость и воспроизводимость очень важны.

Modus полезен, когда нужна логика поверх менеджера пакетов. Скажем, шаблон докерфайла OpenJDK использует AWK скрипты и фильтры JQ, чтобы описать эту логику. Эквивалентный Modusfile гораздо короче и исполняется быстрее.

Да, я понимаю. Это такой небольшой скриптовый язычок поверх сборки контейнеров, который позволяет делать зашибись. Мы никсом похожее делаем.

Все сценарии в Modus исполняются внутри контейнера, и есть поддержка multi-stage builds

👍

Мы сейчас думаем в каком направлении развивать проект, т.ч. если бы Вы могли сказать какие ограничения докерфайлов и Nix вызывают неудобства, это было бы очень полезно!

Dockerfile просто убоги и ограниченны, и для чего-то сложнее скачать базовый образ и добавить в него бинарник их использовать бесполезно.

На Nix у нас сейчас полный CI, через него идёт сборка софта и оборачивание его в контейнер с помощью dockerTools.

Основные проблемы для нас:

• Довольно высокий порог вхождения, из-за чего разобраться в проблемах Nix могут наверное три человека из всех компании. Это большая проблема.
• Мало документации. Это часть проблемы выше, но стоит упомянуть отдельно.
• Разные совсем странные баги, которые непонятно как чинить. Например, никс любит закэшировать и использовать старые derivations, хотя надо использовать новые. Т.е. это следствие всей архитектуры этой приблуды.
• Кривая работа за пределами NixOS. Особенно на маках. К самим контейнерам это прямого отношения не имеет, но тем не менее, часть команды любят маки и для них что-то связанное с CI сделать – большая проблема.

Что бы я хотел от идеальной штуки для сборки образов:

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

Думаю, тут весьма заметно, что всё это имеет отношение к работе в CI, и это основное направление где меня интересуют такие инструменты.