Radek Sprta (Posts about ansible)

Level Up Your YAML: Tips For Advanced Usage

Radek Sprta — Fri, 29 Dec 2023 22:19:42 GMT

Leveraged by tools such Ansible & Kubernetes, YAML has become a ubiqitous configuration format over the last decade. It owes its high adoption rate can be attributed to its simple design. It is consise yet readable, thanks to its minimal use of syntactical marks. However, under the surface it is surprisingly complex. This post aims to introduce some of its features you might not be aware of.

ansible_user Is Undefined on Localhost

Radek Sprta — Wed, 21 Jun 2023 23:33:55 GMT

I rely on Ansible for configuring my workstation, so I can easily synchronize it across multiple computer. However, I recently ran into an intriguing issue when my playbook failed with the following error after adding a third-party role:

'ansible_user' is undefined

This puzzled me, because by default all ansible_* variables should be automatically populated, unless gather_facts has been explicitly disabled. It turns out that this behavior does not apply for ansible_user, if you run the playbook on localhost with a local connection instead of SSH.

Start AWX Job Via API

Radek Sprta — Sat, 03 Dec 2022 21:18:22 GMT

If you are using Ansible, there is high change you are also using AWX (or Ansible Tower) to orchestrate your jobs. And you might want trigger AWX jobs externally in some cases, such as from your CI pipeline. Luckily, AWX has an API that allows you to do just that.

To run AWX jobs remotely, you will need to make 3 API calls. One to start the job itself, another one to monitor its progress and lastly a request to print the output. You can see sample code to do that in bash shell below. In order to keep things simple, it uses authentication token, but you could also use OAuth 2.

POLLING_SLEEP=30

function print_job_output() {
  api_request GET "/jobs/${id}/stdout/?format=txt"
}

response=$(
  curl -s -i -o - "${AWX_API}/job_templates/${TEMPLATE_ID}/launch/" \
    -H "Authorization: Bearer ${API_TOKEN}" \
    -H "Content-Type: application/json" \
    -XPOST
)

http_status=$(head -n 1 <<<"${response}" | awk '{print $2}')
body=$(grep '^{' <<<"${response}")

if [[ ${http_status} != 201 ]]; then
  echo "AWX returned error."
  exit 1
fi

id=$(jq <<<"${body}" '.id')
echo "Monitoring job ID: ${id}"
while true; do
  echo "Sleeping for ${POLLING_SLEEP}s"
  sleep $POLLING_SLEEP

  response="$(api_request GET "/jobs/${id}/" -i)"

  http_status=$(head -n 1 <<<"${response}" | awk '{print $2}')
  body=$(grep '^{' <<<"${response}")
  if [[ ${http_status} != 200 ]]; then
    echo "AWX returned error."
    exit 1
  fi

  status="$(jq -r '.status' <<<"${body}")"
  if [[ "${status}" == "failed" ]]; then
    echo "Job failed."
    print_job_output
    exit 1
  elif [[ "${status}" == "successful" ]]; then
    echo "Job has finished successfully."
    print_job_output
    exit 0
  fi
done

Control Whitespace in Ansible Templates

Radek Sprta — Sat, 02 Jan 2021 11:13:38 GMT

Ansible uses the powerful Jinja templating engine. However, the way it handles whitespace in templates is not ideal. Specifically, the fact that it preserves leading whitespace around Jinja blocks. So, you can either not indent Jinja syntax, making the templates hard to comprehend, or accept broken indentation in the resulting file (not an option with whitespace-sensitive formats such as yaml).

Luckily, there is a third option. Jinja has two configuration options regarding whitespace:

Modify All Items in Ansible List

Radek Sprta — Sat, 08 Aug 2020 06:58:40 GMT

Ansible lets you easily interpolate list items within values (like interpolated_{{ item }}_value). However, sometimes you need a more powerful transformation. This is where the map filter comes to rescue again. You can use it to perform regular expression replace on each item in a list. As you can see, the syntax is relatively simple:

map('regex_replace', REGEX_PATTERN, OUTPUT)

For a concrete example, let us say you want to extract network mask from a list of IP addresses (192.168.0.100/24 for example). Assuming this list is stored in the ip_addresses variable, the regex replace would look like this:

