What is an Ansible ?
Ansible is simply an IT automation, configuration management and provisioning tool.
It uses ‘playbooks’ to deploy, manage, build, test and configure anything from full server environments to web sites to custom compiled source code for applications.
It brings the environment management together that have been managed traditionally separate and managed independently.
Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs.
Being designed for multi-tier deployments since day one, Ansible models your IT infrastructure by describing how all of your systems inter-relate, rather than just managing one system at a time.
It uses no agents and no additional custom security infrastructure, so it’s easy to deploy – and most importantly, it uses a very simple language (YAML, in the form of Ansible Playbooks) that allow you to describe your automation jobs in a way that approaches plain English.
In this section, we’ll give you a really quick overview of how Ansible works so you can see how the pieces fit together.
Ansible works by connecting to your nodes and pushing out small programs, called “Ansible Modules” to them. These programs are written to be resource models of the desired state of the system. Ansible then executes these modules (over SSH by default), and removes them when finished.
Your library of modules can reside on any machine, and there are no servers, daemons, or databases required. Typically you’ll work with your favorite terminal program, a text editor, and probably a version control system to keep track of changes to your content.
Plugins are pieces of code that augment Ansible’s core functionality. Ansible ships with a number of handy plugins, and you can easily write your own.
By default, Ansible represents what machines it manages using a very simple INI file that puts all of your managed machines in groups of your own choosing.
To add new machines, there is no additional SSL signing server involved, so there’s never any hassle deciding why a particular machine didn’t get linked up due to obscure NTP or DNS issues.
If there’s another source of truth in your infrastructure, Ansible can also plugin to that, such as drawing inventory, group, and variable information from sources like EC2, Rackspace, OpenStack, and more.
Here’s what a plain text inventory file looks like:
--- [webservers] www1.example.com www2.example.com [dbservers] db0.example.com db1.example.com
Once inventory hosts are listed, variables can be assigned to them in simple text files (in a subdirectory called ‘group_vars/’ or ‘host_vars/’ or directly in the inventory file.
Or, as already mentioned, use a dynamic inventory to pull your inventory from data sources like EC2, Rackspace, or OpenStack.
Playbooks can finely orchestrate multiple slices of your infrastructure topology, with very detailed control over how many machines to tackle at a time. This is where Ansible starts to get most interesting.
Ansible’s approach to orchestration is one of finely-tuned simplicity, as we believe your automation code should make perfect sense to you years down the road and there should be very little to remember about special syntax or features.
Here’s what a simple playbook looks like:
--- - hosts: webservers serial: 5 # update 5 machines at a time roles: - common - webapp - hosts: content_servers roles: - common - content
Extending Ansible with plug-ins and the API
Should you want to write your own, Ansible modules can be written in any language that can return JSON (Ruby, Python, bash, etc). Inventory can also plug in to any datasource by writing a program that speaks to that datasource and returns JSON. There’s also various Python APIs for extending Ansible’s connection types (SSH is not the only transport possible), callbacks (how Ansible logs, etc), and even for adding new server side behaviors.
Ansible Vs. Other DevOps Tools
What Other Tools ?
Basically, Ansible ‘plays in the sandbox’ of a large number of deployment and configuration management tools such as:
However, Ansible works at a high enough level that it can also be used in conjunction with one or more of these tools. Ansible is very often called an ‘orchestration’ tool since it can function independently as well as ‘control’ one or more of the tools listed above.
There are some key differences in these technologies, let’s talk about a few:
- Server/Management Nodes : Puppet/Chef will usually contains ‘master’ or ‘controller’ server in the setup. Ansible, operating only with SSH, does not. Any system with Ansible can function in that role at any time based on the task or deployment type.
- Workflow –Push vs.Pull : Since most configuration management tools have a ‘master’ server, they use the ‘pull’ method (i.e. the client ‘checks in’ on the server to pull it’s configuration). Ansible uses the ‘push’ method, requiring no client installation or configuration (other than general Python).
- Resource Definitions and Execution Ordering : Puppet (for example)instructions are not applied in order (in other words, not ‘top to bottom’ in how they appear in the manifest). Ansible uses pure in order execution,which can be easy to read as well as convert from other languages or scripts.
- Language : Ansible is built upon Python and the huge standard of inclusive functionality that comes with it. Puppet (Ruby) and Chef or Salt are not quite so inclusive.
- Syntax : Puppet is based on custom DSL while Ansible is based on YAML standard.
This is not really a competition/comparison . Depending on your environment, experience and goals, Ansible may or may not be the tool for you. Ansible does provide some advantages in terms of overall orchestration and standardization of tools and language, but that doesn’t eliminate some of its ‘competition’ from being useful in their own ways. It’s up to you!
Please comment and subscribe to get updates on daily basis. Thanks for reading it out !