Ansible_7

 Variables

Variables can be used in tasks, as well as in template files. we can call variables by "{{ var_name }}"

Quoting in Ansible Strings
A variable right after specifying the module, the YAML parser will misinterpret the variable reference as the beginning of an inline dictionary.


- name: Perform some task
command: {{ myapp }} -a foo

Ansible will try to parse the first part of {{ myapp }} -a foo as a dictionary instead of a string, and will return an error. In this case, you must quote the arguments:
- name: Perform some task
command: "{{ myapp }} -a foo"

A similar problem arises if your argument contains a colon. For example:
- name: Show a debug message
debug:
msg: The debug module will print a message: neat, eh?

The colon in the msg argument trips up the YAML parser.

To get around this, you need to quote the entire msg string. Single and double quotes are both correct; Bas prefers to use double quotes when the string has variables:
- name: Show a debug message
debug:
msg: "The debug module will print a message: neat, eh?"

This will make the YAML parser happy. Ansible supports alternating single and double quotes,
'single quotes' → literal strings
"double quotes" → interpreted strings (supports escaping + special chars)

Double Quotes
- name: Print variable
debug:
msg: "Hello {{ user }}"
👉 {{ user }} will be evaluated

msg: "Line1\nLine2"
👉 Produces:
Line1
Line2


Single Quotes
- name: Print variable
debug:
msg: 'Hello {{ user }}'
👉 Jinja2 still processes it, BUT:
Escaping behaves differently
Harder to nest quotes

msg: 'Line1\nLine2'
👉 Produces:
Line1\nLine2

Loop
A loop executes the task multiple times, each time replacing item with different values from the specified list:
- name: Install multiple packages
hosts: all
tasks:
- name: Install packages
yum:
name: "{{ item }}"
state: present
loop:
- nginx
- git
- curl

Loop with List Variable
vars:
packages:
- nginx
- git
- curl

tasks:
- name: Install packages
yum:
name: "{{ item }}"
state: present
loop: "{{ packages }}"

Loop with Dictionary (Key-Value)
vars:
users:
user1: dev
user2: admin

tasks:
- name: Create users
user:
name: "{{ item.key }}"
comment: "{{ item.value }}"
loop: "{{ users | dict2items }}"
👉 dict2items converts dictionary → list

Ansible_6

 Anatomy of a Playbook

---

- name: expample playbook

hosts: all

become: true

tasks:

- name: Ensure nginx pkg is installed

package:

name: nginx

update_cache: true

ansible -i <inv_name> -b -m package -a 'name=nginx update_cache=true'

Playbooks

playbook is a list of dictionaries. A playbook is a list of plays only

we have only single play named "example playbook", every play must contain the hosts variable, the magic group all (all hosts in the inventory)

name:

Decribe about the play, Ansible prints the name when the play runs.

become:

is a boolean, used to specify the privillaged account (root)

tasks:

tasks of that play

we have used the module package and the used argunets name: nginx and update_cache: true, name for the tasks are optional

Ansible will print out the name of a task when it runs.

Modules

Modules are standalone scripts written for a particular job

module is a small program that performs actions on a local machine, application programming interface (API), or remote host. Modules are expressed as code, usually in Python, and contain metadata that defines when and where a specific automation task is executed and which users can execute it.

Documentation

$ ansible-doc <module_name> # shows documentation about the modules you have installed.

Any Ansible task that runs has the potential to change the state of the host in some way. Ansible modules will first check to see whether the state of the host needs to be changed before taking any action. If the host’s state matches the module’s arguments, Ansible takes no action on the host and responds with a state of “ok.”

On the other hand, if there is a difference between the host’s state and the module’s arguments, Ansible will change the state of the host and return “changed.”

Ansible_5

 Indentation and Whitespace

Like Python, YAML uses space indentation to reduce the number of interpunction characters. We use two spaces as a standard. For readability, we prefer to add whitespace between each task in a playbook, and between sections in files.

Strings

In general, you don’t need to quote YAML strings. Even if there are spaces, you don’t need to quote them. For example, this is a string in YAML:

this is a lovely sentence

The JSON equivalent is as follows:

"this is a lovely sentence"

Use single quotes for literal values that should not be evaluated, like version numbers and floating point numbers, or strings with reserved characters like colons, brackets, or braces.

Booleans

YAML has a native Boolean type and provides you with a variety of values that evaluate to true or false.

These are all Boolean true values in YAML:

true, True, TRUE, yes, Yes, YES, on, On, ON

JSON only uses: true

These are all Boolean false values in YAML:

false, False, FALSE, no, No, NO, off, Off, OFF

JSON only uses:false

Lists

YAML lists are like arrays in JSON and Ruby, or lists in Python.The YAML specification calls these sequences, but we call them lists here to be consistent with the official Ansible documentation.

Indent list items and delimit them with hyphens.

shows:

- My Fair Lady

- Oklahoma

- The Pirates of Penzance

YAML also supports an inline format for lists, with comma-separated values in square brackets:

shows: [ My Fair Lady , Oklahoma , The Pirates of Penzance ]

Dictionaries

YAML dictionaries are like objects in JSON, dictionaries in Python, hashes in Ruby, or associative arrays in PHP The YAML specification calls them mappings, but we call them dictionaries here to be consistent with the Ansible documentation.

address:

street: Main Street

appt: 742

city: Logan

state: Ohio

YAML also supports an inline format for dictionaries, with comma separated tuples in braces:

