Comments 8
Давно использую salt (чуть ли ни с его рождения), мне очень нравятся те идеи которые в нем заложены, простота и невероятная гибкость. Тем не менее есть и негатив от него. Сразу списком, а ниже подробнее:
1) нестабильность версий и плохое их тестирование;
2) часто ломают совместимость;
3) ужасный стиль кода и плохая внутренняя согласованность.
У меня написано весьма немало конфигураций, в том числе достаточно сложные и взаимосвязанных, и чуть-ли ни каждая новая версия salt ломала ранее работавшие конфигурации. Приходилось экстренно либо находить/придумывать воркэраунды либо исправлять код самому. И вот новый переход на последнею версию опять сломал кое-что (уже сам пофиксил и заслал автору pull request).
Так же несколько раз случалось, что новые версии minion'ов требовали также обновленного master'а, то есть нельзя было компоненты salt обновлять постепенно, а нужно было только сразу везде и до одинаковой версии. Для продакта это так же «неприятно».
Поскольку мне приходилось и самому писать какие-то модули для него и исправлять что-то внутри, то у меня есть представление о том как он написал с точки зрения программиста. Так вот, писал его явно не программист. Прям по коду видно как автор все больше и больше узнавал как же писать на python и старался писать все более правильнее со временем. От одних только __getitem___ по всему коду плакать хочется. Ну и целом очень много решений «в лоб» без обобщений. Прям иногда есть желание форкнуть и вычистить все, сдерживаюсь пока :-)
Кстати, действительно невероятная гибкость salt тоже иногда играет ему в минус, потому что одну и туже конфигурацию можно написать тучей способов и, когда нет опыты, сложно выбрать как именно. Возможно, ваши статьи помогут начинающим сориентироваться как это все готовить.
Так что, если вы думаете выбрать salt для продакта, то учтите есть ли у вас навыки и желание, что-то в нем исправлять и обслуживать как отдельную сущность (следить за обновлениями). Конечно, проект развивает (и очень быстро), поэтому есть вера, что будет становиться все лучше и лучше.
1) нестабильность версий и плохое их тестирование;
2) часто ломают совместимость;
3) ужасный стиль кода и плохая внутренняя согласованность.
У меня написано весьма немало конфигураций, в том числе достаточно сложные и взаимосвязанных, и чуть-ли ни каждая новая версия salt ломала ранее работавшие конфигурации. Приходилось экстренно либо находить/придумывать воркэраунды либо исправлять код самому. И вот новый переход на последнею версию опять сломал кое-что (уже сам пофиксил и заслал автору pull request).
Так же несколько раз случалось, что новые версии minion'ов требовали также обновленного master'а, то есть нельзя было компоненты salt обновлять постепенно, а нужно было только сразу везде и до одинаковой версии. Для продакта это так же «неприятно».
Поскольку мне приходилось и самому писать какие-то модули для него и исправлять что-то внутри, то у меня есть представление о том как он написал с точки зрения программиста. Так вот, писал его явно не программист. Прям по коду видно как автор все больше и больше узнавал как же писать на python и старался писать все более правильнее со временем. От одних только __getitem___ по всему коду плакать хочется. Ну и целом очень много решений «в лоб» без обобщений. Прям иногда есть желание форкнуть и вычистить все, сдерживаюсь пока :-)
Кстати, действительно невероятная гибкость salt тоже иногда играет ему в минус, потому что одну и туже конфигурацию можно написать тучей способов и, когда нет опыты, сложно выбрать как именно. Возможно, ваши статьи помогут начинающим сориентироваться как это все готовить.
Так что, если вы думаете выбрать salt для продакта, то учтите есть ли у вас навыки и желание, что-то в нем исправлять и обслуживать как отдельную сущность (следить за обновлениями). Конечно, проект развивает (и очень быстро), поэтому есть вера, что будет становиться все лучше и лучше.
Почти во всем согласен с Вами, — все верно. Салт, как и любой другой молодой продукт не лишен недостатков. Будем надеяться, что сообщество работающее над его развитием будет пополняться более талантливыми программистами (от того, наверняка и проблемные места, что сообщество разнородное и многочисленное). Но, с другой стороны, его сумасшедшая гибкость и простота тянет как магнит.
У меня уже тоже много конфигураций и своя модель представления компонентов с наследованием и прочими вкусностями. А статьи пишу и буду писать для таких же как я авантюрно настроенных людей, которым интересно взять все новое и внедрить его, как это уже было с салтом, докером и прочими «сырыми» технологиями.
У меня уже тоже много конфигураций и своя модель представления компонентов с наследованием и прочими вкусностями. А статьи пишу и буду писать для таких же как я авантюрно настроенных людей, которым интересно взять все новое и внедрить его, как это уже было с салтом, докером и прочими «сырыми» технологиями.
Небольшое замечание: странно что вы используете параметр watch у nginx-service отдельно для каждого конфигурационного файла. На мой взгляд, гораздо более логично использовать watch_in: — service: nginx-service для каждого конфигурационного файла.
Кстати, на мой взгляд, гораздо удобнее использовать состояние file.recurse для управления некоторой дирректорией конфигураций.
Кстати, на мой взгляд, гораздо удобнее использовать состояние file.recurse для управления некоторой дирректорией конфигураций.
приветствую! да, действительно *_in реквизиты достаточно сильно упрощают жизнь, но, по сути, делают то же самое, что и собственно реквизиты описанные в самих зависимых стейтах, потому оба способа — приемлемы. По поводу file.recurse — этот стейт еще не входил в поставку salt stack на момент написания статьи :) (вышел только в 2014.7.0) В любом случае — советы правильные, спасибо.
По поводу file.recurse — этот стейт еще не входил в поставку salt stack на момент написания статьи :) (вышел только в 2014.7.0)
Это не совсем так. Это состояние появилось начиная с версии 0.10.0 а она вышла в июне 2012 года.
но, по сути, делают то же самое, что и собственно реквизиты описанные в самих зависимых стейтах
На мой взгляд есть некоторая путаница в этих реквизитах… по крайней мере в некотором не соответствии их названий тому что же они делают на самом деле.
require — используется в том стейте, которому необходим другой стейт, при этом другой стейт ничего не знает об этом.
watch_in — используется так же, но при этом еще и вызывает перезагрузку службы (или что-то еще) если состояние текущего стейта изменилось.
require_in и watch указывают на ровно противоположные отношения между стейтами.
Т.е. если у нас есть некоторое дерево состояний, то require и watch_in используются в дочерних элементах и эти элементы очевидно знают своих родителей. А require_in и watch — в родительских, которые в свою очередь не обязательно знают всех своих детей.
{% for cnf in ['vhost1.conf', 'vhost2.conf', 'vhost3.conf', 'vhost4.conf', 'vhost5.conf'] %}
В вашем примере как раз и показано то, через что приходится проходить, чтобы заставить родителей знать своих детей (:
Абсолютно согласен с тем, что Вы описали по части реквизитов, — все верно. Каюсь: на момент написания статьи и сам Salt и автор были еще не столь глубоко знакомы. :) Но все меняется со временем и остальные статьи — тому пример.
Но, на самом деле, соль статьи была как раз в описании мало документированного примера использования модуля cp. И стейты в статье описывались не как пример для «copy-paste» себе в дерево, а как рассмотрение шагов модернизации от самого простого проходя более комплексный (всегда рабочий, но не всегда элегантный!) до последнего, описывающего собственно то, что удалось выкопать автору и то, чем хотелось бы поделится.
Естественно, как мне кажется, каждый должен применять голову к тому или иному материалу изложенному на Хабре.
В любом случае — буду рад прочесть и обсудить Вашу статью на тему SaltStack, — вполне возможно, что мне будет чему поучится.
Но, на самом деле, соль статьи была как раз в описании мало документированного примера использования модуля cp. И стейты в статье описывались не как пример для «copy-paste» себе в дерево, а как рассмотрение шагов модернизации от самого простого проходя более комплексный (всегда рабочий, но не всегда элегантный!) до последнего, описывающего собственно то, что удалось выкопать автору и то, чем хотелось бы поделится.
Естественно, как мне кажется, каждый должен применять голову к тому или иному материалу изложенному на Хабре.
В любом случае — буду рад прочесть и обсудить Вашу статью на тему SaltStack, — вполне возможно, что мне будет чему поучится.
Естественно, как мне кажется, каждый должен применять голову к тому или иному материалу изложенному на Хабре.
Согласен. И надеюсь, что все-таки мои комментарии будут служить не критикой вашего материала, а скорее дополнением.
Например в документации на SaltStack есть, на мой взгляд, большой пробел в том, что *_in параметры вводятся как дополнительные, не смотря на их семантику (видимо, это исторически обусловлено)… Также сложно сразу раскопать список всех стейтов с описанием.
Приведенный в этой статье подход прекрасно демонстрирует гибкость Salt, которая с лихвой окупает его недостатки. Также хотелось бы отметить вашу третью статью на эту тему, которая демонстрирует подход к управлению кластером.
От себя хочу сказать что имея опыт управления небольшим кластером серверов при помощи Puppet, сейчас внедряю в очередной проект Salt и не могу не нарадоваться его гибкости и удобству использования по сравнению с Puppet.
На тему Salt, наверное, сложно написать что-то большее чем уже существует. У меня скорее зреет мысль по поводу статьи о некоторых нетривиальных аспектах PHP, которые не всплывали из-за основного способа его использования, но становятся более актуальными в связи с переходом к более долгоживущим процессам. Надеюсь у меня получится оформить это в виде статьи. (:
Sign up to leave a comment.
SaltStack: управление произвольным количеством файлов конфигураций