Ansible: testing playbooks (part 2)

So, in our last article, we looked at how you can quickly and easily set up an environment for testing playbooks and Ansible roles. This is all, of course, very good and convenient, but why don't we automate the entire process of making changes to the infrastructure from writing a playbook to making changes to the servers?



Let me remind you of several conditions under which we will perform configuration testing:
')
1. All configuration is stored in the git-repository;
2. Jenkins periodically polls the git repository with our roles / playbooks for changes;
3. When changes appear, Jenkins runs a job with configuration testing. Tests consist of two stages:
3.1 Kitchen-CI takes the updated code from the repository, launches a completely fresh docker-container, floods the updated playbooks from the repository and launches Ansible locally in the docker-container;
3.2 If the first stage was successful, the serverspec is started in the docker-container and checks whether the new configuration correctly stood up;
4. If in Kitchen-CI all tests were successful, then Jenkins initiates the filling of a new configuration.

Ideally, the whole process from writing a playbook and commit to the repository to making changes to the server should take place without our participation. It is not planned to go deep into the Jenkins installation and to describe in detail about the pipelines in this article. The first is done without problems from standard repositories, and the second is purely individual.

Jenkins

So what is it and what is it eaten with? Jenkins is a continuous integration service that is actively used to build and automate the development process from writing code to rolling out to production. This is a fairly flexible tool with a long history and extensive community support. For him, there is an uncountable set of plug-ins and add-ins. I bring to your attention that version 2.0 will be released soon. If we use infrastructure as a code, then why shouldn't we go this way?

As I mentioned earlier, Jenkins can be supplied from the standard repository (in our case, Debian, but there are repositories for other OSs )

sudo apt-get install jenkins 

Next, we need to give Jenkins the opportunity to run the kitchen and docker containers:
Editing sudoers:

 visudo -f /etc/sudoers.d/jenkins 

We give the opportunity to run docker

 jenkins ALL=(ALL) NOPASSWD: /usr/bin/docker 

Restart Jenkins:

 service jenkins restart 

And we go to the dashboard browser.

Now we need to create a script for Jenkins to do all the work for us. First, create an Item with a free configuration:



In the settings of the version control system, select git, specify the path to the git repository and the credentials for the connection. If you store the entire configuration in one repository, then it may be convenient to use sparse with the indication of the project folder that you will test and deploy.



In the assembly triggers, we specify to periodically poll SCM and set the interval with which we will poll our git. In this case, the next steps of the task will begin only if changes have been made to the repository.

Next, in the assembly steps, we indicate “Execution of the shell command” and simply indicate the steps that are needed to start the playbook test and casting:

 sudo kitchen test 

At this stage, kitchen-ci launches our docker containers, launches Ansible with a playbook locally, then launches inside the serverspec container. If desired, the steps can be divided into converge and verify.

 ansible-playbook site.yml 

Starts casting of the configuration specified in the role / playbook. The last step is also optional. Someone may not trust the machine to spill the configuration and do it manually, provided that the tests were successful. To do this, you can install a plugin to send a notification (e-mail, IRC, XMPP, because there are many of them) and add a post-build action. Thus, after the tests will be sent a notification of successful or unsuccessful assembly.

Thanks for attention. Successful tests and automation!
Author: DevOps admin Southbridge - Victor Batuev.

Links

Ansible
Jenkins
Kitchen-ci
Serverspec