Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells


SSH-based configuration management, deployment, and task execution system

News Enterprise Unix System Administration Recommended Links Software configuration Management Heterogeneous Unix server farms Baseliners
Parallel command execution Config files distribution: copying a file to multiple hosts Slurping: copying a file from multiple hosts Configuration Files Generation SSH for System Administrators rsync
Rex Ansible cdist Bcfg2    
puppet Red Hat Satellite Etch pacha Chief GNU cfengine
HP SRC Webmin synctool IBM Remote System Management Tool LCFG A large scale UNIX configuration system MValent
Software Distribution Simple Unix Backup Tools Enterprise Job schedulers Sysadmin Horror Stories Humor Etc


License: GPLv3

Vendor: Fedora Project

Ansible is a radically simple model-driven configuration management, multi-node deployment, and remote task execution system. Ansible works over SSH and does not require any software or daemons to be installed on remote nodes. Extension modules can be written in any language and are transferred to managed machines automatically.

From Wikipedia, the free encyclopedia

Developer(s) Michael DeHaan
Initial release February 20th, 2012
Stable release 1.6.3 / 9 June 2014; 29 days ago
Written in Python
Operating system GNU/Linux, Unix-like
Type Configuration management, Orchestration engine
License GNU General Public License

Ansible is an open-source software platform for configuring and managing computers. It combines multi-node software deployment, ad hoc task execution, and configuration management. Additionally, Ansible prefers to be categorized as an orchestration engine.[1] It manages nodes over SSH and does not require any additional remote software (except Python 2.4 or later)[2] 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.[3]

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.[4] 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.[5]

Ansible is commercially supported and sponsored by Ansible, Inc.[6]

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



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.[8] When Ansible is not managing nodes, it does not consume resources because no daemons or programs are executing for Ansible in the background.[9]

In contrast with popular configuration management software such as Chef and Puppet, Ansible uses an agentless architecture.[9] 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.[9]

Design Goals

The design goals of Ansible[8] include:


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 such as Python, Perl, Ruby, bash, etc. One of the guiding properties of modules is idempotency which means that no operations are performed once an operation has placed a system into a desired state.[8]

Inventory Configuration

The Inventory is a description of the nodes that can be accessed by Ansible. 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.[10]

An example configuration file:


This configuration file specifies three nodes. The first node is specified by an IP address and the latter two nodes are specified by hostnames. Additionally, the latter two nodes are grouped under the webservers group name.


Playbooks express configurations, deployment, and orchestration in Ansible.[11] 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.

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, OSX, and BSD, among others except Windows.[12]

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.[12]

Cloud Integration

Ansible can deploy to virtualization environments and public and private cloud environments including VMWare, OpenStack, AWS, Eucalyptus Cloud, KVM, and CloudStack.[8]

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.[8]


Ansible is used by Atlassian, Twitter, OneKingsLane, Evernote, TrunkClub, edX, hootsuite, GoPro and, among others.[13]


From Wikipedia, the free encyclopedia

Jump to: navigation, search

Filename extension .yaml, .yml
Initial release 11 May 2001; 13 years ago (2001-05-11)
Latest release 1.2 (Third Edition) / 1 October 2009; 4 years ago (2009-10-01)
Type of format Data interchange
Open format? Yes

YAML (/ˈjməl/, rhymes with camel) is a human-readable data serialization format that takes concepts from programming languages such as C, Perl, and Python, and ideas from XML and the data format of electronic mail (RFC 2822). YAML was first proposed by Clark Evans in 2001,[1] who designed it together with Ingy dt Net[2] and Oren Ben-Kiki.[2] It is available for several programming languages.

YAML is a recursive acronym for "YAML Ain't Markup Language". Early in its development, YAML was said to mean "Yet Another Markup Language",[3] but it was then reinterpreted (backronyming the original acronym) to distinguish its purpose as data-oriented, rather than document markup.




