Ops already have a very well documented process to creating these environments, but it’s a slow, methodical and laborious process. The perfect low hanging fruit to prove how CM can help save time and effort.
Initially the greatest challenge I encountered with this choice of CM was that it currently does not run natively in windows environments. Some may question my decision to proceed in this path due to this point, however my decision is based on many factors. The thing I like about Ansible is that it is agentless. There does not need to be anything installed in Linux or Windows for Ansible to work with it whereas Puppet and Chef would require the addition of an agent.
There is cost as well. My client will require a centralised control mechanism to initiate the creation and provisioning of VMs on their vCenter cluster. Ansible’s solution is considerably cheaper than it’s competitors.
And finally there is the consideration of staff training and organisational adoption. Ansible I feel has the lower learning curve. As it uses YAML, it has an easier structure to learn than either puppet and chef. Ansible’s methods of structure in the form of roles allows for easy creation of playbooks that can use multiple roles in any combinations and it’s intuitive structure makes it very easy to get staff on board with it’s logical flow.
So how did I go about bringing about using a technology that won’t run on windows to provision a windows server environment?
Let’s first talk about vagrant. For those new to it, vagrant is a VM abstraction layer that allows you to easily create and delete virtualized environments in VmWare or Oracle Virtualbox intsalled on your development workstation from standard templates without all the faf and hassle of needing to manually create, install OS and set them up. With the proper provisioning commands you can get an entire environment up and running with the simple command:
Vagrant allows you to do many neat tricks. Such as spin up 2 VMs in a single call. And this is how I have managed to get around the windows/ansible problem.
My vagrant solution first defines 2 machines. The windows 2012 r2 which will be the main environment, and a minimal install centos 7 which will be the ansible control.
First the windows box is brought up, and shell commands are ran to prepare the Remote Management settings needed to allow ansible to connect. Secondly, the centos box is brought up, ansible installed and a playbook ran against the 1st VM.
Yes it is a work around, but it works far better than I expected. This now can form the template design for other development environments my client has. They would only need to change the playbooks with the correct configuration management for the application they’re developing on and be able to use the same vagrant file on all.