Кстати, а кто какую архитектуру для ансибля выбрал?

Все в одной плейбуке, или тонна плейбука?

чат это уведомления, у них нет статусов - в процессе, сделано и так далее

да, но если это для команды из 1-3 человек, то в общем-то и ок

то есть каждый день видишь, что ситуация ухудшается

потом понимаешь, что нужно сделать

бук это конечно книга, она моя, но плейбук - это таки сборник, он мой :)

тогда лучше и туда и туда

Все в одной плейбуке, или тонна плейбука?

тонна плейбука )

Все в одной плейбуке, или тонна плейбука?

тонна

тонна правильнее, но управлять этим , полагаю, сложнее

тонна плейбука )

во второй части у него просто опечатка, на самом деле хотел "тонна плейбуков"

Не придирайтесь к т9))

у меня тонна :))

аццкий монолит - путь к злу :)

Вот да...

а как его раскатывать один. нафиг надо

ну не тонна, ну несколько штук, ну десяток. как попрёт

а как его раскатывать один. нафиг надо

ну раскатывать, допустим, можно тэгами. но нет.

вот как раз с точки зрения "управлять", кмк, в монолите с тонной тэгов запутаться как бы не проще, чем в тонне плейбуков

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

спасибо) вот ещё что нашел https://gist.github.com/pkuczynski/8665367 и https://stackoverflow.com/questions/5014632/how-can-i-parse-a-yaml-file-from-a-linux-shell-script

Если не сложно поставьте пойду ? - на то что вам интересно

Зачем конфиги, если можно превратить конфиг в конфиг с тригером логики. Конфиг в данном слуяае лишняя сущность, имхо.

воу-воу, опять "программирование на конфигах"? :)

воу-воу, опять "программирование на конфигах"? :)

вот с другой стороны - скрипт можно запускать в докер-контейнере и каждый раз подкладывать туда разные переменные окружения через docker run -e ...

воу-воу, опять "программирование на конфигах"? :)

Парсить в баше yaml ничем не лучше.

ansible в типичном использовании то же программирование в конфигах, между прочим

варвар

Вы бы еще про синий цветочек icq начали

извините, я случайно

ansible в типичном использовании то же программирование в конфигах, между прочим

Не программирование в конфигах, а декларативный стиль описания задач ?

Как в языке Пролог типа

зачем вообще башем что-то парсить?

Вы бы еще про синий цветочек icq начали

а что это?

Не программирование в конфигах, а декларативный стиль описания задач ?

https://docs.ansible.com/ansible/playbooks_loops.html#nested-loops это что-то не очень декларативно, это скорее императивно

зачем вообще башем что-то парсить?

Чтобы можно было применить оператор $? наконец то

зачем вообще башем что-то парсить?

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

вопрос был про то, как эти данные из конфига заюзать в баше

а что это?

Старая мулька, тира письма счастья. Мол отошли это сообщение n контактам и твой цветок (иконка) в ICQ станет синим

а чат опс это вообще, кстати, не только об управлении инфраструктурой

DevOps - это разработчики + админы + тестировщики

https://docs.ansible.com/ansible/playbooks_loops.html#nested-loops это что-то не очень декларативно, это скорее императивно

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

Старая мулька, тира письма счастья. Мол отошли это сообщение n контактам и твой цветок (иконка) в ICQ станет синим

вот и выросло поколение старперов которым стыдно признаться что они так отсылали сообщение :)

тут вот тестировщиков, похоже, совсем мало

судя по обсуждаемым темам

странно что в чате девопса мало тестировщиков, ага

вот и выросло поколение старперов которым стыдно признаться что они так отсылали сообщение :)

Не стыдно, например

я знаю YandexTank, Jmeter и много других страшных слов)

Не стыдно, например

та я о Никите :)

странно что в чате девопса мало тестировщиков, ага

так DevOps это в том числе и про тестирование

тестировать скучно

девопс в первую очередь о культуре взаимодействия Dev и Ops

http://www.lxpert.info/uploads/images/Logos/devops-diagram.png

как видно на рисунке, DevOps - это чёрная дыра, рядом с которой крутятся вот эти три специалиста/команды

ERROR: S client not available

хорошо, что sales туда не приплели

ну, а мне кажется вполне логичным присутствие тут тестировщиков в этом процессе

Кто тут тестировщиков потерял?)

тестировать скучно

это очень спорный вопрос. вручную - определенно да, согласен.

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

без ручного тестирования никак в любом случае

но да, автоматизировать нужно по максимуму

вручную тестировать -- это все равно, что вручную пакеты ставить

без этого никак на старте любого проекта, но от этого нужно уходить как можно быстрее

На самом деле нет :). Хорошо, если автоматизация всегда немного позади развития продукта. Потому что если автоматизация всегда on par - это означает, что продукт развивается слишком медленно.

iotop ни разу не показатель

А что показатель нагрузки на io?

iostat ?

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

без этого никак на старте любого проекта, но от этого нужно уходить как можно быстрее

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

это означает, что 80% компаний тратят деньги на автотесты зря

а что здесь имеется ввиду под автотестами?

тесты чего?

покрытие кода, наверное

мне интересно, а вообще вот у многих работает система непрерывного деплоя?

вроде как в Яндексе именно так?

ведь это конечная цель введения кучи тестов?

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

ведь это конечная цель введения кучи тестов?

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

И наоборот, можно непрерывно деплоить бажный код без тестов и ловить батхерты пользователей.

никто не сталвкивался с проблемой, collectd снимает с интфрейса снимает тока один показатель rx или tx а оба не хочет.

м ?