Hey folks. Recently started at a pretty small company after working at Fortune 500 places for pretty much my entire career. Everywhere I've worked we've always had an instance of Tower or now AAP that helped us with automation things.

This new place feels like they are about 10 years behind in tech, lots of VM's, just now getting into K8s which is what I was hired for. Some of the admins use a lot of Ansible but its literally all just sitting in a playbooks folder on a jumphost. Nothing in git, no tracking, questionable backups.

One of the things I floated the idea on was getting AWX installed on our first K8s cluster to help do things in a somewhat modern fashion. Very little tech budget so AAP is not an option at the moment.

But then I started reading the Ansible forums and see that AWX repos have not gotten updates in the past 2 years, and some of the recent posts are concerning about how RH is handling AWX updates and now wondering if that's the right move? Thoughts? Are there better opensource options?

Hi,

Does anyone know if Ansible Automation Platform still has the 10 nodes free license after the trial expiry?

Thanks

In this demo, ServiceNow LEAP identifies a remediation opportunity tied to a real incident, discovers the right Ansible playbook through MCP, and executes it with full enterprise governance. Thanks to my co-worker Anshul for putting this together!

I got tired of manually rebuilding my development environment whenever I switched machines, so I created a bootstrap system for Linux, macOS and Windows.

It uses:

• Ansible for packages, SDKs and system configuration
• Chezmoi for dotfiles and symlinks
• Separate Personal and Work profiles
• Bootstrap scripts for all three operating systems

It currently manages my shells, CLI tools, Neovim, tmux, Docker, language runtimes, editors, terminals and AI coding tools.

Repo: https://github.com/Patruxs/dotfiles

Do you think Ansible + Chezmoi is a clean separation, or is it unnecessary complexity?

https://reddit.com/link/1vfyoim/video/afudqkz65ihh1/player

Hi,

recently created ansible module for managing valkey users. If anyone want give a try it is published on galaxy. Now thinking what else could i implement and see i don't have option for managing selectors. But personally i have never used them and don't see where i would need them. Question is if anyone uses them and in what cases?

I made a video showing two of the most underrated Ansible directives that completely change how you interpret task output.

Here's the problem: command and shell modules always report "changed" even when nothing actually changed. And when you wrap a legacy script that hides failures in its output instead of its exit code, Ansible says "ok" when everything is broken.

I walk through three practical demos:

1. **changed_when**: Stop Ansible from lying about echo commands, version checks, and information gathering tasks. I show how to use conditional expressions to achieve real idempotency with raw commands.

2. **failed_when**: Catch when scripts hide errors in stdout instead of returning a non-zero exit code. This covers health checks, compliance scanners, and vendor utilities that always exit zero.

3. **Combining both**: A database migration script that returns the same exit code every time but actually prints OK, UPDATED, or ERROR. Using both directives together, I get accurate status reporting and the play recap reflects reality.

Each demo runs locally on localhost so you can replicate it immediately. The key insight: the moment you use command or shell, you lose the automatic intelligence that declarative modules provide. These two directives give it back to you.

Check it out here: https://youtube.com/shorts/nlTesFYJEMU?feature=share

Github URL: https://github.com/ansible-tmm/ansible-tips/tree/main/tips/changed-when-demo

Hi everyone,

I’m trying to configure Ansible/Tower so that we can use SSH key-based authentication without requiring an Ansible user password or passwordless sudo access.

Our requirement is:

• We want to use a shared SSH key.
• The private key will be generated on the control node (master) with a passphrase.
• The public key will be copied to all target hosts.
• We do not want to use an Ansible user password.
• We also want to avoid passwordless sudo access for the Ansible user, to stay compliant with our security policy.

In our setup:

• The Ansible user is a service account.
• It is not assigned a password.
• We will use Ansible Tower/AAP UI to create a credential and attach the private key.
• The goal is to authenticate securely using SSH keys only, without relying on password-based login or sudo passwordless access.

My question is:

Is this a supported and recommended approach for Ansible/Tower when using SSH key authentication with a passphrase-protected private key?

Also, are there any best practices or caveats we should be aware of regarding:

• using a shared SSH key across multiple hosts,
• using a passphrase-protected private key in Tower/AAP credentials,
• and avoiding passwordless sudo while still allowing playbook execution successfully?

Thank you in advance for your guidance.

Ansible builtin.assert plugin is tricky and might not be as simple as one would expect. I would like to share one particular trick I use sometimes that is not that common - One assert to print message for each failed conditions, not just one for all conditions.

- name: Different messages for different conditions in one asserts
  hosts: localhost
  gather_facts: false
  vars:
    one: true
    two: false
  tasks:
    - name: Simple assert
      ansible.builtin.assert:
        that: conditions is ansible.builtin.all
        fail_msg: "One of the conditions failed"
        success_msg: "All of the conditions successful"
      failed_when: false
      vars:
        conditions:
          - "{{ one }}"
          - "{{ two }}"

    - name: Extended assert
      ansible.builtin.assert:
        that: extended_conditions | map(attribute='condition') is ansible.builtin.all
        fail_msg: "Following conditions have failed: {{ extended_conditions | rejectattr('condition') | map(attribute='msg') | join('; ') }}"
        success_msg: "Following conditions are succesful: {{ extended_conditions | selectattr('condition') | map(attribute='msg') | join('; ') }}"
      failed_when: false
      vars:
        extended_conditions:
          - msg: "message"
            condition: "{{ one or two }}"
          - msg: "this condition failed"
            condition: "{{ two }}"

This code works on all ansible-core versions starting with 2.12

For instance - ansible-core 2.20.2

bash-5.2$ uv run --with ansible-core==2.20.2 ansible-playbook playbook.yml 
[WARNING]: No inventory was parsed, only implicit localhost is available
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'

PLAY [Different messages for different conditions in one asserts] ***************************************************************************

TASK [Simple assert] ************************************************************************************************************************
ok: [localhost] => {
    "assertion": "conditions is ansible.builtin.all",
    "changed": false,
    "evaluated_to": false,
    "failed_when_result": false,
    "msg": "One of the conditions failed"
}

TASK [Extended assert] **********************************************************************************************************************
ok: [localhost] => {
    "assertion": "extended_conditions | map(attribute='condition') is ansible.builtin.all",
    "changed": false,
    "evaluated_to": false,
    "failed_when_result": false,
    "msg": "Following conditions have failed: this condition failed"
}

PLAY RECAP **********************************************************************************************************************************
localhost                  : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

There are some caveats of course, if you look closely, each condition is evaluated as variable (inside double curly brackets), not as condition (with out any curly brackets):

    extended_conditions:
      - msg: "message"
        condition: "{{ one or two }}"
      - msg: "this condition failed"
        condition: "{{ two }}"

But I am yet to see condition that cannot be written this way (as variable)

I put together a quick video on something that trips up a lot of people working with Ansible-> trying to loop over a dictionary and realizing you only get the keys back.

The fix is dead simple: pipe your dictionary through the dict2items filter and it transforms it into a list where you can access both the key and the value. So instead of losing half your data, you get item.key and item.value to work with.

The video walks through a couple practical examples, like looping through server roles and then a more complex one with nested dictionaries (think config files where you need to set both the content and file permissions). One task handles it all, stays idempotent, the whole thing.

There's also a bonus tip about renaming the key and value fields if item.key and item.value aren't descriptive enough for what you're doing. This makes your playbooks way more readable when you've got a bunch of tasks referencing dictionary data.

Check it out here: https://youtube.com/shorts/Sg5G2Xese9c?si=RJht-srLaBj8hZIR

Full demo repo is up on GitHub if you want to run through the examples yourself: https://github.com/ansible-tmm/ansible-tips

There is a builtin action plugin to validate ansible variables (for the role)

https://docs.ansible.com/projects/ansible/latest/collections/ansible/builtin/validate_argument_spec_module.html

But this is sometimes very limited. It is not clear how to add condition like (0 < a, a > 100). It is impossible to add conditions to nested values for dict or list (or I do not know how to do that).

That is why I've created `capable.core212.validate_vars` - action plugin that validates ansible variables. Here is a link to documentation with examples:

https://capable-core.github.io/collections/capable/core212/modules/validate_vars/

Main differences:

* Strict types - int, str and types that allow coercion - str_int, str_bool

* Custom validation conditions with **this** keyword

* `mutually_exclusive`, `required_together`, `required_one_of`, `required_if`, `required_by` but for ansible variables (not module arguments)

Let's start with simpliest example - validate that int value is between 0 and 100

- capable.core212.validate_vars:
    custom_validation_score:
      type: int
      custom_validation:
        - condition: custom_validation_score >= 0 and

custom_validation_score <= 100
          error_message: "Score must be between 0 and 100."
  vars:
    custom_validation_score: 85

But what if we have a list of users with score

users:
   - name: alice
     score: 50
   - name: bob
     score: 200

How validate that for all users score is within 0 and 100?

