What is it?
Ansible is an open source IT automation tool for application deployment, configuration management and device orchestration. Ansible have two offerings ‘Ansible Core’ and an enterprise level offering called ‘Ansible Tower’ which is a licensable product. Ansible Core however, remains open source and will remain the focus for this introduction.
Why pick Ansible?
The number one reason for picking Ansible is that it offers an agent-less architecture. Instead of using an agent, Ansible uses SSH for remote access to systems. This means not only can you manage servers you can also manage network systems such as Routers, Switches, Firewalls and Load solutions from this tool. As a bonus several modules are included in Ansible that focus specifically on network vendor systems such as Arista, Juniper and F5’s Big Switch. The other big win for Ansible is the Modules with over 450 build in modules Ansible is a very flexible solution for providing automation for a lot of tasks.
Ways to use Ansible
Ansible can be used primarily in one of two ways:
- Ad-hoc: which allows you to use it against specific systems as and when necessary. This is great for situations where you need to push a patch to multiple systems quickly.
- Playbook: Using a playbook is the preferred way to leverage Ansible’s strenghs as a configuration management system.
For this overview we will use the example of configuring servers, simply as they provide an easier way to provide examples
Ansible uses the following concepts
To give you more of an idea of how these compents interact, take a look at the following image we’ll then dive into each section to provide an overview of what it does.
A playbook is a YAML file that contains one or more play’s and are used to manage the overall deployments made to remote systems.
A play is a series of tasks that will be applied against a specific target. For example a play is usually focused on a single host or group of hosts say webservers. Several plays can be included in a single playbook, so you may have one play for webservers and another for database servers.
Tasks are literally what they sounds like, a list of tasks that should be carried out against the ‘play’. For example, you may have a task to ensure an application is installed you may have another task to make sure that application is then running. Tasks in turn tasks call on ‘modules’ and ‘templates’
Ansible provides a default list of modules that can interact with hosts and network equipment. These modules are included as a part of the release installation.
Some of the functions available in modules include service management; start/ stop services etc, file handling such as copying, package management; installation and removal of applications and the remote execution of commands.
Are literally system wide variables that can be applied to the playbook. Variables can be applied from many places not just the playbook. They can be environment specific or dynamic. They can be used by tasks and templates.
Templates are written in ‘Jinja2’ and can be used to complete complex tasks. So for exmple if you wanted to apply a configuration file as a task you would use a template as oposed to creating a very complex task list.
Handlers are tasks that only exist at the end of a playbook and only run once when called, they can however be called as many times as required from a play.
Ansible in Action
As you can probably tell Ansible can be as simple or as complex as you need it to be and as always I believe the only way to get your head around a system, especially if you’ve never used a configuration management tool, is simply to jump in. So in the next post we will build a basic lab and take a look at how to use Ansible as an Ad-hoc Configuration Management tool.