Ansible: тестируем плейбуки (часть 1)

Думаю, любой системный администратор, использующий Ansible для управления своим зоопарком серверов задавался вопросом о проверке корректности описания конфигурации своих серверов. Как же не бояться вносить изменения в конфигурации серверов?
В серии статей, посвященных DevOps, мы расскажем об этом.

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

1. Вся конфигурация хранится в git-репозитории.
2. Jenkins (CI-сервис) периодически опрашивает репозиторий с нашими ролями/плейбуками на предмет внесённых изменений.
3. При появлении изменений Jenkins запускает сборку конфигурации и покрывает её тестами. Тесты состоят из двух этапов:
3.1 Test-kitchen берёт обновленный код из репозитория, запускает полностью свежие docker-контейнер, заливает в них обновлённые плейбуки из репозитория и запускает ansible локально, в docker-контейнере.
3.2 Если первый этап прошёл успешно, в docker-контейнере запускается serverspec и проверяет, корректно ли встала новая конфигурация.
4. Если в test-kitchen все тесты прошли успешно, то Jenkins инициирует заливку новой конфигурации.

Конечно, можно запускать каждый плейбук/роль в Vagrant (благо, там есть такая крутая штука как provisioning ^[1]), проверять, что конфигурация соотвествует ожидаемой, но каждый раз для теста новой или изменённой конфигурации выполнять столько ручных действий — сомнительное удовольствие. Зачем? Ведь можно всё автоматизировать. Для этого к нам приходят такие замечательные инструменты как Test-kitchen ^[2], Serverspec ^[3] и, конечно же Docker ^[4].

Давайте для начала рассмотрим, как нам тестировать код в Test-kitchen на примере пары сферических ролей в вакууме.

Ansible.

Ansible я собирал последний, самый свежий из исходников. Предпочёл собирать руками. (кому лень — можно воспользоваться Omnibus-ansible ^[5])
git clone git://github.com/ansible/ansible.git --recursive
cd ./ansible

Собираем и устанавливаем deb-пакет (тестировать плейбуки будем на Debian).
make deb
dpkg -i deb-build/unstable/ansible_2.1.0-0.git201604031531.d358a22.devel~unstable_all.deb

Ansible встал, проверим:
ansible --version
ansible 2.1.0
config file = /etc/ansible/ansible.cfg
configured module search path = Default w/o overrides

Отлично! Значит, пора перейти к делу.

Теперь нам необходимо создать git-репозиторий.

mkdir /srv/ansible && cd /srv/ansible
git init
mkdir base && cd base # Создаём папку проекта с конфигурацией


Архитектура репозитория примерно следующая:

├── ansible.cfg
├── inventory
│ ├── group_vars
│ ├── hosts.ini
│ └── host_vars
├── logs
├── roles
│ ├── common
│ │ ├── defaults
│ │ │ └── main.yml
│ │ ├── files
│ │ ├── handlers
│ │ │ └── main.yml
│ │ ├── tasks
│ │ │ ├── install_packages.yml
│ │ │ └── main.yml
│ │ ├── templates
│ │ └── vars
│ └── nginx
│ ├── defaults
│ ├── files
│ ├── handlers
│ │ └── main.yml
│ ├── tasks
│ │ ├── configure.yml
│ │ ├── install.yml
│ │ └── main.yml
│ ├── templates
│ │ └── nginx.conf.j2
│ └── vars
├── site.yml
├── Vagrantfile
└── vars
└── nginx.yml


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

ansible.cfg:

[defaults]
roles_path = ./roles/ # Папка с ролями
retry_files_enabled = False # Отключаем retry-файлы в случае неудачного выполнения таска
become = yes # Параметр эквивалентен вызову sudo
log_path = ./logs/ansible.log # логи
inventory = ./inventory/ # Путь к inventory-файлам.


Далее нам нужен inventory-файл, где нужно указать список хостов, с которыми мы будем работать.
mkdir inventory
cd invetory
mkdir host_vars
mkdir group_vars


Файл invetory:

127.0.0.1 ansible_connection=local


Здесь перечислены все хосты, которыми будет управлять ansible.
host_vars — папка, где будут храниться переменные, которые могут отличаться от базовых значений в роли.
Пример: в ansible может быть полезен jinja2-шаблонизатор при работе с файлами и конфигами.
У нас есть шаблон resolv.conf templates/resolv.conf.j2:
nameserver {{ nameserver }}


В файле переменных по-умолчанию (roles/common/defaults/main.yml) указано:
nameserver: 8.8.8.8


Но на хост 1.1.2.2 нам нужно залить resolv.conf с другим значением nameserver.
Проворачиваем это через host_vars/1.1.2.2.yml:
nameserver: 8.8.4.4


В этом случае, при выполнении плейбука на все хосты зальётся стандартный resolv.conf (со значением 8.8.8.8), а на хост 1.1.2.2 — со значением 8.8.4.4.
Подробнее об этом можно почитать в документации Ansible ^[6]

common-role

Это роль, которая выполняет стандартные задачи, которые должны выполняться на всех хостах. Установка каких-нибудь пакетов, к примеру, заведение пользователей, etc.
Структуру я немного описал выше. Пройдёмся по подробностям.

Структура роли:
./roles/common/
├── defaults
│ └── main.yml
├── files
├── handlers
│ └── main.yml
├── tasks
│ ├── install_packages.yml
│ └── main.yml
├── templates
└── vars


В файле roles/common/defaults/main.yml указаны переменные, задаваемые по-умолчанию.
---
deb_packages:
- curl
- fail2ban
- git
- vim

rh_packages:
- curl
- epel-release
- git
- vim


В папке files лежат файлы, которые должны быть скопированы на удалённый хост.
В папке tasks перечислены все задачи, которые должны быть выполнены при присвоении хосту роли.
roles/common/tasks/
├── install_packages.yml
├── main.yml


roles/common/tasks/install_packages.yml
---
- name: installing Debian/Ubuntu pkgs
apt: pkg={{ item }} update_cache=yes
with_items: "{{deb_packages}}"
when: (ansible_os_family == "Debian")

- name: install RHEL/CentOS packages
yum: pkg={{ item }}
with_items: "{{rh_packages}}"
when: (ansible_os_family == "RedHat")


Здесь использованы циклы with_items и when. Если дистрибутив семейства Debian — будут установлены пакеты из списка deb_packages с помощью модуля apt ^[7]. Если дистрибутив семейства RedHat — будут установлены пакеты из списка rh_packages с помощью модуля yum ^[8].

roles/common/tasks/main.yml
---
- include: install_packages.yml


(Да, я очень люблю декомпозировать роли на отдельные файлы со своими задачами).

В файле main.yml просто инклудятся yaml-файлы, где описаны все задачи, описанные в папке tasks.

В папке templates лежат шаблоны в формате Jinja2 ^[9] (выше был рассмотрен пример с resolv.conf).

В папке handlers перечислены действия, которые могут совершать после выполнения каких-либо тасков. Пример: имеем кусок таска:
- name: installing Debian packages
apt: pkg=fail2ban update_cache=yes
when: (ansible_os_family == "Debian")
notify:
- restart fail2ban


и хэндлер roles/common/handlers/main.yml:
---
- name restart fail2ban
service: name=fail2ban state=restarted


В этом случае после выполнении таска apt: pkg=fail2ban update_cache=yes запустится задача-хэндлер restart fail2ban. Другими словами fail2ban перезапуститься сразу, как только будет установлен. В противном случае, если fail2ban в нашей системе уже установлен, то нотификация и запуск хэндлера будут проигнорированы)

В папке vars можно указать переменные, которые должны использоваться не по-умоланию.
/vars/common.yml
---
deb_packages:
- curl
- fail2ban
- vim
- git
- htop
- atop
- python-pycurl
- sudo

rh_packages:
- curl
- epel-release
- vim
- git
- fail2ban
- htop
- atop
- python-pycurl
- sudo


Test-kitchen + serverspec.

