A Witchy Chant

Ansible Pitfall: Accessing Variables using vars

Mon, 20 Jun 2022 15:55:21 -0400

tl;dr: vars is an undocumented internal variable with surprising behaviour. Use foo instead of vars['foo'] and lookup('vars', 'foo' ~ bar) instead of vars['foo' ~ bar].

For a long time the only supported way of retrieving variables based on an expression was to use hostvars. This generally works, but not all variables that are in scope are present in hostvars. At some point people learned that you could use a dictionary called vars to access more variables than are present in hostvars[inventory_hostname]:

Ansible Hall of Shame: Jinja Loop Counter

Mon, 10 May 2021 20:23:57 -0400

Someone was working with a Jinja template that they hadn’t created and having difficulty understanding it, so they brought it to the #ansible IRC channel and I hated it so much I had to preserve it for posterity.

A slightly simplified version:

{% set count = [1] %}
{% for item in ['a', 'b', 'c'] %}
{% for node in ['d', 'e'] %}
{{ node }}:{{ item }} {{ count | regex_replace('\[', '') | regex_replace('\]', '') }}
{% if count.append(count.pop() + 1) %}{% endif %}
{% endfor %}
{% endfor %}

This produces:

Ansible Pattern: Templated Dictionary Keys

Wed, 03 Feb 2021 13:57:34 -0500

Except for cases like set_fact where this functionality has been specifically implemented, Ansible does not template dictionary keys. This means you cannot do things like this:

- name: Create a frobnitz
  frobnitz:
    frobnicators:
      "{{ foo }}": bar

Templating Dictionaries

As a workaround you can template the entire dictionary. In the simplest cases it isn’t unbearably ugly to do this inline:

Ansible Pattern: Cumulative Inventory Variables

Sat, 29 Aug 2020 18:00:00 -0400

This is something I’ve never actually used, but has come up multiple times in #ansible, e.g. “I want to add on to a list variable in N places, but writing foo: "{{ foo1 + (foo2 | default([])) + (fooN | default([])) }}" is horrible and clunky and I have to know all of the variable names ahead of time.” Well, we can fix that.

Appended Lists

You want to define a base list (e.g. of packages to install), but allow membership in a group to add items on to that list? Here’s an example YAML inventory that does that (you can do this with any inventory using group_vars/, but it’s easier to demo in a single file):

Ansible Pitfall: Quotes and Strings

Tue, 28 Jan 2020 14:51:41 -0500

There are at least two levels of parsing that happen when Ansible playbooks are run, and the interaction between YAML parsing and Jinja causes a lot of confusion.

A common inductive leap is to see syntax like foo: "{{ bar }}" in existing Ansible code and conclude that Jinja cares whether your value is enclosed in quotes. The truth is that Ansible’s Jinja templating does not know those quotes existed, because they are part of the YAML syntax and do not survive past the initial parsing into a data structure.

Jinja FAQ: Nested Moustaches?

Wed, 21 Aug 2019 00:00:00 -0400

If you’re already in a Jinja statement or expression, you should not use a second set of delimiters to set off expressions.

Wrong:

{{ foo[{{ bar }}] }}
{{ hostvars['{{ 'myhost-' + {{ foo }}']['bar'] }}
{{ '{{ foo }}' if bar else 'baz' }}

{% set foo == "{{ bar }}foo" %}

Right:

{{ foo[bar] }}
{{ hostvars['myhost-' ~ foo]['bar'] }}
{{ foo if bar else 'baz' }}

{% set foo = bar ~ 'foo' %}

Conditionals

An Ansible-specific twist is that conditional statements are implicitly a Jinja context, so you rarely want to include Jinja delimiters in them.

Jinja FAQ: What's the deal with '~'?

Sun, 06 May 2018 00:00:00 -0400

~ is the string concatenation operator. It coerces both sides to strings, then concatenates them.

Follow-up question: “Doesn’t + concatenate strings? Why not just use that?”

+ is the addition operator, which is overloaded to mean concatenation when both sides of the expression are strings. While they’re often interchangeable, developing a habit of using the concatenation operator means that you don’t have to worry about or code around the situations where they’re not.

Ansible Pitfall: File Modes

Mon, 27 Nov 2017 00:00:00 -0500

tl;dr: To avoid unexpected behaviour, always quote your file modes in Ansible tasks and variables.

Ansible often exhibits unintuitive behaviour for people who are unfamiliar with the intricacies of YAML syntax and parsing, so today we’re going to explore some of those intricacies by setting a trap for the unwary:

- copy:
    src: /dev/null
    dest: /var/tmp/foo
    mode: 0755

$ ls -lh /var/tmp/foo
-rwxr-xr-x 1 root root 0 Nov 27 17:58 /var/tmp/foo

This is a perfectly valid Ansible task that sets the mode to exactly what you would expect. A week later your coworker comes along and copies your code, but wants their file to be setuid:

You should use Zstandard for log file compression

Thu, 03 Aug 2017 00:00:00 -0400

(Never heard of Zstandard? Read this after looking at my fancy charts.)

We ship our logs to a popular log analysis tool that provides a web interface and cool data mangling tools, but we also store plaintext copies that we occasionally need to refer to. Logs used to be archived on individual servers, but during a recent architecture shift we set up a centralised aggregation service to preserve logs from ephemeral instances. Centralising log storage also centralises log processing, and the choice of compression tool matters a lot more than it used to when compression and decompression were done in parallel across a whole fleet of machines.