Disclaimer
The following is a review of a presentation given at FLOSSUK Spring DevOps Conference. The event was held at Mary Ward House in London between 15th-17th March 2016. Although this is a description of a presentation with some dissection of what was discussed it is not a verbatim account and will contain personal impressions and interpretation. The content therefore does not reflect the quality of the original presentation and should be considered a review and personal opinion.
This is one of a series of reviews of the talks I saw at the event.
Configuration Management
The conference had a strong feel of configuration management to it and the second talk on the subject I attended was from Paul Waring about using Ansible. A section of Paul’s talk was a little confusing to me as I lost the thread in the second half of his presentation. This was less to do with Paul’s presentation style and more my inexperience with the subject and sitting too far to the back of the room so that I couldn’t follow the slides (again this wasn’t Paul’s fault the room had very large windows and no blinds).
To begin Paul discussed why there was a need for Configuration Management, the situation was that packaging and installation was a manual process. This was boring for the developer to repeatedly perform; time consuming, and so therefore costly; prone to mistakes, mostly due to the first two reasons.
Paul at the start of his presentation
Ansible seeks to solve this issue, in much the same was as Chef, a major difference is that Ansible calls orchestration a ‘playbook’.
All About Ansible
Ansible is fully open source software and protected under the GPL3, it is available on Github. Ansible has been incorporated into the RedHat Linux distributions when they acquired the parent company that supports its development.
Ansible has a minimal set of dependencies and these are found in most Linux distributions. It also works cross environment to the other popular operating systems. It has become known as working well in both smaller environments as well as large server farms. It goes without saying that Ansible has probably the best integration with RedHat which is a favoured distribution in corporate environments. If you have a larger configuration management, change management or process management plan then Ansible can be a player.
Ansible is written in an INI format which is based on the principle that it is easy to configure and to write. In this manner if the requirement is for a small rollout of a staging and deployment server then Ansible works well for easy replication. The requirement is that the person configuring Ansible must be in a User Trust Status or logged in as Root. You can specify keys and host names if required.
Ansible uses a distributed environment for adding extra features which are created as modules. To configure Ansible you write a set of instructions (a dance) in the playbook.
Ansible works well with Git for a central repository, you can use other management systems like CVS and SVN. The advantage of using Git is the powerful way in which it uses rollback, undo and rebase, the good view history and the cheap method for utilising branches. You can also use Git-Hooks to perform actions in the workflow both as pre- or post-commit. This would allow you to perform tasks such as running unit tests, checking syntax and checking dependency structure.
Ansible seems like a lighter configuration system than Chef or Puppet and using Git as an extra layer for working with this adds to its value. Much like Thom’s talk Paul was able to convey how Ansible works it was just unfortunate to me that I couldn’t read the examples he gave on his slides.
[Don't forget that you can join in this conversation by using the comments form or by tweeting at @shadowcat_mdk]
Notes
*
