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 

pip upgrade

python3 -m pip install --upgrade pip

pip3 -V

➜ ~ python3 -m pip install --upgrade pip

➜ ~ pip3 install ansible

dnf and rpm troubleshooting

 

dnf
dnf update -v
--debuglevel=<no>
-v = default debug level
0 = No additional information
1-9 = Increasing levels of debugging
10 = Highest level
dnf update --debuglevel=10

rpm --repmverbosity=<level> (info or debug)

Kubernetes images

 Kubernetes image pull

kubeadm config images pull --v=<no> (--v verbosity levels)

| Level   | Meaning                    |
| --------- | --------------------------------------------- |
| `--v=0`  | Default minimal logs             |
| `--v=1-2` | Basic info messages              |
| `--v=3-4` | More detailed operational logs        |
| `--v=5`  | Debug level (recommended for troubleshooting) |
| `--v=6`  | Detailed debugging              |
| `--v=7`  | Very detailed API calls            |
| `--v=8`  | HTTP request bodies              |
| `--v=9`  | Maximum verbosity (very noisy)        |

kubeadm init --v=5
kubeadm init --v=6 2>&1 | tee kubeadm-debug.log

Ansible_1

 Playbook

In Ansible, a script is called a playbook. 

A playbook describes which hosts to configure, and an ordered list of tasks to perform on those hosts. 

The playbook can be execute by using the ansible-playbook command

Ansible’s playbook syntax is built on top of YAML

$ ansible-playbook <name>.yml

Ansible will make SSH connections in parallel

It will execute the first task on the list on all hosts simultaneously.

eg:- 1st tasks 

- name: Install nginx

  apt: name=nginx

Ansible will do the following:

1. Generate a Python script that installs the required package

2. Copy the script to host1, host2, and host3

3. Execute the script on host1, host2, and host3

4. Wait for the script to complete execution on all hosts

Ansible will then move to the next task in the list, and go through these same four steps. It’s important to note the following:

• Ansible runs each task in parallel across all hosts.

• Ansible waits until all hosts have completed a task before moving to the next task.

• Ansible runs the tasks in the order that you specify them.

Simple Terms

Ansible playbooks as executable documentation. It’s like the README file that describes the commands you had to type out to deploy your software, except that the instructions will never go out-of-date because they are also the

code that gets executed directly.

Remote Hosts

To manage a server with Ansible, the server needs to have SSH and Python 2.5 or later installed, or Python 2.4 with the Python simplejson library installed. 

There’s no need to preinstall an agent or any other software on the host.

Control machine 

The control machine (the one that you use to control remote machines) needs to have Python 2.6 or later installed