Комментарии 17
У меня есть один идейный вопрос: почему после няшного питонового ансибла мы начинаем адски bundler exec ruby was here? Фактически, все рубёвые штуки очень любят юзать ruby/erb синтаксис, что сильно увеличивает объём того, что нужно знать. И это ради тестов?
Вообще, для ансибла я видел тесты, написанные на самом ансибле. Выглядят как отдельная playbook'а, состоящая из набора утверждений с fail (и условиями fail).
Вот иметь какой-то слой интеграции между ansible и контейнерами — было бы мило.
Вообще, для ансибла я видел тесты, написанные на самом ансибле. Выглядят как отдельная playbook'а, состоящая из набора утверждений с fail (и условиями fail).
Вот иметь какой-то слой интеграции между ansible и контейнерами — было бы мило.
> Фактически, все рубёвые штуки очень любят юзать ruby/erb синтаксис, что сильно увеличивает объём того, что нужно знать. И это ради тестов?
Возможно, потому что serverspec оказался первым попавшимся инструментом для тестирования.
> Вообще, для ансибла я видел тесты, написанные на самом ансибле. Выглядят как отдельная playbook'а, состоящая из набора утверждений с fail (и условиями fail)
О, а можете поделиться? Я видел только тесты плейбуков на python'е. Но это выглядело как-то не очень.
> Вот иметь какой-то слой интеграции между ansible и контейнерами — было бы мило.
Не совсем понял, о чём идёт речь. У ansible есть connection-модуль для docker (немного кривоватый, правда), или Вы о другом?
Возможно, потому что serverspec оказался первым попавшимся инструментом для тестирования.
> Вообще, для ансибла я видел тесты, написанные на самом ансибле. Выглядят как отдельная playbook'а, состоящая из набора утверждений с fail (и условиями fail)
О, а можете поделиться? Я видел только тесты плейбуков на python'е. Но это выглядело как-то не очень.
> Вот иметь какой-то слой интеграции между ansible и контейнерами — было бы мило.
Не совсем понял, о чём идёт речь. У ansible есть connection-модуль для docker (немного кривоватый, правда), или Вы о другом?
У ансибла обновилась документация, вот сходу: http://docs.ansible.com/ansible/test_strategies.html
Вот ещё нашлось: https://github.com/nylas/ansible-test
В живую я вопрос тестов сам не щупал, хотя очень интересно было бы.
По второму вопросу: речь про то, чтобы иметь какой-то вменяемый формат для описания «что нужно для теста».
Вот ещё нашлось: https://github.com/nylas/ansible-test
В живую я вопрос тестов сам не щупал, хотя очень интересно было бы.
По второму вопросу: речь про то, чтобы иметь какой-то вменяемый формат для описания «что нужно для теста».
Какой-то детский сад прям, а не DevOps.
И еще, почему не упомянули про ansible-galaxy, ну хотя бы в аспекте создания проекта (папок), например:
# ansible-galaxy init common -p roles
И еще, почему не упомянули про ansible-galaxy, ну хотя бы в аспекте создания проекта (папок), например:
# ansible-galaxy init common -p roles
Обычно во взрослых компаниях так или иначе использующих методологию DevOps настраивают несколько окружений. И как правило тестируют новый код на соответсвующем окружении (DEV например).
Вообще, мне не очень понятна идея автоматизированного тестирования плейбуков, на мой взгляд нужно в первую очередь четко понимать что в них писать и для чего (ну и желательно как). Т.е. проверять их в любом случае нужно глазами, а потом уже пробовать запускать на DEV-окружении. Плюс есть же еще Dry run. А то получается сам накодил, сам запустил автотесты, сам себе вернул на доработку.
Вообще, мне не очень понятна идея автоматизированного тестирования плейбуков, на мой взгляд нужно в первую очередь четко понимать что в них писать и для чего (ну и желательно как). Т.е. проверять их в любом случае нужно глазами, а потом уже пробовать запускать на DEV-окружении. Плюс есть же еще Dry run. А то получается сам накодил, сам запустил автотесты, сам себе вернул на доработку.
Согласен с тем, что вызывает недоумение то, что автор декларирует devops — и тут же описывает единый inventory, когда даже в документации рекомендуемая структура содержит production и staging.
Статью автора могу только приветствовать, он по касательной затрагивает тему, которая мне в последнее время интересна — ansible best practice.
Вот очень бы хотелось увидеть чью-то готовую статью на эту тему, потому что самому писать пытаясь обобщить собственный опыт времени не хватает: это не меньше месяца-двух точно займёт. (Никто не хочет поделиться своими наработками, а?)
На хабре было несколько вводных статей по ансиблу, вроде и хостеры пишут (инфобокс, селектел) — а всё равно статьи вышли уровня для новичков. Навскидку: мы же храним ansible скрипты в git'е, значит конфиги хостов должны либо лежать вне git, либо уж хотя бы пароли в открытом виде не содержать и закрытые ключи ssh.
Собирать информацию по бест практис приходится по крохам.
Вот в текущей статье автор опять зачем разжёвывал структуру плейбуков, полстатьи можно смело под нож урезать и сосредоточиться именно на тестировании ролей — ан нет, повторяет документацию.
Например, явно хорошей практикой (на мой взгляд) является "одна роль — одна переменная (массив)", в то же время и в текущей статье я не вижу hash_behaviour = merge в конфиге и вижу на гитхабе в репозиториях простыни глобальных переменных.
Тестирование плейбуков у нас делается по-старинке, вручную: создай пустую виртуальную машину и тестируйся по самое не хочу откатываясь к контрольным точкам. Статья же дала импульс поискать варианты решения на базе teamcity (у нас на него лицензии куплены, корпоративный стандарт).
Вот очень бы хотелось увидеть чью-то готовую статью на эту тему, потому что самому писать пытаясь обобщить собственный опыт времени не хватает: это не меньше месяца-двух точно займёт. (Никто не хочет поделиться своими наработками, а?)
На хабре было несколько вводных статей по ансиблу, вроде и хостеры пишут (инфобокс, селектел) — а всё равно статьи вышли уровня для новичков. Навскидку: мы же храним ansible скрипты в git'е, значит конфиги хостов должны либо лежать вне git, либо уж хотя бы пароли в открытом виде не содержать и закрытые ключи ssh.
Собирать информацию по бест практис приходится по крохам.
Вот в текущей статье автор опять зачем разжёвывал структуру плейбуков, полстатьи можно смело под нож урезать и сосредоточиться именно на тестировании ролей — ан нет, повторяет документацию.
Например, явно хорошей практикой (на мой взгляд) является "одна роль — одна переменная (массив)", в то же время и в текущей статье я не вижу hash_behaviour = merge в конфиге и вижу на гитхабе в репозиториях простыни глобальных переменных.
Тестирование плейбуков у нас делается по-старинке, вручную: создай пустую виртуальную машину и тестируйся по самое не хочу откатываясь к контрольным точкам. Статья же дала импульс поискать варианты решения на базе teamcity (у нас на него лицензии куплены, корпоративный стандарт).
Навскидку: мы же храним ansible скрипты в git'е, значит конфиги хостов должны либо лежать вне git, либо уж хотя бы пароли в открытом виде не содержать и закрытые ключи ssh.
Можно (и нужно) всё хранить в git даже пароли если использовать (ansible-vault). Ну кроме файлов приватных ключей наверное, хотя их тоже можно хранить в виде зашифрованных переменных.
Вместо serverspec мне кажется лучше использовать testinfra для ansible.
Занимаюсь примерно такой же фигней, только столкнулся с тем, что 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 мин)
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. Поправьте пожалуйста, а то глаз режет.
— 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.
Мы используем Ansible для настройки новых VM на AWS. Для этого мы написали Python скрипт который выполняется каждую ночь:
— Скрипт сначала обновляет playbook'и из dev ветки, затем читает определенную директорию где лежат «задачи». Каждая задача это — список AMI ID и роль для хоста.
— Затем для каждой задачи этот скрипт запускает чистую машину с указанным AMI и через AWS API получает информацию о машине.
— Из полученной информации собирается inventory и в отдельном потоке начинается выполнение playbook на этой виртуалке. Соответственно STDOUT, STDERR и код возврата сохраняются в результатах выполнения
— Если все выполнилось без ошибок (определяется по коду возврата), то машина останавливается и удаляется. Если же произошла какая-либо ошибка, то машина просто останавливается и разработчики на следующий день могут залогиниться и посмотреть почему произошла ошибка.
— Когда все потоки закончили выполнятся, результаты отправляются по емейлу в виде билд-матрицы (по горизонтали различные AMI/системы, по вертикали — роли)
Было бы очень интересно узнать как такое решение можно реализовать на Jenkins.
Ну, вы же всё уже описали :) Создаём задачу в Jenkins, описываем шаги сборки, шлём e-mail по окончанию. Jenkins определяет статус джоба по коду возврата.
По решению Вашей задачи мы сделали небольшую заметку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ansible: тестируем плейбуки (часть 1)