Стратегии тестирования

Интеграция тестирования с Ansible Playbooks

Часто задают вопрос: «Как лучше всего интегрировать тестирование с Ansible playbooks?» Вариантов много. Ansible разработан как «быстрая» и упорядоченная система, поэтому легко встраивать тестирование непосредственно в Ansible playbooks. В этой главе мы рассмотрим некоторые шаблоны для интеграции тестов инфраструктуры и обсудим подходящий уровень тестирования.

Внедряя определённую степень тестирования в ваш рабочий процесс развертывания, вы будете меньше удивлены, когда код попадёт в производство, а в многих случаях тесты можно использовать в производстве, чтобы предотвратить сбой обновлений на всей установке. Поскольку это ориентировано на отправку, то легко запускать шаги на локальном сервере или тестовых серверах. Ansible позволяет вставлять в ваш рабочий процесс обновления столько проверок и балансировок, сколько вам нужно.

Правильный уровень тестирования

Ansible ресурсы – это модели желаемого состояния. Как следствие, не нужно проверять, запущены ли службы, установлены ли пакеты, или другие подобные вещи. Ansible – это система, которая гарантирует, что эти вещи будут декларативно истинными. Вместо этого, проверяйте эти вещи в своих playbooks.

Если вы думаете, что служба может не запуститься, лучше всего попросить её запуститься. Если служба не запустится, Ansible должным образом сообщит об этом. (Это не должно путать с тем, выполняет ли служба функциональные действия, о чём мы поговорим позже).

Режим проверки как тест дрейфа

В приведенной выше настройке режим проверки в Ansible также может использоваться как уровень тестирования. Если вы запускаете playbook развертывания на существующей системе, использование флага --check для команды ansible-playbook покажет, считает ли Ansible, что ему нужно будет внести какие-либо изменения, чтобы привести систему в желаемое состояние.

Это позволит вам заранее узнать, есть ли необходимость в развертывании на данной системе. Обычно скрипты и команды не выполняются в режиме проверки, поэтому если вы хотите, чтобы определённые шаги всегда выполнялись в режиме проверки, например, вызовы модуля скрипта, отключите режим проверки для этих задач:

Модули, полезные для тестирования

Определённые модули playbook особенно хорошо подходят для тестирования. Ниже приведен пример, который гарантирует открытие порта:

Вот пример использования модуля URI для проверки того, что веб-сервис возвращает:

Легко запустить произвольный скрипт (на любом языке) на удалённом хосте, и скрипт автоматически завершится ошибкой, если у него есть код возврата, отличный от нуля:

Если вы используете роли (а вы должны, роли отличные!), скрипты, загруженные модулем скрипта, могут храниться в каталоге «files/» роли.

А модуль assert очень легко используется для проверки различных истин:

Если вам нужно проверить существование файлов, которые не декларативно задаются вашей конфигурацией Ansible, модуль «stat» – отличный выбор:

Как упоминалось выше, нет необходимости проверять такие вещи, как коды возврата команд. Ansible проверяет их автоматически. Вместо проверки существования пользователя, рассмотрите возможность использования модуля пользователя для его создания.

Ansible – это система «fail-fast», поэтому при возникновении ошибки при создании пользователя выполнение playbook будет остановлено. Вам не нужно проверять это.

Жизненный цикл тестирования

Если вы внедрите некоторую степень проверки вашего приложения в ваши playbooks, они будут выполняться каждый раз при развертывании.

Таким образом, развертывание на локальной виртуальной машине разработки и в среде подготовки будут проверять, что всё соответствует плану, прежде чем вы развернёте приложение в производство.

Ваш рабочий процесс может быть таким:

Если вы – веб-сервис в производстве, ваша команда QA должна написать что-то вроде набора интеграционных тестов. Это будут такие вещи, как тесты Selenium или автоматические API-тесты, и обычно это не то, что нужно встраивать в ваши Ansible playbooks.

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

Интеграция тестирования с поэтапными обновлениями

Если вы ознакомились с Делегирование, поэтапные обновления и локальные действия, то, возможно, быстро станет ясно, что шаблон поэтапного обновления можно расширить, и вы можете использовать результат выполнения playbook для решения вопроса о добавлении машины в балансировщик нагрузки или нет.

Вот кульминация встроенных тестов:

Конечно, в приведенном выше примере шаги «извлечение из пула» и «возврат» были бы заменены вызовом модуля балансировщика нагрузки Ansible или соответствующей оболочной команде. Вы также можете иметь шаги, использующие модуль мониторинга для запуска и завершения периода простоя машины.

Однако вы можете видеть, что тесты используются как ворота: если шаг «apply_testing_checks» не выполнен, машина не вернётся в пул.

Прочитайте главу о делегировании о «max_fail_percentage», и вы также можете контролировать, сколько не пройденных тестов остановят поэтапное обновление.

Этот подход также можно изменить, чтобы запустить шаг с тестовой машины удалённо на машине:

В приведенном выше примере скрипт запускается с тестового сервера на удалённый узел перед возвращением его в пул.

В случае проблемы, исправляйте несколько серверов, на которых произошли сбои, используя автоматически сгенерированный Ansible файл повторных попыток, чтобы повторить развертывание только на этих серверах.

Достижение непрерывного развертывания

При необходимости вышеописанные техники можно расширить для поддержки непрерывного развертывания.

Рабочий процесс может выглядеть так:

Некоторые пользователи Ansible используют этот подход для развертывания приложения несколько десятков раз в час, не отключая всю инфраструктуру. Важна культура автоматизированного контроля качества, если вы хотите достичь такого уровня.

Если вы всё ещё проводите значительную часть контроля качества вручную, вы всё равно должны принимать решение о ручном развертывании, но использование шаблонов поэтапного обновления из предыдущего раздела и включение некоторых базовых проверок работоспособности с помощью модулей «script», «stat», «uri» и «assert» может помочь.

Заключение

Ansible считает, что вам не нужен другой фреймворк для проверки того, что базовые вещи вашей инфраструктуры верны. Это так, потому что Ansible – это система, ориентированная на порядок, которая немедленно завершит работу с ошибкой при необработанных ошибках для хоста и предотвратит дальнейшую конфигурацию этого хоста. Это заставляет ошибки выходить наверх и отображаться в сводке по окончании выполнения Ansible.

Однако, поскольку Ansible разработан как многоуровневая система оркестрации, то очень легко интегрировать тесты в конец выполнения playbook, используя отдельные задачи или роли. При использовании с поэтапными обновлениями, шаги тестирования могут решать, следует ли возвращать машину в пул балансировщика нагрузки или нет.

И наконец, поскольку ошибки Ansible распространяются до кода возврата самой программы Ansible, и Ansible по умолчанию работает в простом режиме отправки, Ansible отлично подходит для внедрения в среду сборки, если вы хотите использовать его для развертывания систем как части конвейера непрерывной интеграции/непрерывной доставки, как показано в разделах выше.

Внимание должно уделяться тестированию приложения, а не инфраструктуры, поэтому мы настоятельно рекомендуем связаться с вашей командой QA и выяснить, какие тесты были бы уместны при каждом развертывании виртуальных машин разработки и какие тесты они хотели бы запускать в среде подготовки при каждом развертывании. Очевидно, на стадии разработки отличными являются также модульные тесты. Но не тестируйте свои playbooks модульными тестами. Ansible описывает состояния ресурсов декларативно, поэтому это не требуется. Если есть случаи, когда вы хотите быть уверены в чём-то, то это хорошо, и такие модули, как stat/assert, очень подходят для этой цели.

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