Introduction

Ansible is an infrastructure as code tool that uses SSH as its transport mechanism. When the targeted nodes are close, latency-vise to the Ansible controller things usually work fine with the default settings. However, when the targets are far away or latency is big, you may notice that ansible-playbook hangs on some long-running task and never recovers. When you rerun the playbook it may proceed further and then hang at some other task. Or the same task. This is incredibly frustrating, but fortunately also fairly easy to fix.

Introduction

Being able to build IT infrastructure always having to involve an IT, operations or platform team seems be a big priority for many organizations. This is understandable because processes typically slow down to a crawl when they have to pass organizational boundaries. Also, teams responsible for infrastructure would not want to spend time on routine requests if possible. Provisioning infrastructure is no exception here. It is possible to create a custom solution to enable self-service infrastructure with Ansible and Terraform, but that takes a fair amount of effort. In this article we focus on open source and commercial open source offerings that make enabling self-service infrastructure provisioning easier.

Introduction

Ansible has reasonably good support for managing various aspects of Keycloak. You can use the community.general.keycloak_realm module to handle realm management, including Keycloak realm SMTP server settings. However, in the true Ansible fashion the documentation looks good, but does not help you much. In fact, documentation only mentions that the smtp_server parameter is a dictionary, but that’s it. To be honest, that’s about as helpful as the description of the RealmRepresentation for Keycloak. This article aims to fill this documentation void. I also want to share some general advise for similar cases that pop up when you manage Keycloak programmatically.

What are Ansible modules?

Ansible modules provide the infrastructure as code building blocks for your Ansible roles, plays and playbooks. Modules manage things such as packages, files and services. The scope of a module is typically quite narrow: it does one thing but attempts to do it well. Writing custom Ansible modules is not particularly difficult. The first step is to solve the problem with raw Python, then you can convert that Python code to an Ansible module

What are Ansible Collections?

Ansible is an infrastructure as code tool used for configuration management, network device management, orchestration and other tasks. Ansible Collections are a way to distribute Ansible content such as roles, playbooks and modules. They can be downloaded from Ansible Galaxy, Git repositories or local directories. Basically collections are a more modern packaging format compared to standalone roles which they are in the process of replacing. Version-locking Ansible Collections allows you to run the exact same Ansible code every time.

Overview of Ansible quality assurance

Ansible is an IT automation engine which you can use for configuration management, orchestration and device management, among other things. While you can get started fast with Ansible, ensuring high-quality, bug-free code can be challenging. Moreover, there’s not that much official, high-quality or coherent documentation available on Ansible quality assurance best practices. While low hanging fruit like Ansible variable validation are available, they are not emphasized in official documentation.

We participated in Red Hat Open Tour 2022 Tallinn a few weeks ago. Jaan Tanel Veikesaar from Elering, a gas/energy company in Estonia, gave a really nice presentation about their Ansible automation project. Ansible is a very common infrastructure as code and automation tool. Below I’ll go over Jaan’s presentation, adding some comments and key takeaways.

The starting point for the Ansible automation project

The starting point at Elering was fairly typical: to create a new VM, one had to go to VSphere, launch a VM and continue from there manually. In other words, automation did not really exist. This started to change when business started to demand more from the IT without adding any more human resources. This essentially made automation a necessity instead of being a luxury. So, they did some research and testing, after which Elering ended up with Ansible. They made this choice in part because whenever an Ansible problem was encountered, they could find an answer easily from the Internet.