Ansible Configuration Management with Playbooks : twtech Use Case.

Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard

Use Cases for Ansible Playbooks...twtech Environment

Ansible playbooks are widely used for automating IT operations. Here are some common use cases for Ansible playbooks:

1. Configuration Management

• Ensures systems are consistently configured across multiple servers.
• Example: Setting up users, configuring SSH, modifying system settings.

Example Playbook:

# yaml

- name: Configure SSH settings
  hosts: all
  tasks:
    - name: Disable root login
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PermitRootLogin'
        line: 'PermitRootLogin no'
      notify: Restart SSH

  handlers:
    - name: Restart SSH
      service:
        name: sshd
        state: restarted

2. Software Deployment

• Automates application deployment to ensure consistency.
• Example: Deploying a web server, database, or microservices.

Example Playbook:

# yaml

- name: Deploy twtech-webapp Server
  hosts: twtech-webapp-servers
  tasks:
    - name: Install twtech-webapp
      apt:
        name: devopspatemf2021/webapps:version-1.9
        state: present

3. Patch Management & OS Updates

• Automates system updates across multiple machines.
• Example: Applying security patches to all servers.

Example Playbook:

# yaml

- name: Update all packages
  hosts: all
  tasks:
    - name: Update package cache and upgrade system
      apt:
        update_cache: yes
        upgrade: dist

4. Security & Compliance Automation

• Enforces security policies like firewall rules, user access control, and SSH hardening.

Example Playbook:

# yaml

- name: Configure Firewall
  hosts: all
  tasks:
    - name: Allow only SSH and HTTP(S)
      ufw:
        rule: allow
        port: "{{ item }}"
        proto: tcp
      loop:
        - 22
        - 80
        - 443

5. Cloud Infrastructure Provisioning

• Automates provisioning of cloud resources in AWS, Azure, GCP.
• Example: Creating an EC2 instance on AWS.

Example Playbook:

# yaml

- name: Launch an EC2 instance
  hosts: localhost
  tasks:
    - name: Create EC2 instance
      amazon.aws.ec2_instance:
        name: twtech-instance
        instance_type: t2.medium
        image_id: <ami-xyxyxyxyxyxyxy>
        count: 1
        region: us-east-2

6. Container Orchestration

• Automates Docker and Kubernetes deployments.
• Example: Deploying a containerized application.

Example Playbook:

# yaml

- name: Start a Docker container
  hosts: docker_server
  tasks:
    - name: Run twtech-springapp in Docker-server 
      docker_container:
        name: twtech-springapp
        image: devopspatemf2021/twtech:twtech-spring-boot-mongo
        state: started
        ports:
          - "80:80"

7. Database Management

• Automates database installation and configuration.
• Example: Deploying and setting up MySQL.

Example Playbook:

# yaml

- name: Install and configure MySQL
  hosts: twtechdb_servers
  tasks:
    - name: Install twtech-MySQL
      apt:
        name: twtech-mysql-server
        state: present
    - name: Start twtech-MySQL service
      service:
        name: twtech-mysql
        state: started

8. Continuous Integration/Continuous Deployment (CI/CD)

• Integrates with Jenkins, GitLab, GitHub Actions to automate deployments.

Example Playbook:

# yaml

- name: Deploy application from Git
  hosts: twtech-app_servers
  tasks:
    - name: Clone Git repository
      git:
        repo: 'https://github.com/Devopspat35/maven_web_application.git'
        dest: /var/www/app
        version: main

9. Network Automation

• Automates network device configuration (Cisco, Juniper, Arista).
• Example: Configuring a Cisco router.

Example Playbook:

# yaml

- name: Configure Cisco router
  hosts: routers
  tasks:
    - name: Set hostname
      ios_config:
        lines:
          - hostname twtech-Router

10. Backup and Disaster Recovery

• Automates system and database backups.

Example Playbook:

# yaml

- name: Backup Database
  hosts: twtech-db_server
  tasks:
    - name: Dump twtech-MySQL database
      command: msqldump -u root -p twtech-db > /backup/twtech-db.sql

Ansible playbooks offer:  scalability, repeatability, and consistency, making ansible-playbooks, essential for modern automation.

Addendum:

Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboar

