quartz/content/Devops&DevSecOps/Ansible.md

[Ansible PDF Link](https://github.com/ErdemOzgen/brain/blob/v4/docs/pdfs/ansible1.pdf)

![[Pasted image 20231213081951.png]]

Control node

A system on which Ansible is installed. You run Ansible commands such as `ansible` or `ansible-inventory` on a control node.

Inventory

A list of managed nodes that are logically organized. You create an inventory on the control node to describe host deployments to Ansible.

Managed node

A remote system, or host, that Ansible controls.


```ini
[myhosts]
192.0.2.50
192.0.2.51
192.0.2.52
```


ansible myhosts -m ping -i inventory.ini

```yaml
myhosts:
  hosts:
    my_host_01:
      ansible_host: 192.0.2.50
    my_host_02:
      ansible_host: 192.0.2.51
    my_host_03:
      ansible_host: 192.0.2.52
```

```yaml
leafs:
  hosts:
    leaf01:
      ansible_host: 192.0.2.100
    leaf02:
      ansible_host: 192.0.2.110

spines:
  hosts:
    spine01:
      ansible_host: 192.0.2.120
    spine02:
      ansible_host: 192.0.2.130

network:
  children:
    leafs:
    spines:

webservers:
  hosts:
    webserver01:
      ansible_host: 192.0.2.140
    webserver02:
      ansible_host: 192.0.2.150

datacenter:
  children:
    network:
    webservers:
```

# Creating a playbook[](https://docs.ansible.com/ansible/latest/getting_started/get_started_playbook.html#creating-a-playbook "Permalink to this heading")

Playbook

A list of plays that define the order in which Ansible performs operations, from top to bottom, to achieve an overall goal.

Play

An ordered list of tasks that maps to managed nodes in an inventory.

Task

A list of one or more modules that defines the operations that Ansible performs.

Module

A unit of code or binary that Ansible runs on managed nodes. Ansible modules are grouped in collections with a [Fully Qualified Collection Name (FQCN)](https://docs.ansible.com/ansible/latest/reference_appendices/glossary.html#term-Fully-Qualified-Collection-Name-FQCN) for each module.

1. Create a file named `playbook.yaml` in your `ansible_quickstart` directory, that you created earlier, with the following content:
    
```yaml
    - name: My first play
      hosts: myhosts
      tasks:
       - name: Ping my hosts
         ansible.builtin.ping:
    
       - name: Print message
         ansible.builtin.debug:
          msg: Hello world
    
```
2. Run your playbook.
    
    ansible-playbook -i inventory.ini playbook.yaml

#ansible
#inventory

Inventory in Ansible is a crucial concept, essential for defining and managing the servers, machines, or devices on which Ansible will run tasks. Here's a breakdown of what inventory means in the context of Ansible:

### Definition
- **Inventory**: An inventory is a collection of hosts (servers, devices, etc.) against which Ansible can execute tasks. It's essentially a list of nodes or machines that Ansible can manage.

### Format
- **Hosts and Groups**: The inventory can list individual hosts or group them. Groups can have child groups, allowing for complex groupings and hierarchies.
- **File Formats**: The inventory file can be in various formats, including INI-like simple text files or YAML files. Ansible also supports dynamic inventories, where the inventory is generated by an external system or script.

### Basic Example
- **INI Format**:
  ```
  [webserver]
  server1.example.com
  server2.example.com

  [database]
  dbserver.example.com
  ```
- **YAML Format**:
  ```yaml
  all:
    children:
      webserver:
        hosts:
          server1.example.com:
          server2.example.com:
      database:
        hosts:
          dbserver.example.com:
  ```

### Key Features
- **Variables**: Inventory can also define variables for hosts or groups. These variables can be used to customize Ansible's behavior for different hosts.
- **Connection Details**: It can include details like the IP address, domain, or other connection information (SSH port, user, etc.).
- **Dynamic Inventory**: For environments that change frequently (like cloud environments), Ansible can use dynamic inventories that are not static files but scripts or programs returning the inventory.

### Usage
- **Specifying Inventory**: When running Ansible commands or playbooks, you specify which inventory to use. This can be a path to a file or a script for dynamic inventory.
- **ansible.cfg**: The default inventory file location can be set in Ansible's configuration file, `ansible.cfg`.

### Importance
- **Orchestration**: Inventory is crucial for orchestrating tasks across multiple servers or environments. It tells Ansible "what" it will be managing or automating.
- **Scalability**: Inventories make managing large numbers of servers feasible, as they can be organized into manageable groups.

### Best Practices
- **Keep It Simple**: Start with a simple inventory and expand as needed.
- **Version Control**: Keep your inventory files under version control.
- **Security**: Be mindful of sensitive data in inventory files. Use Ansible Vault for encryption if needed.

In summary, the inventory in Ansible is a foundational element for defining which systems your Ansible playbooks and roles will interact with. It's flexible enough to handle a small number of servers or scale up to a large, dynamic infrastructure.

Ansible roles are a powerful feature for organizing and reusing code in Ansible. They help in managing complex playbooks by breaking them down into smaller, reusable components. Here’s an overview of what roles are and how they work in Ansible:

### Definition and Purpose
- **Roles**: A role is a set of related tasks, variables, files, and handlers that are organized in a predefined directory structure. Roles allow you to group content, making it easier to reuse and redistribute.
- **Modularity and Reusability**: Roles promote modularity and reusability. By using roles, you can easily share and use code for common tasks across different playbooks.

### Directory Structure
A typical role directory structure looks like this:
```
role_name/
    ├── defaults/         # Default variables for the role
    │   └── main.yml
    ├── files/            # Files to be transferred to the target system
    ├── handlers/         # Handlers, which can be used by this role or even anywhere outside this role
    │   └── main.yml
    ├── meta/             # Metadata for the role, including dependencies
    │   └── main.yml
    ├── tasks/            # Main list of tasks that the role executes
    │   └── main.yml
    ├── templates/        # Templates files, usually using Jinja2 syntax
    ├── tests/            # Test code for the role
    └── vars/             # Other variables for the role
        └── main.yml
```

### Key Components
- **Tasks**: The `tasks` directory contains the main list of tasks that the role will execute.
- **Handlers**: In the `handlers` directory, you define handlers, which are tasks that only run when notified.
- **Defaults**: The `defaults` directory stores default variables for the role.
- **Vars**: The `vars` directory contains other variables for the role, usually with higher priority than defaults.
- **Files and Templates**: `files` and `templates` directories contain files and templates that can be deployed to target systems.
- **Meta**: The `meta` directory contains metadata, like role dependencies.

### Creating a Role
- Use the `ansible-galaxy` command to create a new role with the basic directory structure:
  ```
  ansible-galaxy init role_name
  ```

### Using Roles in Playbooks
- Roles are called within playbooks. Here’s a basic example of how a role is referenced in a playbook:
  ```yaml
  - hosts: webservers
    roles:
      - role: nginx
      - role: php
        php_versions: ['7.4', '8.0']
  ```

### Variables and Overriding
- Variables in roles can be overridden by passing them in playbooks or setting them in different variable files.

### Role Dependencies
- Roles can depend on other roles, and these dependencies are defined in the `meta/main.yml` file of the role. Ansible will automatically include and execute dependent roles.

### Best Practices
- **Modular Design**: Design roles to be as modular and reusable as possible.
- **Documentation**: Document each role, including its purpose, variables, and dependencies.
- **Version Control**: Keep roles in version control systems for better management.
- **Testing**: Regularly test roles independently to ensure they function as expected in different environments.

### Sharing and Reuse
- **Ansible Galaxy**: You can share and reuse roles via Ansible Galaxy, a hub for finding, reusing, and sharing Ansible content.

Roles are essential for scaling and managing larger, more complex Ansible configurations, allowing for cleaner code, easier maintenance, and better organization.