Ansible: тестуємо плейбуки (частина 2)

Отже, в нашій попередній статті ми розглянули як можна швидко і просто налаштувати середовище для тестування плейбуков і ролей Ansible. Це все, звичайно, дуже добре і зручно, але чому б нам не автоматизувати весь процес внесення змін в інфраструктуру від написання плейбука до внесення змін сервера?

image

Нагадаю кілька умов, при яких ми будемо виконувати тестування конфігурацій:

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-адміністратор Міст — Віктор Батуев.

Посилання
Ansible
Jenkins
Kitchen-CI
Serverspec
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.