Sunday, July 12, 2026

ansible.cfg


The ansible.cfg file is the main configuration file that controls how Ansible behaves globally or per project.

Where Ansible Looks for ansible.cfg (VERY IMPORTANT)

Order of precedence:

ANSIBLE_CONFIG (environment variable)
./ansible.cfg (current project directory) ✅
~/.ansible.cfg (user home)
/etc/ansible/ansible.cfg (system-wide)

💡 First one found → used

Ansible Vault

 Ansibel Vault

Ansible Vault performs various operations. Specifically, it can
Encrypt/Decrypt a file
View an encrypted file without breaking the encryption
Edit an encrypted file
Create an encrypted file
Generate or reset the encrypted key

Ansible Vault uses AES256 encryption

The ansible-vault create command is used to create the encrypted file.
# ansible-vault create test_vault # it will prompt for a password
New Vault password:
Confirm New Vault password:

# cat test_vault
$ANSIBLE_VAULT;1.1;AES256
34363365356262323333626363616366383161393739663331373231386563306632323163336231
6537393461353932353035373561636461633738396662640a316165346666303439303030623032
62653534643866343465313134373862343839646434353130393764366632393237656265303531
3062613639663865310a383137316133653435643236336635626661323736646336323434643164
6162
Ansibel Vault id

# ansible-vault create --vault-id password@prompt multi_vault.yml
New vault password (password):
Confirm new vault password (password):

Edit File
# ansible-vault edit multi_vault.yml

Decrypting File
# ansible-vault edit multi_vault.yml
once decrypt the file can be opened using cat

While running playbook
# ansible-playbook --ask-vault-pass multi_vault.yml

Change/reset password for vault
# ansible-vault rekey multi_vault.yml
Vault password:
New Vault password:
Confirm New Vault password:
Rekey successful


Multi Vault
Ansible Vault allows operators to work with multiple vaults, each uniquely identified by a vault ID.
Vault IDs provide a “hint” to indicate the correct password to use when decrypting a vault file.

# Encrypt staging config with "mte & prod" vault ID
# ansible-vault encrypt --vault-id mte@prompt config/sec_mte.yml
# ansible-vault encrypt --vault-id prod@prompt config/sec_prod.yml
# ansible-playbook site.yml -i inventory.ini --vault-id staging@prompt --vault-id prod@vault_prod_pass.txt

Configuring Vault IDs in ansible.cfg
# ansible.cfg
[defaults]
# Comma-separated list of vault identity sources
vault_identity_list = dev@~/.vault_pass_dev, staging@~/.vault_pass_staging, prod@~/.vault_pass_prod

Ansible Variables_1






Ansible_Facts

Ansible implements fact collecting through the a module called the setup module.
It collects detailed information (called facts) from managed nodes.
It collects detailed information (called facts) from managed nodes.
By default, Ansible automatically runs setup at the start of every play.


$ ansible ubuntu -m setup


- name: Gather facts manually
hosts: all
tasks:
- name: Run setup module
ansible.builtin.setup:
- debug:
msg: "Host {{ ansible_hostname }} has {{ ansible_memtotal_mb }} MB RAM"


Filtering Facts

Collect only specific facts
- name: Get only network-related facts
ansible.builtin.setup:
filter: ansible_default_ipv4

- name: Get only facts that start with 'ansible_processor'
ansible.builtin.setup:
filter: 'ansible_processor*'
- name: Get only facts that start with 'ansible_processor' and 'ansible_mem'
ansible.builtin.setup:
filter: 'ansible_processor*', 'ansible_mem*'

$ ansible all -m setup -a 'filter=ansible_all_ipv6_addresses'

Gather_Subset
Control what facts to collect
- name: Gather only minimal facts
ansible.builtin.setup:
gather_subset:
- min

Other options:
all (default)
hardware
network
virtual
ohai
facter


gather_subset: ! 'all,!hardware' # Gather all facts except hardware facts
gather_subset: ! 'all,!network' # Gather all facts except network facts
gather_subset: ! 'all,!virtual' # Gather all facts except virtual facts
gather_subset: ! 'all,!ohai' # Gather all facts except ohai facts
gather_subset: ! 'all,!facter' # Gather all facts except facter facts