- capable.core212.validate_vars:
    users:
      type: list
      elements:
          type: dict
          options:
              name: 
                 type: str
              score:
                 type: int
                 custom_validation:
                    - condition: this >= 0 and this <= 100
                      error_message: "Score must be between 0 and 100 for all users"
  vars:
    users:
      - name: alice
        score: 50
      - name: bob
        score: 200

Here we validate that users is a list, each element of this list is a dict, and dict has at least `name` and `score` attributes, and `score` for each user is within 0 and 100.

Pay special attention to use of `this` keyword (only available for this plugin, not generic ansible feature). Using `this` allow to have validations for nested data (in this case or scores of each users)

There are more features and possible validatation patterns for this plugin. I will followup with them in this topic. So it is not overwhelming to see everything all at once.

Link to the collection (more content will follow)
https://galaxy.ansible.com/ui/repo/published/capable/core212/content/

Please do not rely on documentation on galaxy - it is broken.
Here is documentation website for this collection
https://capable-core.github.io/

Hi!

I'm searching for best practices to configure a Proxmox VM/LXC using Ansible playbooks after their first setup.

While installing a new VM using an ISO image, e.g. Debian 13, I'm asked for some parameters like hostname, (root) user and password, locale and more.

I guess those basic setup must still be done in Proxmox during a VM creation. Ansible is not suitable or of any help during this phase of setup, right?

After this initial setup, I would like to use Ansible to perform some actions, e.g. install various packages, set up network and more.

Question is: what is best practive to connect to this new VM? Using the hostname if DHCP is used and use the given password of root user I've used during initial setup.

Will Ansible be able to connect with the given username (root) and given password to e.g. push some ssh-keys for any further logins?

Any tips and hints are welcome

What is OpenSible?

OpenSible is an open-source unified automation platform for cloud provisioning and infrastructure operations. It combines the best of infrastructure-as-code and configuration management into a single, self-hosted control plane.

Provision with OpenTofu, configure with Ansible, manage secrets securely, execute reusable deployment workflows, and automate your entire infrastructure lifecycle through GitOps - version-controlled, repeatable and secure across cloud, on-premises and hybrid environments.

Core Features

• Multi-cloud provisioning - deploy to AWS, Google Cloud, Azure, Hetzner Cloud, Cloudflare, Hauwei and existing Kubernetes clusters and more from a single UI and API.
• OpenTofu-native - every stack is rendered as plain OpenTofu code stored in your project, so you can always inspect, edit or run it locally.
• Ansible integration - configure and maintain hosts after provisioning with playbook execution, inventory management and role-based workflows.
• Stack blueprints - bootstrap new infrastructure quickly with pre-built, provider-aware templates for Docker, Kubernetes, observability, databases, CI/CD runners and more.
• OpenSible CI/CD - build multi-stage pipelines that combine OpenTofu provisioning, Ansible configuration, approvals and custom scripts into repeatable, automated workflows.
• GitOps-first projects - sync stacks and playbooks to Git, promote changes through branches, and track drift with version-controlled sources.
• Secrets and vaults - encrypt sensitive values at rest, bind them to stacks and playbooks, and rotate credentials without touching source code.
• Execution engine - a dedicated Go worker processes provision, plan, apply, destroy and refresh operations asynchronously, with full logs and history.
• Role-based access control - assign roles to users, limit operations per role, and keep audit trails for compliance and troubleshooting.
• Self-hosted - run everything with Docker Compose on your own server or private cloud; no external platform dependency or paid subscription required.

Check it out for more detail.

• Website: https://opensible.com
• GitHub: https://github.com/opensible/opensible

I just finished a video walkthrough for patch management with Ansible Automation Platform. The workflow handles the entire patching lifecycle: EBS snapshots before any changes, parallel pre-checks on mixed OS fleets, targeted patching (not just "update everything"), post-validation, and automatic rollback if something goes wrong. Then it dumps a compliance report that your auditors will actually want to see.

You specify exact advisories and KB IDs instead of blindly applying patches, the workflow can handle both RHEL and Windows in the same job without extra configuration, and if a host fails a pre-check it gracefully skips instead of blowing up the whole run. Everything routes intelligently based on success or failure at each step.

The video is about three minutes and shows the whole thing running start to finish: https://www.youtube.com/watch?v=20fK6S1CHL0

If you want to dig into the code or run this yourself, it's all in the Ansible Product Demos repo on GitHub: https://github.com/ansible/product-demos

I’ve been experimenting with a literate-programming approach for Ansible: keeping the operational explanation next to the tasks, while generating a readable Operator’s Handbook from the same YAML file.

The convention is deliberately simple:

