Mastering Ansible

This blog post covers the practical aspects of using Ansible, including installation, setting up passwordless authentication, executing ad-hoc commands, and writing playbooks. It emphasizes the importance of understanding Ansible modules, roles, and best practices for efficient automation in DevOps environments.

In this blog post, we will delve into the practical aspects of using Ansible, a powerful automation tool widely used in DevOps. This discussion is based on Day 15 of a comprehensive DevOps course, where we transitioned from theoretical concepts to hands-on practice with Ansible.

ansible-example

Recap of Previous Lessons

On Day 14, we explored the theory of configuration management, focusing on why Ansible has emerged as a key player in this domain. We compared Ansible with other tools like Puppet and discussed various theoretical aspects of configuration management.

Getting Started with Ansible

Setting Up Your Environment

To begin using Ansible, you need to set up your environment. It is recommended to use a Linux machine for this purpose. If you are new to Ansible, consider launching an EC2 instance on AWS with Ubuntu. However, if you are unable to do so, you can also use a Mac or Windows machine.

Installing Ansible

The first step is to install Ansible. You can do this using the package manager specific to your Linux distribution. For Ubuntu, the commands are as follows:

Update your package list:
```
 sudo apt update
```
Install Ansible:
```
 sudo apt install ansible
```

After installation, verify it by running:

ansible --version

Setting Up Passwordless Authentication

To effectively use Ansible, you need to set up passwordless SSH authentication between your Ansible server and the target server. Here’s how to do it:

Generate SSH keys on your Ansible server:
```
 ssh-keygen
```
Copy the public key to the target server:
```
 ssh-copy-id user@target-server-ip
```
Test the connection:
```
 ssh user@target-server-ip
```

Passwordless Authentication from ansible-server to target-server

ansible-server →

ssh-keygen → generate (authorized_keys, id_ras, id_rsa.pub)
id_rsa.pub → consist of secret key → copy it

target-server →

ssh-keygen → generate (authorized_keys, id_ras, id_rsa.pub)
authorized_keys → paste copied secret key from id_rsa.pub of ansible-server → authorized_keys of target-server

now, ansible-server can login to target-server without password

ansible-server

target-server

ansible-server can login to target-server without password

If successful, you should be able to log in without a password.

Executing Ansible Commands

Ad-Hoc Commands → excute 1 or 2 simple task

Once Ansible is installed and configured, you can start executing commands. Ansible allows you to run ad-hoc commands, which are useful for performing quick tasks without writing a full playbook. For example, to create a file on the target server, you can use:

ansible -i inventory all -m shell -a "touch /path/to/file"

for 1 server → (target-server)

ansible-server

target-server

for 2 or more server → (db-server,web-server)

only run on all specified list of webservers , not the dbservers

Writing Your First Playbook→ ansible file

Ansible playbooks are YAML files that define a series of tasks to be executed on your target servers. Here’s a simple example of a playbook to install and start Nginx:

---
- name: Install and start Nginx
  hosts: all
  become: yes
  tasks:
    - name: Install Nginx
      apt:
        name: nginx
        state: present
    - name: Start Nginx
      service:
        name: nginx
        state: started

To run the playbook, use the following command:

ansible-playbook -i inventory playbook.yaml

ansible-server

target-server

Understanding Ansible Modules

Ansible uses modules to perform tasks. Each module has specific parameters and options. To learn about available modules, you can refer to the official Ansible documentation. For example, the apt module is used for package management on Debian-based systems, while the service module manages services.

Grouping Servers in Inventory Files

When managing multiple servers, you can group them in your inventory file. This allows you to execute commands or playbooks on specific groups of servers. For example:

[webservers]
192.168.1.1
192.168.1.2

[dbservers]
192.168.1.3

You can then run commands on all web servers by specifying the group name:

ansible -i inventory webservers -m shell -a "uptime"

Advanced Concepts: Ansible Roles

As your playbooks grow in complexity, it’s beneficial to use Ansible roles. Roles allow you to organize your playbooks into reusable components. You can create a role using:

ansible-galaxy init role_name

This command creates a directory structure for your role, including folders for tasks, handlers, templates, and more. This organization helps manage complex playbooks more effectively.

You're asking for more specific examples of how Ansible Galaxy and its folder structure relate to elements like templates and tasks within roles. Let's break that down:

Within a Role's Directory:

When you install a role (e.g., ansible-galaxy install some_role), it gets placed in the roles directory (usually /etc/ansible/roles). Inside that role's directory (e.g., /etc/ansible/roles/some_role), you'll find these key subdirectories:

tasks/:
- This directory contains the main task lists for the role.
- The primary file is usually tasks/main.yml, which lists the tasks to be executed when the role is used in a playbook.
- You can include other YAML files here and include them in main.yml for better organization (e.g., tasks/install.yml, tasks/configure.yml).
- Example: A task to install a package:

YAML

    - name: Install Apache
      apt:
        name: apache2
        state: present

templates/:
- This directory holds Jinja2 template files. These are used to generate configuration files or other text-based files on the target systems.
- Example: A template for an Apache virtual host configuration:

    <VirtualHost *:80>
        ServerName {{ domain_name }}
        DocumentRoot /var/www/{{ domain_name }}
    </VirtualHost>

files/:
- This directory contains static files that you want to copy to the target systems. These are not templates and are copied as-is.
- Example: A pre-configured logrotate configuration file.
handlers/:
- This directory contains handlers, which are tasks that are triggered by notifications from other tasks. They are typically used for service restarts or other actions that should only occur when necessary.
- Example: A handler to restart Apache:

YAML

    - name: Restart Apache
      service:
        name: apache2
        state: restarted

defaults/:
- This directory contains default variables for the role. These can be overridden by variables defined in playbooks or inventory.
- Example:

YAML

    domain_name: example.com

vars/:
- This directory contains other variables for the role. These have higher precedence than defaults.
- Example:

YAML

    http_port: 8080

How it Works Together:

A playbook includes a role.
Ansible looks for the role in the roles_path (which includes /etc/ansible/roles).
Within the role's directory:
- Tasks in tasks/main.yml (and included files) are executed.
- If a task uses the template module, Ansible looks for the template file in the templates/ directory. It renders the template using Jinja2 and variables, then copies the resulting file to the target system.
- If a task uses the copy module, Ansible looks for the file in the files/ directory and copies it to the target system.
- If a task notifies a handler, the handler defined in handlers/main.yml is executed (but only once, even if notified multiple times).

Example in a Playbook:

YAML

- hosts: webservers
  roles:
    - role: some_role
      vars:
        domain_name: mywebsite.net # Overrides the default domain_name

This playbook would use the some_role role, overriding the domain_name variable with mywebsite.net. Any templates within the role that use {{ domain_name }} would be rendered with this new value.

This detailed explanation should give you a clearer picture of how Ansible Galaxy's folder structure connects to the use of templates, tasks, and other components within roles.

Conclusion

In this session, we covered the practical aspects of using Ansible, including installation, setting up passwordless authentication, executing ad-hoc commands, and writing playbooks. Understanding Ansible modules and roles is crucial for efficient automation in DevOps environments. As you continue your journey with Ansible, practice these concepts to solidify your understanding and enhance your skills.

Feel free to reach out with any questions or for further clarification on any topics discussed. Happy automating!

Day-15-devops