Ansible 101: Part 1: In the beginning there was YAML

Just like the first creatures taking steps on land, learning a new technology is a daunting task. We can see the tree full of fruit at the top but between it and us is a mile of unsteady terrain, creatures with big pointy teeth and a fifty foot climb up with no net to save our fall. In this series the fruit we will be striving for is automation with Ansible.

Stepping out of the Primordial Ooze

We have all heard and seen the amazing things that can be done through the use of Ansible automation however, before we can get to that glorified state we need to understand the basics. In the inaugural post in this series, we will take our first steps out of the ooze and toward automation by understanding the legs that supports us: YAML.

YAML Ain't Markup Language

YAML at its core attempts to be an incredibly human-friendly way to allow us to serialize information. With its predominantly top-down design and inherent readability it can be digested by someone with minimal exposure to or experience with it. YAML will be the formatting used for much of our Ansible coding and is a critical component to fully comprehend. Singing YAML’s praises is great, but let us take a look at an example of YAML code.

  # Me
  - me:
      name: Russ Zaleski
      employed: yes
      job: Senior Technical Account Manager
      age: 34
      interests: |
        fishing
        kayaking
      friends:
        - Marc
        - Freddy
        - Eric

A quick read of the above snippet and you can quickly garner what is being denoted. It has some information about “Me”. It includes my name, job, and age. There are some things that I am interested in as well as a listing of people we can assume to be my friends. While the information provided is completely non-technical, it gets the simplicity and layout of a YAML file across very well.

Let’s stretch our legs

YAML files are built upon key-value pairs. These pairs can and will be used as the basis of running our Ansible automation tasks. They can be expressed simply in single definitions such as “name: Russ Zaleski” or through the use of lists:

  # List of favorite foods
  foods:
    - bacon
    - pizza
    - steak

And dictionaries:

  # Dictionary of a favorite book
  book:
    name: Ansible 101
    author: Foo Bar
    brief: Getting started with Ansible

Or if we want to put on our fancy pants we can use lists of dictionaries and dictionaries with lists:

  # People
  - foo:
      name: Foo Bar
      job: Awesome Administrator
      languages:
        - perl
        - python
  - learn:
      name: Learn Moar
      job: Sr Awesome Administrator
      languages:
        - ansible
        - ruby
        - awk

Formatting Matters

Keen eyed readers may have noticed the spacing in the previous examples. One of YAML’s strictest rules is the proper layout of spaces. We must have a space in between a key value declaration and, undoubtedly the most frequent mistake made, is the number of spaces when indenting. Two shall be the number of spaces, and the number of the spaces shall be two. As seen above when indenting our list under the declarative there are two spaces of indent for each of the language entries under the languages declaration..

YAML is also kind enough to provide us with some abbreviated forms of list and dictionary declaration:

  foo: {name: Foo Bar, job: Awesome Administrator, skill: High}
  foods: ['bacon', 'pizza', 'steak', 'blueberries']

Dictionaries use { } while lists use [ ] as seen in the example above. Using a more advanced shorthand is fantastic once you’ve been around the block a few times but when just getting our legs under us, it’s advisable to use to full notation as to avoid any unintentional outcomes. Additionally, while cramming excessive amounts of information onto a single line might give us some nerd cred, it also hamstrings one of YAML’s greatest strengths: it’s inherent readability.

Continuing forward, as with most languages we have a set of boolean values. In this case, we can denote them through a variety of techniques.

  is_true: yes
  is_false: no
  use_caps: True
  all_caps: FALSE

We can also have some fun with newlines when doing a large text block:

  with_newlines: |
    the text is going
    to look
    exactly like this

  single_line: >
    this text is
    going to present as a
    single line

In the first example we can use the pipe symbol (|) to automatically insert newlines into our text because they are on another line. Conversely, in the second example we can use a close angle bracket (>) to ignore newlines and instead have the text all present as a single line despite the multiple lines that were used to code it.

Left foot, right foot

Looking back at our first example of Me we can now quickly see the different syntax uses that came into play. We have a dictionary that includes key value pairs, lists, as well as a block of text with newlines. While we have spent this session on the non-technical pieces of Ansible, it was a necessary step to getting us on our feet and moving. With our newly found legs now under us we can truly begin our journey to automation with Ansible.

Throughout this series we will continue our evolution of Ansible knowledge while diving into concepts and inventories, modules, ad-hoc commands, playbooks, variables, troubleshooting and much much more. Stay tuned for Part 2 in which we will take a look at the basic components in an Ansible environment, static inventories and run some of our first Ansible commands.