Ansible London, November 2024: Lockdown, goss and Hetzner

Two months after my GraphRAG demo at the September meetup, I was back in London on Thursday 21 November 2024 for the next Ansible London meetup. It was in the same Dell Technologies meeting room as September. This time I didn’t give a talk. I sat in the audience and photographed the slides, and this post is rebuilt from those photos plus one short interview I recorded afterwards.

There were three talks: a Dell automation framework with retrieval-augmented generation (RAG), Infrastructure as Code on Hetzner Cloud, and the Ansible-Lockdown compliance project with its goss-based audit.

I got there early: the room before the first talk.

Dell Automation Framework, enhanced with RAG

The first talk was a remote session from Dell, with the speaker on video and a colleague in the room, about generating Ansible content with retrieval-augmented generation over Dell’s own automation code. The deck was marked for internal use, so I’m not reproducing its architecture or results here. For my own take on the pattern, see GraphRAG with Ansible from the September meetup.

The Dell RAG talk, with the speaker joining remotely on the right-hand screen.

Infrastructure as Code on Hetzner Cloud

Next came Daniel Brennand with “Infrastructure as Code - VPS provisioning and configuration on Hetzner Cloud”. His title slide carried an “#iwork4dell” tag and a note that the views were his own.

Daniel Brennand’s talk on provisioning VPSs on Hetzner Cloud with Ansible.

Most of the talk was a live walkthrough of a public demo repository, dbrennand/demos (ansible/meetup-nov-21). It has three playbooks, provision-playbook.yml, post-deploy-playbook.yml and deprovision-playbook.yml, plus an inventory folder, vars and the Python and Galaxy requirements files. The provisioning playbook I photographed:

• runs against localhost with connection: local and gather_facts: false, and loads vars/main.yml;
• in pre_tasks, looks up the machine’s public IP with ansible.builtin.uri against api.ipify.org (tagged firewall), and creates a local SSH key pair with community.crypto.openssh_keypair;
• then creates a Hetzner Cloud SSH key with hetzner.hcloud.ssh_key (the API token comes from a variable, not the playbook) and a Hetzner Cloud firewall with hetzner.hcloud.firewall.

According to the repository’s README, the post-deploy playbook then configures the new server through the Hetzner Cloud dynamic inventory, and the deprovision playbook tears everything down.

The provisioning playbook on screen: public IP lookup, local key pair, then Hetzner Cloud SSH key and firewall.

My take: I like this provision, post-deploy and deprovision split for small VPS estates. Fetching your own public IP to lock the firewall down to it is a simple step that a lot of “spin up a box” tutorials skip.

Ansible-Lockdown: let’s talk compliance

The last talk opened on a slide that said “Let’s talk compliance” with a cartoon of someone asleep in a chair. The speaker was Mark Bolwell. His “About” slide described him as principal automation engineer on the open-source Ansible-Lockdown project, at Krameff Solutions Limited (a UK consulting company), in partnership with MindPoint Group. He has been using Ansible since 2014.

The compliance talk opened with the slide everyone in the room could relate to.

What Ansible-Lockdown is

From the “What is Ansible-lockdown?” slide:

• Open-source security and compliance automation, written as Ansible roles.
• It assists with frameworks such as PCI-DSS, DORA and NIS2, and it includes an audit capability.
• It implements best-practice, industry-recognised baselines from CIS (Center for Internet Security) and DISA (the STIGs).
• Coverage on the slide: Red Hat, Rocky, Alma and Oracle Linux 7, 8 and 9; Ubuntu 18, 20, 22 and 24; Debian 11 and 12; Windows 10, 11, 2012, 2016 and 2022. Under “Other” it listed Cisco networking, Windows firewalls, Apache and Postgres.

Supported platforms and baselines, from the “What is Ansible-lockdown?” slide.

The ansible-lockdown GitHub organisation matches this. It has a remediation role per benchmark, such as RHEL9-CIS, UBUNTU22-CIS and RHEL9-STIG. Most of them have a paired -Audit repository that runs the checks with goss.

How a run works

The “Overview” slide, shown over the demo inventory, set out the flow:

1. Assertions are run first. After that, almost everything is optional.
2. Audit the system. The options can set the system up for you, copying, installing or downloading what’s needed, and the controls run according to the Ansible settings.
3. Remediate. Ansible steps bring the system into compliance, and each item can be switched on or off.
4. Run a post-audit after the changes.

Mark then showed a demo inventory where individual controls are toggled through role variables.

Assert, audit, remediate, then audit again.

Why goss for auditing

The slide “Why use another product to audit?” made the case for goss (goss.rocks), described as “Go server-spec”:

• An open-source, single Go binary of about 14 MB.
• Self-contained: no extra modules or dependencies, which is “great for air gapped environments”. It runs on the host, not across the network, with a caution about shared infrastructure.
• Fast: 700 tests in under two minutes on a clean OS build (the slide put it as “FAST!!!!!”).
• Driven by a YAML configuration file, with the Ansible settings fed through Jinja2 to configure the goss checks.

The goss project calls itself a YAML-based serverspec alternative for validating a server’s configuration, which fits that description.

The case for goss: small, self-contained and fast.

I saw the same project again at CfgMgmtCamp 2025 in Ghent, and I’d met Mark once before, for an interview at Ansible Automates London 2023.

My take: separating the audit tool from the remediation tool is the right design for regulated customers. An auditor will trust a report more if the thing that checks the system isn’t the same thing that changed it. A single static binary also matters on hardened or air-gapped hosts where you can’t install a Python stack.

After the talks: James Freeman

After the talks I recorded a short clip with James Freeman. He introduced himself as having been around Ansible for six or seven years and having written five books on it. His Packt titles include Mastering Ansible and Practical Ansible. Earlier in the evening we’d talked about how to apply generative AI to Ansible in enterprise environments.

His takeaway went beyond AI. He said he loved the presentations on the foundations, such as provisioning VMs on Hetzner. They reminded him of how he started with Ansible, and he was glad to see that passion for “all the foundational stuff that Ansible’s so good at” was still there. I agreed. The technology is over a decade old and still fits regulated, compliance-heavy work well.

Related

• Ansible London Meetup 2024: GraphRAG and Neo4j (the September edition, where I spoke)
• CfgMgmtCamp 2025 in Ghent: The Talks I Saw
• Ansible Automates London 2023
• Ansible Community Day Berlin 2023