Above: Steps in writing and executing playbooks

Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard.

 Above: Steps on How to create ansible vault, encrypt content and pass the vault password when running a playbook

 Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard.

Above: Steps in writing and executing ansible playbooks... twtech use-case

 Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard

Above: How to authenticate secret variables in ansible playbooks.

Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard

Above: How to use encrypted ansible-vault and vaultpass to run adhoc commands

Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard

Above: How to reference sensitive data in a playbook with variables.

Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard

Above: How secrets variables like passwords, sshKeys, certificates are handled in Ansible.

 Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard.

Above: How to decrypt ansible vault secrets in Ansible.

Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard.

Above: How to gather information about the hosts (other nodes) using Ansible ad-hoc command.

Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard.

Above: How to ping host with encrypted secrets in Ansible.

Ansible Playbooks and Roles

Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboar

Starting with Ansible Playbooks and Roles for organizing Playbooks

Getting Started with Ansible Playbooks

An Ansible Playbook is a YAML-based script that defines tasks to automate system configurations, deployments, and management. Below is a step-by-step guide to help you get started.

1. Install Ansible

Ensure Ansible is installed on your control machine (For Linux -ubuntu: use the script below).

https://github.com/Devopspat35/ansible-roles/blob/master/bootstrap-ansible.sh

Verify the installation:

ansible --version

2. Set Up the Inventory File

The inventory file (/etc/ansible/hosts or a custom file) defines the managed hosts.

Create an inventory file (inventory.ini):

# ini

[webservers]
192.168.1.10 ansible_user=ubuntu ansible_ssh_private_key_file=~/.ssh/id_rsa
192.168.1.11 ansible_user=ubuntu ansible_ssh_private_key_file=~/.ssh/id_rsa

Test connectivity:

ansible all -m ping -i inventory.ini

Expected Output:

# json

192.168.1.10 | SUCCESS => { "changed": false, "ping": "pong" }
192.168.1.11 | SUCCESS => { "changed": false, "ping": "pong" }

3. Create Your First Playbook

A playbook is a YAML file that defines tasks to execute.

Example: Install and Start Nginx

Create a new file install_nginx.yml:

# yaml

- name: Install and Start Nginx
  hosts: webservers
  become: yes  # Run as sudo
  tasks:
    - name: Install Nginx
      apt:
        name: nginx
        state: present

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

4. Run the Playbook

Use the ansible-playbook command:

ansible-playbook -i inventory.ini install_nginx.yml

Expected Output:

# markdown

PLAY [Install and Start Nginx] ****************
TASK [Install Nginx] **************************
changed: [192.168.1.10]
changed: [192.168.1.11]

TASK [Start Nginx service] ********************
ok: [192.168.1.10]
ok: [192.168.1.11]

PLAY RECAP ************************************
192.168.1.10              : ok=2    changed=1  
192.168.1.11              : ok=2    changed=1  

5. Verify the Installation

Check if Nginx is running:

ansible webservers -i inventory.ini -m shell -a "systemctl status nginx"

Alternatively, access it in a browser:

# cpp

http://192.168.1.10

6. Add Handlers for Better Management

Handlers are triggered only when changes occur. Modify install_nginx.yml:

# yaml

- name: Install and Start Nginx
  hosts: webservers
  become: yes
  tasks:
    - name: Install Nginx
      apt:
        name: nginx
        state: present
      notify: Restart Nginx  # Calls handler

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

  handlers:
    - name: Restart Nginx
      service:
        name: nginx
        state: restarted

Re-run the playbook:

ansible-playbook -i inventory.ini install_nginx.yml

7. Use Variables for Flexibility

Define variables in vars.yml:

# yaml

nginx_package: nginx

Modify the playbook to use variables:

# yaml

- name: Install and Start Nginx
  hosts: webservers
  become: yes
  vars_files:
    - vars.yml
  tasks:
    - name: Install Nginx
      apt:
        name: "{{ nginx_package }}"
        state: present
      notify: Restart Nginx

    - name: Start Nginx service
      service:
        name: "{{ nginx_package }}"
        state: started

  handlers:
    - name: Restart Nginx
      service:
        name: "{{ nginx_package }}"
        state: restarted

