RedHat приобретает систему управления конфигурацией Ansible

Вот тут не знаю - там в последней стабильной ветке \n не всегда нормально обрабатывается (при том что эта проблема минимум с 1.7, но там какая-то сложная логика), чего уж говорить о цветах.

Я вот думал им патч написать на это дело. Но я пока не уверен, что буду использовать Ansible.

Ну ты же какой-то логикой руководствуешься когда выполняешь «условно-автоматизируемые задачи» - пропиши ее в сценариях.

Я просто хочу посмотреть, что там ставиться-то будет.

Если это не возможно - пересмотри сам процесс, например прогоняй действие на тестовой машине и если все ок - тиражий на «продуктив», или (как в случае с emerge) напиши список (или передавай его при запуске) пакетов, которые надо искать в списке кандидатов на обновление (или как там у вас это зовется), если пакеты из твоего «особого» списка планируют обновиться, значит прерываем процесс, тебе шлем сообщение с информацией об этом и так далее. В общем, если ты можешь какую-то логику найти в своих решения, то ты можешь описать это в сценариях. Если нет - возможно тогда стоит отказаться от использования какого-либо оркестратора\средства автоматизации.

Штука в том, что Portage позволяет мне по NFS раздать желаемую конфигурацию установленных пакетов (/usr/portage/my-custom-repo) и флагов. Но это только базовые пакеты. Конфигурация специфичных для каждого хоста пакетов задается локально (/etc/portage) для этого хоста, но я хочу положить это в git и пихать чем-то на хосты (предполагается, что ansible). На этом мои мучения должны были кончится, но обновлять системы руками мне надоело. Я вот хотел как раз и прикрутить что-то готовое, чтобы оно показывало мне список обновлений, я соглашался, а дальше запускался процесс сбора / обновления ядра / сборки initrd и рестарта демонов по вкусу.

Планы запихнуть изделие в системД имеются?

Я вот думал им патч написать на это дело.

Так там придется здорово переворошить весь этот модуль, который отвечает за вывод информации, и не факт что это примут.

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

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

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

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

Должен или нет - зависит от перспективы.

Я не могу дернуть emerge --ask ...

Попробуй дёргать emerge --pretend ..., и если всё устраивает, то просто emerge ...

Нет интерактивного выполнения.

На тысячах хостов интерактивное выполнение? Ты упрлся?

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

И как в таком случае добиться консистентности в сети?

На тысячах хостов интерактивное выполнение? Ты упрлся?

О какой тысяче ты говоришь? У меня их дюжина.

Попробуй дёргать emerge --pretend ..., и если всё устраивает, то просто emerge ...

Да, в случае с emerge я так и делаю. Хотя отсутствие цветов выглядит забавно. В 2015-то году.

В LPIC есть главы по bash

В LPIC есть главы по bash

Странно было бы, если бы их там не было. И странно было бы, если бы по bash была отдельная сертификация. Ansible это просто инструмент, также как и bash. А сертификация проводится всегда по системе, в которой используются те или иные технологии и инструменты. Но никак не по отдельным инструментам.

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

Можно поныть? Спасибо :) В один проект приходишь - Puppet, в другой - Шеф, в третий Git + костыли, в четвертый Salt (пока мой фаворит). Ansible, конечно, маленько попроще, чем тот-же Шеф или Кукольщик. Но!.. чем старше и больше инфраструктура, тем меньше народу, который шарит, как это работает. В итоге сидит такой аксакал, который только он, в единственом экземпляре, может править скрипты. А после того, как он уходит, начинается плачь Ярославны. Ведь в каждом своя «изюминка», в которой без ящика крепкого алкоголя не разобраться. Каждый изобретает с нуля как внедрить ту или иную систему с нуля. Порог вхождения «ух»! То-же можно и о системах мониторинга сказать - Nagios, Icinga, Icinga2, Zabbix, TSM (свят-свят!), да еще куча всего - страницы, наверное не хватит. Хочу общих стандартов с внятной документацией и дружелюбных к пользователям-админам, которые, чего уж говорить, не все академики.

Усе, пар выпустил. Пошел конфигурировать manage-now -еще одну богомерзкую систему мониторинга, которую знают полтора человека на всей Земле.

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

У меня почти вся дюжина машин разная. Что мне делать, дергать tmux ssh каждый раз?

