Category: Online Tutorials

A YAML format primarily uses 3 node types:

1. Maps/Dictionaries (YAML calls it mapping):
   The content of a mapping node is an unordered set of key/value node pairs, with the restriction that each of the keys is unique. YAML places no further restrictions on the nodes.
2. Arrays/Lists (YAML calls them sequences):
   The content of a sequence node is an ordered series of zero or more nodes. In particular, a sequence may contain the same node more than once. It could even contain itself.
3. Literals (Strings, numbers, boolean, etc.):
   The content of a scalar node is an opaque datum that can be presented as a series of zero or more Unicode characters.

Let us try and identify where these appear in the sample YAML file we saw earlier.

Indentation

A YAML file relies on whitespace and indentation to indicate nesting. Notice the hierarchy and nesting is visible through a Python-like indentation style. It is critical to note that tab characters cannot be used for indentation in YAML files; only spaces can be used. The number of spaces used for indentation doesn’t matter as long as they are consistent.

Mapping

Mappings are used to associate key/value pairs that are unordered. Maps can be nested by increasing the indentation, or new maps can be created at the same level by resolving the previous one.

Sequences

Sequences in YAML are represented by using the hyphen (-) and space. They are ordered and can be embedded inside a map using indentation.

Tip: Remember that the order matters with sequences but not with mappings.

Literals — Strings

The string literals do not require to be quoted. It is only important to quote them when they contain a value that can be mistaken as a special character.

Here is an example where the string has to be quoted as & is a special character.

1. Folding Strings
   Strings can also be written in blocks and be interpreted without the new line characters using the fold operator (greater than).

The above YAML snippet is interpreted as below.

2. Block strings
   Strings can be interpreted as blocks using the block (pipe) character.

This is interpreted with the new lines (\n) as below.

3. Chomp characters
   Multiline strings may end with whitespaces. Preserve chomp(+) and strip chomp operators can be used either to preserve or strip the whitespaces. They can be used with block and pipe characters.

• Preserving new line character

The above snippet is interpreted as below in JSON

• Stripping new line character

The above snippet is interpreted as below in JSON.

Comments 

YAML file also supports comments, unlike JSON. A comment starts with #. To learn more see – how to add comments in YAML.

Documents

The above YAML snippet that we saw is called a document. A single YAML file can have more than one document. Each document can be interpreted as a separate YAML file which means multiple documents can contain the same/duplicate keys which are not allowed in the same document.

The beginning of a document is denoted by three hyphens —.

A YAML file with multiple documents would look like this, where each new document is indicated by ---.

Finally, triple dots are used to end a document without starting a new one ...

Before we learn more about YAML, this is a good time to practice writing your own YAML file. They can be validated here.

Now that we have seen an online YAML parser in action, it’s time we learn about schemas and tags.

Schemas and Tags

Let’s take a moment to consider how YAML will interpret the given document. Is the sequence’s first literal a string or a boolean?

You are correct if you answer that the first item on the list is a boolean, and you are also correct if you answer that it is a string. The way it is resolved is determined by the YAML schema that the parser has implemented. But what exactly are schemas?

Schemas can be thought of as the way a parser resolves or understands nodes (values) present in a YAML file. There are primarily 3 default schemas:

1. FailSafe Schema: It only understands maps, sequences and strings and is guaranteed to work for any YAML file.
2. JSON schema: It understands all types supported within JSON including boolean, null, int and float as well as the ones in the FailSafe schema.
3. Core schema: It is an extension of the JSON schema, making it more human-readable supporting the same types but in multiple forms.
   For e.g: 1. null | Null | NULL will all be resolved to the same type null and true | True | TRUE will all be resolved to the same boolean value.

Note: It is also possible to create your own custom schemas based on the above default schema.

So coming back to the original question, if the parser supports only the basic schema (FailSafe Schema), the first item will be evaluated as a string. Otherwise, it will be evaluated as a boolean.

Read more about YAML schemas here.

This leads to the next question: What if we explicitly want a value to be parsed in a specific way?

Let’s say from the same example that we want the first true value to be parsed as a string instead of a boolean, even when the parser uses the JSON or the core schema.

This is where tags come into the picture. Tags can be thought of as types in YAML. 

Even though we explicitly didn’t mention the tags/types in any of the YAML snippets we saw so far, they are inferred automatically by the YAML parser. For instance, the maps have the tag/type as tag:yaml.org,2002:map, sequences are tag:yaml.org,2002:seq and strings are tag:yaml.org,2002:str 

The below snippet works perfectly fine, even when we specify the tags. It can be validated here.

We can use these tags to explicitly specify a type. For our example, all we have to do is specify the type as a string, and the YAML parser will parse it as a string.

