User:Aboke2/Ansible

• Comment: For this to be accepted, please add third-party coverage (such as news and magazines). SwisterTwister talk 06:20, 15 September 2015 (UTC)

---

Ansible

Developer(s)	Michael DeHaan
Initial release	February 20, 2012 (2012-02-20)
Stable release	1.9.2 / 25 June 2015 (2015-06-25)
Written in	Python
Operating system	GNU/Linux, Unix-like, Windows
Type	Configuration management, Orchestration engine
License	GNU General Public License
Website	www.ansible.com

Ansible is a free software platform for configuring and managing computers. It combines multi-node software deployment, ad hoc task execution, and configuration management. It manages nodes over SSH or PowerShell and requires Python (2.4 or later) to be installed on them. Modules work over JSON and standard output and can be written in any programming language. The system uses YAML to express reusable descriptions of systems.

The platform was created by Michael DeHaan, the author of the provisioning server application Cobbler and co-author of the Func framework for remote administration. It is included as part of the Fedora distribution of Linux, owned by Red Hat inc., and is also available for Red Hat Enterprise Linux, CentOS, and Scientific Linux via Extra Packages for Enterprise Linux (EPEL) as well as other operating systems. Ansible is commercially supported and sponsored by Ansible, Inc.

It was named "Ansible" after the fictional instantaneous hyperspace communication system featured in Orson Scott Card's Ender's Game, and originally invented by Ursula K. Le Guin for her 1966 novel Rocannon's World.

Architecture

As with most configuration management software, Ansible distinguishes two types of servers: controlling machines and nodes. First, there is a single controlling machine which is where orchestration begins. Nodes are managed by a controlling machine over SSH. The controlling machine describes the location of nodes through its inventory.

To orchestrate nodes, Ansible deploys modules to nodes over SSH. Modules are temporarily stored in the nodes and communicate with the controlling machine through a JSON protocol over the standard output. When Ansible is not managing nodes, it does not consume resources because no daemons or programs are executing for Ansible in the background.

In contrast with popular configuration management software — such as Chef, Puppet, and CFEngine — Ansible uses an agentless architecture. With an agent-based architecture, nodes must have a locally installed daemon that communicates with a controlling machine. With an agentless architecture, nodes are not required to install and run background daemons to connect with a controlling machine. This type of architecture reduces the overhead on the network by preventing the nodes from polling the controlling machine.

Design goals

"I also wanted to make the automation software that anybody could pick up and learn in minutes, but also that possessed some capabilities that nothing else really had. Many people had cloned Func or Puppet — but in my opinion hadn’t made significantly major departures towards making those tools easier to use. So that’s why I made Ansible" -Michael DeHaan (Ansible Author)

The design goals of Ansible include:

• Minimal in nature. Management systems should not impose additional dependencies on the environment. For this reason, one of the main dedign goals for Ansible is to make it agentless. All that Ansible requires to access remote hosts is SSH (on Linux/Unix) or Windows PowerShell (on Windows)
• Consistent.
• Secure. Ansible does not deploy vulnerable agents to nodes. Only OpenSSH is required, which is already critically tested. Ansible does not need root access to the remote host as well. It can configure hosts using sudo privileges if requested.
• Highly reliable. Ansible uses a recource model that abides by the discipline of idempotence and applies this model during software deployments to prevent side-effects from re-running scripts. Hence all the Ansible operations are reliably repeatable.
• Low learning curve. Playbooks use an easy and descriptive language based on YAML. YAML based code syntax is quick to learn, easy-to-use and very intuitive.

Inventory configuration

The Inventory is a description of the nodes that can be accessed by Ansible. By default, the Inventory is described by a configuration file, in INI format, whose default location is in /etc/ansible/hosts. The configuration file lists either the IP address or hostname of each node that is accessible by Ansible. In addition, nodes can be assigned to groups.

An example configuration file:

192.168.6.1

[webservers]
foo.example.com
bar.example.com
foo_bar.example.com

[dbservers]
foo_db.example.com
bar_db.example.com
foo_bar.example.com

This configuration file specifies three nodes. The first node is specified by an IP address and the other nodes are specified by hostnames. Additionally, the latter three nodes are grouped under the webservers group name. Group names are used to classify nodes that have different installation tasks into different groups. Complementary to that, we can put different nodes into the same group, for which the tasks to be done are the same. Ansible does not put any hard restriction for a node to be in a single group alone. A node can be present in multiple groups. As an instance, foo_bar.example.com resides in both the node groups, webservers and dbservers.
To carry out the installation tasks on each node, Ansible accesses the node using ssh on the default port 22. However, there could be a use case where the nodes expect incoming ssh requests on a different non-default port. Ansible extends to support this model. In such a case, the node's entry in the inventory file would look like as belows: (assuming that the open port listening to ssh connections is 8888 for foo_bar.example.com )

