← All TILs

ansible

16 TILs filed under ansible.

Reading order: Ansible development environment

  1. Locking an Ansible development environment: pip, venv, pip-tools, uv or an execution environment
  2. Pinning ansible-core with pip-tools, uv and Poetry
  3. Building an Ansible execution environment from a locked requirements file
  4. Where to run an Ansible development environment: venv, Dev Container, Remote-SSH, code-server or Dev Spaces
  5. Ansible Development Tools (ADT): one install, and the Python version decides what you get
  6. Committing the VS Code Ansible settings with the repository
  7. Running playbooks locally in the execution environment production uses

Everything in this topic, oldest first

Starting an Ansible role project with uv for the venv - 2026-09-05

Ansible needs a Python environment (ansible-core, plus ansible-lint/molecule if you're testing), but a role's directory layout is fixed by ansible-galaxy — not something uv init's project scaffolding understands. So the two tools stay in their own lanes: ansible-galaxy for the…

Using the Foreman/Satellite dynamic inventory plugin - 2026-09-05

theforeman.foreman.foreman pulls hosts straight out of Foreman (or Red Hat Satellite, which is built on it) as live Ansible inventory — no manually maintained host list to fall out of sync with what's actually registered.

Targeting hosts the same way, whether the inventory is static or dynamic - 2026-09-05

The host patterns Ansible accepts on the command line and in a playbook's hosts: line don't care where the hosts came from — a plain INI file, a YAML static inventory, or a dynamic plugin like the Foreman one all get flattened into the same in-memory host/group graph first.…

Storing an Ansible Galaxy token as an environment variable, not in ansible.cfg - 2026-09-05

ansible-galaxy needs a token to install from or publish to anything other than the fully public Galaxy — a private Automation Hub, a self-hosted galaxy_ng, or even the public Galaxy for publishing your own collections. The token can live directly in ansible.cfg, but that's…

git tag basics, grounded in how Ansible collection releases actually use them - 2026-09-12

git tag looks simple until a release process actually depends on getting it right. Ansible collection releases are a good concrete example — the tag isn't decorative, tooling reads it back.

Deploying a Podman Quadlet stack on RHEL9 with linux-system-roles - 2026-09-16

Earlier I hand-wrote Quadlet files for Caddy + PHP-FPM directly on the host. The linux-system-roles.podman role turns that into something declarative: instead of writing .container/.network unit files as text, you describe them as nested YAML matching each unit's own [Section]…

Ansible Vault encrypts the secret in git; Podman's default driver stores it in plaintext - 2026-09-20

Encrypting a variable with ansible-vault and rendering it into a Podman secret for a rootless container looks like the secret is protected end to end. It isn't, by default — verified from both the Ansible module's own source and Podman's, because the gap between "encrypted in…

What Ansible Vault actually encrypts, and where that protection stops - 2026-09-24

Ansible's own vault guide opens with a warning worth reading before anything else about the tool: "Encryption with Ansible Vault ONLY protects 'data at rest'." That's a precise boundary, not a vague caveat, and it's worth tracing exactly where it falls — both what "at rest"…

Handling deployment failures with Ansible's block/rescue/always - 2026-09-29

Saw a LinkedIn post comparing Ansible's block/rescue/always to try/catch — deploy, roll back automatically on failure, alert the team, clean up regardless. It's a real, built-in Ansible feature (current docs), and it's more precise than "try/catch" once you look at what…

Building an Ansible execution environment from a locked requirements file - 2026-09-29

Third entry in the Ansible development environment series. An execution environment (EE) is a container image holding the whole Ansible runtime: ansible-core, ansible-runner, Python packages, collections and system packages. The first entry ranks it against the venv-based…

Locking an Ansible development environment: pip, venv, pip-tools, uv or an execution environment - 2026-09-29

First entry in the Ansible development environment series. An Ansible project needs a runtime on the control node, the machine that runs ansible-playbook. That runtime has five layers, and each tool below fixes some of them:

Pinning ansible-core with pip-tools, uv and Poetry - 2026-09-29

Second entry in the Ansible development environment series; the first ranks all the options. pip-tools, uv and Poetry all do the same job for an Ansible project. They record the exact ansible-core a project runs, plus everything it pulls in, so every laptop and CI job installs…

Where to run an Ansible development environment: venv, Dev Container, Remote-SSH, code-server or Dev Spaces - 2026-09-29

Fourth entry in the Ansible development environment series. The first three decide what the runtime is made of and how to lock it. This one decides where the editor and tools run. There are five common answers, and most of the choice comes down to three things: - what the…

Ansible Development Tools (ADT): one install, and the Python version decides what you get - 2026-09-29

Fifth entry in the Ansible development environment series. Part 4 chose where the tools run; this one is about the tools themselves. ADT (Ansible Development Tools) is the PyPI package ansible-dev-tools. It's a meta-package: its own code is little more than an adt command, and…

Committing the VS Code Ansible settings with the repository - 2026-09-29

Sixth entry in the Ansible development environment series. Part 4 chose where VS Code runs and part 5 installed the tools. This part makes every developer's editor behave the same way on a given repository. The means is two small files committed next to the code: one for…

Running playbooks locally in the execution environment production uses - 2026-09-30

Seventh entry in the Ansible development environment series. Part 6 pointed the editor at the team's execution environment (EE), the container image that AAP (Red Hat Ansible Automation Platform) and its automation controller run every job in. This part does the same for the…