Anchors and Alias

With a lot of configuration, configuration files can become quite large.

In YAML files, anchors (&) and aliases (*) are used to avoid duplication. When writing large configurations in YAML, it is common for a specific configuration to be repeated. For example, the vars config is repeated for all three services in the following YAML snippet.

As more and more things are repeated for large configuration files, this becomes tedious.

Anchors and aliases allow us to rewrite the same snippet without having to repeat any configuration.

Anchors (&) are used to define a chunk of configuration, and aliases are used to refer to that chunk at a different part of the configuration.

Anchors and aliases here helped us cut down the repeated configuration.

But practically, configurations won’t be completely identical they would vary here and there. For instance, what if all the above services are running on different versions? Does this mean we have re-write and repeat the whole config again?

This is where overrides (<<:) come to the rescue. We can still use aliases and make the changes that we need.

YAML files treat : , { , } , [ , ] , , , & , * , # , ? , | , -- , < , > , = , ! , % , @ , \, etc, as special characters. But what if these special characters are actually a part of the data/value? How do we escape them?

Special characters can be escaped in various different ways:

Entity Escapes

• space:  
• colon: :
• ampersand: &

Unicode Escapes

• space: "\u0020"
• single-quote: "\u0027"
• double quote: "\u0022"

Quoted Escapes

1. Double quote in a single quote: ‘YAML is the “best” configuration language’
2. Single quote in a double quote: “ Yes, the ‘best’ “

How is YAML different from JSON? Let’s try to figure it out.

Check out the below code snippet of Kubernetes configuration written in JSON. Don’t pay attention to what it does just observe the file.

Doesn’t it look like a pure JSON file? Let’s see if we can validate it in our YAML parser.

It’s odd that the YAML parser didn’t report the file as invalid. Does this imply that JSON is also YAML?

YAML is, in fact, a superset of JSON. All JSON files are valid YAML files, but not the other way around.

Can we combine JSON and YAML? Is it still a valid YAML file? Let’s put this hypothesis to the test. Let us change some of the above snippet to make it look more like the YAML we are familiar with ????

Notice that there isn’t a root JSON wrapper {} anymore, there are just maps at the root level, but most of it is still JSON. Validate the file once more in a YAML parser. It is a valid YAML file, but when we try to validate it in a JSON parser, it says it is invalid. That’s because the file is no longer JSON, but rather YAML. This demonstrates that YAML is, in fact, the superset of JSON.

We learned a lot about YAML and saw that it works great as a configuration language. Let us see it in action with some of the most famous tools.

Ansible

Ansible playbooks are used to automate repeated tasks that execute actions automatically.

Playbooks are expressed in YAML format and perform any action defined in plays.

Here is a simple Ansible playbook that installs Nginx, applies the specified template to replace the existing default Nginx landing page, and finally enables TCP access on port 80.

To learn more about Ansible playbooks, see our article: Working with Ansible Playbooks – Tips & Tricks with Examples.

Kubernetes

Kubernetes, also known as K8s, is an open-source system for automating the deployment, scaling, and management of containerized applications.

Kubernetes works based on a state model where it tries to reach the desired state from the current state in a declarative way. Kubernetes uses YAML files to define the Kubernetes object, which is applied to the cluster to create resources like pods, services, and deployments.

Here is a YAML file that describes a deployment that runs Nginx.

YAML works great as a configuration language, but it is important to be aware of certain challenges as well when using it.

The curious case of the Norway problem

Imagine listing the abbreviation of all the countries where it snows

All looks good, right? But when you try to read this YAML file in python, we see NO being read False instead of ‘NO’

So why does this happen?

Remember the core schema which interprets NULL | null the same way? The same schema interprets FALSE | F | NO the same way. So instead of parsing NO as a string, it parses it as a boolean. This is can be easily solved by quoting NO.

But instead, to avoid any such kinds of surprises, we can use StrictYAML, which parses everything as a string by default.

Source here.

Congratulations on completing the article. You are now on your way to becoming a YAML expert. Isn’t YAML fantastic?

YAML is an important language that finds its uses almost everywhere where writing configuration is required. Kubernetes, Ansible, docker-compose, and other tools are excellent examples.

Then you can use Spacelift to mix and match Terraform, Pulumi, AWS CloudFormation, Kubernetes, and Ansible Stacks and have them talk to one another. For example, you can set up Terraform Stacks to provision the required infrastructure (like an ECS/EKS cluster with all its dependencies) and then deploy the following via a Kubernetes Stack. Check it out for free by creating a trial account.

——> Click Here to PDF Download

—–> Click here for Interview Questions
——> Click here for MCQs