Ansible

Getting Started

Installation & Setup

Install Ansible and configure basic settings

Install Ansible on Ubuntu

Code

sudo apt update
sudo apt install -y ansible

Install Ansible via pip

Code

pip install ansible
pip install ansible==2.10.7

Verify Ansible Installation

Displays installed Ansible version and configuration details

Code

ansible --version

Execution

ansible 2.10.7
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/user/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.10.12

Version should be 2.9+
Python 3.6+ required

Ansible Configuration File

Main configuration file setup at ansible.cfg

Create Basic ansible.cfg

Code

1
[defaults]
2
inventory = ./hosts
3
remote_user = ubuntu
4
private_key_file = ~/.ssh/id_rsa
5
host_key_checking = False
6
gather_facts = True

Configure Parallel Execution

forks increases parallelism for faster execution

Code

1
[defaults]
2
forks = 10
3
timeout = 30
4
retries = 3

Default forks value is 5
Higher forks = more parallelism = higher memory usage

First Playbook Run

Execute your first Ansible playbook

Simple Hello World Playbook

Basic playbook that prints a debug message

Code

1
---
2
- name: Hello World
3
  hosts: all
4
  tasks:
5
    - name: Print Hello
6
      debug:
7
        msg: "Hello from Ansible"

Execution

PLAY [Hello World] *****
TASK [Print Hello] *****
ok: [localhost] => {
    "msg": "Hello from Ansible"
}
PLAY RECAP *****
localhost : ok=1 changed=0 failed=0

Playbooks must be valid YAML
[object Object]

Test Host Connectivity

Verify connectivity to managed hosts

Ping All Hosts

Tests connectivity to all hosts without running tasks

Code

ansible all -i hosts -m ping

Execution

webserver01 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}
database01 | SUCCESS => {
    "ping": "pong"
}

ping module requires Python on remote
SUCCESS indicates host is reachable

Inventory Management

Inventory Formats

Different ways to define managed hosts

INI Format Inventory

INI format with groups and variables

Code

1
[webservers]
2
web1 ansible_host=192.168.1.10
3
web2 ansible_host=192.168.1.11
4

5
[databases]
6
db1 ansible_host=192.168.1.20
7
db2 ansible_host=192.168.1.21
8

9
[all:vars]
10
ansible_user=ubuntu
11
ansible_ssh_private_key_file=~/.ssh/id_rsa

Groups defined with [groupname]
[all:vars] applies to all hosts

YAML Format Inventory

YAML format for complex hierarchies

Code

1
all:
2
  children:
3
    webservers:
4
      hosts:
5
        web1:
6
          ansible_host: 192.168.1.10
7
        web2:
8
          ansible_host: 192.168.1.11
9
    databases:
10
      hosts:
11
        db1:
12
          ansible_host: 192.168.1.20
13
  vars:
14
    ansible_user: ubuntu

Better for nested groups
More readable for complex inventories

Host Patterns

Select specific hosts or groups

Target Specific Groups

webservers targets group, !web2 excludes host

Code

ansible webservers -i hosts -m ping
ansible databases -i hosts -m ping
ansible 'webservers:!web2' -i hosts -m ping

Execution

web1 | SUCCESS => {"ping": "pong"}
web2 | SUCCESS => {"ping": "pong"}

webservers selects entire group
negates selection

Wildcard and Range Patterns

Wildcards match patterns, [1:2] matches range

Code

ansible 'web*' -i hosts -m ping
ansible 'db[1:2]' -i hosts -m ping
ansible 'webservers[0]' -i hosts -m ping

* matches any characters
[1:2] includes indexes 1 and 2

Dynamic Inventory

Generate inventory from external sources

EC2 Dynamic Inventory

AWS EC2 plugin pulls instances from AWS

Code

1
plugin: aws_ec2
2
regions:
3
  - us-east-1
4
filters:
5
  tag:Environment: production
6
keyed_groups:
7
  - key: placement.region_name
8
    prefix: aws_region

Requires boto3 library
Cache results for performance

Custom Inventory Script

Custom script outputs JSON inventory format

Code

#!/bin/bash
cat << EOF
{
  "webservers": {
    "hosts": ["web1", "web2"]
  }
}
EOF

Script must be executable
Output must be valid JSON

Host Variables & Priorities

Set variables at different levels

Host-Level Variables

Variables specific to individual hosts

Code

1
all:
2
  children:
3
    webservers:
4
      hosts:
5
        web1:
6
          ansible_host: 192.168.1.10
7
          http_port: 80
8
          server_role: primary

Host variables override group variables
Highest precedence level

Group Variables File

Load variables from files by host/group name

Code

group_vars/webservers.yml
group_vars/webservers/main.yml
host_vars/web1.yml

group_vars/groupname.yml for entire group
host_vars/hostname.yml for single host

Ad-Hoc Commands

Basic Syntax

Run single tasks without playbook

Run Adhoc Command

Execute shell command on all hosts

Code

ansible all -i hosts -m shell -a "uptime"

Execution

web1 | CHANGED | rc=0 >>
 10:45:23 up 5 days,  3:21,  2 users,  load average: 0.05, 0.10, 0.08
web2 | CHANGED | rc=0 >>
 10:45:24 up 3 days,  1:15,  1 user,  load average: 0.02, 0.06, 0.05

-m specifies module
-a passes arguments

Use copy Module

Copy file from control node to remote

Code

ansible webservers -i hosts -m copy -a "src=/etc/hosts dest=/tmp/hosts"

Execution

web1 | CHANGED => {
    "changed": true,
    "checksum": "5d41402abc4b2a76b9719d911017c592",
    "dest": "/tmp/hosts",
    "gid": 0,
    "mode": "0644",
    "owner": "root",
    "size": 158,
    "src": "/tmp/ansible.87a8vz/hosts",
    "state": "file"
}

src path on control node
dest path on remote

Common Ad-Hoc Modules

Frequently used modules for ad-hoc tasks

Package Management

Install nginx package

Code

ansible webservers -i hosts -m apt -a "name=nginx state=present"

Execution

web1 | CHANGED => {
    "changed": true,
    "stderr": "",
    "stdout": "Reading package lists..."
}

apt for Debian/Ubuntu
yum for Red Hat/CentOS

Service Management

Start nginx service and enable on boot

Code

ansible webservers -i hosts -m service -a "name=nginx state=started enabled=yes"

Execution

web1 | CHANGED => {
    "changed": true,
    "enabled": true,
    "name": "nginx",
    "state": "started"
}

[object Object]
enabled=yes enables service on boot

File Permissions

Set file permissions and ownership

Code

ansible all -i hosts -m file -a "path=/tmp/test.txt mode=0644 owner=root"

Execution

web1 | CHANGED => {
    "changed": true,
    "mode": "0644",
    "owner": "root",
    "path": "/tmp/test.txt"
}

mode in octal format
owner and group can be specified

Parallelism & Forks

Control how many hosts execute simultaneously

Limit Concurrent Execution

Execute on 2 hosts at a time instead of default

Code

ansible all -i hosts -m ping -f 2

-f or --forks sets parallelism
Lower for safety, higher for speed

Serial Execution

Execute one at a time (serial)

Code

ansible all -i hosts -m shell -a "systemctl restart app" -f 1

Useful for rolling restarts
Prevents service downtime

Playbooks

Playbook Structure

Create and organize playbooks

Basic Playbook Structure

Complete playbook with all major sections

Code

1
---
2
- name: Deploy Web Application
3
  hosts: webservers
4
  become: yes
5
  vars:
6
    app_port: 8080
7
    app_user: www-data
8
  tasks:
9
    - name: Install dependencies
10
      apt:
11
        name: python3-pip
12
        state: present
13
    - name: Start application
14
      command: /opt/app/start.sh

--- indicates YAML document start
[object Object]
[object Object]

Multiple Plays in Single Playbook

Multiple plays execute sequentially

Code

1
---
2
- name: Configure Databases
3
  hosts: databases
4
  tasks:
5
    - debug: msg="Setting up database"
6

7
- name: Configure Web Servers
8
  hosts: webservers
9
  tasks:
10
    - debug: msg="Setting up web server"

Each play is independent
Plays execute in order

Playbook Execution

Run playbooks with various options

Run Basic Playbook

Execute playbook against specified inventory

Code

ansible-playbook playbook.yml -i hosts

Execution

PLAY [Deploy Web Application] *****
TASK [Install dependencies] *****
ok: [web1]
ok: [web2]
TASK [Start application] *****
changed: [web1]
changed: [web2]
PLAY RECAP *****
web1 : ok=2 changed=1 failed=0
web2 : ok=2 changed=1 failed=0

ok = task already in desired state
changed = task made changes