foo_bar.example.com:8888

The port number should be appended to the hostname after a colon.

Below is a brief list of inventory parameters provided by Ansible to control the interaction of Ansible with the remote hosts:

• ansible_connection  : Connection type to the host.
• ansible_ssh_host  : Name of the host to connect to.
• ansible_ssh_port  : The ssh port number, if not 22.
• ansible_ssh_user  : The default ssh user name to use.
• ansible_ssh_private_key_file  : Private key file used by ssh.
• ansible_shell_type  : The shell type of the target system.
• ansible_python_interpreter  : The target host python path.
• ansible_become  : Allows to force privilege escalation.
• ansible_become_method  : Allows to set privilege escalation method.

These parameters make Ansible a very flexible configuration management tool as we can model a lot of diverse use cases. Things such as environmental parameters, ways to address remote hosts can vary a lot across different scenarios. Ansible makes it possible to still let us configure remote hosts using the above said behavior parameters.
For an instance, Ansible supports a use case, where the nodes are only addressable by their public IPs and not by their DNS hostnames. Ansible allows users to specify additional parameters to such nodes in the inventory file. A sample entry of such a node is as belows:

node0 ansible_ssh_host=192.168.1.103 ansible_ssh_user=root

There are several other options that Ansible exposes to the user to make the inventory file specific to a given use case (using the same set of inventory parameters) :

• Host Variables : The below snippet shows setting up host specific parameters in the inventory file for different nodes:

[dbservers]
node0 foo.example.com ansible_ssh_host=root ansible_ssh_private_key_file = <path_to_private_key> http_port=80
node1 bar.example.com http_port=3509

As per the above example, Ansible will ssh as root into node0 and will use this <path_to_private_key> private key during SSH.

• Group Variables : Ansible also allows setting up a set of variables for a specific group as belows:

[dbservers]
node0 foo.example.com http_port=3507
node1 bar.example.com http_port=3509
[dbservers:vars]
ntp_server=ntp.example.com
proxy=proxy.example.com

In the above example, Ansible will set the parameters ntp_server and proxy for every host machine in the hostgroup : dbservers

Ansible can also be pointed towards a custom "Dynamic Inventory" script, which can pull data from any different software system.

Modules

Modules are considered to be the units of work in Ansible. Each module is mostly standalone and can be written in a standard scripting language (examples include: Python, Perl, Ruby, Bash, etc.). One of the guiding properties of modules is idempotency, which means that even if an operation is repeated multiple times (i.e.; upon recovery from an outage), it will always place the system into the same state.. In a nutshell, modules are the basic Ansible work units and they get executed in every playbook task.

Following is a set of sample four different modules executed from the command line

ansible webservers -m service -a "name=httpd state=started"
ansible webservers -m ping
ansible webservers -m command -a "/sbin/reboot -t now"
ansible webservers -s -m shell -a 'nginx'

The modules invoked in the above set of commands are service , ping , command and shell . Each module supports taking arguments. Most of the modules take key=value arguments. Each tuple of a key-value pair is delimited by space(s). Some modules take no arguments, and the command/shell modules simply take the string of the command you want to run ( The third and the fourth modules in the above example).

Ansible provides a tool called ansible-doc that contains an elaborate documentation for each module. The tool can be accessed from the command line as follows:

ansible-doc <module_name>

There is also a functionality that Ansible exposes to list all the installed modules on the system. This list can be obtained using the same tool by passing a different option to it:

ansible-doc -l

Ansible modules normally return a data structure that can be registered into a variable, or seen directly when using the ansible program as output. There are a few modules which have their own unique returns. However, below are a few return values common to all modules:

• Facts : Some modules return ‘facts’ to Ansible. This is done through a ‘ansible_facts’ key and anything inside will automatically be available for the current host directly as a variable.
• Status : Every module must return a success or a failure status to Ansible.
• Other Common Returns : Upon successful/unsuccessful completion, some modules generally return a message that either explains the failure or makes a note about the execution. Some modules, specifically those that execute shell or commands directly, will return stdout and stderr.

All the modules return the data back to Ansible in JSON format. Below is a sample JSON object returned by Ansible upon a successful installation of a software package on a remote host:

changed: [node0] => {"changed": true, "stderr": "", "stdout": "... <installation_log> ..."}

We clearly see the returned JSON object having its keys as changed, stderr and stdout.

Playbooks

Playbooks express configurations, deployment, and orchestration in Ansible. The Playbook format is YAML. Each Playbook maps a group of hosts to a set of roles. Each role is represented by calls to Ansible call tasks.

