We are pleased to announce our latest open-source release – a Dynamic Ansible Inventory for use with Skytap Environments. Ansible is commonly used by DevOps teams to coordinate configuration changes for hosts over SSH (for Linux/Unix machines) or Powershell remoting (Windows). Ansible’s simple approach and ease of integration with existing infrastructure make it an attractive utility for teams that need a flexible, lightweight way to ensure that collections of hosts share a desired state.
We’ve solved some of our own test automation problems with Ansible, and have written a brief dynamic inventory that will retrieve hostnames and IP’s from the Skytap API and construct an inventory for use with Ansible. Since we are fans of open source and love enabling a robust software development life-cycle, we’ve decided to share our own work with the world. Check out our Github page for this (and other) open source offerings from Skytap.
Curious about how your team might leverage something like Ansible, or how this dynamic inventory relates to your Skytap Environments? Read on!
Code your Infrastructure
Here at Skytap we’re believers in DevOps. In “How I Learned to Love Environment Proliferation,” Kelly Looney discusses the need for infrastructure as code. Skytap’s EaaS model allows DevOps teams to streamline their SDLC with the creation of ‘golden’ environment templates, which are used to eliminate the problem of environment drift. How useful are your tests if you can’t be sure that your Test environment and Certification environment have the same configuration and infrastructure, after all?
The EaaS model is, of course, a boon to organizations who are embracing the DevOps philosophy – but it isn’t a magic bullet. We still have to change things within the environments as we iterate. We still have some operational and maintenance concerns, even for Dev and Test environments.
DevOps is about mutual awareness of and choreography between Development, Operations and Quality Assurance concerns. For smooth interaction between these DevOps contributors, we need a common, reproducible method to exercise necessary changes, and we need a way track and version those changes as we would source code or build artifacts. Exercising and tracking changes quickly becomes problematic when we’re dealing with tens or hundreds of instances.
Furthermore, we might sometimes want to reproduce host configurations we’re running in Skytap Cloud outside of Skytap—on physical hardware, or in AWS, for example. The Skytap architecture is excellent at providing transportation and ‘cold storage’ of VM’s and whole environments within Skytap Cloud, or to on-premises based infrastructure, but experience has shown that hybrid solutions often benefit from tools that allow us to think at a higher level of abstraction.
Conducting the Orchestra
This higher abstraction is often provided by tools such as Ansible, Chef, Puppet and others. These tools are typically billed as providing “Orchestration” or “Configuration Management.” They all have slightly different design and operation philosophies, but they share a high-level goal: use configuration or code to modify the state of hosts and infrastructure. Some of them provide provisioning capabilities, others focus more on configuring hosts themselves. Each assumes some configuration will define a set of actions that will be executed on a set of running hosts.
Ansible strives to provide a light-weight configuration server that does not require the installation of client software on configuration targets. It accomplishes this by executing commands on the target hosts over the SSH (or Powershell Remoting) protocol. The learning curve for Ansible is very shallow. The un-opinionated nature of the client-server model allows for significant flexibility in use-cases – we’ve seen Ansible used for configuration management, deployment, provisioning (via VMWare or OpenStack API’s), and ad-hoc operational tasks. Internally, we use Ansible to gather information about hosts within our Dev and Test environments, and execute test tasks directly on the hosts.
Executing a command across a set of servers with Ansible is easy. You set up an inventory file (a list of hosts grouped in .ini format), and you supply Ansible either an ad-hoc command or a playbook (YAML formatted description of a task to execute). Ansible uses SSH to contact each host (in serial or parallel) and execute the desired action.
Managing inventories in the cloud can become cumbersome or even impossible – particularly in production-like environments where hosts may be added or removed from the environment in response to scaling concerns or operational problems. Ansible’s response to this is the dynamic inventory. A dynamic inventory is any script or process that can run from wherever you’re using Ansible, and which produces a JSON-formatted description of the hosts that Ansible needs to communicate with. You then run your ad-hoc command or playbook against those hosts like you would any other.
The dynamic inventory provided by skytap_inventory.py is is configured with skytap.ini (the project includes an example .ini file). Use this file to set the username, API Token, Environment ID, and network type (private, nat_vpn, nat_incr). You may also configure some SSH options for Ansible in this file.
A Simple Ansible Use-Case
$ ansible -i skytap_inventory.py all -m ping
This will use the Ansible ‘ping’ module (NOT related to ICMP ping) to test whether or not you can communicate with each host. If things are working as expected, you should see a response from each of the hosts in your environment:
someHost | success >> {“changed”: false,”ping”: “pong”}
A more useful example is to use a playbook to make sure that a package is installed, and started. Here’s an example that installs nginx on a RHEL server and makes sure it’s started. Create a playbook file (simplePlaybook.yaml):
—- hosts: webservertasks:- name: Install nginxyum: name=nginx state=installednotify:- start nginx
handlers:
– name: start nginx
service: name=nginx state=started
Run the playbook with
ansible-playbook -i skytap_inventory.py simplePlaybook.yaml
Output might look like this for a successful run:
PLAY [webserver] ****************GATHERING FACTS ***********************ok: [webserver]TASK: [Install Nginx] *************changed: [webserver] => (item={‘nginx’: ‘started’})PLAY RECAP ****************webserver : ok=2 changed=1 unreachable=0 failed=0
Tune in Next Time!
We’re excited to enable teams with power and flexibility in building and managing their Development and Test environments. Ansible, with dynamic inventories, is a great general-case utility for smoothing over a lot of the rough edges that exist between Development, Operations, and Quality Assurance concerns, and we hope that you’ll find our release of a Skytap dynamic inventory useful.
