LINUX.ORG.RU
ФорумAdmin

Вот вам пример как не нужно делать роли в ansible.

 , , плохой пример


0

3

Добрый день.

Попалась мне на глаза статья на хабре - https://habr.com/ru/articles/854792/.

Я бы сказал, что это хороший анти-паттерн. Не нужно так писать роли.

Роль - это «invariant», она должна содержать все данные, чтобы устанавливать asterisk (в нашем случае). А playbook - должен содержать данные, снабдить всем необходимым, чтобы роль смогла установится.

Чтобы я сделал:

  • Добавить в meta/main.yml - добавить информацию, что данная роль работает в RHEL;
  • Добавить в tasks/main.yml - первая task - ansible.builtin.fail, должна определить, что система не RHEL и прекратить работу;
  • Почаще запускать ansible-lint, чтобы, например, писать ansible.builtin.fail - вместо fail.
  • Следовать порядку в tasks - name, when, task name, данные задания.
  • Помнить о приоритете переменных, поместить все переменные в defaults/main.yml, вместо текущего vars/main.yml.
  • Добавить Molecule - для лучшего тестирования;
  • Добавить testinfra - добавить еще больше тестов.
★★★

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

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

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

Роли надо писать так, чтобы завтра не было стыдно за бесцельно прожитые годы.

А еще хорошая привычка в корень репозитория положить README.md, где автор может дать 2-3 примера как использовать эту роль.

Чтобы завтра у автора или после автора инженерам нужно было бы тратить меньше времени на то, чтобы понять и использовать эту роль.

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

Ну я не плохо пишу на perl, bash. В целом сказать с 2004 года. Но последние 3-4 года перучивался писать все на yaml.

Спасибо хорошей книге от Jeff Geerling - Ansible for Devops. (вроде книга бесплатная уже).

А до Ansible 10 лет назад изучал Chef. Также спасибо хорошей книге Test Driven Infrastructure with Chef.

Нравится, что многие вещи уже реализованы как модули, например, создать файл, закачать туда шаблон, сразу выставить владельца и группу, выставить права. И повесить еще и notify - перестартовать сервис, если нужно. И это все сделано в рамках одной задачи (task) - ansible.builtin.template.

В perl / bash - нужно написать дополнительно кучу строк кода чтобы это все проверить.

Там вроде автор Ansible даже новый проект открывал, который был на rust и «идентичен натуральному», но проект закрыли через полгода. Не знаю почему (кажется Python-лобби приложило руку).

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

А еще хуже другое, что вопросы на которые есть ответы в Linux.org.ru, почему-то задают в телеграм-канале DevOps RU, DevOps Jobs RU.

сколько раз там рекомендовал, идти сюда и тут поиском найти ответ, но нет все туда (в телеграм) ломятся. Да еще и в токсичности обвиняют.

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

В том то и дело что таков опыт был и csv файлики вместо netbox народ юзает на хардвер инфре, и баш скрипты вместо плейбуков пишет (и делает это тоже хреново), просто забавно что взрослые дяди мыслят до сих пор категориями каломета:)

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

В каком месте ты нормальный. Даже выше уровня простого метания дерьмом держаться не можешь (ну это конечно не упоминание мамок как у персонажа выше)… Убавь ЧСВ. Bash лучше YAML.

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

Гит для слабаков.

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

Ты сравниваешь теплое с мягким. Как тебе гит поможет в отслеживании изменений самой конфигурации, закоммитил ты в прод реп свой скрипт, а применил ты его или не применил инженеры на кофейной гуще должны гадать? Или полторы тысячи виртуалок/хостов (условно) по clusterssh проверять? Ямл это всего лишь маркап а анзибл всего лишь cm, так что как одно может быть лучше другого я хз, это не взаимозаменяемые сущности

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

YAML-инженеры с кофейной гущей? Какие 1500 виртуалок? Что за фантазии??? В стране считанное количество компаний с такими масштабами, а если читать байки местных постояльцев, то все чуть ли не в гуглах работают

rtxtxtrx ★★
()

Добавить Добавить Добавить

Добавил в шелл функцию ifos, которая грепает /etc/issue и функцию run_task, которая вызывает функцию по ифу двух других (функция_require и функция_provided).

Не понимаю, зачем нужны замены шелла на YAML кроме имиджа и зарплаты за имидж.

anonymous
()

Почитал статью. Особых замечаний к роли (кроме того, что она написана только под RHEL, но не проверяет дистрибутив - вдруг там Debian) у меня нет.

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

Harliff ★★★★★
()