Run it:

ansible-playbook -i inventory.ini install_nginx.yml

8. Debugging & Testing

• Check Syntax:

  ansible-playbook install_nginx.yml --syntax-check
  

• Run in Dry Mode:

  ansible-playbook -i inventory.ini install_nginx.yml --check
  

• Enable Verbose Mode:

  ansible-playbook -i inventory.ini install_nginx.yml -vvv
  

 Thoughts:

• Explore roles for organizing playbooks (ansible-galaxy init myrole).
• Use Jinja2 templates for configuration files.
• Integrate Ansible with Docker, Kubernetes, or AWS.
•  

Ansible Roles for Organizing Playbooks

Ansible roles help organize playbooks by breaking them into reusable components. A role is a structured directory that contains tasks, handlers, templates, variables, and other necessary configurations.

1. Why Use Roles?

• Modular & Reusable: Write once, use multiple times.
• Scalability: Manage complex infrastructure easily.
• Separation of Concerns: Keep playbooks clean and manageable.

2. Creating an Ansible Role

You can manually create a role structure or use ansible-galaxy to generate it.

Manual Structure

A role follows this directory structure:

# perl

my-playbook/
├── roles/
│   ├── nginx/
│   │   ├── tasks/        # Contains task files (main.yml)
│   │   ├── handlers/     # Handlers for service restart, etc.
│   │   ├── templates/    # Jinja2 templates for configuration files
│   │   ├── files/        # Static files (e.g., scripts, binaries)
│   │   ├── vars/         # Role-specific variables
│   │   ├── defaults/     # Default variables
│   │   ├── meta/         # Role metadata (dependencies, author)
│   │   ├── tests/        # Testing scripts
│   │   └── README.md     # Documentation
├── inventory.ini
├── site.yml             # Main playbook

Using ansible-galaxy to Generate a Role

Run the following command:

ansible-galaxy init roles/nginx

This creates the necessary directories and files automatically.

3. Writing Role Components

A. Tasks (roles/nginx/tasks/main.yml)

Defines the sequence of actions.

# yaml

- name: Install Nginx
  apt:
    name: nginx
    state: present
  notify: Restart Nginx

- name: Ensure Nginx is running
  service:
    name: nginx
    state: started
    enabled: yes

B. Handlers (roles/nginx/handlers/main.yml)

Executed when notified.

# yaml

- name: Restart Nginx
  service:
    name: nginx
    state: restarted

 C. Variables (roles/nginx/vars/main.yml)

Define custom variables.

# yaml

nginx_port: 80

D. Templates (roles/nginx/templates/nginx.conf.j2)

Jinja2 template for configuration files.

# jinja

server {
    listen {{ nginx_port }};
    server_name localhost;

    location / {
        root /var/www/html;
        index index.html;
    }
}

E. Default Variables (roles/nginx/defaults/main.yml)

Define default values.

# yaml

nginx_port: 80

F. Files (roles/nginx/files/index.html)

Static files (e.g., website content).

4. Using the Role in a Playbook

Create site.yml to apply the role.

# yaml

- name: Configure Web Server
  hosts: webservers
  become: yes
  roles:
    - nginx

Run the playbook:

ansible-playbook -i inventory.ini site.yml

5. Using Role Dependencies

Define dependencies in roles/nginx/meta/main.yml:

# yaml

dependencies:
  - role: common

6. Sharing Roles with Ansible Galaxy

Upload roles for reuse:

ansible-galaxy role install myrole

Insights:

Ansible roles provide a structured way to organize playbooks, making them reusable, scalable, and maintainable.

Ansible ad-hoc commands: How to use ad-hoc commands to checking Resource Availability in the Hosts

 Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard

How to check resource availability for hosts using ansible ad-hoc commands.

We can use Ansible ad-hoc commands to check resource availability (CPU, memory, disk, etc.) on managed hosts. Here are some common checks:

1. Check CPU Usage

ansible all -m shell -a "top -bn1 | grep 'Cpu(s)'" -i inventory.ini

or using /proc/stat:

ansible all -m command -a "cat /proc/stat | head -n 1" -i inventory.ini

2. Check Memory Usage

ansible all -m command -a "free -m" -i inventory.ini

