Ansible - The Answer to Managing Multiple Servers
An often-underestimated technical cost, both in terms of time and money, for any website or service is the maintenance and management of servers.
Being able to quickly adapt to and combat security issues, such as the infamous Heartbleed OpenSSL exploit in 2014, is critically important for the security of your website and, by extension, your users' personal information. Managing these high-profile security issues across multiple servers manually can be tricky and time-consuming, taking technical staffs' attention away from new features, bugs, or consultation for your site.
Ideally any such maintenance or upgrade should result in as little downtime as possible for the server as a whole and for individual sites to ensure your users don't experience any unexpected behaviour. Typically this involves remotely accessing each server and updating the package manually, one at a time. This process can work when you have only a few servers to manage, but with each additional server comes a heavier workload and delay for patching the issue. Each server may also have its own distinct requirements and nuances which, if left undocumented, could cause unpredictable problems during the patch, compounding the issue of additional workload.
Developers, after all, are notorious for their dislike of writing and maintaining documentation.
Ansible
There's a clear requirement that emerges from poor server documentation, slow security patching, and common configuration between servers: server management automation.
Ansible is one of several tools built to solve this problem. It allows you to express server configuration as code that you can then execute across any specified hosts. In the case of the OpenSSL update described before, the Ansible script would look something similar to the following:
- hosts: all
become: true tasks: - name: Update OpenSSL apt: name: openssl state: latest
This Ansible task will update the openssl package to the latest it can find, and can be executed across all specified servers simultaneously. In itself, this is a huge saving in terms of time, but sharing Ansible scripts amongst the technical team and keeping them under version control allows the whole technical team to discuss, change and adapt to client needs.
This is where Ansible's "server configuration as code" idea and incredibly simple syntax come into play. Each "task" is written with a name that will be read by a human being so, as long as the name is meaningful, the task is "self-documenting" and can be understood with minimal explanation.
Combining related tasks into a "role" can allow you to abstract your server stack and use tasks in different ways for different use cases. For example at tictoc, we have roles to handle setting up user authorisation, configuring firewall rules, and many more. Each have their own associated project and issue board to track problems, discussions for improvements and feature requests, similar to open-source projects on GitHub. Keeping the discussion open allows for all technical staff to have a say and contribute to further development, even without an in-depth understanding of Ansible itself.
Transitioning to Ansible
Transitioning to using Ansible from a completely manual setup takes time and care. At tictoc, one developer has spent the majority of 6 months of investment time to migrate all of our servers to being fully managed by our Ansible scripts, but allow us to quickly build new servers, react to security threats and spend less time maintaining servers and more time building and maintaining your website.
Worried your site isn't quite as secure as you first thought? Don't worry - that's what we're here to help with.