May 10, 2017
5 minute read
Like many configuration management and automation tools, Ansible was originally an open-source project for automating IT infrastructures and environments. As it began to gain a foothold in the enterprise, parent company AnsibleWorks expanded commercial support for the product. Currently their solutions consists of two offerings: Ansible and Ansible Tower, the latter featuring the platform’s UI and dashboard. Despite being a relatively new player in the arena when compared to competitors like Chef or Puppet, it’s gained quite a favorable reputation amongst DevOps professionals for its straightforward operations and simple management capabilities.
Of course, every tool has ideal use cases in which it shines brighter than the rest. For example, Ansible is widely regarded as being easy to learn and use– its Playbooks are human-readable/understandable, allowing for results to be achieved in a shorter amount of time. That said, the offering’s simplicity may leave advanced users desiring more sophistication. The following are our top 5 best and worst attributes of Ansible.
This is perhaps Ansible’s most lauded attribute: users can get up to speed and productive quickly with the tool. Supported by clear, easy-to-follow documentation, one can learn the workflow and logic of Ansible’s operations in a short amount of time. A lack of a dependency system means Ansible tasks just run sequentially and stop when an error is encountered. This makes troubleshooting easier, especially when initially starting out with the tool.
Written in Python
Ansible was written in Python, unlike other competing solutions that were built with languages such as Ruby. Consequently, getting it up and running is easier, since Python libraries are by default present on most Linux distributions. It’s also a language that’s more common for administration and scripting tasks: engineers and systems administrators are more likely to know Python than Ruby. Ansible modules for extending the tool’s functionality, however, can be written in any language, just as long as it returns data in JSON format.
For managing nodes, Ansible handles all master/agent communications with standard SSH or the Paramiko module, which is a Python implementation of the SSH2. The tool doesn’t require any agents to be installed on remote systems to be managed, which means less maintenance overhead and performance degradations. Check out our take on why agentless was the way to go for GuardRail.
Playbooks– Ansible configuration files– are written in YAML, which for configuration management and automation purposes is a better fit than other formats such as JSON. It’s easier to read, supports comments, and employs the use of anchors for referencing other items.
This portal serves as the central repository for finding, reusing, and sharing Ansible content. For example, reusable Roles for server configuration or application installation can be downloaded for use in one’s playbooks, significantly accelerating deployment time.
UI is Lacking
Originally a command-line only tool, Ansible made a first attempt at a UI with AWX: a graphical user interface and REST endpoint to make infrastructure management easier. AWX eventually evolved into Ansible Tower, a web management UI that provides visual management capabilities and a team-based workflow tool. Though a serious improvement over AWX, Ansible Tower still has much room for improvement– in fact, only 85% of what can be done from the command line can be accomplished via the UI. Another common annoyance is that the GUI occasionally falls out of sync with the command line, resulting in different query results. Overall, Ansible Tower is still a work-in-progress, and cannot do everything that the command line interface can.
No Notion of State
Unlike comparable automation tools like Puppet, Ansible has no notion of state. Since it doesn’t keep track of dependencies, the tool simply executes a sequential series of tasks, stopping when it finishes, fails or encounters an error. For some, this simplistic mode of automation is desirable; however, many prefer their automation tool to maintain an extensive catalog for ordering (à la Puppet), allowing them to reach a defined state regardless of any variance in environmental conditions.
Nascent Windows Support
As of version 1.7, Ansible supports both Unix/Linux and Windows nodes. For the latter it uses native powershell remoting (as opposed to SSH), and a Linux control machine is still required for managing Windows hosts. Ansible is still early in its efforts to extend support for Windows, with future versions of Ansible ostensibly incorporating deeper Windows interoperability.
Minimal Enterprise Support Experience
Though Ansible’s Enterprise Tower and Premium Tower are targeted at medium-to-large enterprises-- both options offer extended support options: enterprise 8x5 support & SLA (4 hour critical incident response) and premium 24x7 support & SLA (2 hour critical incident response), respectively-- the company has had less experience working with large enterprises than competitors like Chef and Puppet.
A Newer Offering
Ansible hasn’t been around as long as competing solutions like Chef or Puppet; subsequently, it has the smallest developer/user community and has the least materials on the web for self-help and troubleshooting. Less time on the market means that certain problematic edge scenarios, bugs, and software issues have perhaps yet to come to light.
In short, Ansible’s solution is a simple but powerful tool for configuration management and automation. The Ansible Tower offering features a web management UI, built-in REST API for easy integration with other services, and extended service and support for enterprises-- despite this being new territory for them. As with most things, there is no “one-size-fits-all” solution– Ansible is easy to learn and use, but lacks some advanced features present in more mature competitors' solutions. Depending on the use case at hand, this can either be a hindrance or advantage.