Pull to refresh

Comments 10

Чем Ansible. А также чем Chef/Puppet/cfengine/пачка самописных скриптов. У каждого свои религиозные предпочтения. Главное — они делают свою работу.
Использую salt уже 3 года. На данный момент число машин (физических и виртуальных) превысило 7000. Сперва использовали стандартную конфигурацию с мастером и миньонами. Работало плохо, подвисали и мастера и миньоны. Перешли на salt-ssh. Стабильность сильно улучшилась, но, к сожалению, salt-ssh нелюбимое дитя saltstack и развивается по остаточному принципу. В процессе работы были обнаружены очень неприятные баги с race conditions. Зафайлил их на гитхабе, позже пофиксил локально через патчи, обновил issue на гитхабе, реакции нет.

Общие претензии к salt следующие:
1. Плохое тестирование, новые версии часто ломают обратную совместимость, каждое обновление до новой версии это боль.
2. Нет версионности для стейтов. Внес изменения, выкатил их, захотел откатить — и вот тут начинаются танцы с саблями, штатных средств нет.
3. Конкретно в salt-ssh очень сложна отладка.
4. salt не отслеживает, какие файлы он создал. Если вы создали файл в стейте, а в следующей версии этот файл должен отсутствовать вам надо добавить явную логику по удалению этого файла, salt не может этого сделать автоматически.
5. В общем и целом пользователи (разработчики) жалуются, что salt не удобен.
6. Код salt крайне сложен для понимания, использует очень много питоновской магии.

К сожалению мы увязли в salt достаточно глубоко, переключиться на что-то другое в данный момент невозможно. Если бы такая возможность была — я бы смотрел в сторону ansible.
А почему 3 года назад выбрали именно Salt? Чем руководствовались при выборе?
Это было не мое решение. До этого использовали chef. Chef не устраивал тем, что в нем не было нормальной push модели, а в salt она была.
мы выбрали несколько лет назад salt потмоу, что он уже тогда достаточно хорошо поддерживал windows на клиентах.

У нас, правда, не тысячи хостов (десятки, может будут сотни)
А какая-нибудь система умеет делать откат действий (пункты 2 и 4)? Уже несколько лет ищу решение, но не вижу, чтобы кто-нибудь над этим заморачивался кроме меня. Даже пытался сделать свой велосипед несколько лет назад, но безуспешно.)
Версионность есть в шефе (про остальные системы конфигурирования сказать не могу, не использовал) и в deb/rpm пакетах. Откатывать изменения умеет apt и yum (можно установить предыдующую версию пакета). Лично я все свои сервисы оформляю пакетами. К сожалению построение пакетов для многих разработчиков сильно сложнее, чем написание salt state-ов, даже не смотря на наличие такого инструмента, как fpm.
Какие преимущества перед тем же Ansible?
Правильно ли я понимаю если мастер сервер по какой-либо причине поменялся то реконфигурировать весь зоопарк миньонов нужно будет руками?
> Чем хуже/лучше Ansible?
Чем SaltStack лучше Ansible

Есть мнение что SaltStack лучше массштабируется чем Ansible.
Субьективно легче писать расширенную логику для SaltStack.

Чем Ansible лучше SaltStack-а… Мне нравится поддержка Red Hat за спиной у Ansible, и опять же субьективно, Ansible имеет меньше багов чем SaltStack сейчас.
Еще нравятся модули Ansible для управления сетевым оборудованием.

А в чем то похожи. Python, YAML, JINJA.

Ansible по умолчанию ориентирован на client-less подход.
SaltStack по умолчанию ориентирован на установку клиента.

Думаю это неплохой критерий выбора.
Решить какой подход вам нужен в обозримом будущем, и взять подходящую систему.
Sign up to leave a comment.

Articles