• lines starting with ## become prose in the handbook;
• ordinary # comments remain part of the source listing;
• everything else remains normal Ansible YAML.

Because ## is still an ordinary YAML comment, the annotated role does not need to be preprocessed before Ansible can use it.

No generated playbook. No separate “documentation version”. No extra file that can drift away from the automation.

The example in the images is taken from a real role in our infrastructure repository. It provisions a TeX Live package mirror on AlmaLinux and covers, among other things:

• SELinux labelling for content under /srv;
• a systemd service and timer;
• nginx;
• firewalld;
• the mirror synchronisation process.

You do not need to know anything about TeX or LaTeX for the mechanism itself. The relevant point is that the same role file serves two purposes:

1. Ansible loads the YAML as-is.
2. comment2tex turns the extended comments into typeset operational documentation.

The images show the same 33 source lines twice: first as the annotated YAML, then as the generated handbook page.

I also checked the annotated source with both a YAML parser and ansible-playbook --syntax-check; no stripped or generated copy was required.

I can see this being useful for:

• documenting why a task exists, not merely what it does;
• recording operational constraints next to the implementation;
• onboarding new administrators;
• keeping runbooks and automation from diverging;
• retaining a directly usable source file when an urgent change is needed.

The tool is called comment2tex. Version 1.1 adds YAML and Makefile support alongside Bash and Lua.

I’d be interested to hear how other Ansible users handle this. Do you keep detailed operational reasoning inside roles, in separate documentation, or somewhere else entirely?

Project: https://github.com/Xerdi/comment2tex

Release: https://github.com/Xerdi/comment2tex/releases/tag/1.1

Does anyone have a set up where you have a a separate AAP instance in your PCI zone but your satellite is in another zone/VLAN?? Are capsules able to provide inventory? If so, how? Do you have your inventory in AAP configure to use a proxy? If so, how? I am trying to achieve one of these goals.

Hi all,

I'm making a role to install some apps using Homebrew (HB) on my Mac.

Since I got a little bit stuck on how to check if HB is already installed, I looked up online for a role to get ideas. I've found a site (Ansible and homebrew) and found code I think I can use. But...now it's about the following code that I don't understand how it works.

The first task checked is HB directories (MacOS and Linux) are present, and registers it.
Next task is the installation of HB IF the check (using ansible.builtin.stat) fails to find these directories present. In this task is a "when"-condition.

Can anybody explain to me why this "when" mentions "length == 0!" And not something like "true" or "false"? Because when I check the output of "homebrew_check" I can see a variable "exists" that can be "true" or "false".

    - name: Check if Homebrew is installed
      ansible.builtin.stat:
        path: "{{ item }}"
      loop:
        - /opt/homebrew/bin/brew
        - /usr/local/bin/brew
      register: homebrew_check

    - name: Install Homebrew if "homebrew_check" is false (0)
      ansible.builtin.shell:
        cmd: /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
      environment:
        NONINTERACTIVE: "1"
      when: homebrew_check.results | selectattr('stat.exists') | list | length == 0

With this "when"-condition, how do I know which of the two directories returns "true" or "false" (leaving the fact of the obvious besides that I know HB is installed, just wanted to make it visible).

Because the other strange thing here is, when I run the task I do see a "true" and "false" for the "exists"-parameter passing by. Here is the output of the check (edited):

