LINUX.ORG.RU

Какую систему управления конфигурациями вы используете?

 , , , ,


0

2

Аналогичный опрос проводился в 2013 году. Прошло 4 года, многое изменилось.

  1. Не использую 360 (60%)

    ********************************************************************************************************************************************************************************************************************************************************************************************************************************

  2. Ansible 166 (28%)

    ***************************************************************************************************************************************************

  3. Puppet 53 (9%)

    ***********************************************

  4. Chef 27 (5%)

    ************************

  5. Salt 26 (4%)

    ***********************

  6. Другое 23 (4%)

    ********************

  7. Capistrano 11 (2%)

    *********

  8. NOC 5 (1%)

    ****

  9. CFEngine 4 (1%)

    ***

  10. Rex 4 (1%)

    ***

  11. Spacewalk 3 (1%)

    **

  12. Juju 2 (0%)

    *

  13. Quattor 1 (0%)

  14. Bcfg2 1 (0%)

  15. Rudder 0 (0%)

Всего голосов: 686, всего проголосовавших: 598

★★★

Проверено: Licwin ()
Последнее исправление: JB (всего исправлений: 1)

Поправка к опросу ...

Puppet есть бесплатный и есть платная версия. Может имеет смысл разделить пункт?

ApB
()

NOC это что за зверь?

lv77 ★★★
()

А где git в вариантах?

Tanger ★★★★★
()

шеф юзали когда надо было

upcFrost ★★★★★
()

Сейчас никакую, использовал Puppet.

exst ★★★★
()

Знаю, что в нашей конторе опсы используют ansible и puppet.

Miguel ★★★★★
()

Долго пытался привыкнуть к ансиблю, так и не привык. Проще использовать велосипед из шелл-скриптов и parallel-ssh.

lizard ★★★
()

Забавно, что в вакансиях чаще встречается шеф, а здесь папет в фаворе.

По сабжу: папет для подготовки серверов, деплой и настройка приложений через fabric (вернее нечто, что в своей основе использует fabric). Есть некоторое количество хостов под ansible.

leave ★★★★★
()

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

sT331h0rs3 ★★★★★
()

На локалхосте, где доп. логика не нужна и только статичные файлы - дотфайлы на гитхабе, большего не нужно. На проекте только ansible.

bytecode ★★
()
Последнее исправление: bytecode (всего исправлений: 1)

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

// По роду деятельности к девопсу я имею достаточно посредственное отношение

sphericalhorse ★★★★★
()

Ansible для создания образов виртуалок, CFEngine3 для управления запущенными виртуалками.

MrKooll ★★★
()

пощупал puppet и ansible, удобнее показался ansible, хотя у меня была связка из этих струментов, один дёргал другой на определённом этапе, больше пришлось работать с ansible, но т.к. не знаю python - pep8 накаляет. в целом «СУК» - системы управления конфигурациями, lol, круты

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

Больше подходит дефолтная архитектура, меньше велосипедов заставляют использовать, много готовых playbook'ов, сам проект поживее.

В итоге у Ansible чуть больше плюсов, а главные минусы у них обоих одинаковые.

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

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

Самый гибкий и удобный инструмент из систем управления конфигурациями.

я только не смог разобраться как у него делать зависимости - ставит пакет, а репы еще не настроил, везде пишут что он не умеет в порядок. в salt это легко и работает.

prizident ★★★★★
()

Пользуясь моментом, хочу узнать, есть ли у кого-нибудь истории (не)успеха в переезде с puppet на saltstack?

tiandrey ★★★★★
()
Последнее исправление: tiandrey (всего исправлений: 1)

Я одно не понимаю, почему Ansible более популярен, чем Salt Stack. Если с долей Chef, Puppet и CFEngine все более-менее понятно. По идеи Salt Stack должен был отправить всех тех, кроме тех кто пользуется всяким legacy(или вынужден поддерживать) на покой. Или ansible популярен из-за IoT и ботнетов?

anonymous_sama ★★★★★
()

без системы управления конфигурациями

dormeur86 ★★★★
()

Использую Puppet, впринципе все устраивает, разве что синтаксис деревянный и иногда такой штуки не хватает чтобы прям на bash можно было писать куски кода. А что за Ansible такой? Чем он так крут

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

