Итак, в нашей прошлой статье мы рассмотрели как можно быстро и просто настроить среду для тестирования плейбуков и ролей Ansible. Это всё, конечно, очень хорошо и удобно, но почему бы нам не автоматизировать весь процесс внесения изменений в инфраструктуру от написания плейбука до внесения изменений на сервера?
Напомню несколько условий, при которых мы будем выполнять тестирование конфигураций:
1. Вся конфигурация хранится в git-репозитории;
2. Jenkins периодически опрашивает git-репозиторий с нашими ролями/плейбуками на предмет внесённых изменений;
3. При появлении изменений Jenkins запускает job с тестированием конфигурации. Тесты состоят из двух этапов:
3.1 Kitchen-CI берёт обновленный код из репозитория, запускает полностью свежий docker-контейнер, заливает в них обновлённые плейбуки из репозитория и запускает Ansible локально, в docker-контейнере;
3.2 Если первый этап прошёл успешно, в docker-контейнере запускается serverspec и проверяет, корректно ли встала новая конфигурация;
4. Если в Kitchen-CI все тесты прошли успешно, то Jenkins инициирует заливку новой конфигурации.
В идеале, весь процесс от написания плейбука и коммита в репозиторий до внесения изменений на сервера, должен проходить без нашего участия. Сильно углубляться в установку Jenkins и подробно расписывать о пайплайнах в данной статье не планируется. Первое делается без проблем из стандартных репозиториев, а второе — сугубо индивидуальное.
Jenkins
Итак, что же это такое и с чем его едят? Jenkins — это сервис непрерывной интеграции, активно используется для построения и автоматизации процесса разработки от написания кода до выкатки в продакшн. Это достаточно гибкий инструмент с большой историей и обширной поддержкой сообщества. Для него существует неисчисляемое множество плагинов и надстроек. Довожу до вашего сведения, что скоро выйдет версия 2.0. Если мы используем инфраструктуру как код, то почему бы и нам не пойти по этому пути?
Как я упоминал ранее, Jenkins можно поставить из стандартного репозитория (в нашем случае — Debian, но есть репозитории и для других ОС )
sudo apt-get install jenkins
Далее нам необходимо дать для Jenkins возможность запускать kitchen и docker-контейнеры:
Редактируем sudoers:
visudo -f /etc/sudoers.d/jenkins
Даём возможность запускать docker
jenkins ALL=(ALL) NOPASSWD: /usr/bin/docker
Перезапускаем Jenkins:
service jenkins restart
И заходим браузером на дэшборд.
Теперь нам нужно составить сценарий для того чтобы Jenkins делал всю работу за нас. Для начала создадим Item со свободной конфигурацией:
В настройках системы контроля версий выбираем git, указываем путь к git-репозиторию и учётные данные для подключения. Если вы храните всю конфигурацию в одном репозитории, то, возможно, будет удобно использовать sparse с указанием папки проекта, который будете тестировать и деплоить.
В триггерах сборки указываем периодически опрашивать SCM и устанавливаем интервал с которым будем опрашивать наш git. В этом случае следующие шаги задачи будут начинаться только если в репозиторий были внесены изменения.
Далее, в шагах сбоки указываем «Выполнение команды shell» и просто указываем шаги, которые необходимы для запуска теста плейбука и разливки:
sudo kitchen test
На этом этапе kitchen-ci запускает наши docker-контейнеры, запускает Ansible с плейбуком локально, затем запускает внутри контейнера serverspec. При желании шаги можно разделить на converge и verify.
ansible-playbook site.yml
Запускает разливку конфигурации, указанной в роли/плейбуке. Последний шаг, также, по желанию. Кто-то может не доверять машине разливать конфигурацию и делать это вручную при условии, что тесты прошли успешно. Для этого можно установить плагин для отсылки уведомления (e-mail, IRC, XMPP, благо их там много) и добавить post-build action. Таким образом, после тестов будет отправлено уведомление об удачной или неудачной сборке.
Спасибо за внимание. Удачных тестов и автоматизации!
Автор: DevOps-администратор Southbridge — Виктор Батуев.
Ссылки
Ansible
Jenkins
Kitchen-CI
Serverspec
Автор: Centos-admin.ru
