We began by searching for an orchestration and configuration management tool for our test lab, and we ended up with Ansible playbooks that we ship with our product.
Automation is a key tenet of our engineering team at AppFormix. Repetitive tasks are automated, such as those surrounding continuous integration, host configuration, maintenance, and backups. This saves time and allows us to document a task, which in turn enables others to understand, contribute, and use the automation. Our engineers spend their time creating our product that provides infrastructure performance optimization for cloud-based datacenters, leaving the mundane work to computers.
We began our automation with Python and Bourne shell scripts, since we were familiar with these languages. Such scripts worked great for a set of steps to perform on a single host, but become very complex when managing several hosts (like in a cloud). We used ssh, scp, and Fabric, but found it challenging to maintain configuration about every host and handle errors robustly.
As our engineering team and deployments grew in size, we needed a sustainable tool to configure our testbeds and deploy our software. We chose Ansible for a number of reasons, including:
- Agentless. Ansible’s agentless design did not require installing new software on our hosts, which lowers the barrier the entry and reduces the maintenance effort. Ansible only requires SSH and Python on the managed host, and these familiar tools were already present on our hosts.
- Declarative syntax. Ansible’s simple, declarative syntax was very approachable to our engineers.
- Community. An active open source community that contributes not only to the core Ansible framework, but helpful modules, such as copy, apt, easy_install, lineinfile, and wait_for, that addressed our common tasks of deploying and configuring software.
We started using Ansible in our test lab by defining playbooks to configure requirements on testbeds. Not only did this help document the catalog of software we use, it saved countless engineer-hours spent setting up a new host, or changing requirements across all hosts. We now store our requirements in source control, alongside source code for tests and product. A new dependency may be pushed as a commit, and during automated tests, the testbeds will be updated appropriately. Ansible simplifies keeping testbeds in sync with evolving test requirements.
After getting our feet wet with testbed configuration, we started using Ansible to deploy our product to testbeds. The AppFormix software continuously analyzes resource utilization of an OpenStack cluster. The software includes an AppFormix agent that is installed on each OpenStack compute node. Key Ansible features, including reusable roles and dynamic inventory, enable our deployments to be more organized.
- Inventory. Defines properties and assigns roles for each host. Dynamic inventory can be input from JSON data provided by a script.
- Roles. Promote modularity in our tasks. Each role has a self-contained directory of supporting files and variables. It is easy to apply different combinations of roles to a host.
- Logging and error handling. Failures associate to a particular task in the playbook. A failure on one host does not affect others. The output of commands are captured and displayed on an error. This is a big improvement over `set -ex` in Bourne shell.
Our experience using Ansible in our test automation proved to be a huge success. We now ship the playbooks with our product. The versatility of the playbooks and roles enables us to use the same playbooks to deploy in customer environments as we use in our test lab. Ansible has minimal requirements on the remote host (only SSH server and Python 2.4+), providing us a lightweight installation tool at customer sites. Without an agent on the remote host, we can leverage Ansible’s utility without installing or maintaining any additional software on a customer’s hosts.
With Ansible's dynamic inventory, we can create an effortless installation experience on a customer's OpenStack cluster. Using OpenStack Python APIs, AppFormix discovers computes nodes in an OpenStack cluster. The Python script in Listing 1 outputs discovered hosts as JSON data that Ansible uses as a dynamic inventory for playbooks that deploy AppFormix across the OpenStack cluster.
The script in Listing 1 replaces a static inventory file when executing Ansible (see Listing 2).
In some customer environments, the OpenStack compute nodes do not have access to the Internet. As a result, the typical steps that fetch packages are not an option. We solve this problem by first copying our software to the target host, and then installing the software from the local disk. Ansible copy and apt modules make it simple to write a playbook to perform these tasks (see Listing 3).
Everyday, we are expanding our understanding of Ansible: honing the modularity of our roles, increasing effectiveness with host groups in our inventories, and employing additional modules that complement other management tools (such as Docker, OpenStack).
Are you using Ansible? Stop by the AppFormix booth at OpenStack Tokyo (booth T64) to learn about how we are using Ansible - and get free stuff!
AppFormix is the leading provider of infrastructure performance optimization for cloud-based datacenters. AppFormix increases the ROI of existing enterprise infrastructure through software that enables consistent performance of applications running in virtual machines or containers, either on-premise or in the public cloud. Operators, developers, and IT managers use AppFormix software to create a more efficient and collaborative IT experience. AppFormix is venture-backed by August Capital.