피드 구독

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.

저자 소개


채널별 검색

automation icon


기술, 팀, 인프라를 위한 IT 자동화 최신 동향

AI icon


고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트

open hybrid cloud icon

오픈 하이브리드 클라우드

하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요

security icon


환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보

edge icon

엣지 컴퓨팅

엣지에서의 운영을 단순화하는 플랫폼 업데이트

Infrastructure icon


세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보

application development icon


복잡한 애플리케이션에 대한 솔루션 더 보기

Original series icon

오리지널 쇼

엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리