Check Mode (Dry Run)

Preview changes without executing

Code

ansible-playbook playbook.yml -i hosts --check

Shows what would change
Useful before production runs

Run with Extra Variables

Pass variables from command line

Code

ansible-playbook playbook.yml -i hosts -e "env=production app_version=2.0"

-e or --extra-vars for variables
Overrides defaults in playbook

Verbose Output

Show detailed execution information

Code

ansible-playbook playbook.yml -i hosts -vvv

-v = info, -vv = debug, -vvv = extra debug

Conditionals

Execute tasks based on conditions

Simple When Condition

Skip task if condition false

Code

1
- name: Install nginx if not exists
2
  apt:
3
    name: nginx
4
    state: present
5
  when: ansible_distribution == "Ubuntu"

Execution

TASK [Install nginx if not exists] *****
skipped: [web1] => (item=centos)
ok: [web2] => (item=ubuntu)

Conditions use when keyword
Access facts with ansible_variablename

Multiple Conditions

All conditions must be true (AND logic)

Code

1
- name: Restart service
2
  service:
3
    name: nginx
4
    state: restarted
5
  when:
6
    - ansible_os_family == "Debian"
7
    - ansible_distribution_version >= "20.04"

List format uses AND logic
[object Object]

Tasks & Handlers

Task Structure

Define and organize tasks

Basic Task Definition

Task with module, arguments, and tags

Code

1
- name: Install web server
2
  apt:
3
    name: nginx
4
    state: present
5
  become: yes
6
  tags:
7
    - webserver
8
    - packages

[object Object]
[object Object]

Register Task Output

Save task output in variable for later use

Code

1
- name: Get service status
2
  command: systemctl status nginx
3
  register: nginx_status
4
  changed_when: false
5

6
- name: Display status
7
  debug:
8
    msg: "{{ nginx_status.stdout }}"

register stores full result
Access with variable name

Handlers

Run tasks on change events

Basic Handler

Handler executes if task notifies it

Code

1
- name: Deploy application
2
  hosts: webservers
3
  tasks:
4
    - name: Copy app config
5
      copy:
6
        src: app.conf
7
        dest: /etc/app/app.conf
8
      notify: restart app
9
  handlers:
10
    - name: restart app
11
      service:
12
        name: app
13
        state: restarted

Handlers only run if task changed
Run at end of play by default

Multiple Handlers

Single task can notify multiple handlers

Code

1
tasks:
2
  - name: Update config
3
    template:
4
      src: nginx.conf.j2
5
      dest: /etc/nginx/nginx.conf
6
    notify:
7
      - reload nginx
8
      - log config change
9
handlers:
10
  - name: reload nginx
11
    service:
12
      name: nginx
13
      state: reloaded
14
  - name: log config change
15
    command: logger "nginx config updated"

Handlers run in defined order
Duplicate handler calls only run once

Loops

Repeat tasks with different variables

Loop Over List

Item variable changes per loop iteration

Code

1
- name: Install multiple packages
2
  apt:
3
    name: "{{ item }}"
4
    state: present
5
  loop:
6
    - nginx
7
    - php-fpm
8
    - mysql-client

Execution

TASK [Install multiple packages] *****
ok: [web1] => (item=nginx)
ok: [web1] => (item=php-fpm)
ok: [web1] => (item=mysql-client)

[object Object]
item is implicit variable name

Loop Over Dict

Loop over dictionary structures

Code

1
- name: Create users
2
  user:
3
    name: "{{ item.name }}"
4
    uid: "{{ item.uid }}"
5
    state: present
6
  loop:
7
    - { name: 'alice', uid: 1001 }
8
    - { name: 'bob', uid: 1002 }

Access dict items with dot notation
Useful for complex configurations

Variables & Facts

Variable Definition

Define and use variables

Play-Level Variables

Define variables at play scope

Code

1
- name: My playbook
2
  hosts: all
3
  vars:
4
    db_host: localhost
5
    db_port: 3306
6
    db_name: myapp
7
    env: production
8
  tasks:
9
    - name: Connect to database
10
      debug:
11
        msg: "Connecting to {{ db_host }}:{{ db_port }}"

Accessible in all tasks
{{ }} for variable substitution

Task-Level Variables

Variables local to specific task

Code

1
- name: Configure service
2
  service:
3
    name: nginx
4
    state: started
5
  vars:
6
    nginx_user: www-data
7
    nginx_workers: 4