YAML syntax was designed to be easily mapped to data types common to most high-level languages: list, associative array, and scalar.[4] Its familiar indented outline and lean appearance make it especially suited for tasks where humans are likely to view or edit data structures, such as configuration files, dumping during debugging, and document headers (e.g. the headers found on most e-mails are very close to YAML). Although well-suited for hierarchical data representation, it also has a compact syntax for relational data.[5] Its line and whitespace delimiters make it friendly to ad hoc grep/Python/Perl/Ruby operations. A major part of its accessibility comes from eschewing the use of enclosures such as quotation marks, brackets, braces, and open/close-tags, which can be hard for the human eye to balance in nested hierarchies.


Sample document[edit]

Data structure hierarchy is maintained by outline indentation.

receipt:     Oz-Ware Purchase Invoice
date:        2012-08-06
    given:   Dorothy
    family:  Gale

    - part_no:   A4786
      descrip:   Water Bucket (Filled)
      price:     1.47
      quantity:  4

    - part_no:   E1628
      descrip:   High Heeled "Ruby" Slippers
      size:      8
      price:     100.27
      quantity:  1

bill-to:  &id001
    street: |
            123 Tornado Alley
            Suite 16
    city:   East Centerville
    state:  FL

ship-to:  *id001

specialDelivery:  >
    Follow the Yellow Brick
    Road to the Emerald City.
    Pay no attention to the
    man behind the curtain.

Notice that strings do not require enclosure in quotations. The specific number of spaces in the indentation is unimportant as long as parallel elements have the same left justification and the hierarchically nested elements are indented further. This sample document defines an associative array with 7 top level keys: one of the keys, "items", contains a 2-element array (or "list"), each element of which is itself an associative array with differing keys. Relational data and redundancy removal are displayed: the "ship-to" associative array content is copied from the "bill-to" associative array's content as indicated by the anchor (&) and reference (*) labels. Optional blank lines can be added for readability. Multiple documents can exist in a single file/stream and are separated by "---". An optional "..." can be used at the end of a file (useful for signaling an end in streamed communications without closing the pipe).

Language elements[edit]

Basic components of YAML[edit]

YAML offers both an indented and an "in-line" style for denoting associative arrays and lists. Here is a sample of the components.


Conventional block format uses a hyphen+space to begin a new item in list.

 --- # Favorite movies
 - Casablanca
 - North by Northwest
 - The Man Who Wasn't There

Optional inline format is delimited by comma+space and enclosed in brackets (similar to JSON).[6]

 --- # Shopping list
 [milk, pumpkin pie, eggs, juice]

Associative arrays[edit]

Keys are separated from values by a colon+space. Indented Blocks, common in YAML data files, use indentation and new lines to separate the key: value pairs. Inline Blocks, common in YAML data streams, use comma+space to separate the key: value pairs between braces.

 --- # Indented Block
   name: John Smith
   age: 33
 --- # Inline Block
 {name: John Smith, age: 33}

Block literals[edit]

Strings do not require quotation.

Newlines preserved[edit]
 --- |
   There once was a short man from Ealing
   Who got on a bus to Darjeeling
       It said on the door
       "Please don't spit on the floor"
   So he carefully spat on the ceiling

By default, the leading indent (of the first line) and trailing white space is stripped, though other behavior can be explicitly specified.

Newlines folded[edit]
 --- >
   Wrapped text
   will be folded
   into a single
   Blank lines  denote
   paragraph breaks

Folded text converts newlines to spaces and removes leading whitespace.

Hierarchical combinations of elements[edit]

Lists of associative arrays[edit]
- {name: John Smith, age: 33}
- name: Mary Smith
  age: 27
Associative arrays of lists[edit]
men: [John Smith, Bill Jones]
  - Mary Smith
  - Susan Williams

Advanced components of YAML[edit]

Two features that distinguish YAML from the capabilities of other data serialization languages are Structures[7] and Data Typing.


YAML structures enable storage of multiple documents within single file, usage of references for repeated nodes, and usage of arbitrary nodes as keys.[7]

Repeated nodes[edit]

