KitchenCI + Ansible for Windows and Linux

My colleague wrote an excellent blog about local testing of Ansible roles using KitchenCI . A very fast and simple tool consisting of ruby ​​gems, available on each OS, which also works with different testing tools (for example, Serverspec and Pester). A colleague developed this solution for the needs of his projects (provision and deploy exclusively for Windows), which at first glance became a problem, because:

• I love Ansible too
• I need ansible to manage linux
• I don’t want to create another repository on GitHub for a separate testing of Linux roles, because I don’t want to create entities (Occam's razor is everything)

Who cares what happened next, please under the cat.

After a bit of discussion, we agreed that I would adapt his tool for both environments, and the end user of the tool (be it an engineer or a developer) would be able to use all of its components or only a part. But first, a brief description of what is working now.

And now we have the standard Ansible role, in a separate directory is the kitchen, in which the Pester tests are located to test the WinServer configuration and the settings of the kitchen itself. In the .kitchen file there are 2 configurations for Vagrant boxes (Ansible + Winserver), deployment scripts and paths to tests. Who cares, the source here .
')
According to 4 teams in the kitchen directory, we will pass our testing from the beginning to the end.

• kitchen create - will create our local virtual infrastructure
• kitchen converge - apply the role of ansible
• kitchen verifiy - apply the test suite from the verifier
• kitchen destroy - removes it.

The first time will be performed for an incredibly long time (the Windows box is very hard), so you need to be patient.

An important point I forgot to mention is that this configuration is the skeleton of a role that a developer can learn in order to understand how to develop and test his role. I can’t imagine a case when a developer develops one role that should work on both ecosystems.

Nevertheless, the corporate GitHub is not rubber, so you need to save a little.
To begin with, we will configure the playbook role to be universal for both OSs. Banal facts Ansible will help us here.

--- # 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" 

As you can see, in the first case we install the IIS role in Windows, in the second we install and run Nginx.

Now to the tests. Create a new directory in kitchen / tests / integration / default (default is the name of our test suit'a) called serverspec. In it we will have only one file defailt_spec.rb

I'm not very good at ruby, so I did it dirty without a 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.imtqy.com/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 

Here we have only three checks: the package is installed, the service is running both on autostart and on port 80 someone is listening.

A little advice for those who, like me, do not know how to use Ruby - according to the serverspec-init documentation, it will generate a default test for you, as in the example above.

So, the role is, there are tests. Now you need to configure the kitchen itself. A colleague is forced to raise two machines, because deploying a small ansible server is much easier than installing it on Windows. In my case, installing the ansible role will be the kitchen itself, so one machine will suffice for me. My kitchen script will be smaller.

 --- 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 

I have a separate ansible_playbook, because in it the role is performed only for the linux machine in the inventory file.

With the development in general, and done. And to explain to the kitchen what configuration to use is quite easy. Before executing the kitchen command, you need to pass the environment variable KITCHEN_YAML = "our_configuration_name" to it.

For example:

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

Thank you for attention.