Уф... Если заменить вывод emerge на вывод apt получается примерно та же самая история. Или ты обновляешься не глядя?

Блджад, ты задрал. Возьми fabric и иди плачь в другом месте.

Why so butthurt?

Уф... Если заменить вывод emerge на вывод apt получается примерно та же самая история. Или ты обновляешься не глядя?

Какая такая история? У всех здоровых людей на дебиане включены unattended upgrades. А юзающие генту с рачиком на серверах должны страдать.

Смысл ansible обновить тысячи одинаковых хостов, без каких-либо вопросов. Чтобы это произошло обновление обкатывается на одном тестовом сервере и потом запускается на продакшен. Если ты привык, что у тебя каждый сервер это уникальное творение имени тебя, то ansible тебе не нужен. Автоматизация это когда нажал кнопку и оно отработало.

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

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

P.S. Нет, я правда не знаю, как можно сформулировать ещё проще.

У меня почти вся дюжина машин разная.

Значит, инструменты для devops тебе не подходят, либо ты должен их использовать только для тех задач, которые на всех машинах выполняются 100% одинаково

Значит, инструменты для devops тебе не подходят, либо ты должен их использовать только для тех задач, которые на всех машинах выполняются 100% одинаково

Господи, я просто хочу конфигурацию на серверы из git пушить, сервисы после этого перезапускать и обновляться. Серьезно? Даже здесь тулзы из 80-х оказываются более полезными?

Даже здесь тулзы из 80-х оказываются более полезными?

Если каждый сервер имеет индивидуальные особенности (aka «snowflake server»), то да, и это вполне естественно. Старое != плохое

Каждый сервер выполняет свою задачу. Они разные.

Как тебе тут уже написали, ansible и devops инструменты нужны для одинаковых серверов, а не для разных. Или для задач, которые 100% выполняются на необходимых серверах одинаково. Например, мне нужно обновить tzdata на проекте, я делаю один playbook для всех своих серверов, потому что там не может быть разночтений. Пришел, увидел, победил. Если мне нужно обновить бекенд, я делаю playbook только для бекендов, которые различаются между собой ip-шниками и хостнеймами, но не более. Все остальные кейсы можно делать индивидуально для каждого сервера, либо все делать руками через ssh. Ты точно понимаешь, чего ты хочешь?

Как тебе тут уже написали, ansible и devops инструменты нужны для одинаковых серверов, а не для разных.

Что такое DevOps инструменты? Просто любопытно.

Или для задач, которые 100% выполняются на необходимых серверах одинаково. Например, мне нужно обновить tzdata на проекте, я делаю один playbook для всех своих серверов, потому что там не может быть разночтений. Пришел, увидел, победил.

Да, я делаю то же самое для своих серверов. Потому что они не на 100% различны.

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

Да, я хочу, чтобы придуманные ещё в 70-х методы работы с вводом-выводом поддерживались в 21 веке. Серьезно, я даже против prompt'ов ansible ничего против не имею. Уж вывод-то можно передать как есть, зачем его в json траснформировать?

У меня складывается впечатление, что современные программисты какие-то полярные. Если автоматизация - то такая, что про интерактивность в нужных случаях можно даже не думать. Я не очень понимаю выгоду такого подхода.

Что такое DevOps инструменты?

chef, puppet, ansible, docker, python и т.д.

Да, я делаю то же самое для своих серверов.

Но при этом ты хочешь отвечать каждый раз на одни и те же вопросы во время установки? Или все же там есть ньюансы в зависимости от сервера?

Уж вывод-то можно передать как есть, зачем его в json траснформировать?

Потому что задуман он не для ad-hoc использования, а для автоматического. Чтобы json мог парсить какой-нибудь веб-интерфейс или другая управлялка. Режим ad-hoc есть, но он довольно ущербный, возможно из него и правда когда-нибудь сделают универсальную штуку для пробежек по серверам. Было бы интересно.

Я не очень понимаю выгоду такого подхода.

Выгода в keep it simple, ты автоматизируешь разные маленькие задачи и собираешь потом из них что-то большое. И в этом большом потом можно легко разобраться, как если бы ты все свои шаги записывал в вики, например. А не судорожно вспоминать, как и с какими флагами ты собирал кастомный nginx для мелкой задачи.

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

