Out of the many configuration management and deployment tools, one that has been gaining traction for the past few years is Ansible. At Box UK we have been using Ansible since around version 0.7 and up until recently we only used it to automate Linux hosts.
We use Ansible because it uses no agents and requires no additional custom security setup. Ansible playbooks are easy to read since they are described in YAML. This low learning curve allows anyone interested in automation to contribute to our internal playbooks and read how our infrastructure is currently set up.
We currently do lots with Ansible; however we can do lots more. So far we have been using it for:
We were fairly limited to Linux hosts until Ansible 2.0 arrived in early 2016, offering expanded Windows modules which we can use to automate our infrastructure.
With the majority of our infrastructure being automated we have started to look into automating Windows. The first playbook we wrote was to manage server access users since we have Windows servers across multiple different locations (AWS, Azure, etc.) and different cloud accounts. Managing AD domains across all these servers would be overkill and we wanted a simple way to grant people access to servers and a simple way to change passwords.
We are now in the process of automating Sitecore deployments to Windows hosts. This will allow us to treat Sitecore installations as immutable which will prevent any differences between environments (QA, UAT, staging and live). If an installation goes bad we can easily re-create the server.
While Ansible now offers expanded support for Windows, the modules available still don’t compete with what Ansible has to offer for Linux. We are confident though that this will change over time, as it did with Linux. As it is, we are now using one tool for both Linux and Windows which lowers the overhead of maintaining two types of operating systems, as you would have to if you were using two completely different toolchains.