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 is software sovereignty

Software sovereignty is a subset of digital sovereignty. In essence, digital sovereignty means controlling your data, hardware and software. In Europe digital sovereignty has been driven by the EU. The reason is the reliance on services from big, global US-led vendors such as Amazon, Microsoft and Google. This poses a risk to the EU, just as does reliance on Chinese manufacturing is similarly a risk.

These worries are compounded by the threats to democracy posed by rise of authoritarianism (e.g Russia and China) and other threats to democracy, such as Trump’s rise to power and the MAGA movement in the US, and the rise of far-right nationalistic parties in various European countries. Without digital sovereignty in general, or software sovereignty in particular, somebody could “pull the plug” and you would loose access to your own data, hardware and software. Moreover, if you do not control your data, hardware and software, you’re capability to innovate is severely hindered.

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.

Automation use-cases in the Cloud

Johan Wennerberg, a Solution Architect for Red Hat Nordics in Stockholm gave presentation in Red Hat Open Tour 2022 Tallinn. In his presentation titled “Gain robust repeatability as selfservice, by automating your automation” he listed several automation use-cases in the Cloud. Each of these automation use-cases is made possible by automation stacks. The automation stacks are technology stacks that produce business value through automation. In practice you need to build your automation stacks on top of infrastructure as code.

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 while back. Johan Wennerberg, who is a Solution Architect for Red Hat Nordics in Stockholm, gave a presentation titled “Gain robust repeatability as self.service, by automating your automation”. Among other things he discussed the importance and use-cases of Cloud infrastructure standardization and automation. Here I willsummarize his views on standardization and automation and explain how they tie in with our focus on quality in the Cloud infrastructure and elsewhere.

Computers were supposed to relieve us humans from boring and repetitive jobs. Here we turn this upside down and do the boring and repetitive job of a computer by importing Cloudflare DNS records to Terraform ourselves. Not fun, but someone’s gotta do it sometimes. If you’re reading this, that someone is probably you. Condolences. My hope is that someone lazy enough gets bored enough to write a program to do this. I didn’t. Yet. 

Microsoft Azure provides a metrics and monitoring framework called Azure Monitor. With it you can monitor your Cloud infrastructure and services running there. You can view graphs of the metrics, alert on threshold and all that usual stuff, just like in AWS Cloudwatch.

Some Cloud resources like Azure Functions expose “a limited number of useful metrics” in Azure Monitor. This is a polite way of saying that the metrics are “completely useless” for most intents and purposes. For example, an Azure Function that gets triggered a few times a week on an irregular schedule by real people you don’t really have any useful metrics in Azure Monitor which you could alert on if something is off.

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.

When you create a distribution, AWS creates several DNS A records with the same name (e.g. d25gma2ea3ckma.cloudfront.net) which point to IPs the distribution is using. Then, typically, you would define CNAME(s) pointing to that cloudfront.net address in your own DNS. Each Cloudfront distribution has a list of aliases, similar to Subject Alternative Names (“SAN”) in SSL certificates. The aliases should match the CNAME(s) you’ve set in DNS.

Now, this is all good until you need to migrate those Cloudfront distributions to, say, a new AWS account. If you attempt to create a new distribution (here with Terraform) with the same alias you will get this error: