KitchenCI + Ansible для Windows і Linux

Мій колега написав прекрасний блог про локальному тестуванні ролей Ansible з використанням KitchenCI. Дуже швидкий і простий інструмент, що складається з ruby gem'ів, доступний на кожній ОС, який також працює з різними інструментами тестування (наприклад Serverspec і Pester). Колега розробляв це рішення під потреби своїх проектів (provision і deploy виключно під Windows), що на перший погляд стало проблемою, тому що:

  • Я теж люблю Ansible
  • Ansible мені потрібен, щоб управляти Linux
  • Я не хочу створювати ще один репозиторій на GitHub для окремого тестування Linux-ролей, тому що не хочу плодити сутності (Бритва Оккама наше все)
Кому цікаво, що було далі, прошу під кат.

Після невеликої дискусії ми домовилися, що я адаптують його інструмент під обидва оточення, а кінцевий користувач інструменту (будь то інженер або розробник), зможе користуватися всіма його компонентами або тільки частиною. Але для початку — короткий опис, що працює зараз.

А зараз у нас є стандартна роль Ansible, в окремій директорії лежить kitchen, в якому розташовані тести Pester для тестування конфігурації WinServer'а і налаштування, власне, самого kitchen. у файлі .kitchen є 2 конфігурації для Vagrant box ів (Ansible + Winserver, сценарії розгортання і шляхи до тестів. Кому цікаво, исходники тут.

По 4 команди в директорії kitchen, пройде наше тестування від початку і до кінця.

  • kitchen create — створить нашу віртуальну локальну інфраструктуру
  • kitchen converge — застосує ролі ansible
  • kitchen verifiy — застосує тест suite verifier'а
  • kitchen destroy — прибере за собою.
Перший раз буде виконуватися неймовірно довго (Windows box штука дуже важка), тому треба запастися терпінням.

Важливий момент, що я забув згадати: ця конфігурація — скелет ролі, яку розробник може вивчити, щоб зрозуміти як йому розробляти і тестувати свою роль. Я не уявляю собі кейс, коли розробник розробляє одну роль, яка повинна працювати на обох екосистемах.

Але тим не менш, корпоративний GitHub не гумовий, тому треба трохи економити.
Почнемо з того, що ми налаштуємо роль playbook'а, щоб вона була універсальна для обох ОС. Тут нам допоможуть банальні факти Ansible.

---
# This play installs IIS, if you run it on windows box
- name: install web-server feature
win_feature:
name: Web-Server
state: present
when: ansible_os_family == "Windows"

- name: deploy iis start page template
template:
src: iisstart.j2
dest: C:\inetpub\wwwroot\iisstart.htm
when: ansible_os_family == "Windows"

# This play installs Nginx, if you run it on linux box
- name: install nginx
yum: name=nginx state=latest
when: ansible_os_family == "RedHat"

- name: start nginx
service: name=nginx state=started enabled=True
when: ansible_os_family == "RedHat"

Як видно, у першому випадку ми встановлюємо в Windows роль IIS, у другому — встановлюємо і запускаємо Nginx.

Тепер до тестів. Створюємо нову директорію в kitchen/tests/integration/default (default — це назва нашого тест suit'a) під назвою serverspec. В ньому у нас буде всього один файл defailt_spec.rb

Я не дуже сильний в ruby, тому зробив брудно без spec-helper'а

require 'rubygems'
require 'bundler/setup'

require 'serverspec'
require 'pathname'
require 'net/ssh'

RSpec.configure do |config|
set :host, ENV['KITCHEN_HOSTNAME']
# ssh options at http://net-ssh.github.io/net-ssh/Net/SSH.html#method-c-start
# ssh via ssh key (only)
set :ssh_options,
:user => ENV['KITCHEN_USERNAME'],
:port => ENV['KITCHEN_PORT'],
:auth_methods => [ 'publickey' ],
:keys => [ ENV['KITCHEN_SSH_KEY'] ],
:keys_only => true,
:paranoid => false,
:verbose => :error
set :backend, :ssh
set :request_pty, true
end

describe package('nginx'), :if => os[:family] == 'redhat' do
it { should be_installed }
end

describe service('nginx'), :if => os[:family] == 'redhat' do
it { should be_enabled }
it { should be_running }
end

describe port(80) do
it { should be_listening }
end

Тут у нас всього три перевірки: пакет встановлено, служба запущена і на автостарте, і на порту 80 хтось слухає.

Невелика порада тим, хто, як і я, не вміє в Ruby — відповідно до документації serverspec-init згенерує вам дефолтний тест, як у прикладі вище.

Отже, роль — є, тести — є. Тепер треба налаштувати саму кухню. Колега змушений піднімати дві машини, оскільки розгорнути маленький ansible сервер набагато простіше, ніж встановити його на Windows. У моєму ж випадку встановлювати ansible роль буде сам kitchen, тому мені вистачить однієї машинки. Мій скрипт kitchen буде поменше.

---
driver:
name: vagrant
gui: true
linked_clone: true

platforms:
- name: centos_box
driver_plugin: vagrant
driver_config:
box: centos/7
network:
- [ 'private_network', { ip: '172.28.128.13' } ]
transport:
max_ssh_sessions: 1
provisioner:
name: ansible_playbook
roles_path: ../
role_name: kitchen_test_role
ansible_inventory: inventory/hosts
require_windows_support: true
require_chef_for_busser: false
ansible_host_key_checking: false
ansible_verbose: true
ansible_verbosity: 4
playbook: default_linux.yml
verifier:
name: serverspec
remote_exec: false


suites:
- name: default
verifier:
patterns:
- tests/integration/default/serverspec/default_spec.rb


У мене окремий ansible_playbook, оскільки в ньому роль виконується тільки для linux машини в інвентарному файлі.

З розробкою в загальному-то й покінчено. А пояснити kitchen'у який конфігурацією використовувати досить легко. Потрібно перед виконанням команди kitchen передати їй змінну оточення KITCHEN_YAML=«имя_нашей_конфигурации».

Наприклад:

KITCHEN_YAML=".kitchen_linux.yml" kitchen create/converge/verify/destroy.

Дякую за увагу.
Джерело: Хабрахабр

0 коментарів

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