Но при этом ты хочешь отвечать каждый раз на одни и те же вопросы во время установки? Или все же там есть ньюансы в зависимости от сервера?

Ты, похоже, невнимательно читаешь. Я хочу автоматизировать всё, что можно. Изменение tzdata, например. Это не требует моего участия, ansible без меня справится. А вот update'ы я хочу контролировать.

Потому что задуман он не для ad-hoc использования, а для автоматического. Чтобы json мог парсить какой-нибудь веб-интерфейс или другая управлялка. Режим ad-hoc есть, но он довольно ущербный, возможно из него и правда когда-нибудь сделают универсальную штуку для пробежек по серверам. Было бы интересно.

Ну уж опцию-то можно было сделать, ей богу.

Выгода в keep it simple, ты автоматизируешь разные маленькие задачи и собираешь потом из них что-то большое.

Да, я так и делаю.

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

Мои флаги записаны в git. Я хочу проверить, что ничего не упустил и java опять не потащит мне иксы с ALSA на сервер.

когда ждать ansibled?

Это не требует моего участия, ansible без меня справится. А вот update'ы я хочу контролировать.

Тут либо не требует твоего участия, либо ты это контролируешь. Почему нельзя это разделить на две задачи, например? Либо можно сделать стоп, если что-то пошло не так как ты хотел.

Ну уж опцию-то можно было сделать, ей богу.

Опенсурс, тащемта, хочешь сам сделай, хочешь фичареквест напиши в трекер.

Я хочу проверить, что ничего не упустил и java опять не потащит мне иксы с ALSA на сервер.

Опять же проблемы сурс-лайк систем. А решается либо обкаткой на тестовом сервере, либо руками, если это единичный сервер. Нельзя автоматизировать то, что делается руками. Не понятно чего ты хочешь от ansible в таком случае.

Красиво это можно автоматизировать контейнерами. Работает java в контейнере, запускаешь обновление в новом, если собрался, происходит замена, не собрался смотрим что не так.

через puppet + foreman

Так то ж puppet. А то spacewalk.

чего конкретно не хватало?

Здешняя проблема в том, что среднее количество хостов со сколько-нибудь похожей конфигурацией - чуть меньше 2х, и живут они подолгу. Т.ч. сильные стороны spacewalk-а дают лишь небольшой выигрыш, а слабые кусаются вовсю.

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

Может, конечно, я так и не научился его готовить.

Тут либо не требует твоего участия, либо ты это контролируешь. Почему нельзя это разделить на две задачи, например? Либо можно сделать стоп, если что-то пошло не так как ты хотел.

Одна задача требует, другая нет. Откуда либо-то взялось? Это вообще в разных playbook'ах может быть.

Опенсурс, тащемта, хочешь сам сделай, хочешь фичареквест напиши в трекер.

Похоже придется патч делать, да.

Опять же проблемы сурс-лайк систем. А решается либо обкаткой на тестовом сервере, либо руками, если это единичный сервер. Нельзя автоматизировать то, что делается руками. Не понятно чего ты хочешь от ansible в таком случае.

Я хочу, чтобы он меня спросил об этом. Prompt'ы же сделали. Вот их я, пожалуй, и возьму.

Красиво это можно автоматизировать контейнерами. Работает java в контейнере, запускаешь обновление в новом, если собрался, происходит замена, не собрался смотрим что не так.

Серьезно? Вместо того, чтобы заставить ansible спросить меня «нормально, обновляемся?» ты предлагаешь реализовать контейнеры и обновляться через них?

оценить вывод софтины с другой стороны и принять на основании этого какое-то решение

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

Вместо того, чтобы заставить ansible спросить меня «нормально, обновляемся?»

Если ты не собираешься обновляться, зачем говорить ему «обнови!»? Напиши «предварительную» задачу «проверить всё», и запускай по очереди, останавливаясь при неожиданностях. Роботы это умеют.

Если ты не собираешься обновляться, зачем говорить ему «обнови!»? Напиши «предварительную» задачу «проверить всё».

Что значит «проверить всё»? Написать ИИ?

Существуют более надёжные способы сделать это, чем читать выхлоп программ своими глазами и принимать решения своими мозгами.

Вообще да. Нанять секретаршу - отличная идея.

Ansible

Оно чем-то лучше saltstack-а?