For clarity, compactness, and avoiding data entry errors, YAML provides node anchors ( & ) and references ( * ). References to the anchor work for all data types (see the ship-to reference in the example above).

Below is an example of a queue in an instrument sequencer in which two steps are reused repeatedly without being fully described each time.

# sequencer protocols for Laser eye surgery
- step:  &id001                  # defines anchor label &id001
    instrument:      Lasik 2000
    pulseEnergy:     5.4
    pulseDuration:   12
    repetition:      1000
    spotSize:        1mm

- step: &id002
    instrument:      Lasik 2000
    pulseEnergy:     5.0
    pulseDuration:   10
    repetition:      500
    spotSize:        2mm

- step: *id001                   # refers to the first step (with anchor &id001)
- step: *id002                   # refers to the second step
- step: *id001
- step: *id002

Data types[edit]

Explicit data typing is seldom seen in the majority of YAML documents since YAML autodetects simple types. Data types can be divided into three categories: core, defined, and user-defined. Core are ones expected to exist in any parser (e.g. floats, ints, strings, lists, maps, ...). Many more advanced data types, such as binary data, are defined in the YAML specification but not supported in all implementations. Finally YAML defines a way to extend the data type definitions locally to accommodate user-defined classes, structures or primitives (e.g. quad-precision floats).

Casting data types[edit]

YAML autodetects the datatype of the entity. Sometimes one wants to cast the datatype explicitly. The most common situation is a single word string that looks like a number, boolean or tag may need disambiguation by surrounding it with quotes or use of an explicit datatype tag.

a: 123                     # an integer
b: "123"                   # a string, disambiguated by quotes
c: 123.0                   # a float
d: !!float 123             # also a float via explicit data type prefixed by (!!)
e: !!str 123               # a string, disambiguated by explicit type
f: !!str Yes               # a string via explicit type
g: Yes                     # a boolean True
h: Yes we have No bananas  # a string, "Yes" and "No" disambiguated by context.
Other specified data types[edit]

Not every implementation of YAML has every specification-defined data type. These built-in types use a double exclamation sigil prefix ( !! ). Particularly interesting ones not shown here are sets, ordered maps, timestamps, and hexadecimal. Here's an example of base64 encoded binary data.

 picture: !!binary |
Extension for user-defined data types[edit]

Many implementations of YAML can support user defined data types. This is a good way to serialize an object. Local data types are not universal data types but are defined in the application using the YAML parser library. Local data types use a single exclamation mark ( ! ).

myObject:  !myClass { name: Joe, age: 15 }


A compact cheat sheet as well as a full specification are available at the official site.[8] The following is a synopsis of the basic elements.

