Я взял Ansible потому что ему не нужны агенты (нет наркомании с какими-то там сертификатами как в puppet), потому что на python и развивается. Не пожалел.

Все перечисленное - написано программистами для программистов. Ни админам ни девопсам это не подходит.

К то му же лишнии зависимости - python (ansible, salt) ruby (puppet, Chef)

IMHO Не нужно это.

Ansible

это и + и -

Ну снес ты ключи случайно, и вуаля.

Все перечисленное - написано программистами для программистов. Ни админам

Бред. Если ты не админ, то они тебе не подходят.

Только начинаю разбираться, и пытаюсь сделать выбор.

1. Определи список задач, которые тебе надо сделать.
2. Пробуй. Потрать на них время, решая эти задачи.
3. На выбор во много повлияет то, что тебе надо.

Для своего небольшого вычислительного кластера я выбрал Ansible, т.к. нет лишнего сервиса, а ситуации по изменению конфигурации появляются очень редко (так что легче ручками набрать пару команд для применения изменений). Если реально 100+ хостов и изменения в настройке требуются часто, то возможно Puppet/... будет лучше.

Как земля

Пробовал Puppet. До сих пор помню этот вкус говна на зубах. Долго пытался убедить себя, что он не говно, просто надо распробовать и научиться его готовить. Ведь все же им пользуются, энтерпрайз и т. д. Потом наконец выкинул гавёху, вымыл руки и перешёл на ansible. Сейчас пишу книгу: «Puppet, или лёгкий способ бесплатно поесть говна, а потом перейти на ansible».

пока читал твоё сообщение, кушал сникерс...

Пробуй. Потрать на них время, решая эти задачи.

честно скажу и лень и время на это жалко) хочу почитать, что уже сделал. Узнать кто чем пользуется и почему
и дальше самому

Я для себя выбрал salt. Причина: не ruby.

Я взял Ansible потому что ему не нужны агенты (нет наркомании с какими-то там сертификатами как в puppet), потому что на python и развивается. Не пожалел.

salt тоже с недавнего времени научился работать без агентов.

2) можно ли сказать, что Ansible, Salt это «замена» более сложных puppet и chef?

и питон по дефолту практически везде есть. и стэйты писать гораздо проще. и cmd.run шикарная штука

В ансибль я не тыкал, но думаю, что salt-ssh это что-то похожее. Мне удобнее оказалось расставить агентов.

Паппет, до его выпиливания периодически делал 100% загрузку одного из ядер, применяя конфиг. И да, руби тащить в систему из-за сраного CM не комильфо.

Ничего себе случайно... Ну раз такое возможно то ключик можно записать на флешку и убрать в сейф.

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

+1 к Ansible

IMHO в данный момент нет ничего лучше.

Бред.

В каком месте ?

Если ты не админ, то они тебе не подходят.

Рецепты писать меня не прёт.

Лорчую, чё там писать? Хуяк, хуяк, и в продакшон.

Я совсем недавно стал разбираться именно с Ansible. Перед ним пробовал puppet и офигел с того, как много всего там. Поэтому думаю для новичка (меня) Ansible отличное начало для знакомства с SCM.

Просто оставлю это здесь: (R)ex

Используем ansible, полет нормальный. Особенно годно если питон знаешь.

Поэтому думаю для новичка (меня) Ansible отличное начало для знакомства с SCM.

Это я не знаю, что такое SCM или вы? Сначала мне показалось, что вы так шутите..

+ в копилку ансибла. Умеет всё, что нужно. Работает быстро, поправить плейбуки - дело 5 минут. И куча уже готовых плейбуков доступно на гитхабе и т.п. ресурсах. Также прекрасно работает с любой контрольной машины (мак, вин). Плюс развивается и упрощается быстро. Недавно вышла вторая версия, а уже клепают новые минорные пакеты.

Я взял Ansible потому что ему не нужны агенты (нет наркомании с какими-то там сертификатами как в puppet), потому что на python и развивается. Не пожалел.

Солидарен целиком.

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

Все перечисленное - написано программистами для программистов. Ни админам ни девопсам это не подходит.

Да ладно, чудак. Тебе хоть раз приходилось админить больше сотни хостов или ВМ?

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

carter, я внедряю puppet. Делал выбор. Выбрал puppet. Больше, монструознее. Кросплатформенен.