Only available in this task's context

Gathering Facts

Collect system information from hosts

Auto-Gather Facts

Facts gathered by default unless disabled

Code

1
- name: Display fact
2
  hosts: all
3
  tasks:
4
    - name: Show OS
5
      debug:
6
        msg: "OS: {{ ansible_os_family }}, Memory: {{ ansible_memtotal_mb }}"

Execution

TASK [Show OS] *****
ok: [web1] => {
    "msg": "OS: Debian, Memory: 4096"
}

ansible_* variables are facts
[object Object]

Custom Facts

Define custom facts in JSON files

Code

/etc/ansible/facts.d/custom.fact
{
  "app_version": "2.1.0",
  "deployment_date": "2026-01-15"
}

Store in /etc/ansible/facts.d/
Extension must be .fact

Variable Precedence

Order of variable resolution

Precedence Levels

Variables override based on source location

Code

1
# Lowest to highest precedence:
2
# 1. defaults/main.yml in role
3
# 2. group_vars/all
4
# 3. group_vars/groupname
5
# 4. host_vars/hostname
6
# 5. vars in playbook
7
# 6. vars_files
8
# 7. task vars
9
# 8. -e extra vars (highest)

Command line (-e) always wins
Host vars override group vars

Override with Extra Vars

Extra vars override all others

Code

ansible-playbook playbook.yml -e "db_host=newhost db_port=5432"

-e highest precedence
Useful for overriding defaults

Variable Templating

Template and manipulate variable values

Jinja2 Filters

Transform variables with filters

Code

1
- name: Use filters
2
  debug:
3
    msg: |
4
      Uppercase: {{ service_name | upper }}
5
      Lowercase: {{ domain | lower }}
6
      Default: {{ undefined_var | default('localhost') }}
7
      List join: {{ servers | join(',') }}

Execution

TASK [Use filters] *****
ok: [localhost] => {
    "msg": "Uppercase: NGINX\nLowercase: example.com\nDefault: localhost\nList join: web1,web2,web3"
}

| for multiline strings
| filters modify variable values

Roles

Role Structure

Organize code with roles

Role Directory Structure

Standard role directory structure

Code

roles/webserver/
├── tasks/
│   └── main.yml
├── handlers/
│   └── main.yml
├── vars/
│   └── main.yml
├── defaults/
│   └── main.yml
├── files/
├── templates/
└── meta/
    └── main.yml

tasks/ contains main task execution
defaults/ provides variable defaults

Role Definition

Define tasks in role

Code

1
---
2
- name: Install web server
3
  apt:
4
    name: nginx
5
    state: present
6
  become: yes
7

8
- name: Copy config
9
  template:
10
    src: nginx.conf.j2
11
    dest: /etc/nginx/nginx.conf
12
  notify: restart nginx

Include handler definitions
Keep role single-purpose

Role Options & Includes

Include and configure roles

Include Role in Playbook

Include multiple roles

Code

1
- name: Deploy web application
2
  hosts: webservers
3
  roles:
4
    - webserver
5
    - php
6
    - mysql

Roles execute in order
Most common role usage

Role with Variables

Pass variables to roles

Code

1
- name: Deploy web application
2
  hosts: webservers
3
  roles:
4
    - role: webserver
5
      vars:
6
        nginx_port: 8080
7
        nginx_workers: 8
8
    - role: php
9
      when: "'php' in group_names"

Vars override role defaults
when can conditionally include roles

Role Dependencies

Manage role dependencies

Declare Dependencies

Specify required roles

Code

1
---
2
dependencies:
3
  - role: webserver
4
  - role: database
5
    vars:
6
      db_type: mysql

Dependencies execute first
Can pass variables to dependencies

Modules

System Modules

System administration modules

User Management

Create system user with specified properties

Code

1
- name: Create user
2
  user:
3
    name: appuser
4
    uid: 2000
5
    home: /opt/app
6
    shell: /bin/bash
7
    state: present

Execution

ok: [web1] => {
    "changed": false,
    "comment": "",
    "home": "/opt/app",
    "name": "appuser",
    "shell": "/bin/bash",
    "uid": 2000
}

[object Object]
uid specifies numeric user id

File Management

Create directory with permissions

Code

1
- name: Create directory
2
  file:
3
    path: /opt/app/data
4
    state: directory
5
    mode: '0755'
6
    owner: appuser
7
    recurse: yes

Execution