Отвратительная поделка.

На самом деле, хороших не то, что FOSS, даже и проприетарных, но доступных поделок для оркестрации нет и не было.

Просто «эффекторов» для оркестровки, к коим относится вот это вот чудо тоже нет.

Есть борг, которого никто не видел, есть кубернетес, который ни у кого не заработал, у каждой конторы есть своё проприетарное поделие, а открытого нет.

Чудеса.

saltstack

Сорта сладких хлебобулочных изделий.

chef, puppet, ansible, docker, python и т.д.

Все, кроме докера - тухлятина.

Но и вместо докера вот эта штука в 80% случаев будет лучше: https://github.com/yandex/porto

Оно чем-то лучше saltstack-а?

Проще и быстрее взлететь

Каждый сервер выполняет свою задачу

Это у нищебродов, которые никогда не слышали об отказоустойчивости и баллансировке нагрузки.

Можно поныть? Спасибо :) В один проект приходишь - Puppet, в другой - Шеф, в третий Git + костыли, в четвертый Salt (пока мой фаворит). Ansible, конечно, маленько попроще, чем тот-же Шеф или Кукольщик. Но!.. чем старше и больше инфраструктура, тем меньше народу, который шарит, как это работает. В итоге сидит такой аксакал, который только он, в единственом экземпляре, может править скрипты. А после того, как он уходит, начинается плачь Ярославны. Ведь в каждом своя «изюминка», в которой без ящика крепкого алкоголя не разобраться. Каждый изобретает с нуля как внедрить ту или иную систему с нуля. Порог вхождения «ух»! То-же можно и о системах мониторинга сказать - Nagios, Icinga, Icinga2, Zabbix, TSM (свят-свят!), да еще куча всего - страницы, наверное не хватит. Хочу общих стандартов с внятной документацией и дружелюбных к пользователям-админам, которые, чего уж говорить, не все академики.

Истины сплошные. Тоска-печаль...

баллансировке нагрузки

Нагрузки чего? Нашего git'а? Я не уверен, что она ему нужна :D

Проще и быстрее взлететь

В каком смысле? Ты про порог вхождения?

Нанять секретаршу - отличная идея.

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

Человеки они такие. Ненадёжные.

Что значит «проверить всё»?

Не знаю. Ты же собирался что-то проверять? Если у тебя нет чётких критериев проверки, как ты собираешься это вообще делать? Найди то, не знаю что? Тут всего 2 варианта:

1. информации к проверке мало - значит ты сможешь её формализовать, и потом робот будет проверять, что всё правильно, а ты отдыхать.

2. информации много - ты её на станешь проверять глазами, это бессмысленно. Робота, как минимум, можно научить правильному выхлопу, и пусть считает ошибкой всё, что на него не похоже. Тут остаётся только 1 риск - записать в whitelist что-то существенное, но это намного проще чинится по сравнению с вероятностью проигнорировать то же человеком.

Всегда считал что satellite ~ spacewalk = puppet + foreman + MQ и + что-то там ещё их собственное.

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

Одна задача требует, другая нет. Откуда либо-то взялось? Это вообще в разных playbook'ах может быть.

И в чем проблема? Не надо совать в плейбуки то, что можно сделать только руками.

Я хочу, чтобы он меня спросил об этом

Зачем тебе тогда ansible, можешь объяснить?

Серьезно? Вместо того, чтобы заставить ansible спросить меня «нормально, обновляемся?» ты предлагаешь реализовать контейнеры и обновляться через них?

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

Принцип девопса в том, чтобы при увеличении сервисов не было увеличения работы. Никакой рутины и ручной работы, только скриптование задач до состояния нажал и забыл. Хочешь админить по старинке, дело твое, но подумай о будущем.

И в чем проблема? Не надо совать в плейбуки то, что можно сделать только руками.

Потому что параллельная обработка на shell это то ещё извращение. Можно конечно запустить ctmux, но зачем?

Зачем тебе тогда ansible, можешь объяснить?

Чтобы автоматизировать всё остальное.

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

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

Потому что параллельная обработка на shell это то ещё извращение.

Хорошего ad-hoc для shell-a нет на сегодняшний день и ansible сейчас в эту сторону не развивается. А почему он туда не развивается это другой вопрос. Может быть потому что такой подход устарел?

Зачем?

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

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

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