User:Aboke2/Ansible

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 &mdash; such as Chef, Puppet, and CFEngine &mdash; 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  access to the remote host as well. It can configure hosts using   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. 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  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,  resides in both the node groups,   and.

To carry out the installation tasks on each node, Ansible accesses the node using  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  file would look like as belows: (assuming that the open port listening to ssh connections is 8888 for  ) 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:
 *   : Connection type to the host.
 *   : Name of the host to connect to.
 *   : The ssh port number, if not 22.
 *   : The default ssh user name to use.
 *   : Private key file used by ssh.
 *   : The shell type of the target system.
 *   : The target host python path.
 *   : Allows to force privilege escalation.
 *   : 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  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  file specific to a given use case (using the same set of inventory parameters) : [dbservers] node0 foo.example.com ansible_ssh_host=root ansible_ssh_private_key_file =  http_port=80 node1 bar.example.com http_port=3509 As per the above example, Ansible will  as   into   and will use this  private key during SSH. [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
 * Host Variables : The below snippet shows setting up host specific parameters in the  file for different nodes:
 * Group Variables : Ansible also allows setting up a set of variables for a specific group as belows:

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

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  that contains an elaborate documentation for each module. The tool can be accessed from the command line as follows: ansible-doc  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": "...  ..."}

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

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  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. However, a playbook can also have multiple plays such that each play caters to a different host group such as ,   and so on.

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

hosts: webservers remote_user: root tasks: - name: make sure apache is running service: name=httpd state=running - name: restart memcached service: name=memcached state=restarted - name: restart apache service: name=apache state=restarted
 * Hosts and Users : This segment lists the target machines in the system infrastructure where the installation tasks need to run. The  line is a list of one or more groups or host patterns, separated by colons. The   is the name of the user account.
 * 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.
 * 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.

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  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.