Pull to refresh

Comments 17

У меня есть один идейный вопрос: почему после няшного питонового ансибла мы начинаем адски bundler exec ruby was here? Фактически, все рубёвые штуки очень любят юзать ruby/erb синтаксис, что сильно увеличивает объём того, что нужно знать. И это ради тестов?

Вообще, для ансибла я видел тесты, написанные на самом ансибле. Выглядят как отдельная playbook'а, состоящая из набора утверждений с fail (и условиями fail).

Вот иметь какой-то слой интеграции между ansible и контейнерами — было бы мило.
> Фактически, все рубёвые штуки очень любят юзать ruby/erb синтаксис, что сильно увеличивает объём того, что нужно знать. И это ради тестов?
Возможно, потому что serverspec оказался первым попавшимся инструментом для тестирования.

> Вообще, для ансибла я видел тесты, написанные на самом ансибле. Выглядят как отдельная playbook'а, состоящая из набора утверждений с fail (и условиями fail)
О, а можете поделиться? Я видел только тесты плейбуков на python'е. Но это выглядело как-то не очень.

> Вот иметь какой-то слой интеграции между ansible и контейнерами — было бы мило.
Не совсем понял, о чём идёт речь. У ansible есть connection-модуль для docker (немного кривоватый, правда), или Вы о другом?
У ансибла обновилась документация, вот сходу: http://docs.ansible.com/ansible/test_strategies.html

Вот ещё нашлось: https://github.com/nylas/ansible-test

В живую я вопрос тестов сам не щупал, хотя очень интересно было бы.

По второму вопросу: речь про то, чтобы иметь какой-то вменяемый формат для описания «что нужно для теста».
Какой-то детский сад прям, а не DevOps.
И еще, почему не упомянули про ansible-galaxy, ну хотя бы в аспекте создания проекта (папок), например:
# ansible-galaxy init common -p roles

Обычно во взрослых компаниях так или иначе использующих методологию DevOps настраивают несколько окружений. И как правило тестируют новый код на соответсвующем окружении (DEV например).
Вообще, мне не очень понятна идея автоматизированного тестирования плейбуков, на мой взгляд нужно в первую очередь четко понимать что в них писать и для чего (ну и желательно как). Т.е. проверять их в любом случае нужно глазами, а потом уже пробовать запускать на DEV-окружении. Плюс есть же еще Dry run. А то получается сам накодил, сам запустил автотесты, сам себе вернул на доработку.
Статью автора могу только приветствовать, он по касательной затрагивает тему, которая мне в последнее время интересна — ansible best practice.

Вот очень бы хотелось увидеть чью-то готовую статью на эту тему, потому что самому писать пытаясь обобщить собственный опыт времени не хватает: это не меньше месяца-двух точно займёт. (Никто не хочет поделиться своими наработками, а?)

На хабре было несколько вводных статей по ансиблу, вроде и хостеры пишут (инфобокс, селектел) — а всё равно статьи вышли уровня для новичков. Навскидку: мы же храним ansible скрипты в git'е, значит конфиги хостов должны либо лежать вне git, либо уж хотя бы пароли в открытом виде не содержать и закрытые ключи ssh.

Собирать информацию по бест практис приходится по крохам.

Вот в текущей статье автор опять зачем разжёвывал структуру плейбуков, полстатьи можно смело под нож урезать и сосредоточиться именно на тестировании ролей — ан нет, повторяет документацию.

Например, явно хорошей практикой (на мой взгляд) является "одна роль — одна переменная (массив)", в то же время и в текущей статье я не вижу hash_behaviour = merge в конфиге и вижу на гитхабе в репозиториях простыни глобальных переменных.

Тестирование плейбуков у нас делается по-старинке, вручную: создай пустую виртуальную машину и тестируйся по самое не хочу откатываясь к контрольным точкам. Статья же дала импульс поискать варианты решения на базе teamcity (у нас на него лицензии куплены, корпоративный стандарт).
Навскидку: мы же храним ansible скрипты в git'е, значит конфиги хостов должны либо лежать вне git, либо уж хотя бы пароли в открытом виде не содержать и закрытые ключи ssh.