Set timeout for fact gathering
- ansible.builtin.setup:
gather_timeout: 10

set_fact → create custom facts
Set_fact is a powerful module that allows you to create custom facts during playbook execution.

- name: Set a variable
set_fact:
my_var: "hello"

- name: Set multiple variables
set_fact:
env: "prod"
version: "1.2.3"

Append to a list variable
- name: Append to a list variable
set_fact:
my_list: "{{ my_list | default([]) + ['new_item'] }}"

Update a dictionary variable
- name: Update a dictionary variable
set_fact:
my_dict: "{{ my_dict | default({}) | combine({'key': 'value'}) }}"

Loop with set_fact
- name: Create a list of hostnames
set_fact:
hostnames: "{{ hostnames | default([]) + [item] }}"
loop: "{{ ansible_play_hosts }}"

- name: Build list dynamically
set_fact:
servers: "{{ servers | default([]) + [item] }}"
loop:
- web1
- web2


hostvars → access facts of other hosts
Hostvars is a powerful Ansible variable that allows you to access the facts and variables of other hosts in your inventory.
This can be particularly useful when you need to reference information about other hosts during playbook execution.

HOSTVARS VERSUS HOST_VARS
Please be warned that hostvars is computed when you run Ansible, while host_vars is a directory that you can use to define variables for a particular system.

What is hostvars?
👉 It is a dictionary of all hosts and their variables.

hostvars['hostname']['variable_name']


- name: Access hostvars
hosts: all
tasks:
- name: Show IP address of another host
debug:
msg: "The IP address of {{ item }} is {{ hostvars[item]['ansible_default_ipv4']['address'] }}"
loop: "{{ ansible_play_hosts }}"

Local facts
Local facts are custom facts that you can create on the managed nodes themselves.
They are stored in the /etc/ansible/facts.d/ directory on the managed nodes.
Local facts are useful for storing information that is specific to a particular host and may not be easily gathered through the setup module.
You can place one or more files on the remote host machine in the
/etc/ansible/facts.d directory. These files can be in JSON or INI format and must have a .json or .ini extension. When Ansible runs the setup module, it will automatically read these files and include the custom facts in the gathered facts for that host.

These facts are available as keys of a special variable named ansible_local.

To create a local fact, you can create a JSON or INI file in the /etc/ansible/facts.d/ directory on the managed node. For example, you could create a file called /etc/ansible/facts.d/custom_facts.json with the following content:

{
"custom_fact": "This is a custom fact"
}
Once you have created the local fact file, you can access the custom fact in your playbooks using the ansible_local variable. For example:
- name: Access local fact
hosts: all
tasks:
- name: Show custom fact
debug:
msg: "The custom fact is: {{ ansible_local.custom_facts.custom_fact }}"
Dynamic Inventory Script
An Ansible dynamic inventory script must support two command-line flags:
--host=<hostname> for showing host details
--list for listing groups


Magic Variables
Ansible provides several magic variables that are automatically available in your playbooks. These variables provide information about the playbook execution context, such as the current host, group, and task. Some commonly used magic variables include:

hostvars A dict whose keys are Ansible hostnames and values are dicts that map variable names to values for that host. This variable is useful for accessing variables of other hosts in the inventory.

inventory_host name The name of the current host as known in the Ansible inventory, might include domain name
inventory_hostname_short Name of the current host as known by Ansible, without the domain name(e.g., myhost)
group_names A list of all groups that the current host is a member of

- ansible_play_hosts: A list of all hosts in the current play
- ansible_play_batch: A list of hosts in the current batch (when using serial)
- ansible_play_name: The name of the current play
- ansible_play_role_names: A list of roles applied to the current play
- ansible_play_task_name: The name of the current task
- ansible_play_hosts_all: A list of all hosts in the inventory
- ansible_play_hosts_all_groups: A list of all groups in the inventory
- ansible_play_hosts_all_hosts: A list of all hosts in the inventory
- ansible_play_hosts_all_groups_hosts: A dictionary of all groups and their hosts in the inventory
- ansible_play_hosts_all_groups_hosts_vars: A dictionary of all groups, their hosts, and their variables in the inventory
- ansible_play_hosts_all_groups_hosts_vars_hostvars: A dictionary of all groups, their hosts, their variables, and the hostvars for each host in the inventory