address: { street: Main Street, appt: '742', city: Logan, state:Ohio}

Multiline Strings

You can format multiline strings with YAML by combining a block style indicator (| or >)

If you want one string across multiple lines:

Using |

message: |

This is line one

This is line two

This is line three

Using >

message: >

This is line one

This is line two

This is line three

output will be

This is line one This is line two This is line three

Ansible_4

 $ ansible testserver -i inventory -m ping

The "ping": "pong" output text is specific to the ping module.

The ping module doesn’t do anything other than check that Ansible can start an SSH session with the servers.

ansible.cfg

ansible.cfg file, to set some defaults

Ansible looks for an ansible.cfg file in the following places, in this order:

* File specified by the ANSIBLE_CONFIG environment variable

* ./ansible.cfg (ansible.cfg in the current directory)

* ~/.ansible.cfg (.ansible.cfg in your home directory)

* /etc/ansible/ansible.cfg (Linux) or /usr/local/etc/ansible/ansible.cfg (*BSD)

We typically put ansible.cfg in the current directory, alongside our playbooks.

ansible.cfg

[defaults]

inventory = inventory/file_name.ini

host_key_checking = False

stdout_callback = yaml

callback_enabled = timer

$ ansible testserver -m ping

$ ansible testserver -m command -a uptime

When invoking this module, you also need to pass an argument to the module with the -a flag, which is the command to run.

The command module is the default module, so you can omit it:

$ ansible testserver -a uptime

$ ansible testserver -a "tail /var/log/dmesg"

If you need privileged access, pass in the -b or --become flag to tell Ansible to become the root user.

$ ansible testserver -b -a "tail /var/log/syslog"

$ ansible testserver -b -m package -a name=nginx

$ ansible-inventory --graph

Playbooks Are YAML

A valid JSON file is also a valid YAML file.

---

In Ansible playbooks it is customary to start with the three “-” (so that editors can pick up on this).

However, if you forget to put those three dashes at the top of your playbook files, Ansible won’t complain.

...

YAML files may end with three dots

If you forget to put those three dots at the end of your playbook files, Ansible won’t complain.

Comments start with a hashmark (#) and apply to the end of the line,

# This is a YAML comment

Ansible_3

 Idempotency

Modules are also idempotent. Idempotence is a nice property because it means that it is safe to run an Ansible playbook multiple times against a server.

- name: Ensure deploy user exists

user:

name: testuser

group: tester

If the "testuser" user does not exist, Ansible will create it. If it does exist,Ansible will not do anything.

In October 2015, Red Hat bought Ansible, Inc.

IBM bought Red Hat in 2019.

ansible-pull

ansible-pull -U https://github.com/<compnay>/repo.git -C main site.yml

-U → Git repository URL

-C → Branch name

-i → Inventory

-d → Destination directory

*/30 * * * * /usr/bin/ansible-pull -U https://github.com/company/repo.git site.yml

Installing Ansible

$ brew install ansible

on the target systems, assuming that the Linux/macOS/BSD systems have Python installed and that Windows machines have PowerShell.

Install Ansible using one of the Python package managers

$ pip3 install --user ansible==2.9.27

To worrk with Ansible Tower or AWX, then you should install the same version of ansible-core on your workstation.

python virtualenv

If you work on multiple projects, you should install Ansible into a Python virtualenv.

This lets you avoid interfering with your system Python or cluttering your user environment. Using Python’s venv module and pip3, you can install just what you need to work on for each project:

$ python3 -m venv .venv --prompt A

$ source .venv/bin/activate

(A)

During activation of the environment, your shell prompt will change to (A) as a reminder. Enter deactivate to leave the virtual environment.

Manage Windows systems remotely, with PowerShell over WinRM under the hood.

ansible-builder

ansible-builder is a tool that aids in creating execution environments by controlling the execution of Ansible from within a container for single purpose automation workflows. It is based on the directory layout of ansible-runner.

Inventory

Ansible can manage only the servers it explicitly knows about. you provide Ansible with information about servers by specifying them in an inventory.

$ vi inventory

[webservers]

testserver ansible_port=2222

[webservers:vars]

ansible_host=<ip>

ansible_user=<user_name>

Ansible_2

 

Push Based

Ansible is push based by default

Making a change looks like this:

1. You: make a change to a playbook.

2. You: run the new playbook.

3. Ansible: connects to servers and executes modules that change the state of the servers.

The push-based approach has a significant advantage: you control when the changes happen to the servers.

Ansible Runner

"Ansible Runner “is a lightweight tool and python library that helps when interfacing with Ansible directly or as part of another system whether that be through a container image interface, as a standalone tool, or as a Python module that can be imported.”

Ansible Runner is a lightweight tool and Python library used to run Ansible playbooks and modules programmatically—especially useful in automation platforms like Ansible Automation Platform.

Using the ansible-runner library, you can run an Ansible playbook from within a Python script:

#!/usr/bin/env python3

import ansible_runner

r = ansible_runner.run(private_data_dir='./playbooks',

playbook='playbook.yml')

print("{}: {}".format(r.status, r.rc))

print("Final status:")

print(r.stats)

Organizations with hundreds of software teams typically use AWX or a combination of Ansible Tower and Automation Hub for auditability, and for security with role-based access controls.

Ansible uses SSH multiplexing to optimize performance

vi tricks

vi
# Delete all lines starting with "pattern"
:g/^pattern/d

# Save and quit
:wq

open vi with insert mode
alias vi='vim +start'

# Open at line 10

vi +10