YAML requires that colons and commas used as list separators be followed by a space so that scalar values containing embedded punctuation (such as 5,280 or can generally be represented without needing to be enclosed in quotes.

Two additional sigil characters are reserved in YAML for possible future standardisation: the at sign ( @ ) and accent grave ( ` ).

Comparison to other data structure format languages[edit]

While YAML shares similarities with JSON, XML and SDL (Simple Declarative Language), it also has characteristics that are unique in comparison to many other similar format languages.


JSON syntax is a subset of YAML version 1.2, which was promulgated with the express purpose of bringing YAML "into compliance with JSON as an official subset".[10] Though prior versions of YAML were not strictly compatible,[11] the discrepancies were rarely noticeable, and most JSON documents can be parsed by some YAML parsers such as Syck.[12] This is because JSON's semantic structure is equivalent to the optional "inline-style" of writing YAML. While extended hierarchies can be written in inline-style like JSON, this is not a recommended YAML style except when it aids clarity.

YAML has many additional features lacking in JSON, including comments, extensible data types, relational anchors, strings without quotation marks, and mapping types preserving key order.

XML and SDL[edit]

YAML lacks the notion of tag attributes that are found in XML and SDL.[13] For data structure serialization, tag attributes are, arguably, a feature of questionable utility, since the separation of data and meta-data adds complexity when represented by the natural data structures (associative arrays, lists) in common languages.[14] Instead YAML has extensible type declarations (including class types for objects).

YAML itself does not have XML's language-defined document schema descriptors that allow, for example, a document to self-validate. However, there are several externally defined schema descriptor languages for YAML (e.g. Doctrine, Kwalify and Rx) that fulfill that role. Moreover, the semantics provided by YAML's language-defined type declarations in the YAML document itself frequently relaxes the need for a validator in simple, common situations. Additionally, YAXML, which represents YAML data structures in XML, allows XML schema importers and output mechanisms like XSLT to be applied to YAML.

Indented delimiting[edit]

Because YAML primarily relies on outline indentation for structure, it is especially resistant to delimiter collision. YAML's insensitivity to quotes and braces in scalar values means one may embed XML, SDL, JSON or even YAML documents inside a YAML document by simply indenting it in a block literal:

example: >
        HTML goes into YAML without modification
message:  |

        <blockquote style="font: italic 12pt Times">
        <p>"Three is always greater than two,
           even for large values of two"</p>
        <p>--Author Unknown</p>
date: 2007-06-01

YAML may be placed in JSON and SDL by quoting and escaping all interior quotes. YAML may be placed in XML by escaping reserved characters (<, >, &, ', "), and converting whitespace; or by placing it in a CDATA-section.

Non-hierarchical data models[edit]

Unlike SDL and JSON, which can only represent data in a hierarchical model with each child node having a single parent, YAML also offers a simple relational scheme that allows repeats of identical data to be referenced from two or more points in the tree rather than entered redundantly at those points. This is similar to the facility IDREF built into XML.[15] The YAML parser then expands these references into the fully populated data structures they imply when read in, so whatever program is using the parser does not have to be aware of a relational encoding model, unlike XML processors, which do not expand references. This expansion can enhance readability while reducing data entry errors in configuration files or processing protocols where many parameters remain the same in a sequential series of records while only a few vary. An example being that "ship-to" and "bill-to" records in an invoice are nearly always the same data.

Practical considerations[edit]

YAML is line-oriented and thus it is often simple to convert the unstructured output of existing programs into YAML format while having them retain much of the look of the original document. Because there are no closing tags, braces, or quotation marks to balance, it is generally easy to generate well-formed YAML directly from distributed print statements within unsophisticated programs. Likewise, the whitespace delimiters facilitate quick-and-dirty filtering of YAML files using the line-oriented commands in grep, awk, perl, ruby, and python.

In particular, unlike mark-up languages, chunks of consecutive YAML lines tend to be well-formed YAML documents themselves. This makes it very easy to write parsers that do not have to process a document in its entirety (e.g. balancing opening and closing tags and navigating quoted and escaped characters) before they begin extracting specific records within. This property is particularly expedient when iterating in a single, stateless pass, over records in a file whose entire data structure is too large to hold in memory, or for which reconstituting the entire structure to extract one item would be prohibitively expensive.

Counterintuitively, although its indented delimiting might seem to complicate deeply nested hierarchies, YAML handles indents as small as a single space, and this may achieve better compression than markup languages. Additionally, extremely deep indentation can be avoided entirely by either: 1) reverting to "inline style" (i.e. JSON-like format) without the indentation; or 2) using relational anchors to unwind the hierarchy to a flat form that the YAML parser will transparently reconstitute into the full data structure.[citation needed]

Top Visited
Past week
Past month


Old News ;-)

Linux Install Ansible Configuration Management And IT Automation Tool

1.Distro: RHEL/CentOS/Debian/Ubuntu Linux
2.Jinja2: A modern and designer friendly templating language for Python.
3.PyYAML: A YAML parser and emitter for the Python programming language.
4.parmiko: Native Python SSHv2 protocol library.
5.httplib2: A comprehensive HTTP client library.
6.Most of the actions listed in this post are written with the assumption that they will be executed by the root user running the bash or any other modern shell.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles


Top articles


Linux Install Ansible Configuration Management And IT Automation Tool



Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haters Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright 1996-2018 by Dr. Nikolai Bezroukov. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: September, 12, 2017