Pull to refresh

Comments 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 СУБД) превратился в тыкву из-за баги в плейбуке.

Понял, changed_when: false будет всегда говорить ансиблу, что ничего не изменилось, и поэтому не будет провален тест на идемпотентность. Век живи, век учись!!!

Есть такой паттерн в ансибле:


- 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

Немного 6 ролей, покрыты все, проверяем в докере, используем только один инстанс — Ubuntu, время около 5 минут

Какой-то очень странный доклад со ссылками на явно устаревшие репозитории и практики. А также с рядом фактических ошибок.


Например:


  • с помощью ansible-lint якобы можно проверять идемпотентность
  • молекулой якобы нельзя тестить плейбуки
  • хендлеры для проверок
  • деплой прода якобы можно проверить только на проде
  • не упомянут способ инфраструктурной верификации самим ансблом вместо testinfra, goss или serverspec
    и т.п.

Привет, Тимур! Спасибо за замечания по делу )


деплой прода якобы можно проверить только на проде

смотря как написано.....

* Докладу уже 2 года, кое-что и устарело.
* С помощью ansible-lint _можно_ находить неидемпотентность!
* Плейбуки тестить можно, но это не основной use case.
* Выше уже отметили. Да, не знал я про `changed_when`. Но интересно, что когда я доклад готовил с ревьюерами и потом делал на одном большом митапе и двух конференциях, мне на это никто не указал. Видимо, на тот момент это не очень известная фича была.
* Да, именно так. В контексте того что я говорю в докладе.
* Почему не упомянут? Упомянут assert.

Можно узнать, как предполагается проверять идемпотентность кода с помощью ansible-lint?


По последнему пункту: речь не про assert, а про тип верификатора на стадии verify в молекуле. У вас упомянуты только testinfra, goss и serverspec. В то время как есть ещё и верификатор ansible. И с версии 3.0.0 именно он является дефолтным.

В ansible-lint есть проверки, запрещающие выполнять «незащищённые» command/shell операции, которые будут приводить к изменениям при каждом выполнении. Разумеется, это формальная проверка, но она находит такие случаи.

Ещё раз напомню, что это — расшифровка доклада, который готовился летом 2018 года. На тот момент я не помню, чтобы в молекуле был верификтор Ansible. Testinfra был дефолтным.
В ansible-lint есть проверки, запрещающие выполнять «незащищённые» command/shell операции, которые будут приводить к изменениям при каждом выполнении. Разумеется, это формальная проверка, но она находит такие случаи.

Это не проверка идемпотентности от слова "совсем". Проверка идемпотентности — это запуск плейбуки повторно с проверкой состояний changed/ok на каждом шаге — только так. Ворнинги, которые генерит ansible-lint, никакого отношения к идемпотентности непосредственно не имеют. Можно написать совершенно неидемпотентный код без всякого command и shell — и ansible-lint это никак не отследит.

Проверка идемпотентности — это запуск плейбуки повторно с проверкой состояний changed/ok на каждом шаге — только так.


Спасибо, Капитан Очевидность, а я-то не знал :-) Да, также как и всевозможные findbugs и другие средства статического анализа — это не тестирование от слова совсем. Ansible-lint — это средство статического анализа, которое позволяет найти некоторые явные проблемы в коде, не запуская его.

В общем, суть в том, что ansible-lint проверку идемпотентности не делает, я только про это. В докладе сказано, что якобы он может это делать. Это фактическая ошибка.

По поводу тестов плейбук молекулой: согласен, что это не основной юзкейс, но в докладе сказано иначе — что можно тестировать только роли. Новичок будет введён в заблуждение, считая, что молекула не может тестить плейбуки.

Only those users with full accounts are able to leave comments. Log in, please.