Update 2019: We’ve recently developed a Learning Path, Introduction to Ansible, which will help you to get you started using Ansible to automate common IT tasks, you will learn about Configuration Management and you’ll be able to practice your knowledge on Ansible through a series of hands-on labs. Guy Hummel, our expert cloud trainer, has recently written an introductory post on What is Ansible?.
In a previous blogpost, we have seen the 5 best tools for AWS deployment. One of the tools which we covered was Ansible. In this blog post, we will see how to install this software and will learn the basics of it, to help you to get started with Ansible.
Get Started with Ansible: Introduction
Ansible is one of the youngest and fastest growing configuration management, deployment and orchestration engine. Released in 2012, it is one of the most popular GitHub projects already.
Some of the biggest pros of using Ansible are its agent-less architecture, the use of SSH protocol for communication and the use of YAML syntax for its configuration files. It only requires Python packages installed on client nodes. Agent-less architecture removes the burden of upgrading packages at each new release, while the SSH protocol makes the communication between server and clients very secure. Further, YAML is very easy to read and understand, making the use of Ansible a lot simpler.
Ansible is available in two versions: Ansible Tower (paid one – free up to 10 nodes) and Ansible Open-Source (free).
Basic System Requirements
- Control Machine – This pretty much acts as the Ansible server where all the playbooks and configuration files are located. Control machine can be configured on the most common Linux Distribution, OS X or any BSDs. It requires Python 2.6 or greater. The Windows operating system is not supported by the Control Machine.
- Managed Node – These are the nodes managed by the Control Machine. In a server-client architecture, managed nodes are clients where configuration or application is deployed. Any operating system (Linux, Windows or Mac) with python 2.4 or greater installed can act as Managed Node.
Glossary
- Inventory – Ansible holds the information about nodes and group of nodes to be managed in a simple INI format inventory file. The default ansible host inventory file is located at /etc/ansible/hosts. The sample inventory files look like :
staging.example.com [webservers] prod-web01.example.com prod-web02.example.com [databaseservers] prod-db01.example.com prod-db02.example.com
Apart from information about nodes and group of nodes, the inventory file also holds information about host specific variables (e.g.: ssh ports, DB parameters), group variables (e.g.: defining some system level parameters or default interpreter) and a group of variables.
You can also pull information about your dynamic inventory using an external inventory system. Plugins are available to fetch inventory from your cloud provider (AWS, GCE, Rackspace, Openstack, etc), LDAP or Cobbler.
- Modules – Ansible modules are independent pieces of code which can be used to alter and manage your infrastructure. These modules can be executed independently (ad-hoc way) or with ansible playbooks (described below). At a beginner level, modules can help you install, start, stop and restart services, execute commands, copy files, etc on your hosts. There are around 250+ modules available which help you to perform a wide range of tasks on your infrastructure. As per Ansible documentation, Modules are idempotent, that is: they will only execute if the state change is required.
Example: The service module is the easiest way to restart your webservers (apache)
ansible webservers –m service –a “name=httpd state=started”
In this case, if a service is already running, it won’t restart the service. This is what modules idempotence means.
- Playbooks – Playbooks are the heart of Ansible. As mentioned above, modules can run in an ad-hoc way but when you are looking to orchestrate your configuration and execute a series of complex commands in order, playbooks comes into the picture. Playbooks are written in YAML format. In a playbook, you can include multiple modules and perform tasks synchronously or asynchronously.
A playbook is broken into multiple parts:
- hosts: where you want to deploy your configuration
- remote_user: execution of steps as a defined user
- tasks: execute modules with specific variables
- handlers: triggering a specific execution only once if notified by multiple tasks or system state changes. It depends upon notifying block under tasks.
A sample playbook is here below:
---
- hosts: webservers
vars:
http_port: 80
max_clients: 200
remote_user: root
tasks:
- name: ensure apache is at the latest version
yum: pkg=httpd state=latest
- name: write the apache config file
template: src=/srv/httpd.j2 dest=/etc/httpd.conf
notify:
- restart apache
- name: ensure apache is running
service: name=httpd state=started
handlers:
- name: restart apache
service: name=httpd state=restarted
We will dig deeper into Ansible playbooks in the next posts of this series.
Remote Connection Methods
As discussed above, the beauty of Ansible is that it is agent-less and relies on the SSH protocol to communicate with hosts. However, there are multiple ways you can connect to hosts or execute Ansible playbooks:
- OpenSSH – This is the most recommended procedure for connecting to hosts. If you are using the new control machine, it will support ControlPersist, Kerberos and other options in the SSH config file. It is default from Ansible 1.3.
- Paramiko – Paramiko is the Python implementation of OpenSSH. It is used for old EL6 operating systems where ControlPersist feature on OpenSSH is not supported.
- Local – Local is used if you wish to execute playbooks on your control machine itself. If you want to make an API call to AWS or Rackspace, there is no need to execute these commands on a remote host. You can pretty well run ansible-playbook in local mode.
Installation Options
One of the other features making Ansible very easy to use is the variety of installation procedures.
- OS Package Manager – It is the recommended way to install Ansible on your control machine. Ansible is packaged and available in the archives of the most important distribution, so check your distro’s documentation to find out how to install it. If you are using RHEL, CentOS or Amazon Linux, you will need to enable EPEL:
- Enable EPEL repository on Amazon Linux – Go to your yum.repos.d folder and enable epel.repo (modify enabled=0 to enabled=1).
- Install ansible
# yum install ansible
1. If you are on RHEL or Centos, install the EPEL repository as well
2. Enable the RHEL Optional Repository [Only applicable for RHEL]
3. Install ansible
#yum install ansible
- PIP – You can also install Ansible using a Python package manager like PIP. For installing ansible using pip, ensure pip is installed on your system. If not, please install it using your distro’s package manager or esay_install. Once done, you can use pip to install Ansible:
#pip install ansible
- GIT – You can also clone the Ansible repository and install it from source. Before installing ansible from GIT, make sure pip and additional python related dependencies are installed. Then, you can install Ansible from source:
# git clone git://github.com/ansible/ansible.git –recursive #cd ./ansible #source ./hacking/env-setup
Building Inventory
To build the inventory, you need to put your managed nodes information in your inventory file. For demonstration purpose, we have launched two fresh EC2 Amazon Linux instances and put down their private DNS in inventory file (/etc/ansible/hosts).
Using Ansible in Ad-Hoc Mode
As discussed above, Ansible can be used in Ad-Hoc mode or playbook mode. For this blog post, we will demonstrate using ansible in ad-hoc mode to ping, install apache and start apache service on webservers mentioned in the inventory section. To connect to hosts, you should use ssh-agent.
To ping webservers instances group:
# ansible webserver –m ping –u ec2-user
To install apache on the webservers instances group :
# ansible webservers –m yum –u ec2-user --sudo –a “name=httpd state=present”
Now start the Apache service:
# ansible webservers –m service –u ec2-user –sudo –a “name=httpd state=started”
That’s it. Apache is now installed and running on the web servers instances group defined in the inventory file.
In our next blog post, we will have a close look at Ansible playbooks.