Ресурсы, которые были использованы:

serverspec.org/resource_types.html ^[10]

github.com/test-kitchen/test-kitchen ^[11]
github.com/portertech/kitchen-docker ^[12]
github.com/neillturner/kitchen-verifier-serverspec ^[13]
github.com/neillturner/kitchen-ansible ^[14]
github.com/neillturner/omnibus-ansible ^[5]

Test-kitchen — это инструмент для интеграционного тестирования. Он подготавливает среду для тестирования, позволяет быстро запустить контейнер/виртуальную машину и протестировать плейбук/роль.
Умеет работать с vagrant. но мы в качестве провайдера будем использовать docker.
Устанавливается как гем, можно использовать gem install test-kitchen, но я предпочитаю использовать bundler. Для этого необходимо в папке с проектом создать Gemfile и прописать в нём все гемы и их версии.
source 'https://rubygems.org'

gem 'net-ssh','~> 2.9'
gem 'serverspec'
gem 'test-kitchen'
gem 'kitchen-docker'
gem 'kitchen-ansible'
gem 'kitchen-verifier-serverspec'


Очень важно указать версию гема net-ssh, т. к. с более новой версией test-kitchen, вероятно, работать не будет.
Теперь нужно выполнить bundle install и подождать пока все гемы с зависимостями установятся.
В папке с проектом делаем kitchen init. В папке появится файл .kitchen.yml, который необходимо привести примерно к следующему виду:
---
driver:
name: docker

suites:
- name: Common
provisioner:
name: ansible_playbook
playbook: test/integration/default.yml
verifier:
patterns:
- roles/common/spec/common_spec.rb


На этом этапе у меня возникли сложности с запуском serverspec в контейнере, поэтому мне пришлось применить небольшой workaround.
Все образы собраны мной и выложены в dockerhub ^[15], в каждом образе заведён пользователь kitchen, из под которого выполняются тесты, и установлен rvm с версией ruby 2.3.
Параметр additional_serverspec_command указывает, что мы будем использовать rvm. Это способ, при котором не нужны танцы с бубном вокруг версий ruby в стандартных репозиториях, зависимостями гемов и запуском rspec. В противном случае, с запуском serverspec-тестов придётся попотеть.
Дело в том, что kitchen-verifier-serverspec ещё довольно сыроват. Пока писал статью — пришлось отправить несколько баг-репортов и PR автору.

В секции suites мы указываем плейбук с ролью, которые будем проверять.
playbook: test/integration/default.yml
---
- hosts: localhost
sudo: yes
roles:
- common


и patterns для теста serverspec.
verifier:
patterns:
- roles/common/spec/common_spec.rb


Как выглядит тест:
common_spec.rb

require '/tmp/kitchen/roles/common/spec/spec_helper.rb'

describe package( 'curl' ) do
    it { should be_installed }
end

Здесь также очень важно указать в заголовке require именно такой путь. Иначе, он не найдёт и ничего работать не будет.

spec_helper.rb

require 'serverspec'
set :backend, :exec

Полный список того, что serverspec умеет проверять указан тут ^[10].

Команды:

kitchen test — запускает все этапы тестов.
kitchen converge — запускает плейбук в контейнере.
kitchen verify — запускает serverspec.

Результаты должны быть примерно такие:

При выполнении плейбука:
Going to invoke ansible-playbook with: ANSIBLE_ROLES_PATH=/tmp/kitchen/roles sudo -Es ansible-playbook -i /tmp/kitchen/hosts -c local -M /tmp/kitchen/modules /tmp/kitchen/default.yml
[WARNING]: log file at ./logs/ansible.log is not writeable and we cannot create it, aborting

Finished converging <Common-ubuntu-1404> (3m58.17s).


При запуске serverspec:
Running Serverspec

Finished verifying <Common-ubuntu-1404> (0m0.93s).


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

А как вы проверяете свои плейбуки?

Автор: DevOps-администратор Southbridge ^[16] — Виктор Батуев.

Автор: Centos-admin.ru

Источник ^[17]