It can often feel like we’re on a sinking ship with complex server migration tasks. There must be a better way? I’ve found there is.
Server management within operations departments and IT teams can be a tedious and repetitive task. Normally the seriously repetitive tasks such as patch management can be automated without much effort, but the management of server configuration changes, especially if they apply to multiple machines, can be a right pain to replicate.
As the infrastructure grows so do the complexities and level of effort required to track, test and implement change.
At first, manual changes seem like a good thing; they are fast to apply, but they don’t scale, and most importantly are difficult to track where and when done. Internal documentation and process control help around this but introduce a delay and difficulties in getting work done as some would see it.
The biggest challenge of all comes with server migration, a task that can, thankfully, if I’m lucky, not be a frequent one. Having to build a new server due to scaling up, down, or even splitting function usually results in a headache of what changes need to be made for all of this to work. Without any kind of auditing or documentation, there is little hope of a smooth journey. Something will be forgotten resulting in a myriad of potential issues, again I can hope for minor ones such as a few log notices right up to dreaded critical performance hit, or worst still, application crash.
Getting replication of setup consistently right with minimum risk is one of the operations department’s greatest objectives.
Simple Needs But Powerful Tools
A pair of tools I’ve found really helpful for a middle ground away from just using shell scripts at one extreme and huge solutions such as Chef at the other, are Vagrant and Ansible.
Vagrant
Vagrant is generally geared towards development teams whereby with a simple configuration file a local virtual machine can be consistently created and then destroyed as required. The idea being that during development it’s a good idea to test with a clean consistent environment each time, and with Vagrant this can be done.
Developers are not the only people who require a clean machine for testing. If a new server stack is required with complex configurations I have found Vagrant suitable for this too, and as Vagrant is not limited to a single machine, even an entire network can be modeled in a single configuration file.
For example, if a small network of say a web server, a bunch of ElasticSearch nodes and a mail server are required to all co-operate together in some way Vagrant can do that. Each machine can be specified individually within the configuration file and each one (or the whole network) can be brought up with just the command:
vagrant up
Then the provisioning tools can apply individually to each machine and so produce your network. It is an amazing tool, and what is even more amazing is that once the network has been tested locally the whole lot can be easily deployed to the cloud with a simple change of command line to switch from VirtualBox to a supported cloud provider.
That has been the most incredibly useful feature of Vagrant. Cyclic testing locally which can take all the time in the world and then instant deployment once everything is OK.
If Vagrant can handle creation and tear down, I need a tool to handle long term configuration management. My tool of choice is Ansible.
Ansible
This tool operates on a number of YAML files that define the configuration required. This is as varied as you can imagine, the installation of various packages, services that are required to be in whatever state they need to be, what configurations specific services require and more. These YAML files are easily understood and provide a level of natural documentation for the state of those machines.
When other features such as role-based configurations come into play, further levels of granular control provides a very easy way to replicate (i.e. migrate) servers based on their role. For example having roles such as ‘common’ whereby all configuration requirements for a basic server are considered, and specific roles like ‘webserver’ containing all of the packages and detailed configuration for an uncommon deployment really makes for fast (re)deployment of features across the infrastructure.
What is more, any change to a ‘role’ configuration file, for example, will affect all servers that use that role. Multiple machines can then be affected, and coupled with the Vagrant switch between local and cloud, testing before live deployment is a reality.
Just those two tools can make a huge difference to many aspects of routine tasks. Try it if you don’t already. I know it will save you much grief and sanity!