Я один не понимаю, почему Ansible / Salt Stack / Chef / Puppet / CFEngine более популярны, чем NixOS? Ибо те тулзы, которые притворяются декларативными, а по факту тупо императивно меняют состояние системы прямо во время её работы - так жить нельзя. Во-первых, можно забыть о воспроизводимости. Все уже привыкли, что старая конфигурация работает со старым сервером, а при попытке накатить её на новую чистую маширу всё ломается. Особенно радует, когда старый сервер помре и надо срочно поднять замену. Во-вторых, менять живой сервер во время работы - это как менять двигатель во время полёта. Опечатался в конфиге - сервак пошёл в даун. Об атомарных изменениях и откатах тоже можно забыть. Ну разве что у вас btrfs на продакшоне. В-третьих, ни одна из этих «SCM» не способна управлять конфигурацией *всей* системы. Конфиг всегда описывает только подмножество конфигурации, с остальным пердольтесь как хотите. И первоначальная установка системы тоже за рамками. Растёт ещё одна груда говнокостылей типа Cobbler / Foreman / MaaS / Razor / Crowbar и ещё тысячи их. Классический симптом того, что ни одна тулза не решает проблему полностью. «Нед, мы просто напишем свою стопервую систему провизионирования, и проблема будет наконец-то решетна», ёпт.

Как это работает в NixOS. Во-первых, в NixOS управление конфигурацией ОС интегрировано прямо в ОС, а не прикручено сбоку проволокой. Один и тот же Nix используется и для сборки системных пакетов, и для пользовательских конфигураций. Конфиг описывает состояние всей ОС целиком, включая параметры ядра и бутлоадер. Ну кроме пользовательских данных, типа всяких БД - их Nix не затрагивает. При каждом обновлении конфигурации ВСЯ система пересобирается полностью с нуля. Происходит это в отдельном каталоге, старая система никак не затрагивается. После успешной сборки можно переключиться со старой системы на новую практически атомарно. Можно откатиться на старую систему. Сборка всей системы с нуля происходит быстрее, чем накатывание изменений на существующую систему через какой-нибудь Ansible, потому что промежуточные результаты кэшируются и используются повторно. А собираемые образы системы очень легковесны и содержат в основном симлинки на пакеты в локальном пакетохранилище. Билды полностью воспроизводимые, поэтому кэширование работает так, как надо. Есть кэш cache.nixos.org, поддерживаемый мейнтейнерами, чтоб не компилять все пакеты локально. При пересборке учитываются зависимости - если изменить некую библиотеку, при обновлении системы пересоберётся всё, что от неё зависит. (В отличие от докера, где при изменении базового слоя пересоберётся тупо фсио, а воспроизводимость всё равно хромает.) Воспроизводимые билды означают, что если сборка прошла однажды, она пройдёт всегда. Можно скопировать старый конфиг на новый пустой сервер, и он гарантированно заведётся и даст абсолютно тот же результат. С Ansible и Chef о таком только мечтать. Есть распределённая сборка искаропки, есть NixOps для автоматического развёртывания виртуалок с заданной конфигурацией, есть DisNix для оркестрации - всё глубоко интегрировано, а не прикручено изолентой. Как может психически здоровый человек предпочитать этому Ansible или Chef - для меня загадка. Похоже, привыкли пользоваться всяким полурабочим говном, а когда инструмент слишком хорош - это вызывает когнитивный диссонанс и экзистенциальную панику.

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

Ты один не понимаешь.

SaltStack - это master-minion, так что чтобы банально забутстрапить его нужно написать ansible playbook.

Система state-pillars сделана не для людей, и все пользователи salt так или иначе вынуждены изобрести себе концепцию ролей.

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

Кроме всего прочего salt парсит конфиги на слейве а не на мастере, поэтому результат зависит от версии salt-minion а не версии мастера.

Плюс детские болезни с невозможностью правильно распаковать архив, если он изменился, кривой debug-вывод с мастера и т.п.

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

Хз, лично для меня ансибле удобен тем что ни ставля ничего на клиенты я сразу рулю и линух и офтоповиком.

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

Для меня наличие мастера, одна из самых удобных фич. Можно управлять всем из одного места.

SaltStack - это master-minion, так что чтобы банально забутстрапить его нужно написать ansible playbook.

Salt можно разворачивать с помощью самого Salt. В документации про это есть. Потом есть salt ssh.

Кроме всего прочего salt парсит конфиги на слейве а не на мастере, поэтому результат зависит от версии salt-minion а не версии мастера.

Это только если версии отличаются. Но в любом случае даже если они отличаются, то достаточно только, чтобы на мастере стояла версия выше.

Система state-pillars сделана не для людей, и все пользователи salt так или иначе вынуждены изобрести себе концепцию ролей.

Тут согласен, она просто сделана для суперлюдей. А вот grains это круто.

HeipaVai1o

Я один не понимаю, почему Ansible / Salt Stack / Chef / Puppet / CFEngine более популярны, чем NixOS

Потому-что привязана к одному вендору (дистрибутиву), потому-что там надо что-то компилять, и пусть что-то ускоряется, но 21-й век ведь! Потом реально пользовались этой NixOS «1,5 анонимуса».

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

Для меня наличие мастера, одна из самых удобных фич. Можно управлять всем из одного места.

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

