Getting a New Perspective with Ansible

Our world is shaped by increasing technical debt and operational complexity, nestled within layers of abstraction to the point where daily life needs documentation and an operating manual. As the operational needs of organizations and individuals march onward toward the next generation of post-hype micro-services, reigning in this complexity has become a Sisyphean task.

At all layers of the software and hardware stack, the amount of information needed to fully understand and run modern systems in production has exploded. Many of those designing modern systems have no concept of the simple beauty offered by the bygone eras of computing—even if in hindsight those systems were a house of cards standing proudly for only the implied societal code of ethics not to kick someone else’s sandcastle down.

The situation we now find ourselves in makes it difficult for the average person to have a resilient blog running on unmanaged hosting platforms, lest maintenance consumes their day-to-day lives.

But instead of succumbing to the Sisyphean boulder, we can reign in these systems and orchestrate this complexity. We need not recall every nuance of each tool we use when a tool can do it for us.

Long ago, in the bad before times

We won’t go too far back—depending on when you are reading this—though we will return to the initial age of the humble LAMP stack. Through the anagram alone it’s only four things: Linux, Apache, MySQL, and PHP. How hard can it be to manage FOUR things?

Well, pretty hard, as it turns out.

The amount of CVEs alone is difficult to sift through, let alone figuring out exactly what the implications were is daunting.

• Linux Kernel CVEs – ~2333
• Apache CVEs – ~225
• MySQL CVEs – ~205
• PHP CVEs – ~600

Depending on how many systems you manage, it can be difficult to ensure they all have the same configuration to mitigate issues. Are you sure you updated the configuration files, restarted services, and handled everything else on the checklist for each system? When you hit your tenth server or virtual machine, it should be enough to make any person question the meaning of existence.

Future updates need to be managed carefully and numerous man hours must be spent verifying which components of the system need to be changed to meet new requirements. Failure to do so can lead to security breaches or even outages after changes are made. The risks to the reliability of these systems we craft and the effort needed to avoid risks only increase as users demand more reliable and flexible systems.

How do we fix this, I’m scared

This struggle between improving networks and navigating labyrinthine maintenance is shared among administrators from the most amateur to enterprise level, whether it’s a casual user hoping a required package update won’t conflict with others or an international company hoping a new product launch will integrate seamlessly with their existing infrastructure. 

At InMotion Hosting, we’re finding Ansible to be a superb technology to ease this struggle as we work to improve our own services and provide more for our customers. Ansible provides a simple workflow to automate repetitive, tedious, and complex operations in almost any system context. 

The machine on which Ansible is installed, known as the control node, pushes operations to one or more connected machines known as managed nodes. Ansible itself runs on a declarative philosophy in which operations are run by checking the existing state of the managed node against the desired, declared state, and then automatically bringing the node to the desired state. This approach gives administrators the freedom to focus on other tasks.

Ansible also facilitates configuration management, allowing users to more easily control aspects of systems across their network, such as changing multiple servers to a new version for a package.

While many tools exist to aid in automation and configuration management, Ansible has a low barrier to entry. It requires only Python on the control node with a method such as SSH to communicate to managed nodes. Getting started with Ansible only requires user familiarity in a command line tool and text editor and most components are written in YAML, a human-readable language. This makes Ansible both easy to learn and easy to teach to others. Even better, with the robust Ansible ecosystem of user-made modules, numerous opportunities exist for non-experts to jump into high-quality automation while working with relatively straight-forward YAML files. 

For those who want to go even further, Ansible is more than happy to oblige. As an open source project based in Python, extending Ansible for one’s own purposes is another low barrier to entry proposition with a large and active community already contributing across hubs like Ansible Galaxy. Ansible components, also known as roles, can also be used modularly allowing one to build even more complex interactions by re-using roles or combining their application to a managed node. 

As an example, InMotion Hosting’s UltraStack platform provides a caching system used for NGINX-powered WordPress. By codifying this configuration in open source Ansible roles, we’ve increased our ability to manage and apply these configurations within our own environment as well as facilitate more varied platforms in the future. Our users can also add on to these roles, allowing them to take the aspects of UltraStack they like or use it as a base for their own configurations. To assist with getting Ansible in the hands of more automation enthusiasts we also offer a free Ansible Control Node to both customers and the public.

Ansible for Private Cloud

Another case where Ansible has been extremely powerful is in our private cloud solutions. The main deployment system for our cloud comprises a set of ansible playbooks to deploy each aspect. We accomplish this by using ansible-runner to configure and run Ansible playbooks programmatically, which includes using ceph-ansible and kolla-ansible for deploying OpenStack in various configurations. When coupled with Bifrost and an omnipotent internal backend for doing most of the heavy lifting, we can provision a set of baremetal nodes, generating the private cloud configuration needed for the playbooks to run properly based on the options a user has selected.

While Ansible is impressive in its application, there are use cases in which administrators might benefit more from another automation solution. In involved orchestration across thousands of servers, Ansible can quickly suffer both in the time it takes to run jobs and the resources needed by the control node for execution. Some examples of alternatives that we also use in our ecosystem are Salt and Puppet. We decided to use these better-scaling methods for the 1000+ servers we run as well as for the ability to granularly change things at a very low level whenever the need arises. 

That being said, Ansible has a lot to offer IT departments across the board and is worth taking a look at. Networked computing is only going to get more complex while tools like Ansible offer administrators the ability to focus on the bigger picture of their networks, their growth, and their potential. Consider checking out the documentation based on our own projects; you might find new ways to expand your business online with increased automation and configuration management.