Puppet and Ansible: complementary or competing?

Over the past years, we have put our focus on building, deploying and maintaining your IT infrastructure. In doing so, we are agnostic. And in our work field, two tools for IT automation always emerge. Puppet and Ansible: complementary or competing?

Yes, of course, meanwhile we have built an extensive expertise around Puppet. But at the same time, we also stick to the main goal of our company. We always adopt an agnostic attitude and we intend to continue to do so. As far as we are concerned, Puppet and Ansible are two totally different solutions, each oriented towards a different type of use case.

Push vs pull

Puppet was launched in 2005 as a platform for infrastructure automation. They developed it in Ruby and it had a clear, platform independent approach. Ansible is more recent (it was launched in 2012) and profiles itself as a task orchestrator. They have developed Ansible in Python and it clearly focuses on Linux from the beginning (and on Red Hat in particular). Meanwhile, they also added Windows to the scope.

In general, we can say that Ansible is more suitable for small, fast, one-day deployments, while Puppet rather focuses on more complex environments and deployments requiring more time. Ansible is agentless and relies on a push model. The system administrator determines what needs to be done and pushes those instructions to the nodes.

Puppet, on the other hand, works with a master/agent model, although there is also an agentless version meanwhile. It clearly applies a pull model. In doing so, the nodes rely on the master and attract the right guidelines. The system administrator describes what he wants in Puppet. Subsequently, that descriptive language will be converted into a series of commands. Ansible, however, immediately focuses on the concrete tasks through a sequence of commands.

More differences than similarities

The differences between Puppet and Ansible become very clear when we examine concrete situations, such as configuration drift. This is the phenomenon according to which a configuration will deviate ever more from the original purpose. By default, Puppet provides the functionality for configuration drift remediation. Ansible also allows measures, but the system administrator must set them himself. This will inevitably cost time and money, and partly counter Ansible’s fast start-up.

Puppet sees nuances in the adaptations made to a configuration. Sometimes, it concerns a corrective change in order to maintain the intended configuration and to eliminate configuration drift, among other things. Sometimes, it concerns intentional change, when the system administrator consciously modifies the configuration. Ansible doesn’t make this distinction.

Another example: the different approach to the concept of CI/CD-ready and testable code. Before the system administrator will bring a server live, he performs some kind of dry-run via an abstraction layer in Puppet. This way, he can test the code and see how it will react. Ansible doesn’t offer this option, which increases the risk of the failed go-live of a server.

Complementary solutions

Should we consider Puppet and Ansible as competitors? Absolutely not! We should make optimal use of the strengths of both tools. Very often, we see that companies rely on Ansible to have a configuration up and running very quickly and that they subsequently use Puppet to manage and control the configuration in the long term.

Besides, both tools are increasingly growing towards each other. Puppet Bolt applies the same task-based approach as Ansible, while Ansible Tower positions itself as an alternative to Puppet Enterprise. Both tools have their right to exist. They have proven that by the fact that companies often rely on Ansible for a quick roll-out of Puppet.

Do you want to know more about Puppet and Ansible? Contact us! 

Do you want some help to build your IT infrastructure? Check out our offering!