LINUX.ORG.RU

Jet — новая платформа автоматизации и оркестрации

 ,


3

3

Jet – новая платформа для автоматизации и оркестрации, ориентированная на сообщество пользователей и разработчиков. Платформа создаётся Майклом ДеХааном, создателем программ автоматизации IT-инфраструктуры Cobbler и Ansible.

Основные цели Jet:

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

Язык программирования Jet будет напоминать язык плейбуков Ansible, чтобы облегчить использование для пользователей, работающих с уже существующим контентом. Переход на Jet должен быть относительно простым, а разработчики обещают поддерживать стабильность языка, что позволит избежать необходимости внесения значительных изменений при обновлениях продукта.

Платформа реализовывается на языке программирования Rust, что должно помочь обеспечить высокую производительность и возможность параллельного выполнения задач. Компилятор Rust также будет активно проверять код на предмет ошибок, снижая риск возникновения проблем во время работы и автоматизируя процесс проверки контента на ошибки.

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

Первоначальная поддержка будет доступна только для Linux, но в будущем возможно расширение на другие системы, такие как BSD.

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

>>> Подробности

★★☆

Проверено: hobbit ()
Последнее исправление: unfo (всего исправлений: 6)

ещё один лысапет «потомучта на руст»

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

Да просто стартануть эту поделку ансибл и показать хелп уже 260 миллисекунд, о чем речь вообще. Оно еле пашет.

________________________________________________________
Executed in  261.75 millis    fish           external
   usr time  253.73 millis    1.56 millis  252.17 millis
   sys time    8.06 millis    0.10 millis    7.95 millis
ac130kz ★★
()
Ответ на: комментарий от ugoday

Я подозреваю что дело в трансляции между yaml’ом и собственно модулями. Те же команды шеллом по ssh выполняются кратно быстрее.

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

Да просто стартануть

Милейший, вам в третий раз повторяют, что смысл оркестратора в запуске внешних относительно него сущностей.

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

Да Господь с вами, на любом актуальном железе манипуляция с yaml’ами ничего не стоит.

Те же команды шеллом по ssh

Ну, допустим, нам надо: а) установить mariadb; б) настроить её; в) запустить демона и проверить, что он работает. Любые различия в производительности между python и bash тут не имеют значения. Вообще. Очевидно ansible делает какие-то дополнительные проверки или делает ещё какую работу для переносимости.

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

Да Господь с вами, на любом актуальном железе манипуляция с yaml’ами ничего не стоит.

Речь не об этом. Смари, у тебя есть модуль, который меняет три файла. Если накладные расходы на проверки перед вызовом условного sed превыщают время выполнения sed в разы, то когда таких файлов становится много, мы натыкаемся на тормозища.

Ну, допустим, нам надо: а) установить mariadb; б) настроить её; в) запустить демона и проверить, что он работает. Любые различия в производительности между python и bash тут не имеют значения. Вообще. Очевидно ansible делает какие-то дополнительные проверки или делает ещё какую работу для переносимости.

Ага, и не факт что он делает это хорошо. Мб чуваки это поправят в jet.

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

Если накладные расходы на проверки перед вызовом условного sed

Ну извините, за всё надо платить, один и тот же playbook пашет на широком диапазоне дистрибутивов, а скрипт на баше не факт, что смену версии в одном дистре переживёт.

Ага, и не факт что он делает это хорошо

Ну да, ну да. dpkg -i package.deb или systemctl status service будут работать в сто раз быстрее, потому что руст в сто раз быстрее питона.

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

А я уже светло-серым по темно-серому написал, что если пинг 10 мс, а просто запустить эту балалайку 260 мс, даже ничего не делая, то это стремно. На любой чих будет оверхед, еще раз, для повторения, даже БЕЗ io.

ac130kz ★★
()

Ля, они надоели лепить программный зоопарк решений одной конкретной проблемы. Всё IT только и дышит подобными конвеерами «инноваций».

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

Ну извините, за всё надо платить, один и тот же playbook пашет на широком диапазоне дистрибутивов, а скрипт на баше не факт, что смену версии в одном дистре переживёт.

Вопрос в оптимизациях.

Ну да, ну да. dpkg -i package.deb или systemctl status service будут работать в сто раз быстрее, потому что руст в сто раз быстрее питона.

Ох… возьми 7 центось и поставь штук 40 пакетов через yum. Возьми 9 центось и поставь штук 40 пакетов через dnf. Увидишь разницу секунд в десять, хотя и то и другое банально парсит repomd.

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