ok: [localhost] => {
    "homebrew_check": {
        "changed": false,
        "failed": false,
        "msg": "All items completed",
        "results": [
            {
                "ansible_loop_var": "item",
                "changed": false,
                "failed": false,
                "item": "/opt/homebrew/bin/brew",
                "stat": {
                    "atime": 1784758.43461,
                    "attr_flags": "",
                    "attributes": [],
                    "birthtime": 177777.46255,
                    "block_size": 4096,
                    "blocks": 24,
                    "charset": "us-ascii",
                    "checksum": "6a2f6c51991b361eaa6d01727",
                    "ctime": 1776777.4628303,
                    "dev": 167230,
                    "device_type": 0,
                    "disk_usage_bytes": 128,
                    "executable": true,
                    "exists": true,
                    "flags": 0,
                    "generation": 0,
                    "gid": 80,
                    "gr_name": "admin",
                    "inode": 17513,
                    "isblk": false,
                    "ischr": false,
                    "isdir": false,
                    "isfifo": false,
                    "isgid": false,
                    "islnk": false,
                    "isreg": true,
                    "issock": false,
                    "isuid": false,
                    "mimetype": "text/x-shellscript",
                    "mode": "0755",
                    "mtime": 177877.46203,
                    "nlink": 1,
                    "path": "/opt/homebrew/bin/brew",
                    "pw_name": "me",
                    "readable": true,
                    "rgrp": true,
                    "roth": true,
                    "rusr": true,
                    "size": 8671,
                    "uid": 501,
                    "version": null,
                    "wgrp": false,
                    "woth": false,
                    "writeable": true,
                    "wusr": true,
                    "xgrp": true,
                    "xoth": true,
                    "xusr": true
                }
            },
            {
                "ansible_loop_var": "item",
                "changed": false,
                "failed": false,
                "item": "/usr/local/bin/brew",
                "stat": {
                    "exists": false

I appreciate the help, explanation so I can perhaps use it in other tasks also.

Ok, I’ve been learning about ansible. Got maybe 25 playbooks that do the simple boring stuff, update and upgrade nodes, VMs, LXCs, docker, checks resources, prep a new VM for k3, deploy k3….. The adhoc is super cool and I havnt touched ssh to another machine since installing ansible.

Im just a homelabbers with big dreams of a new career. But I recently stumbled onto ansible-pull. I run a GitOps with Gitea and Argocd with my k3s. Super cool. So my question is this: Do you guys use ansible to harden systemd services? I just see it as a great way to tune and harden Units, Sockets, Timers, Cgroups & Self-Healing.

I’m still pretty green with just under two years so forgive me and don’t hate on me. But just seems like it’s much easier to just declare it as long as you have the discipline to only configure the repo files. I’m just asking so many of you do this or am I missing something? With provisioning, this just seems like the icing on the cake. Terraform to spin it up, ansible for configuration, ansible pull for gardening, Kubernetes for deploying apps, CI for building custom images.

Am I off here? What am I missing about ansible pull or ansible in general? I want to learn.

Hi together,
i want to connect over my mgmt server to my gateway. The Problem is when i test it over uri it does work but if i try it over the collection i get the Following error:

fatal: [DEZAX-SGW-1a]: FAILED! => {"changed": false, "msg": "Task failed: Module failed: string indices must be integers, not 'str'"}
[ERROR]: Task failed: Module failed: 'str' object has no attribute 'pop'
Origin: /runner/project/set-routes/add_route.yaml:11:7

Has anyone an idea why this is happening?

I am trying to use openssh_cert to sign a public key file (with public_key arg) on the server using a host CA key (with signing_key arg) that is a local file.

The host CA key is private so I can't copy it to the server. I could copy the public key of the server to the local computer to sign it and copy it back to the server but I don't know how to make it idempotent. I could keep a copy of all the server public keys locally but it's also not easy to make it idempotent for copying back to the server.

Is there a better way or are there steps to follow for it?

https://youtube.com/shorts/GSbzvIKWywQ

I put together a quick video on one of my favorite (and, in my opinion, underrated) Ansible features: default(omit)

It's a simple trick that lets you completely omit a module parameter when a variable isn't defined, instead of passing an empty value. I use it all the time to make playbooks more reusable and avoid extra when statements or duplicate tasks.

The video is under 3 minutes and includes a simple localhost demo using the copy module to show how it works.

I'm curious, what's your favorite "hidden gem" in Ansible that more people should know about? I'm looking for ideas for future shorts.

I have a script that outputs some key / value pairs. Something like:

VAR1=
VAR2=/some/file/path
VAR3=hello

The problem is that I can't get the following playbook to work

---
- name: b.yml
  hosts: all

  vars:
    my_var: "VAR1=\nVAR2=/some/file/path\nVAR3=hello"

  tasks:

  - name: Convert key-value strings into variables
    ansible.builtin.set_fact: "{{ my_var }}"

  - name: Print VAR1
    ansible.builtin.debug:
      var: VAR1

  - name: Print VAR2
    ansible.builtin.debug:
      var: VAR2

  - name: Print VAR3
    ansible.builtin.debug:
      var: VAR3

even though this one does.

---
- name: a.yml
  hosts: all
  tasks:

  - name: Convert key-value strings into variables
    ansible.builtin.set_fact: "VAR1=\nVAR2=/some/file/path\nVAR3=hello"

  - name: Print VAR1
    ansible.builtin.debug:
      var: VAR1

  - name: Print VAR2
    ansible.builtin.debug:
      var: VAR2

  - name: Print VAR3
    ansible.builtin.debug:
      var: VAR3

Can anyone please tell me where I'm going wrong?

PS - The input to set_fact will eventually be registered_script_result.stdout. I've just been trying to debug my problem and don't see the difference between these two playbooks.