При этом сделать bastion-хост для ansible так же не проблема.

Так что «фичи» все на месте, а гибкость на порядок выше.

то достаточно только, чтобы на мастере стояла версия выше.

для чего достаточно? Чтобы что-то запустилось - достаточно, да, но поведение у разных версий salt-minion разное. И внезапно у одного minion pillar может смерджиться полностью, а у второго частично, потому что параметр, определяющий порядок merge и заданный на мастере обрабатывается на minion по-разному. И ты об этом никогда не узнаешь, даже warning никакого не будет.

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

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

Зависимости чего? Какой пакет? Какие именно репы?

Шеф делает ровно то, что ты ему скажешь, и ровно таким способом, как ты скажешь.

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

Видимо имелось в виду подключить репо и поставить из него пакеты.

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

NixOS

Потому-что привязана к одному вендору (дистрибутиву)

Другие дистрибутивы не нужны. :)

потому-что там надо что-то компилять, и пусть что-то ускоряется, но 21-й век ведь!

Пакеты из официального репозитория компилять не надо, они качаются с cache.nixos.org в виде готовых бинарников. Как в классических дистрибутивах. Компилять надо лишь то, чего в дистрибутиве нет. Как и с Ansible / Salt / whatever. Можно поднять свой кэш с бинарными пакетами и обновлять его его автоматически при git push. Сам NixOS так и обновляется.

Потом реально пользовались этой NixOS «1,5 анонимуса».

Это самые продвинутые же. Года через три и до остальных дойдёт. :3

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

один кукбук настраивает репы, второй ставит из этого репа пакет. в этот момент возникает зависимость. Шеф выполняет кукбуки в рандомном порядке (или же непонятном), в итоге я не смог сделать так чтобы репы всегда настраивались до установки пакетов, он упорно первым степом пытался установить пакеты и фейлился естественно.

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

Шеф выполняет кукбуки в рандомном порядке (или же непонятном)

Это не верно. Почитать стоит тут: https://docs.chef.io/run_lists.html

A run-list is:
An ordered list of roles and/or recipes that are run in the exact order defined in the run-list;

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

При этом сделать bastion-хост для ansible так же не проблема.

А без SSH на хостах bastion-хост может подключаться к хостам? Вообще какая-нибудь система агентов есть с Ansible?

никакой предварительной конфигурации

Нужен SSH, который зачастую не нужен. Потом разве это миф что Ansible тормозной?

но поведение у разных версий salt-minion разное

Да, но иметь одну версию не проблема, а более новой версии на мастере достаточно, чтобы с него обновить minion'ов.

anonymous_sama ★★★★★
()

к конторе используют ansible, пришлось учить его.

Novell-ch ★★★★★
()
Ответ на: комментарий от anonymous_sama

Потом разве это миф что Ansible тормозной?

Да, но какое это имеет значение?

P.S. В прошлой конторе использовался puppet, на новой работе выбрал ansible. Потому что он простой как полено и количество сюрпризов с ним минимальное.

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

Дай что ли пару примеров, когда у тебя ssh не нужен, а установка salt-minion нужной версии, конфигурация его с параметрами конкретного salt-master и подпись его ключа при этом нужны.

Потому что обратную ситуацию представить легко: при ограниченном ssh-доступе ansible спокойно может работать без прав рута выполняя задачи на уровне пользователя.

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

Есть LXD контейнеры, и SSH для большинства из них, мне не нужен. При этом salt-minion у меня уже установлен в образе контейнера. Так как контейнер может быть перенесен, то мне недостаточно только иметь доступ или выполнять команды c LXD-хоста, потом это менее удобно, чем выполнять команды напрямую в контейнере, а тем более сразу в нескольких контейнерах. SSH обычно чаще всего нужен, только когда нужно перенаправить порт в локалхост и удобно работать с БД (и такие контейнеры переносятся редко, и для них созданы отдельные правила iptables, чтобы можно было к ним подключиться по SSH)

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

Есть LXD контейнеры, и SSH для большинства из них, мне не нужен. При этом salt-minion у меня уже установлен в образе контейнера

Я не понимаю в чем в данном случае принципиальная разница. Для управления контейнером нужнен демон висящий на порту, который будет установлен в контейнере. Какая разница ssh это или агент?

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

Для SSH тебе нужен доступ к SSH. Для salt-minion тебе нужен только доступ до мастера. Потом гораздо удобнее выполнять команды сразу на нескольких контейнерах и использовать свои готовые рецепты. Если ты перенесешь контейнер с SSH, то не факт, что ты потом до него достучишься, без каких-либо правок.

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

около года пользовался на работе Ansible / Salt Stack /Fabric, около года пользуюсь NixOS на другой работе. Ощущения аналогичные!

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