пинг 10 мс, а просто запустить эту балалайку 260 мс

Я согласен, что если вам нужен оркестратор, который ничего не делает, просто быстро запускается и падает, то ansible — не лучший выбор. Это признание далось мне нелегко, но ваши убедительные аргументы слишком убедительные.

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

Вопрос в оптимизациях.

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

Увидишь разницу секунд в десять

Копейки.

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

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

Тот же yum -> dnf. Переписали на сях и стало отличненько. Discord портанул с гоголанга на руст и им тоже стало отличненько. Короче историй успеха полным-полно.

Копейки.

Да-да, двадцать человек не отдел, полгода не задача. Я понимаю что интерпрайзу плевать, но все-таки хочется как-то развивать индустрию, а не наоборот.

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

Переписали на сях и стало отличненько

Да полно таких историй. И объединяет их одно: в этой фразе «переписали» весит больше, чем «на сях». Если с питона на питон переписать, тоже будет выигрых по производительности, такие дела.

Я понимаю что интерпрайзу плевать,

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

ugoday ★★★★★
()

А почему все так сильно возбудились на сравнении с Ansible? Банально из-за поддержки плейбуков? Ведь есть Terraform, который написан на языке конкурента Rust’а - Go. Именно с Terraform можно зарубиться за пользовательскую базу, благо Terraform очень плох в императивном провиженинге ресурсов, ибо максимально заточен на декларативный подход.

Мне как пользователю Terraform’а очень не нравится качество продукта, к примеру в версии 1.3 ввели калечущее изменение, которое починили только в 1.5. Было создано множество багов, которые якобы чинили что-то, но по факту лишь к 1.5 разрабы откатили код, который ломал уничтожение ресурсов.

В общем, надеюсь у Terraform’а появится достойный конкурент. А по Ансиблу ничего не могу сказать, не работал с ним уже каких 5 лет, наверняка он уже не тот, каким был раньше.

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

Плётка для подгоняния медленных разрабов

В госухе до сих пор встречаются люди в роли разработчиков? :)

Что они там забыли?

sanyo1234
()

Мало нам было существующих платформ императивного конфигурирования.

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

Не только запуск, а распределение нагрузки и слежение за уже запущенным.

Яркий пример орекстратора это : Kubernetes. Правда там он управляет контейнерами.

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

Это если локальный реп, при удаленном и медленном эти 10 секунд по фигу.

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

CDK — это кодогенератор для Cloudformation. А тот ещё декларативнее нежели Terraform.

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

Я согласен с вами, однако

Jet планирует поддерживать возможность запуска модулей Ansible и собственных модулей на удаленных системах

Выглядит как некая замена Jenkins/CircleCI/whatever, а не Kubernetes. Собственно, я с этого и начал, спросив «какие недостатки имеющихся систем Jet призван решить».

Без этого это даже не новость о намерениях, а новость, что кто-то хочет что-то сделать, но что именно нам не рассказывают.

P.S. Лучше бы на clojure писали с режимом emacs’а в качестве управляющего фронтенда (вместо веба поганого).

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

притаилась коварная бисектуальная сосиска

Это не сосиска, а кокакка… Опасный ксенос, имей ввиду.

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

Плётка для подгоняния медленных разрабов

Вместе с ТА-57 очень ускоряет, когда провода заканчиваются в районе мошонки.

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

У меня ансибле тормозит совершенно не из-за него. Когда софт ставится на 50 хостов сразу главная проблема чтобы эти 50 штук с локального сервака слились ну и поставились, тоже время. А сам ансибле и так нормльно пашет …

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

Вот, полностью согласен, ту же мысль пытаюсь донести.

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

Боюсь, это ещё хуже, чем писать на HCL, так как является обёрткой и переводит код во всё тот же HCL.

You have a strong preference or need to use a procedural language to define infrastructure

Это далеко не обязательное требование, я просто намекнул, что с процедурностью в HCL беда. Переход прям на процедурный язык может быть ещё более опасен

You are comfortable living on the cutting edge; CDKTF may still have breaking changes before our 1.0 release

Вот этого совсем не хочется. Пусть лучше классический Terraform.

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

Это не замена ТФ, я поговорил с Майклом как раз об этом. Фактически это будет пускалка готовых плейбуков плюс основные модули будут переписаны. Когда это все заработает, начнетс движение дальше, но в целях проекта борьбы с ТФ нет и не будет

dyasny ★★★★★
()

Любопытно, и лицензию обещают правильную: GPLv3

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