It’s power in its simplicity, simple to use doesn’t mean it can’t handle complex automation scenario. Think of this, you use some automation tool to deploy some resources, most of the case, you deploy x number of virtual machines (hold your horses container guys, people still deploy virtual machines) , you install and configure some stuff post installation and maybe send some notification to the end user, you can’t delegate this to non-technical users without providing a self-service portal.
So, if you are launching a script, a playbook… you name it:
- How much interaction have you done with your automation tool?
- If any problem happens during or after the deployment, how much effort do you need to spend for troubleshooting?
- How about knowledge transfer for new or existing member of the team?
So, here is scenario that I was dealing with, and by the way, this is not some deployment using Linux virtual machines, that would be too easy:
Build a SharePoint 2016 SP2 Farm based on Windows 2016 using the topology below, if you think no body deploy SharePoint on premise anymore, think of it again.
- A total of 6 vm will be built, every virtual machine should:
- Have an IP address requested from Infoblox.
- Using customer internal naming convention, generate a unique hostname and use it as internal name.
- Add those vms to the Active Directory domain
- Configure static IP address, DNS and gateway
- Enable Nutanix Guest Tools on the vm
- Add the final/requesting user as a local administrator
- Install the antivirus agent
- Then using two of those vms, build a SQL Always On cluster which involve:
- Installing failover clustering module.
- Configuring firewall rules.
- Creating the Windows cluster.
- Enabling HA on the SQL service.
- Setting the MAXDOP to 1 for SharePoint
- Creating the availability group and finally creating the listener with an ip address that you got from Infoblox.
On the rest of the 4 virtual machines:
- Install SharePoint requirement in an offline mode (we were in a Dark site)
- Install SharePoint 2016 with a slipstreamed service pack 2
- Configure SharePoint
- And finally check if everything is installed, if so, protect the SharePoint database using the SQL cluster Always On availability group that we deployed before.
All of this is done with a single blueprint, with zero touch configuration from the end user, all he must do is give the application name, Windows cluster name and SQL cluster name, the last two can be of course automated.
So now imaging how much dependency and constraints are you dealing with like:
- Setting SQL Server parameter and protecting the database (when and how?).
- Managing VM reboot (many!!)
- Setting up Active directory delegation on OU and on file share for the cluster Witness.
- Timing between interaction.
- Cleaning up if the user decides to remove this deployment (IP address on Infoblox, file share witness, Active directory permissions, users, groups and computer object…)
I used PowerShell, Escript (stripped down version of Python used in Calm) and some bash to build this blueprint, so if you have a team with different coding skills, you can spread the dev effort for more complex scenario
Below is a short video of the result, I had to fast forward/cut some part of it (too many vm reboot :D)