Можно (и нужно) всё хранить в git даже пароли если использовать (ansible-vault). Ну кроме файлов приватных ключей наверное, хотя их тоже можно хранить в виде зашифрованных переменных.
Вместо serverspec мне кажется лучше использовать testinfra для ansible.
Спасибо за testinfra, давно такую штуку искал.
Занимаюсь примерно такой же фигней, только столкнулся с тем, что kitchen-ansible не раскрывает переменные внутри, например, group_vars/all файлах. Пришлось свой велосипед написать :(
использую свой велосипед на python скрипте github.com/le9i0nx/ansible-role-test/blob/master/bin/virt.py
Travis файл github.com/le9i0nx/ansible-syncthing/blob/master/.travis.yml

скрипт читает meta для получения списка поддерживаемых ос и создает докер контейнеры с настроенным ключевым доступом.
потом запускается ansible.
тест считается удачным если роль отработала без ошибок во всех контейнерах.
проблемой для меня сейчас является только скорость выполнения такого теста (6мин +-2 мин)
Поделюсь своим небольшим опытом. Путь был примерно следующий:

— Vagrantfile который со временем вырос во что-то стремное github.com/owox-ansible-roles/ansible-role-php/blob/master/Vagrantfile + github.com/owox-ansible-roles/ansible-role-php/blob/master/Makefile
— Со временем пришло осознание что пора завязывать с собственными велосипедами, и под руку попался тот самый github.com/neillturner/kitchen-ansible. Мне нахватало пару мелочей и полез смотреть внутрь как оно там все устроено. PR быстро залетели в мастер и в принципе с этим можно было жить дальше. Но вот тянуть за собой Ruby в проект очень и очень не хотелось.
— Потом очень удачно где-то в рассылках наткнулся на github.com/metacloud/molecule. Грубо говоря, это обертка над Vagrant написанная на Python очень близко копирующая логику Test Kithcen. И вот эта штуковина реально прижилась. Кстати недавно впилили поддержку Docker, но сам еще не смотрел. Сейчас Ansible-ом накатываем реальные сервера, и как по мне не совсем коректно тестировать результат в контейнере. Хотя есть мысли подменять часть задач исходя из github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/facts.py#L2834.

По поводу serverspec, в конце концов ушли от него и начали юзать тот же Ansible для тестирования себя любимого. Правда местами все же юзаем github.com/sstephenson/bats.

Небольшое замечание по оформлению — у вас практически везде сьехала разметка кода. Это я про структуру репозитория, ну и про YAML-ки Test-kitchen. Поправьте пожалуйста, а то глаз режет.
Поделюсь немного нашим опытом:

Мы используем Ansible для настройки новых VM на AWS. Для этого мы написали Python скрипт который выполняется каждую ночь:

— Скрипт сначала обновляет playbook'и из dev ветки, затем читает определенную директорию где лежат «задачи». Каждая задача это — список AMI ID и роль для хоста.
— Затем для каждой задачи этот скрипт запускает чистую машину с указанным AMI и через AWS API получает информацию о машине.
— Из полученной информации собирается inventory и в отдельном потоке начинается выполнение playbook на этой виртуалке. Соответственно STDOUT, STDERR и код возврата сохраняются в результатах выполнения
— Если все выполнилось без ошибок (определяется по коду возврата), то машина останавливается и удаляется. Если же произошла какая-либо ошибка, то машина просто останавливается и разработчики на следующий день могут залогиниться и посмотреть почему произошла ошибка.
— Когда все потоки закончили выполнятся, результаты отправляются по емейлу в виде билд-матрицы (по горизонтали различные AMI/системы, по вертикали — роли)

Было бы очень интересно узнать как такое решение можно реализовать на Jenkins.
Ну, вы же всё уже описали :) Создаём задачу в Jenkins, описываем шаги сборки, шлём e-mail по окончанию. Jenkins определяет статус джоба по коду возврата.
Only those users with full accounts are able to leave comments. Log in, please.