Using Ansible to Manage Jet Infrastructure
Ansible is a configuration management tool. It treats your infrastructure and configuration as simple text files in YAML. You describe what you want in text, without caring about the implementation details. In other words, we can ask Ansible, “Make me a pizza,” and it will make us one without describing the process of obtaining each ingredient and assembling them. Our team uses it to create machines and set up software.
Scale necessitates automation. Without it, you’ll quickly find yourself overwhelmed with the torrent of requests for new and updates to existing servers. We also like to treat our infrastructure as code. Code can be reviewed, compared, refactored, and re-deployed. Jet runs thousands of VMs in the cloud — way too many to manage manually.
Take a Look at Ansible
Tasks make up the core of our infrastructure configuration. Each task runs a Module. A module knows how to get that task done. This means a module is like a function, and a task is like calling that function with arguments.
Here are some example tasks: One that creates an nginx group, and then another that creates an nginx user.
- name: create nginx group
- name: create nginx user
A Play is a set of tasks that achieve some goal on a set of hosts. A Play Book can execute any number of plays. You should also gather related tasks into Roles that can be referenced in plays instead of writing tasks into them directly. So, you can think of a role as a super-task — it has a goal that requires several tasks to complete.
Below is an example of a playbook that contains a single play. The play runs on every host in the ‘my_websites’ group and installs common stuff, nginx, and the nginx website config. Then it defines a task directly to reload nginx.
- hosts: my_websites
- name: reload nginx
Why Do We Like Ansible?
Sorry 007, but Ansible uses the standard remote capabilities of the OS. Therefore, we can configure Linux machines directly over SSH and Windows machines using PowerShell Remoting (WinRM). This means that when you harden your servers access for WinRM and SSH, you also harden Ansible as well.
The Ansible distribution contains core modules and extra modules. Between these two sets, it is rare to find a gap in functionality. Also, there are modules for interacting with the Azure API, and modules for creating users and groups. You’ll also find modules for interacting with big iron switches and networking equipment. Since windows support is newer, there are less available than for Linux, but the number of modules are still growing.
Easy to Extend
You can extend Ansible in many ways. We make use of custom Jinja template filters to alter the template language. Custom PowerShell modules can fill the gap since windows modules are currently scarce (but growing!). Also, if you need more power, you can write plugins to hook into the Ansible playbook lifecycle. And, if you really want, you can hack the core — it is open source after all.
If you’re using a bundle of ad hoc scripts to provision and configure your VMs, I’d urge you to give it a try. Since you don’t need to install anything on the server, there is very little commitment upfront.
If you want to learn more about how Jet uses Ansible to provision VMs, check out this talk I gave at AnsibleFest Brooklyn 2016