This will display total, used, and available memory in MB.

3. Check Disk Usage

ansible all -m command -a "df -h" -i inventory.ini

This will list disk usage for all mounted filesystems.

To check a specific partition (e.g., /):

ansible all -m command -a "df -h /" -i inventory.ini

4. Check Available Inodes

ansible all -m command -a "df -i" -i inventory.ini

This checks the available inodes, useful for diagnosing filesystem issues.

5. Check Network Bandwidth Usage

ansible all -m shell -a "sar -n DEV 1 5" -i inventory.ini

(Requires sysstat package installed.)

6. Check Open File Descriptors

ansible all -m command -a "ulimit -n" -i inventory.ini

7. Check Uptime of Servers

ansible all -m command -a "uptime" -i inventory.ini

This helps monitor how long a server has been running.

8. Check Running Processes

ansible all -m shell -a "ps aux --sort=-%mem | head -n 10" -i inventory.ini

This lists the top 10 processes consuming the most memory.

9. Check Load Average

ansible all -m command -a "cat /proc/loadavg" -i inventory.ini

It displays the system’s load over the last 1, 5, and 15 minutes.

10. Check Open Ports

ansible all -m command -a "netstat -tulnp" -i inventory.ini

Lists active ports and services.

11. Check Swap Usage

ansible all -m command -a "swapon --summary" -i inventory.ini

This checks if swap is enabled and in use.

12. Check System Reboot Status

ansible all -m command -a "who -b" -i inventory.ini

Shows the last system boot time.

13. Check Logged-in Users

ansible all -m command -a "who" -i inventory.ini

Lists users currently logged in.

14. Check Available Package Updates

For Debian-based systems:

ansible all -m command -a "apt list --upgradable" -i inventory.ini

For RHEL-based systems:

ansible all -m command -a "yum check-update" -i inventory.ini

15. Check Firewall Status

For Ubuntu/Debian:

ansible all -m command -a "ufw status" -i inventory.ini

For RHEL/CentOS:

ansible all -m command -a "systemctl status firewalld" -i inventory.ini

 Running Commands as Root (with elevated privileges)

If a command requires root privileges, use -b (become) to execute it with sudo:

ansible all -m command -a "df -h" -b -i inventory.ini

 twtech-Thoughts:

These Ansible ad-hoc commands provide quick insights into system resource availability.

For continuous monitoring, you can integrate Ansible with Nagios, Prometheus, or Grafana

More Key features on Ansible

 More Ansible Key concepts.

Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard

Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard

Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard.

Above: More Difference between tasks and handlers in ansible playbooks.

Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard.

Above:  Custom Ansible Modules in Ansible.

Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard.

Structure of an Ansible Playbook

An Ansible Playbook is structured in YAML and consists of one or more plays, which define a set of tasks to be executed on specified hosts. Here’s the typical structure of an Ansible Playbook:

Basic Structure of an Ansible Playbook

# yaml

---
- name: Example Playbook
  hosts: webservers
  become: true  # Run tasks with elevated privileges (sudo)
  
  vars:
    package_name: nginx

  tasks:
    - name: Install a package
      apt:
        name: "{{ package_name }}"
        state: present
      when: ansible_os_family == "Debian"

    - name: Ensure the service is running
      service:
        name: "{{ package_name }}"
        state: started
        enabled: true

  handlers:
    - name: Restart nginx
      service:
        name: nginx
        state: restarted

 

Key Components of an Ansible Playbook

1. --- (YAML Header)

• Indicates that the file is in YAML format.

2. - name: (Play Definition)

• Defines a play, which includes target hosts, roles, and tasks.

3. hosts:

• Specifies the group of machines (from inventory) where the playbook will run.

4. become:

• Grants administrative privileges (sudo) when necessary.

5. vars: (Variables)

• Allows defining reusable variables.

6. tasks: (List of Tasks)

• Contains a list of actions to execute on the target machines.
• Each task has:
  • name: (Descriptive name)
  • Module (e.g., apt, service)
  • Arguments (e.g., name: nginx, state: present)

7. when: (Conditional Execution)

• Executes a task only if a condition is met.

8. handlers: (Event-Driven Actions)

• Triggered by tasks (e.g., restart a service after package installation).