changed: [web1] => {
    "changed": true,
    "mode": "0755",
    "owner": "appuser",
    "path": "/opt/app/data",
    "state": "directory"
}

[object Object]
[object Object]

Package Management

Install and manage packages

APT Package Manager

Install multiple packages with cache update

Code

1
- name: Install packages
2
  apt:
3
    name:
4
      - curl
5
      - wget
6
      - git
7
    state: present
8
    update_cache: yes

update_cache updates apt database
[object Object]

PIP Package Manager

Install Python packages in virtualenv

Code

1
- name: Install Python packages
2
  pip:
3
    name:
4
      - django==3.2
5
      - requests>=2.25
6
    virtualenv: /opt/app/venv

virtualenv creates/uses virtualenv
Version pinning with == or >=

Command Execution

Execute commands on remote hosts

Command Module (Preferred)

Execute command without shell processing

Code

1
- name: Get nginx version
2
  command: nginx -v
3
  register: nginx_version
4
  changed_when: false

Execution

ok: [web1] => {
    "cmd": ["nginx", "-v"],
    "rc": 0,
    "stderr": "nginx version: nginx/1.18.0",
    "stdout": ""
}

No shell expansion (*, |, &)
More predictable

Shell Module

Execute with shell processing

Code

1
- name: Check if file exists
2
  shell: |
3
    if [ -f /opt/app/config.yml ]; then
4
      echo "exists"
5
    else
6
      echo "missing"
7
    fi
8
  register: config_check

Supports pipes, redirects
Less secure, use with care

Web & Net Modules

HTTP and network operations

HTTP Request

Make HTTP request and validate response

Code

1
- name: Health check
2
  uri:
3
    url: http://localhost:8080/health
4
    method: GET
5
    status_code: 200
6
  register: health_check

Execution

ok: [web1] => {
    "changed": false,
    "content": "{\"status\":\"ok\"}",
    "status": 200
}

status_code validates response
body can parse JSON response

Advanced Features

Blocks & Error Handling

Group tasks and handle errors

Block with Error Handling

Block groups tasks with error handling

Code

1
- name: Database operations
2
  block:
3
    - name: Connect to database
4
      debug: msg="Connecting"
5
    - name: Run migrations
6
      command: /opt/app/migrations.sh
7
  rescue:
8
    - name: Rollback on error
9
      command: /opt/app/rollback.sh
10
  always:
11
    - name: Cleanup
12
      file:
13
        path: /tmp/app.lock
14
        state: absent

[object Object]
[object Object]
[object Object]

Validate Task Results

Control when task is marked failed/changed

Code

1
- name: Run test
2
  shell: npm test
3
  failed_when: "npm_test.rc != 0"
4
  changed_when: false
5
  register: npm_test

failed_when override failure detection
changed_when override change detection

Asynchronous Execution

Run long-running tasks in background

Async with Polling

Run 1-hour task, check every 10 seconds

Code

1
- name: Long running task
2
  shell: /opt/app/long-job.sh
3
  async: 3600
4
  poll: 10
5
  register: long_job

Execution

ASYNC OK on web1 (job_id=123456789.12345)

[object Object]
[object Object]

Fire and Forget

Start task and don't wait for completion

Code

1
- name: Start background service
2
  shell: /opt/app/service.sh
3
  async: 0
4
  poll: 0

async: 0 and poll: 0 for fire-and-forget

Advanced Variable Usage

Complex variable patterns

Access Host Variables

Access variables from other hosts

Code

1
- name: Reference another host
2
  debug:
3
    msg: "Database host: {{ hostvars['db1']['ansible_default_ipv4']['address'] }}"

hostvars dict contains all host info
Useful in multi-host plays

Nested Variable Access

Access deeply nested structures

Code

1
vars:
2
  services:
3
    web:
4
      port: 8080
5
      workers: 4
6
    db:
7
      port: 5432
8
      replicas: 3
9
tasks:
10
  - debug: msg="Web port {{ services.web.port }}"

Dot notation for nested access
Bracket notation also works

Plugins & Extensions

Extend Ansible functionality

Custom Filters

Apply custom filter plugins

Code

1
- name: Use custom filter
2
  debug:
3
    msg: "{{ 'hello' | custom_uppercase }}"

Place filters in filter_plugins/
Extend Jinja2 capabilities

Lookup Plugins

Use lookup plugins for dynamic data

Code

1
- name: Read file content
2
  set_fact:
3
    file_content: "{{ lookup('file', '/etc/config.yml') }}"
4

5
- name: Get environment variable
6
  debug:
7
    msg: "{{ lookup('env', 'HOME') }}"

file, env, pipe lookups common
Results available mid-playbook

Vault & Security

Vault Basics

Encrypt sensitive data

Create Vault File

Create encrypted YAML file

Code

ansible-vault create secrets.yml
# Enter password, then edit:
# db_password: "secret123"
# api_key: "abc123xyz"

Execution

New Vault password:
Confirm New Vault password:

Creates .yml with encrypted content
Prompts for password

View Vault Content

Decrypt and display vault file

Code

ansible-vault view secrets.yml
# Password prompt

Requires vault password
Doesn't save decrypted content

Edit Vault File

Edit encrypted vault file safely

Code

ansible-vault edit secrets.yml

Opens in editor
Re-encrypts on save

Using Vault in Playbooks

Reference vault variables in playbooks

Include Vault Variables

Load vault variables in playbook

Code

1
- name: Deploy app
2
  hosts: webservers
3
  vars_files:
4
    - secrets.yml
5
  tasks:
6
    - name: Configure database
7
      template:
8
        src: db.conf.j2
9
        dest: /etc/app/db.conf
10
      vars:
11
        db_password: "{{ vault_db_password }}"

[object Object]
Automatic decryption on run

Run Playbook with Vault

Run playbook requiring vault password

Code

ansible-playbook playbook.yml -i hosts --ask-vault-pass

Execution

Vault password:
PLAY [Deploy app] *****
TASK [Configure database] *****
ok: [web1]

--ask-vault-pass prompts for password
--vault-password-file for automation

Encrypt Individual Files

Encrypt specific files or variables

Encrypt Single Variable

Encrypt individual secret for playbook

Code

ansible-vault encrypt_string --ask-vault-pass 'mypassword'

Execution

Reading plaintext input from stdin.
New Vault password:
Confirm New Vault password:
!vault |
  $ANSIBLE_VAULT;1.1;AES256
  66386...

Generates encrypted string
Paste into playbook vars

Encrypt Specific Files

Encrypt individual variable files

Code

ansible-vault encrypt host_vars/prod.yml

Encrypts existing file in place

Vault Best Practices

Security practices with vault

Password File Not in Repo

Store vault password file locally, not in git

Code

.gitignore:
.vault_pass

Run playbook:
ansible-playbook playbook.yml --vault-password-file ~/.vault_pass

Keep .vault_pass outside repository
Use --vault-password-file for automation

Different Vaults for Environments

Separate encrypted files per environment

Code

group_vars/prod/secrets.yml (encrypted)
group_vars/dev/secrets.yml (encrypted)
group_vars/staging/secrets.yml (encrypted)

Different passwords per environment
Enhanced security isolation

Ansible

Getting Started

Installation & Setup

Accessibility

Keywords

Install Ansible on Ubuntu

Install Ansible via pip

Verify Ansible Installation

Ansible Configuration File

Accessibility

Keywords

Create Basic ansible.cfg

Configure Parallel Execution

First Playbook Run

Accessibility

Keywords

Simple Hello World Playbook

Test Host Connectivity

Accessibility

Keywords

Ping All Hosts

Inventory Management

Inventory Formats

Accessibility

Keywords

INI Format Inventory

YAML Format Inventory

Host Patterns

Accessibility

Keywords

Target Specific Groups

Wildcard and Range Patterns

Dynamic Inventory

Accessibility

Keywords

EC2 Dynamic Inventory

Custom Inventory Script

Host Variables & Priorities

Accessibility

Keywords

Host-Level Variables

Group Variables File

Ad-Hoc Commands

Basic Syntax

Accessibility

Keywords

Run Adhoc Command

Use copy Module

Common Ad-Hoc Modules

Accessibility

Keywords

Package Management

Service Management

File Permissions

Parallelism & Forks

Accessibility

Keywords

Limit Concurrent Execution

Serial Execution

Playbooks

Playbook Structure

Accessibility

Keywords

Basic Playbook Structure

Multiple Plays in Single Playbook

Playbook Execution

Accessibility

Keywords

Run Basic Playbook

Check Mode (Dry Run)

Run with Extra Variables

Verbose Output

Conditionals

Accessibility

Keywords

Simple When Condition

Multiple Conditions

Tasks & Handlers

Task Structure

Accessibility