ansible, и если возможно, лучше сразу с двойки начинать

ansible

Я для себя выбрал salt когда, похоже, ansible толком и не было. Расскажите доступно, чем ansible круче?

EDIT: блин, тогда и salt толком не было =(

у него есть веб-ка?

Вебинтерфейс? Есть, но платный (бесплатно до 10 машин). Но я, честно говоря, не осилил его запуск - там нужны какие-то руби и прочая белиберда, плюс это все работает на определенных версиях бубунты и рхела, в общем даже разбираться желания не было. По своему опыту могу сказать что он не нужен, весь нужный для веба функционал запиливается в пол пинка коллбэками (там считай чистый python), а для запуска тасков можно взять хоть тот же rundeck. А, да, еще что сильно не понравилось - задачки из вебморды в ps и прочих видны не будут, для меня это жирный минус.

есть tower, он пока закрытый, бесплатно до 10 управляемых хостов, емнип. есть semaphore - на гитхабе. Ну а вообще, это набор простых yaml и j2, которые пишутся руками, и их запуск можно контролировать ъем угодно, от простых скриптов до rundeck, jenkins и т.п.

ansible

ансибл вкусен своей простотой, порог вхождения для опытного админа вообще без опыта в CMS и DSL нулевой, в отлиъии от остальных. Мне кажется его написали ориентируясь именно на простоту в первую очередь

У меня ~300 пк, половина за провайдерским натом или без статики, по всей стране раскиданы, linux+винда, использую puppet 3.х + foreman (причем всего 1 сервер на виртуалке пока что) пока что всё почти отлично, всё что хочу сделать - делает. Проблем очень мало, в основном это русская кодировка (если скормить в манифесте) и неправильно сформированные пакеты chocolatey. На много операций в винде с екзешниками и скриптами ps1/bat руби выпадает в осадок, после несколько запусков агента всё ок становиться, что интересно в win10 всё отлично. Очень много всего можно писать прямо в манифестах, а не в отдельных скриптах. Можно вполне удобно делать разные группы по назначению и можно прикручивать очень много инструментов.

Все перечисленное - написано программистами для программистов. Ни админам ни девопсам это не подходит.

this. Всё это гуано. Но из всего этого anisble воняет меньше других.

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

Fun fact.

У нашего самого главного тех-лида новая шиза. Всё должно быть в anisble. Воспроизводимость, документация и прочее — всё это понять можно. Но... все эти системы автоматизации хороши, если у тебя 1000 одинаковых хостов. Когда же их только 100, но все они разные, хорошая идея превращается в ад.

Приходится вечно бороться с системой. (А ansible это ещё та какашка!) И одновременно смотреть, что бы не поломать всё к чертям. Т.о. настройка нового хоста, это уже не пол-часа, а полный рабочий день. (Что то пошло не так? Жди 10 минут, пока playbook не отиграет и ошибку не выплюнет.)

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

Соддом и Гомора.

Когда же их только 100, но все они разные, хорошая идея превращается в ад.

Что-то я не могу придумать задач, в которых управление такими хостами без оркестратора вообще было бы возможно (ну ОК, осуществимо обычными силами среднестатистического админа). Можешь привести пример? Я просто к тому что чуть с ума не сошел когда приходилось управлять всего лишь парой десятков конфигов на тридцати хостах (при этом в хостоспецифичные части в конфигах были, но не сильно много), после чего и начал искать что-то для управления и в итоге остановился на Ansible. Как без Ansible (ну или аналога) управлять зоопарком из 100 разных машин я вообще не представляю.

Когда же их только 100, но все они разные

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

Скажем так, мне, как старпёру, проще сделать slogin host вместо cd ~/git/ansible/host/role/whatever; vi main.yml; ansible-play whatever; git commit -a.

Апдейты через ansible заливать — нет, спасибо. Всё равно ручками надо ходить и смотреть, что бы ничто не поломалось.

Первичная же конфигурация у хостов уже есть. То тут чуть-чуть поправить, там чуть-чуть поправить — сложность O(1).

С использованием аркестрации сложность же становится сразу O(n!), т.к. при 100 уникальных хостов приходится тут же и смотреть, что бы ничто не сломать одним махом <RETURN>.

В итоге использование ansible сводится к первичной конфигурации хоста. (В принципе тоже, что можно было бы сделать и dpkg --get-selections). Дальше ценность его резко падает.

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

В итоге использование ansible сводится к первичной конфигурации хоста.

Я не согласен вот с этим - прекрасно использую Ansible для поддержания и управлением существующими хостами. Хотя да, из официальной документации и best practice видно что используют его как раз таки для «развернуть определенное ПО на виртуалках амазона и пользоваться».

У меня нет сценариев, завязанных на хосты (вот те же роли как раз таки и завязываются на хосты, хотя тоже не сильно, тоже больше компонентый подход, но с учетом того что все хосты с определенным компонентом сконфигурированы одинаково) - у меня идет привязка именно к «компонентам». Есть компонент (ну или абстракция) «конфиги» - есть сценарий который работает с файлами - он может копировать готовые файлы и работать с шаблонами, выставлять права, проверять существования файлов, проверять ссылки и так далее. Объединив это с vcs получаем «тулзу», которая сможет в случае факапа сконфигурировать любой хост, сможет проверять валидность конфигов на серверах и в то же время у нас есть бэкап конфигурации, история изменений и прочие плюшки. Другой компонент - скажем это «приложения» - сценарий для того чтоб этими приложениями управлять - включать\выключать, проверять состояние и я даже не знаю что тут еще можно придумать. В обоих «абстракциях» сценарии к хостам никак не привязаны, просто в первом случае мы берем список файлов из inventory, во втором - команды для запуска и остановки приложений и так далее из того же inventory. В итоге через некоторое время использования таких скриптов просто забываешь где у тебя там что на хосте лежит и как управляется - надо внести правки в конфиг - закоммитил в vcs и запустил сценарий, откатиться - опять же это пара команд в vcs и запуск сценария. Надо погасить всю среду или часть - запустил другой сценарий, запустить - опять этот же сценарий но с другим тэгом, и при всем при этом ты не паришься что у тебя на хостах 1 и 2 стоят nginx и апач и управляются инитскриптами, на хосте 3 крутится бд с управлением через systemd а на 4 хосте вообще скрипт на питоне, которые останавливается через pkill -9 myscript.py. Надо поправить сам список команд или файлов - правишь только нужный инвентарь.

А от проверки «руками» (или какими-то автоматизированными средствами) ты не уйдешь в любом случае - не важно, доставляешь ли ты изменения руками или делаешь правки на месте, или же используешь оркестратор.

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

У меня ситуация, что все хосты уникальны, но «линия партии» требует централизации.

Идея разбивать по nginx → {hostA, hostB, hostC} вместо hostA → {nginx, postgres, django} интересна. Надо будет подумать.

Но опять таки проблема, что у каждого хоста конфиг nginx уникален. Как их смести под общую гребёнку? Выходит или ужасный template или куча гемороя.

100 хостов и все разные? Подозреваю что у вас или совсем корявый легаси или просто плохо все было распланировано. У меня совершенно разных ролей набирается пара десятков, не более, остальные все легко стандартизовать, где ансибл как раз спасает.

а вообще, я работал в одном стартапе где они свихнулись на agile, вот это был ад. двухнедельные спринты, в которых можно было напороться на пятиминутный таск с поправлением конфига или скрипта, и две недели ничего не делать, или наоборот. Плюс по полдня на идиотские телеконференции и planning-poker и дурные разборки со скраммастером.

Легаси много, очень много. Так много, что я даже со squeeze толком спрыгнуть не могу. (Всё разлетится к чертям из-за dependency hell — нужных весий пакетов уже нет.)

Но опять таки проблема, что у каждого хоста конфиг nginx уникален. Как их смести под общую гребёнку? Выходит или ужасный template или куча гемороя.

уникален или просто привязан к имени хоста, адресу и т.п.? Если так то можно просто писать с привязкой к ansible_facts

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

Именно, что уникален. Например со своим legacy набором rewrite (т.к. схему урлов меняли пару раз, а backward compatibilty нужна).

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

Я тоже постепенно в этом направлении. Надо только дать себе самому огромного пинка. ;)

В общем, надоело за девов (большая половина которых уже уволилась, или у них нет времени или рессурсов обновить свою поделку) подставлять жопу.