{{ ip_addresses | map('regex_replace', '.*/([0-9]{1,2})', '\\1') | list }}

Of course, you can easily use it as a part of longer jinja2 pipelines. If you also want to learn how to loop over dictionary attribute, or see other Ansible tips, take a look here.

Loop Over Dictionary Attribute in Ansible

Radek Sprta — Sat, 04 Jul 2020 08:13:50 GMT

Working with variables can sometimes get tricky in Ansible. Say, you have a dictionary where you want loop over a certain attribute, not all values. For example, when your variables are declared like this:

interfaces:
  eth0:
    ip: 10.0.0.10
    mask: 16
  eth1:
    ip: 192.168.1.100
    mask: 24

How do you just loop over all the IP addresses? This is where the map filter comes in:

vars:
  ip_addresses: "{{ interfaces.values() | map(attribute='container') | list }}"

The snippet takes all values from the interfaces dictionary (eth0, eth1) and then extracts the ip attribute from them. Finally, it casts the result into list.

Ansible filters are a very powerful tool, so I would recommend you take some time to read it thoroughly. If you are looking for more Ansible tips, such as how to make a playbook distribution agnostic or setup your laptop with Ansible, look here.

Make Ansible Playbook Distribution Agnostic

Radek Sprta — Tue, 25 Jul 2017 16:53:27 GMT

I've been thinking about switching to a rolling distribution on my working machine for quite some time. Because the packages in Ubuntu repositories are just too outdated for my needs and I want to save myself the headache of PPAs. And when Ubuntu announced dropping Unity in favor of Gnome, my mind was made up. I would use a rolling distro on my main computer and Ubuntu 16.04 elsewhere.

Unify package installation

In the end, I decided to go for OpenSuse. Since I use an Ansible playbook to setup my machines, it would take no time to have it up an running. Or so I thought. However, there was a little caveat. As my playbook used the apt module to install software, it would obviously not run on OpenSuse. Luckily, since the version 2.0, Ansible provides a platform-agnostic package manager module. It is called simply package. As a result, installing packages across different distributions is as easy as running:

---
- name: Install packages
  become: yes
  package:
    name: git
    state: present

Or is it? While it may work in the case of Git, not all packages have a same name in different Linux distributions. So you have to set up variables for those: First of all, defaults in vars/default.yml:

apache_package: apache2

Then, for Debian family vars/Debian.yml

---
apache_package: apache2

And for Redhat family vars/Redhat.yml

---
apache_package: httpd

Afterwards, just include them in your tasks:

 - include_vars: "{{ item }}"
   with_first_found:
     - "{{ ansible_os_family }}.yml"
     - "default.yml"

 - name: Install Apache
   become: yes
   package: name: "{{ apache_package }}"
   state: present

Automatically Setup Your Computer with Ansible Playbook

Radek Sprta — Sun, 08 Jan 2017 21:50:54 GMT

Setting up a computer can be a major annoyance. Being 'the tech guy', I still have vivid nightmares of spending every other weekend reinstalling friends' and family members' Windows boxes that have come to a crawl. Now, most of us know enough to backup the important data and that makes the process easier. (If you don't have backups, go setup Nextcloud, Syncthing, or some other automatic system. Seriously, it's gonna come back to bite you sooner or later.) But there is still the matter of installing and configuring all your software. Some people have tackled that by writing install scripts. However, there is a better way - Ansible playbook. Let me introduce Ansible. Ansible is a software for computer provisioning. In computing, provisioning means automated installation and configuration of software and services. Provisioning tools, such as Ansible, Chef and Puppet, help you cut down the setup time from hours to mere minutes. Their main advantage over custom scripts is that they are idempotent. That means they only makes the necessary changes. So, if a task fails (for example because ou forgot to connect your Ethernet cable, oops), you can just run it again without any worries. The reason I chose to use Ansible, is that the tasks are easily configurable using yaml files. It is also written in Python, which makes it easy to write your own module for it, in case of need. So what is Ansible playbook? It is the collection of yaml files, describing the tasks to be executed. You can find an introduction to its syntax in Ansible documentation. I will demonstrate how you can setup your computers using an Ansible playbook, using mine as an example. You can find it at my Gitlab page.