Account 로그인

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: |
        - 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
    - bacon
    - pizza
    - steak

And dictionaries:

  # Dictionary of a favorite 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
        - perl
        - python
  - learn:
      name: Learn Moar
      job: Sr Awesome Administrator
        - 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.

About the author

Red Hat logo LinkedInYouTubeFacebookTwitter


구매 정보


Red Hat 소개

Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.

Red Hat Shares 뉴스레터를 구독하세요

지금 신청하기

언어 선택

© 2022 Red Hat, Inc. Red Hat Summit