Комментарии 18
"Нельзя просто так взять и вставить assert в плейбуку".
Можно
- command: get --version
changed_when: false
register: version
- assert:
that:
- "'3.0.0' in version.stdout"
Может это в новой версии появилось?
changed_when? Уж версий 10 как есть. Просто докладчик не знал — отсюда и его постоянные заминки с конвергенцией и command.
А вы докладчик? Спасибо за доклад, я попробую (в пятый раз) таки адаптировать молекулу.
Все мои предыдущие четыре раза закончились лёгкой брезгливостью. Самый яркий пример — это смена драйвера. Если сменить драйвер с докера на libvirt, то molecula'а пишет конфиг в /tmp и юзает его вне зависимости от того, что написано в настройках роли. Файл в /tmp стираешь — переключает драйвер. Не стираешь — игнорирует написанное и использует файл из /tmp. Возможно, пофиксили. Но после потраченного дня на отладку стало очень брезгливо.
Хак с симлинком тоже оставил неприятный привкус.
Но чем-то роли проверять всё-таки надо, так что всё-таки придётся пробовать ещё раз.
А насчёт "тестировать плейбуки продакшена не надо" — это ошибка. Плейбуки содержат в себе бизнес-код и их как раз в первую очередь проверять надо. Но это очень, очень, очень сложно.
Пока что у меня два используемых варианта: мок продакшена (т.е. сервера, у которых настоящие IP продакшена, настоящее всё, но оно разложено в оторванном от интернете мире с имитацией интернета с помощью оверлейной сети), и "стейджинг-инвентори" (собственно, это идея ансибла).
Оба варианта трудно делать и сопровождать, но лучше трудно делать, чем обнаружить, что stateful продакшен (aka СУБД) превратился в тыкву из-за баги в плейбуке.
Есть такой паттерн в ансибле:
- name: Check if foo is done
command: foo status
register: foo_status
changed_when: false
- name: Do foo
command: foo do
when: " 'done' not in foo_status.stdout"Это такой метод реализовать идемпотентность, когда нет модуля. Но, главное, не увлекаться. Если такого кода много — писать модули.
А можно цифер пошарить?
- Сколько ролей?
- Сколько из них покрыто тестами?
- Идемпотентность везде проверяется?
- Какие сценарии в верифаерах и сколько их вобще?
- Какой драйвер в молекуле преобладает?
- Используется ли несколько инстансов в молекуле и как?
- В какое время укладываеься тестирование 80% ролей?
P.S. абсолютные цифры было бы интересно увидеть, но если секрет, то можно порядки.
P.P.S. добавил в подборочку про Тестирование IaC
Какой-то очень странный доклад со ссылками на явно устаревшие репозитории и практики. А также с рядом фактических ошибок.
Например:
- с помощью ansible-lint якобы можно проверять идемпотентность
- молекулой якобы нельзя тестить плейбуки
- хендлеры для проверок
- деплой прода якобы можно проверить только на проде
- не упомянут способ инфраструктурной верификации самим ансблом вместо testinfra, goss или serverspec
и т.п.
Привет, Тимур! Спасибо за замечания по делу )
деплой прода якобы можно проверить только на проде
смотря как написано.....
* С помощью ansible-lint _можно_ находить неидемпотентность!
* Плейбуки тестить можно, но это не основной use case.
* Выше уже отметили. Да, не знал я про `changed_when`. Но интересно, что когда я доклад готовил с ревьюерами и потом делал на одном большом митапе и двух конференциях, мне на это никто не указал. Видимо, на тот момент это не очень известная фича была.
* Да, именно так. В контексте того что я говорю в докладе.
* Почему не упомянут? Упомянут assert.
Можно узнать, как предполагается проверять идемпотентность кода с помощью ansible-lint?
По последнему пункту: речь не про assert, а про тип верификатора на стадии verify в молекуле. У вас упомянуты только testinfra, goss и serverspec. В то время как есть ещё и верификатор ansible. И с версии 3.0.0 именно он является дефолтным.
Ещё раз напомню, что это — расшифровка доклада, который готовился летом 2018 года. На тот момент я не помню, чтобы в молекуле был верификтор Ansible. Testinfra был дефолтным.
В ansible-lint есть проверки, запрещающие выполнять «незащищённые» command/shell операции, которые будут приводить к изменениям при каждом выполнении. Разумеется, это формальная проверка, но она находит такие случаи.
Это не проверка идемпотентности от слова "совсем". Проверка идемпотентности — это запуск плейбуки повторно с проверкой состояний changed/ok на каждом шаге — только так. Ворнинги, которые генерит ansible-lint, никакого отношения к идемпотентности непосредственно не имеют. Можно написать совершенно неидемпотентный код без всякого command и shell — и ansible-lint это никак не отследит.
Проверка идемпотентности — это запуск плейбуки повторно с проверкой состояний changed/ok на каждом шаге — только так.
Спасибо, Капитан Очевидность, а я-то не знал :-) Да, также как и всевозможные findbugs и другие средства статического анализа — это не тестирование от слова совсем. Ansible-lint — это средство статического анализа, которое позволяет найти некоторые явные проблемы в коде, не запуская его.
По поводу тестов плейбук молекулой: согласен, что это не основной юзкейс, но в докладе сказано иначе — что можно тестировать только роли. Новичок будет введён в заблуждение, считая, что молекула не может тестить плейбуки.
Ansible playbooks — это код: проверяем, тестируем, непрерывно интегрируем. Иван Пономарёв