LINUX.ORG.RU

Modus - язык для сборки контейнеров

 , ,


1

3

Привет, ЛОР!

Мы рады анонсировать Modus - новый язык для сборки образов Docker/OCI контейнеров, т.е. альтернатива докерфайлам. Modus использует логическое программирование для того, чтобы описывать зависимости между параметрами сборки, автоматически распараллеливать и кэшировать исполнение, оптимизировать размер образов, и упрощать сопровождение. Modus распространяется по лицензии AGPL-3.0. Текущая версия 0.1 не рекомендуется для использования в продакшене. Отзывы и предложения приветствуются.

https://modus-continens.com/

Ответ на: комментарий от hateyoufeel

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

Modus не накладывает никаких играничений: каждая операция может исполнять произвольную команду, например, установка пакетов с DNF или запуск тестов.

В результате Modus более универсален и проще в использовании. Это, по сути, язык сценариев, которые включают в себя среду исполнения, автоматически распараллеливаются и кэшируются с помощью union mount файловой системы. Преимущество Nix заключается в том, что проще гарантировать воспроизводимость.

symbolic
() автор топика
Ответ на: комментарий от symbolic

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

Про директорию не очень понял. Про формат: в Nix есть тулинг для распаковки RPM, Deb, AppImage и прочих. Думаю, завернуть другие штуки тоже не проблема.

Modus не накладывает никаких играничений: каждая операция может исполнять произвольную команду, например, установка пакетов с DNF или запуск тестов.

Значит ли это, что воспроизводимость не гарантируется? Есть ли возможность её как-то гарантировать? Как насчёт сборки контейнера внутри песочницы, чтобы чужие сценарии не послужили вектором атаки?

P.S. я, если что, не просто так спрашиваю. У нас как раз сборка контейнеров на Nix и это иногда весьма больно, поэтому мне интересны альтернативные инструменты :)

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Про директорию не очень понял.

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

Про формат: в Nix есть тулинг для распаковки RPM, Deb, AppImage и прочих. Думаю, завернуть другие штуки тоже не проблема.

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

Значит ли это, что воспроизводимость не гарантируется? Есть ли возможность её как-то гарантировать?

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

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

Как насчёт сборки контейнера внутри песочницы, чтобы чужие сценарии не послужили вектором атаки?

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

У нас как раз сборка контейнеров на Nix и это иногда весьма больно, поэтому мне интересны альтернативные инструменты

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

symbolic
() автор топика
Ответ на: комментарий от symbolic

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

А.. не, это не так. 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, и это основное направление где меня интересуют такие инструменты.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 3)
Ответ на: комментарий от hateyoufeel

никс любит закэшировать и использовать старые derivations, хотя надо использовать новые. Т.е. это следствие всей архитектуры этой приблуды.

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

Tsukasa
()
Ответ на: комментарий от hateyoufeel

Да нет, просто в Nix тоже есть баги.

Ну уж нет, так не пойдёт, давай разберем тобой написанное. Eval кешируется только в flakes, которые experimental, а так там ничего не кешируется. Если проблемы в экспериментальной фиче, то как бы ССЗБ, ибо ими никто не заставляет пользоваться. Более того, нужно специально настраивать никс чтобы оно работало.

Т.е. это следствие всей архитектуры этой приблуды.

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

Tsukasa
()
Ответ на: комментарий от Tsukasa

Ну уж нет, так не пойдёт, давай разберем тобой написанное.

Не, не давай. Я, честно говоря, могу наверное даже рабочий пример запилить. Но мне настолько лень, что я не буду. Пусть кто-то другой с этим пердолится.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Я, честно говоря, могу наверное даже рабочий пример запилить. Но мне настолько лень, что я не буду. Пусть кто-то другой с этим пердолится.

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

Tsukasa
()
Ответ на: комментарий от hateyoufeel

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

Спасибо, это очень полезно.

symbolic
() автор топика
Ответ на: комментарий от Tsukasa

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

Возможно, ты им пользовался не для тех же целей.

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

А.. ну я багрепорт закидывал, а дальше ковыряться я не хочу. Мой нынешний план: потихоньку выпилить Nix из рабочих проектов к чёртовой бабушке. Даже без этого отдельного косяка, который, честно скажу, всплывает достаточно редко, всего остального достаточно, чтобы Nix был больше проблемой чем решением. Ленивость, динамическая типизация языка и «infinite recursion at undefined location» – это вообще лютый ахтунг. Я понимаю, почему они так сделали, но от этого вот вообще не легче.

hateyoufeel ★★★★★
()
Ответ на: комментарий от symbolic

Я вот это на вашей странице увидел: «© 2022 University College London.»

Это чей-то проект в рамках диссертации или какого-то исследования? Или вы это в итоге собираетесь как-то на коммерческие рельсы пускать?

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Возможно, ты им пользовался не для тех же целей.

Ты не поверишь, как раз активно пользовался в Gitlab CI для сборки около сотни докер-образов из монорепы.

ну я багрепорт закидывал

Есть ссылка?

Tsukasa
()
Ответ на: комментарий от hateyoufeel

Это чей-то проект в рамках диссертации или какого-то исследования? Или вы это в итоге собираетесь как-то на коммерческие рельсы пускать?

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

У нас пока нет бизнес модели, но мы работаем в этом направлении. В любом случае, язык будет под свободной лицензией.

infinite recursion at undefined location

Кстати, Modus не Тьюринг полный, т.ч. в нем любой скрипт завершается.

symbolic
() автор топика
Ответ на: комментарий от symbolic

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

Тогда выглядит очень круто. Жду продолжения!

Кстати, Modus не Тьюринг полный, т.ч. в нем любой скрипт завершается.

Это хорошо. Тьюринг-полные языки правил – это какой-то лютый ад.

Хотя тут можно сказать, что Nix тоже не полон по Тьюрингу, потому что там детектор рекурсии есть. Конкретно эта ошибка вылезает из-за ленивости, когда из-за ошибки в коде бесконечное вычисление запускается хер знает откуда.

hateyoufeel ★★★★★
()
Ответ на: комментарий от sudopacman

Ещё такое есть

Интересный проект. Modus использует Datalog в качестве формализма, т.к. Datalog хорошо подходит для описания зависимостей между образами, и статически гарантирует,что не будет бесконечной рекурсии. Но у нас пока нет хорошей поддержки структур данных как в Nickel.

symbolic
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.