Всем привет, недавно мы начали цикл статей о тестировании в Chef, но сегодня я расскажу о более вводных и универсальных вещах: зачем тестировать инфраструктуру, какие инструменты для этого есть и как все это автоматизировать. Также затрону тему публикации инфраструктурного кода в open source. Статья будет интересна пользователям любой из популярных систем управления конфигурацией — Chef, Puppet, Ansible или SaltStack.

Статья основана на моем выступлении на конференции Стачка в Ульяновске, слайды доступны здесь. После прочтения пишите про свой опыт в тестировании инфраструктуры, думаю, всем будет интересно.

Поехали.

Тесты?

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

Когда актуально?

Тесты особенно актуальны, когда код изменяется, когда над ним работают несколько человек, а изменения затрагивают сложную логику или сторонний код. От изменений никуда не деться, выходят новые версии операционных систем и программ, меняются API и ваш инфраструктурный код устаревает и требует изменений. Когда в код вносят изменения несколько человек, вы уже не можете быть уверены, что ваши изменения не затронут другие, а если вы меняете сложную логику или сторонний код, то вероятность ошибки еще выше. Стандартный подход проверки инфраструктурного кода в Vagrant здесь уже не работает, так как занимает много времени и требует ручной проверки изменений и конечного состояния.

Что делать?

Поэтому в системах управления конфигурацией появились свои инструменты для тестирования инфраструктурного кода. Я рассмотрю самые популярные и универсальные инструменты, которые подойдут для любой из систем управления конфигурацией, будь то Chef, Puppet, Ansible или SaltStack.

Что тестировать?

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

Что проверяем?

Проверять будем следующие вещи:

• синтаксис и стиль написания кода
• функционал
• результат работы системы управления конфигурацией

Стиль языка

Популярные системы управления конфигурацией на написаны на двух языках, Ruby и Python. Для них созданы свои стайл гайды по написанию кода и желательно им следовать, чтобы ваш инфраструктурный код было легче читать и поддерживать. Для проверки стиля языка используются стандартные анализаторы кода, такие как rubocop для Ruby и pep8 для Python. Их можно запускать вручную или они могут быть встроены в ваш редактор или IDE.

Стиль кода

Со временем и в системах управления конфигурацией выработались свои рекомендации, появились стайл гайды и специальные инструменты — линтеры. Их нужно учитывать для выявления известных проблем. Работают они на основе набора правил. Список линтеров для систем приведен ниже:

• Chef Foodcritic
• Puppet-lint
• Ansible-lint
• Salt-lint

Функционал

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

Результат

Для проверки результата работы системы управления конфигурацией используется инструмент Serverspec. Это специальный фреймворк для тестирования инфраструктуры. С его помощью проверяется конечное состояние виртуальной машины или сервера. Написан на Ruby и является расширением RSpec, поддерживает все популярные Linux и BSD дистрибутивы, а также Windows. Serverspec содержит в себе около 40 встроенных ресурсов, с помощью которых можно проверить, что пакет в системе установлен, в конфиге указаны нужные параметры, сервис запущен или слушает порт. Если этого недостаточно, то можно вызвать любую shell команду и проверить ее вывод. Serverspec отличная альтернатива shell скриптам и позволяет выполнять проверки как локально, так и удаленно. Serverspec активно используется в community инфраструктурном коде, а недавно Chef анонсировали поддержку Serverspec и в рецептах.

Как тестировать?

Инфраструктурные тесты можно запускать вручную, локально или удаленно, они могут быть встроены в редактор или IDE, выполняться при каком-либо событии, например, изменении файлов на файловой системе или в репозитории.

Автоматизируем

Для автоматизации будем использовать систему непрерывной интеграции(CI систему). Автоматизация исключает человеческий фактор, улучшает качество и скорость тестирования. Рассмотрим следующие системы:

• Kitchen CI
• Travis CI
• Другие CI системы

Test Kitchen

Это инструмент для запуска инфраструктурного кода и его тестирования. Test Kitchen запускает виртуальную машину, в ней запускает ваш инфраструктурный код и тесты для проверки результата. Test Kitchen позволяет запускать виртуальные машины как локально, так и удаленно. Является отличной альтернативой Vagrant для запуска инфраструктурного кода, так как вводит понятия набор тестов (suites), поддерживает все системы управления конфигурацией, Chef в базе, остальные через плагины (Puppet, Ansible, SaltStack), и поддерживает тестовый фреймворк Serverspec.

Travis CI

Это SaaS система непрерывной интеграции для GitHub проектов. Бесплатна для публичных репозиториев. Подходит для тестирования инфраструктурного кода. Есть интеграция с Chef Supermarket и Puppet Forge, о них я расскажу позже.

Но есть и ограничения, тестовое окружение в Travis CI основано на Ubuntu 12.04 LTS, поэтому если вы используете другой дистрибутив или пишете кросс-платформенный код, то не сможете его протестировать. Плюс тестовое окружение идет вместе с предустановленными пакетами и переменными окружения, которые могут вызвать конфликты.

Test Kitchen + Travis CI

Чтобы обойти эти ограничения, можно использовать две системы Test Kitchen и Travis CI вместе и запускать виртуальные машины в облаке, например, Amazon или DigitalOcean.

Другие CI системы

Если вы уже используете какую-либо CI систему, то процесс по тестированию инфраструктуры можно построить и на ней, также используя Test Kitchen для запуска кода и набора тестов.

Делимся с сообществом

Итого, инфраструктурный код у нас будет в одном стиле, удобный для поддержки, внесения изменений и обучения. Не стыдно показать другим. Поэтому делимся с сообществом и выкладываем в open source. С помощью сообщества можно улучшить тестирование и функционал инфраструктурного кода. За счет экспертизы и взгляда со стороны развитие не останавливается.

Делимся

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

• Chef Supermarket
• Puppet Forge
• Ansible Galaxy
• Salt Stack Formulas

Не забываем

Выкладывая код в open source не забываем про следующие моменты:

• Удалить приватную информацию (ключи, пароли, внутренние компоненты)
• Добавить тесты и статус сборки, это повышает степень доверия к коду
• Вести историю изменений и документацию, их можно создавать автоматически
• Подумать о совместимости, зависимостях и конфликтах
• Синхронизировать код с платформой сообщества
• Добавить лицензию

Как это делаем мы

Как это делаем мы, на примере нашего Chef кукбука postgresql_lwrp:

• Код лежит в репозитории на GitHub
• На каждое изменение запускается билд в Travis CI
• Выполняются проверки стиля языка и кода с помощью Rubocop и Foodcritic
• Далее Test Kitchen запускает виртуальную машину в облаке Digital Ocean и выполняет код и Serverspec тесты
• Если все тесты прошли и был релиз, то кукбук загружается в Chef Supermarket
• А нам приходит нотификация в Slack чат и обновляется статус сборки на странице кукбука

Выводы

Тестируйте изменения, автоматизируйте и делитесь с сообществом.

Ссылки

На GitHub у нас есть примеры тестирования для Chef, самый популярный это postgresql кукбук. В ближайшее время мы выложим еще несколько классных кукбуков. Также мы продолжаем цикл статей на Хабрахабре про тестирование Chef, слушайте наш подкаст Devops Дефлопе и приходите на DevOps митапы в Москве.