Extra variable with the command-line option -e var=value
$ ansible-playbook playbook.yml -e "my_var=value"
$ ansible-playbook playbook.yml -e "my_var=value" -e "my_list=['item1', 'item2']"
$ ansible-playbook playbook.yml -e "my_dict={'key1': 'value1', 'key2': 'value2'}"

plug-ins


To see the list of available plug-ins
$ ansible-doc -t inventory -l

To see plug-in-specific documentation and examples
$ ansible-doc -t inventory <plugin name>

Ansible_9 Automation Execution Environment (EE)_latest

 What are execution environment,


All jobs with AAP are executed within containers, also known as Execution Environments, as a way to isolate jobs from the host system.
They contains the Ansble tools, collections, and roles and software librariers needed for your automation content. This is to reduce complexity and ensure that jobs run consistently across different systems.

Execution environments provide a standardized environment for running Ansible playbooks, making it easier to manage dependencies and avoid conflicts with the host system's configuration.


To create a custom execution environment, you can use Ansible Builder.
Ansible Builder allows you to define the necessary dependencies, collections, and roles required for your automation tasks. It helps you create a reproducible and portable execution environment that can be shared across different systems and teams.

Ansible Builder
Ansible Builder is a tool that allows you to create custom execution environments for Ansible Automation Platform (AAP). It helps you define the necessary dependencies, collections, and roles required for your automation tasks. By using Ansible Builder, you can create a reproducible and portable execution environment that can be shared across different systems and teams.

# ansible-builder --version
Creating custom execution environments
# mkdir -p my_execution_env; cd my_execution_env ; mkdir files; cd files ; touch ansible.cfg

The ansible.cfg file will contain information what AutomationHub Servers, we woule like to download collections from. You can also specify other configuration options as needed.


cat ansible.cfg
[galaxy]
server_list = automation_hub, ansible-galaxy
[galaxy_server.automation_hub]
url=https://automationhub.example.com/api/galaxy/v3/
token=<your_token_here>
validate_certs=False

[galaxy_server.ansible-galaxy]
url=https://galaxy.ansible.com/api/
token=<your_token_here>
validate_certs=False

# tocuch execution-environment.yml # also know as build definition file
The execution-environment.yml file will define the base image and build steps, any additional dependencies, collections, or roles that you want to include in your custom execution environment. This file is used by Ansible Builder to build the execution environment. # Essentially, everyting we need for creating the execution environment.

vi execution-environment.yml
---
version: 3
build_arg_defaults:
EE_BASE_IMAGE: "quay.io/ansible/ansible-runner:latest"
ANSIBLE_GALAXY_CLI_COLLECTION_OPTS: "--ignore-certs"
dependencies:
galaxy: requirements.yml
galaxy:
collections:
- name: ansible.posix
version: "1.5.0"
- name: community.general
version: "6.4.0"
python: requirements.txt
python:
- boto3
- botocore
- boto
- boto3-stubs
system: bind-utils, git, openssh-clients
images:
base_image: "quay.io/ansible/ansible-runner:latest"

additional_build_steps:
prepend:
- RUN echo "Custom build step: Installing additional packages"
- RUN yum install -y jq

optional:
labels:
com.example.description: "Custom Execution Environment for Ansible Automation Platform"
com.example.version: "1.0.0"
options:
build_arg_defaults:
EE_BASE_IMAGE: "quay.io/ansible/ansible-runner:latest"
ANSIBLE_GALAXY_CLI_COLLECTION_OPTS: "--ignore-certs"

# podman login quay.io
# podman login automationhub.example.com


Building the execution environment
Once you have defined your execution-environment.yml and ansible.cfg files, you can build the custom execution environment using the ansible-builder command. This will create a container image that includes all the necessary dependencies, collections, and roles specified in your configuration files.
# ansible-builder create -v 3 # this step is optional, it will create a new execution environment based on the execution-environment.yml file and the ansible.cfg file. It will also create a requirements.yml file that lists all the collections and roles that are included in the execution environment.

# tree context

# ansible-builder build -f execution-environment.yml -t my_custom_execution_env:latest -v 3 --no-cache
# podman image ls


# podman login quay.io --tls-verify=false