Ansible is a buzz word at the moment. Ever since Redhat purchased Ansible back in 2016, it has been rare to hear about anyone deploying alternative automation systems. Recently Ansible has been commercialized into Ansible Tower allowing a wider audience to take advantage of the benefits of automation.
I recently attended a Redhat event where they were pushing Ansible as “if you’re not using Ansible, you’re doing things wrong” and generally speaking i agree. Even if you’re using Ansible for some tasks but not all, you’ll be realizing its time saving impact. And once you’re using Ansible “just a little” you’ll soon find yourself using it a whole lot more for tasks you never imagined automating.
Your mindset should be “i want this system to look like X” and then create/customize your Ansible Playbooks to achieve the desired state. Then you can “point and shoot” your Ansbile tool at the IT resources and see the environment changing to reflect that desire.
Ansible is modular meaning that over time, more capabilities will become available. At the start you’d most likely use it for making a single change across multiple devices (like adding a user account to 50 servers) and over time you’ll add more tasks – and not just to servers. Ansible has modules to manage routers, firewalls, cloud environments (such as AWS and Azure).
Imagine having the ability to create a VPC in AWS, spin up a few EC2’s in that VPC with web services installed and configured, add appropriate firewalls and NAT/IG’s to the VPC, and finally deploy the web application to the EC2’s. The first time you do it, it will take your time. You have to create (or re-use publicly available) Anisble Playbooks. The best part is that you’ll end up with a whole pile of re-usable Ansible Playbooks that you can dig up later for other projects.
Linux system administrators have either heard about Ansbile or are already using it. Windows system administrators are probably less aware that Ansible can help them too. Apparently the key person for Ansible+Windows is in Australia – nice. One issue i have with Anibsle is that it’s less abstract than Puppet in that you must specify the package by package name (such as “httpd” on Redhat and “apache2” on Debian) and it differs between systems and the package manager too (such as “yum” and “apt”). I’ve heard from Redhat that there are plans to change this to allow more abstract functionality. I don’t know how this will look (perhaps something like “pkg name=apache” rather than “apt: name=apache2”). Either way, i’m looking forward to it. It means that Playbook authors can write a single Playbook and have it work on all platforms (Redhat, Debian, Windows, etc). I realize that’s possible already through crafty work but “let’s keep it simple”.
I’ll end this article with a high recommendation to use automation where-ever possible. It will be your best friend.