Ansible : Configuration Management TOOL

Ansible is an open source configuration management DevOps tool used to automate tasks like configuring servers, deploying applications, and managing IT infrastructure.
Think of it as a tool that helps you tell multiple computers or servers what to do by writing simple instructions in plain text files.
Ansible uses YAML (Yet Another Markup Language) for its configuration files, which are called playbooks. YAML is a human-readable, easy-to-understand language designed for writing structured data.
Ansible is agentless, it means that you don’t need to install any special software (called "agents") on the machines or servers you want to manage. Instead, Ansible connects to the target machines using existing protocols like:
- SSH (Secure Shell) for Linux/Unix systems
- WinRM (Windows Remote Management) for Windows systems

All the instructions and tasks are executed directly on the target machine without requiring any pre-installed "agent" software.

This makes Ansible simpler to set up and maintain compared to other tools that require agents running on the managed systems (like Puppet or Chef).

In short:

No agents = Less hassle, fewer dependencies, and easier management.

An inventory file in Ansible is a file that lists all the servers (or hosts) you want to manage. It acts as a database of your infrastructure, where you define the names or IPs of the machines you’ll work with.

You can organize servers into groups to make management easier. For example:
- Group servers by their roles. For example: webservers, dbservers

This allows you to target specific groups of machines in your playbooks or commands. File Format can be in INI format (default) or YAML format. Ansible inventory files supports INI file format (by default):

Here’s an example:

    [webservers]
    web1.example.com
    web2.example.com

    [dbservers]
    db1.example.com
    db2.example.com

By default, Ansible looks for the inventory file in the following locations:

/etc/ansible/hosts: This is the default location if you don’t specify a custom inventory file.
Custom Inventory Location: You can specify a different inventory file location using the -i flag when running Ansible commands. For example:
```
 ansible-playbook -i /path/to/inventory.ini playbook.yml
```

In addition to static inventory files, Ansible also supports dynamic inventory, where the list of hosts is generated dynamically from an external source, such as a cloud provider (AWS, GCP, etc.) or a database. A dynamic inventory script can be written to pull this data and automatically generate the list of hosts and groups.

Passwordless authentication in Ansible is achieved using SSH key pairs (public and private keys). You generate the key pair on the control machine, then copy the public key to the managed servers. Ansible uses the private key for authentication when connecting to remote servers. This setup eliminates the need to enter passwords, enabling automation and improving security.
An Ansible ad-hoc command is a single command that you can use to run a specific task on one or more remote servers without needing to create a playbook. It is ideal for performing quick, one-time operations, such as checking the status of a service, copying a file, or running commands across multiple servers.

Syntax

The basic syntax for an ad-hoc command is:
```
 ansible <group_name> -m <module_name> -a "<arguments>"
```
- <group_name>: The target hosts or groups defined in the inventory.
- -m <module_name>: The Ansible module to run (e.g., ping, shell, copy, service, etc.).
- -a "<arguments>": The arguments passed to the module.

Examples of Ad-Hoc Commands:

Ping all hosts to check connectivity:
```
 ansible all -m ping
```
This sends a "ping" to all hosts in the inventory to check if they are reachable.
Check disk space on a remote host:
```
 ansible all -m shell -a "df -h"
```
This runs the df -h command on all remote servers to show disk space usage.

Copy a file to a remote server:

 ansible all -m copy -a "src=/path/to/local/file dest=/path/to/remote/file"

This copies a local file to all remote servers.

Install a package on all hosts:
```
 ansible all -m apt -a "name=nginx state=present"
```
This uses the apt module to install the nginx package on all remote servers that use the apt package manager.
Start a service on a remote server:
```
 ansible all -m service -a "name=nginx state=started"
```
This starts the nginx service on all remote servers.

An Ansible playbook is a YAML file that defines a series of tasks to be executed on remote servers. Playbooks are used for more complex and repeatable automation tasks, where you need to define multiple steps, conditions, and variables.

A typical playbook contains the following components:
- Hosts: The target machines or groups of machines.
- Tasks: A list of tasks (commands or modules) to run on the target hosts.
- Variables: You can define variables to customize tasks based on conditions.
- Handlers: Special tasks that are triggered when notified by other tasks.

Basic Playbook Example:

    ---
    - name: Install and start nginx on web servers
      hosts: web_servers
      become: yes  # To run tasks with sudo privileges
      tasks:
        - name: Install nginx package
          apt:
            name: nginx
            state: present

        - name: Start nginx service
          service:
            name: nginx
            state: started

become: yes: Elevates the user privileges (equivalent to sudo in Linux).

Ansible Roles are a way to organize and modularize Ansible playbooks into reusable components.

Benefits of Roles:
- Reusability: Roles can be reused across different playbooks.
- Modularity: Each role handles a specific task (e.g., installing a web server, setting up a database).
- Organization: Helps in keeping playbooks clean and structured, especially in larger environments.

Key Components of a Role:

Tasks: A directory (tasks/) containing task files that define the actions to be executed.
Variables: A directory (vars/) for role-specific variables.
Defaults: A directory (defaults/) for default values of variables.
Handlers: A directory (handlers/) for tasks that are triggered by other tasks (e.g., restarting a service).
Files: A directory (files/) for static files to be copied to the remote servers.
Templates: A directory (templates/) for Jinja2 templates that can be rendered with variables.
Meta: A directory (meta/) for role dependencies and metadata.

Structure of a Role:

    roles/
      ├── my_role/
          ├── tasks/
          ├── vars/
          ├── defaults/
          ├── handlers/
          ├── files/
          ├── templates/
          └── meta/

Usage:

To use a role in a playbook, you simply reference it:

    - name: Apply my_role
      hosts: all
      roles:
        - my_role

Ansible : Configuration Management TOOL

Here's everything you need to know about Ansible

Syntax

Examples of Ad-Hoc Commands:

Basic Playbook Example:

Benefits of Roles:

Key Components of a Role:

Structure of a Role:

Usage: