I was going to publish the first part of my review of the Packt book Learning Ansible after every couple of chapters, but the preface and 1st chapter are pretty substantive not mention starts to address some of my questions regarding Ansible compared to Puppet and Chef.

So the first thing that is sticking is that the author’s style is a very easy to read flowing style. It means that your entire focus is on the content, and you don’t feel like you’re being lectured.

The preface is carries a lot of really valuable content setting the context and capabilities into which Ansible is working. It openly identifies the other leading products covering the different aspects in which someone interested in the space would want to know about or may already understand. So the following areas are called out:

• Configuration Management
• Provisioning
• Deployment
• Orchestration
• Monitoring and Alerting
• Logging

Chapter 1 pretty much faces into the question of differentiating Ansible from Chef and Puppet. The key being that Ansible is not a master and distributed client model which Puppet and Chef offer (although both offer a Masterless models which just distribute the client). What is missing from this initial conversation is that consideration of security. In a master and client model security can be stronger because even if you compromise the master, you still have an intermediary in the agent to protect against malicious actions. Where as breaching the Ansible node means you will have obtained SSH access to all the nodes available for management as this is how Ansible interacts with the nodes it is managing.

Despite this, the arguments are simply laid out, particularly the other significant difference is that a lot of the client-agent approaches mean they offer an abstraction of the types of activities you might want for example install an application which are abstracted from the likes of msi, yum, Red Hat Network and so on. The argument for not having this is that to provide abstraction you potentially end up dropping to the lowest common denominator (unless the tool implements capabilities not naturally available on the platform). A very fair and valid argument. It is also likely in an enterprise environment you’re probably using a small set of different types of environment and potentially only type type of environment for different solutions I.e. Your website is unlikely to be hosted by servers running Red Hat, Debian, Ubuntu and Fedora.

The first chapter takes you through a series of simple examples derived from a classic variant of IT’s classic Hello World solution. This does make for a sizeable first chapter (about 1/5th of the book) but does introduce all the core principles, ideas and capabilities that are embodied and provided by Ansible. If you want to know whether Ansible is likely to meet what you want to do then reading just this chapter will probably give you a view on whether you’re likely to be able to do what you want.

Although the book makes references to the support of Windows, but this is still in Alpha phase (Ansible Windows is Coming).This does mean that the examples are Linux only. Additionally it appears from the ansible site (the book doesn’t provide any indication of this) the central Ansible node(s) will still have to be Linux. The book in this case appears to trying to future proof itself. We hope that the author will provide Windows equivalent downloadable demos.

The long and short of it, a great start to a book.