In general, playbooks can be described as a policy to be enforced or sequential steps in a general IT deployment process. In an analogy, if Ansible modules are tools, then playbooks are a way of designing the workflow through a sequence of installation tasks. Playbooks can be used to manage configurations. At a more advanced level, they can sequence multi-tier roll-outs involving rolling updates, and can delegate actions to other hosts, interacting with monitoring servers and load balancers along the way. Playbooks are written in basic text.

Playbooks can have their own configurations which dictate steps to perform any manual process. They can also launch tasks in the target machine by its sequence of steps. While it is possible to run main /usr/bin/ansible program for ad-hoc tasks, playbooks are more likely to be kept in source control and used to push out predefined configurations or assure that the configurations of remote systems are in agreement with the specs.

Sample Example

Each playbook is composed of one or more tasks in a list.
Below code provides a sample playbook :

---
- hosts: webservers
  vars:
    http_port: 8080
    max_clients: 500
  remote_user: root
  tasks:
  - name: check apache as latest version
    yum: pkg=httpd state=latest
  - name: config file
    template: src=/srv/httpd.j2 dest=/etc/httpd.conf
    notify:
    - restart apache
  - name: ensure apache is running
    service: name=httpd state=started enabled=yes
  handlers:
    - name: restart apache
      service: name=httpd state=restarted

In the above example, we have defined a set of installation tasks for a host group webservers . However, a playbook can also have multiple plays such that each play caters to a different host group such as webservers , dbservers and so on.

Below is a brief description of the different segments that go inside a play:

• Hosts and Users : This segment lists the target machines in the system infrastructure where the installation tasks need to run. The hosts line is a list of one or more groups or host patterns, separated by colons. The remote_user is the name of the user account.

hosts: webservers  
remote_user: root

• Tasks list : Tasks are executed in order, one at a time, against all machines matched by the host pattern, before moving on to the next task. The goal of each task is to execute a module, with specific arguments. Arguments can be given to task in terms of variables.

tasks:
  - name: make sure apache is running
    service: name=httpd state=running

• Handlers : Playbooks are designed as to respond to the change in the system will trigger an event. These actions are triggered at the end of each block of tasks in a playbook, and will only be triggered once even if notified by multiple different tasks.

- name: restart memcached
      service: name=memcached state=restarted
- name: restart apache
      service: name=apache state=restarted 

Playbook can be executed with the following command executed from any standard shell:

ansible-playbook playbook.yml 

Case Studies

Here are some case studies where Ansible provided solutions.

BinckBank

BinckBank is an online bank for investors based in Amsterdam which has been using Ansible to overcome data center complexity. This bank wanted to create specific environments into their systems infrastructure while managing production servers.

Cloud Physics

Cloud Physics had a business challenge to manage their assets in Amazon AWS. It is using Ansible for managing AWS assets and deploying components onto them.

Narrative

Narrative’s hardware-based product requires a high degree of automation and continuous deployment. Narrative is deployed onto an application server running in AWS.

HootSuite Media, Inc.

Rebuilding a server at HootSuite depended on limited documentation available and was not feasible. Using Ansible, building servers became a smoother activity.

Platform support

Control machines must have Python 2.6. Operating systems supported on control machines include most Linux and Unix distributions, such as Red Hat, Debian, CentOS, OS X, and BSD, among others.

Managed nodes must have Python 2.4 or later. For managed nodes with Python 2.5 or earlier, the python-simplejson package is also required. Ansible can manage Windows nodes starting from version 1.7.

Cloud integration

Ansible can deploy to virtualization environments and public and private cloud environments, including VMware, OpenStack, AWS, Rackspace Cloud Servers, DigitalOcean Droplets, Eucalyptus Cloud, KVM, and CloudStack.

Big data integration

Ansible can deploy big data, storage and analytics environments, including Hadoop, Riak, and Aerospike. The problem addressed by Ansible in these environments includes the management of resource consumption of each node. Specifically, big data, storage, and analytics environments intend to be resource efficient by wasting as little CPU time and memory as possible. Furthermore, Ansible provides monitoring capabilities that measure quantities such as CPU resources available which can help in the supervision of these nodes.

Users

Ansible is used by Atlassian, Twitter, OneKingsLane, Evernote, TrunkClub, edX, hootsuite, GoPro, NewsCred, and Care.com, among others.

See also

• Comparison of open-source configuration management software
• Chef
• Puppet
• Salt

External links

• Official website
• Official public code repository on GitHub
• List of Ansible Tutorials and Courses

Category:Configuration management Category:Remote administration software Category:Software distribution Category:Free software programmed in Python Category:Software using the GPL license