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

Ansible

Name Ansible

It’s a science-fiction reference

An ansible is a fictional communication device that can transfer information faster than the speed of light. 

Ursula K. Le Guin invented the concept in her book Rocannon’s World, and other sci-fi authors have since borrowed the idea from Le Guin.

Michael DeHaan took the name Ansible from the book Ender’s Game by Orson Scott Card. In that book, the ansible was used to control many remote ships at once, over vast distances. Think of it as a metaphor for controlling remote servers.

Michael DeHaan :- Creator of Ansible software

Ansible started as a simple side project in February of 2012

Configuration Management

we are typically about writing some kind of state description for our servers, and then using a tool to enforce that the servers are, indeed, in that state: the right packages are installed, configuration files contain the expected values and have the expected permissions, the right services are running, and so on.

Deployment

They are usually referring to the process of taking software that was written in-house, generating binaries or static assets (if necessary), copying the required files to the server(s), and then starting up the services.

Ansible is a great tool for deployment as well as configuration management. 

Linux Booting Issues

 Boot Issues

grub> set root=(hd0,msdos1)

grub> linux /boot/vmlinuz-(version) root=/dev/sda1   optional ro or rw

grub> initrd /boot/initrd(version).img

grub> boot

$ ls -l /

vmlinuz -> boot/vmlinuz-3.13.0-29-generic

initrd.img -> boot/initrd.img-3.13.0-29-generic

So you could boot from grub> like this:

grub> set root=(hd0,1)

grub> linux /vmlinuz root=/dev/sda1

grub> initrd /initrd.img

grub> boot