Advanced Playbook Structure

A more structured playbook with multiple plays and roles:

# yaml

---
- name: Setup Web Servers
  hosts: webservers
  become: true
  roles:
    - webserver

- name: Setup Database Servers
  hosts: dbservers
  become: true
  roles:
    - database

Here, roles organize tasks into reusable components.

Ansible Playbook Best Practices

 Use roles for modularity (ansible-galaxy init <role-name>)
Leverage variables (vars, vars_files, group_vars) for flexibility
Use handlers to restart services only when needed
Utilize when: to conditionally execute tasks
Keep playbooks DRY (Don’t Repeat Yourself) with includes & roles.

Deciding on when to use ansible cli or ansible tower

Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard.

Deciding on when to use Ansible cli or Ansible tower

The choice between Ansible CLI and Ansible Tower (now Ansible Automation Platform – AAP) depends on your automation needs, scale, and operational requirements. Here's a breakdown to help you decide:

Use Ansible CLI when:

1. You're managing a small to medium-scale infrastructure – Ideal for individual admins or small teams running ad-hoc automation.
2. You prefer a lightweight solution – CLI requires fewer resources and is easy to set up.
3. You need full control over playbooks – Directly execute and troubleshoot playbooks from the terminal.
4. You don’t require centralized management – Each administrator runs their playbooks manually or with simple scheduling.
5. You’re working with DevOps pipelines – Can integrate into CI/CD workflows via scripts.

Use Ansible Tower (AAP) when:

1. You need enterprise-scale automation – Useful for large teams managing thousands of nodes.
2. You require role-based access control (RBAC) – Enables different users to have varying levels of access and permissions.
3. You want a web-based UI and dashboards – Makes managing jobs, inventory, and logs more visual and accessible.
4. You need centralized logging and reporting – Useful for compliance, auditing, and debugging.
5. You require workflow orchestration – Can chain playbooks and handle complex dependencies between tasks.
6. You need API-driven automation – Provides REST API support to integrate with ITSM tools, CI/CD pipelines, or cloud platforms.
7. You want job scheduling – Supports scheduling recurring tasks and automation workflows.

 Decision Guide:

• For quick, direct automation → Use Ansible CLI.
• For team collaboration, governance, and large-scale automation → Use Ansible Tower (AAP).

Ansible Playbooks and Benefits

 Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard. 

 Benefits of Using Ansible Playbooks

Ansible Playbooks offer a powerful way to automate IT tasks efficiently and consistently. Here are the key benefits of using them:

1. Declarative and Human-Readable

• Uses YAML syntax, making it easy to read and write.
• No need for extensive coding skills—clear structure for tasks, handlers, and roles.

2. Idempotency

• Ensures tasks run only when necessary, preventing unintended changes.
• Avoids redundant operations, optimizing execution time.

3. Agentless Architecture

• No need to install agents on target machines—just SSH (or WinRM for Windows).
• Reduces complexity and maintenance overhead.

4. Reusability and Modularity

• Supports roles and reusable playbooks, promoting best practices.
• Easily share and reuse automation tasks across projects.

5. Scalability and Efficiency

• Can run on multiple hosts simultaneously, using inventory management.
• Handles large-scale infrastructure automation seamlessly.

6. Cross-Platform Compatibility

• Works on Linux, Windows, cloud environments, and network devices.
• Supports hybrid cloud and multi-cloud automation.

7. Workflow Automation and Orchestration

• Enables complex workflows by defining task dependencies.
• Chains multiple playbooks for orchestrating end-to-end deployments.

8. Integration with DevSecOps and CI/CD Pipelines

• Works well with tools like Jenkins, GitLab CI/CD, and Terraform.
• Automates provisioning, configuration management, and deployments.

9. Security and Compliance

• Enforces security policies via automation.
• Reduces human error in configuration and updates.

10. Extensibility with Custom Modules and Plugins

• Supports custom modules and plugins for extended functionality.
• Works with APIs, databases, and third-party tools.

Other Ansible Key concepts

Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard.

Double-click on the image to zoom-out ...Larger.

To return to Home page: Refresh Page or Take ESC Button on Keyboard.

Other Ansible Key concepts.