А на мой вопрос не ответили :)

А на мой вопрос не ответили :)

Думаю, ты сам всё понимаешь 😉

Господа, я тут читал где-то выше про то, что тэги !=Ъ, разъясните пожалуйста, как правильно делать, если есть типовая роль с набором параметров, один из которых вдруг поменялся и этот типовой параметр нужно разнести по набору машин? Я пока хреначу тэг и выполняю плэйбук с указанием тэга. Могу, в принципе, поменять параметр в задачах роли, на будущее, а изменение в уже имеющихся машинах разнести отдельным маленьким плэйбуком или даже используя конструкцию ansible all -m ** -a '*', я так понял, что нормальные люди делают как-то иначе

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

То есть для роли это будет выглядеть как main.yml --- - include: 1.yml - include: 2.yml - include: 3.yml ?

Вы какую задачу-то решаете?

include на мой взгляд не очень норм, лучше на выбор: playbook в котором явно перечислены роли или meta: you_role

Вы какую задачу-то решаете?

Да как обычно, поменялся перечень разрешённых команд из под судо для определённого пользователя, я в роли 'default' нужное добавил, ненужное удалил. Но прогонять весь плэйбук "deploy_default" по всем компам смысла не вижу. Поэтому добавляю тэг и выполняю плэйбук "deploy_default" ограничивая перечень задач тэгом.

Да как обычно, поменялся перечень разрешённых команд из под судо для определённого пользователя, я в роли 'default' нужное добавил, ненужное удалил. Но прогонять весь плэйбук "deploy_default" по всем компам смысла не вижу. Поэтому добавляю тэг и выполняю плэйбук "deploy_default" ограничивая перечень задач тэгом.

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

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

Что простите?

Что простите?

http://docs.ansible.com/ansible/devel/user_guide/become.html

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

Команды, что запрещены под рутом, выполняете под бекам, не?

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

А разве ансимбл не для того, что повторять можно

Мы отклонились от темы. Итак, если есть длинный плэйбук, предположим, на 100 тасков. Один из тасков поменялся и его нужно прогнать по 100 машинам снова. Как правильнее сделать после исправления таска: 1. Добавить тэг и прогнать исполнение плэйбука с тэгом 2. Исправить таск в длинном плэйбуке, создать новый "короткий" плэйбук из одного таска и прогнать его 3. Исправить таск в длинном плэйбуке и прогнать по всем машинам ansible -m * -a '*' all 4. Иной вариант. Почему-то кажется, что 4 пункт самый правильный.

А чем не нравится второй?

зачем вообще буки на 100 тасков? уверен их можно подробить на роли

Там как раз в роли 100 тасков

Это не отменяет

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

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

не пишите таких ролей, дробите на логические. легче же масштабировать потом

Ага, то есть роль должна состоять из - include: *.yml

я не использую include, писал об этом выше

Или просто много мелких ролей?

просто много ролей

и верхнеуровневая бука

типа

- name: users hosts: all become: yes vars_files: - secrets.yml roles: - users tags: - users - common

в roles перечесляете ваши мелкие роли

Опа =) тэг

ну да дробите таким макаром потом и по тегам

Окей. Я понял.

можно еще более интереснее

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

- name: Common system configuration gather_facts: yes hosts: all become: yes vars_files: - secrets.yml roles: - {role: sysctl, tags: [sysctl]} - {role: users, tags: [users]} - {role: sshd, tags: [sshd]} - {role: apt, tags: [apt]} - {role: useful_packages, tags: [useful_packages]} tasks: - name: Upgrade system apt: upgrade: full tags: - upgrade

Ага, то есть роль должна состоять из - include: *.yml

да, мы так делаем

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

вынесите хендлеры в верхний уровень

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

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

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

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

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

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

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

Выше есть рекомендация использовать roles: - {role:1, tags: [1_a, 1_b]} так писать меньше буков чем использовании include

Простите. Кажется я развязал холивар.

Просто теги для простых вещей, не надо хотеть от них странного

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

ансамбль

Ansible

https://docs.ansible.com/ansible/2.3/playbooks_async.html

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

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

А есть ли среди нас клиенты flops.ru?

А есть ли среди нас клиенты flops.ru?

Юзал некоторое время

Да я тут модуль к их апишке пишу... Надоело руками создавать виртуалки. Думал может нужен кому тоже)

ansible/ansible was tagged: v2.5.1 Link: https://github.comhttps://github.com/ansible/ansible/releases/tag/v2.5.1 Release notes: New release v2.5.1

Добрый день! Решил использовать ансибл в своей системе, с каких задача для примера можно начать?

Автоматизировать

Около 150 серверов на rhel centos 7 linux

можно начать с автоматизации проверки диска

А как можно это всю информацию мониторить

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

Аа на контрол машине не удобно мониторить

Ансимбл для мониторинга?

Почитай книгу ansible for devops, там много жизненных примеров

Самое простое начало проверка ntpd и синхронизация времени

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

разжигаешь ?

:)

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

для мониторинга лучше не ansible) в такой формулировке холивар не начнется)

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

разжигаешь ?

Лучше, чем ansible

Ansible - это инструмент для решения задач, подбирать задачи под инструмент - это интересно конечно, но уже пошло не так

а я делал мониторинг ансиблом

а в блоге основателей я видел еще большее дно

они логи им смотрели

они логи им смотрели

в нашем поделии такое есть, для более осмысленного сообщения об ошибке (но помошает не очень)

Самое простое начало проверка ntpd и синхронизация времени

Вот например , у меня уже настроены ntp на серверах, решил проверить , действительно ли они работают , пишу задачу, и получаю результат

В этом и суть?

Я правильно понимаю

Проверить что сервис запущен и вывести date например