Ansible For Teenagers | Suitable For Adults

Ansible is an open-source automation tool for the configuration and management of IT infrastructures. It allows for the easy management of numerous servers using YAML to describe automated tasks. Ansible operates agentlessly, meaning there is no need to install additional software on the nodes it manages.

Ansible is popular for several reasons:

• Simplicity and ease of use: The playbooks (configuration files) are written in YAML, a simple and human-readable language.
• Powerful and flexible: Ansible can handle complex tasks and adapt to various environments.
• Agentless: No need to install software on the managed nodes, simplifying management and security.
• Idempotent: Playbooks can be run multiple times without causing undesirable or unintended effects.
• Large community and support: Ansible benefits from a vast community and an abundance of resources and modules.

Ansible Installation

# Installation of Ansible on a Debian-based distribution
sudo apt update && sudo apt install ansible

# Installation of Ansible on a Red Hat-based distribution
sudo yum install ansible

# Installation of Ansible on masOS Homebrew
brew install ansible

Inventory

[servers]
server1 ansible_host=192.168.63.3

The inventory file is a configuration document used by Ansible to list and organize the hosts and server groups on which tasks and playbooks will be executed.

Ansible communicates with remote nodes using SSH for Unix/Linux systems and WinRM for Windows systems, enabling secure and efficient management of configurations and automations remotely.

Ansible Ping

# 'all' designates all hosts
# '-i' specifies the inventory file
# '-m ping' uses the ping module to rest the connection

ansible all -i inventory.ini -m ping

This command sends a ping to all the hosts defined in inventory.ini to verify that Ansible can connect to them correctly.

server1 | SUCCESS => {
    "ansible_facts":{
         "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

Playbooks

An Ansible playbook is a YAML file describing the tasks to be executed on the servers.

- hosts: servers
  become: yes
  tasks:
    - name: Ensure Apache is installed
      apt: 
        name: apache2
        state: present

This playbook targets the server group in your inventory file and executes a task to install Apache on the machines in this group.

ansible-playbook -i inventory.ini mon_playbook.yml

Tasks

Tasks are the basic units of action in an Ansible playbook. They define what you want to achieve on the targeted hosts.

- hosts: servers
  become: yes
  tasks:
    - name: Update all packages
      apt: 
        update_cache: yes
        upgrade: dist

This task updates the packages on an Ubuntu server using the apt module. Ansible has a wide range of modules for various tasks. For example, to manage files, use the file module.

- hosts: servers
  become: yes
  tasks:
    - name: Create a directory
      apt: 
        path: /my/directory
        state: directory

Variables

http_port: 80
max_clients: 200

- hosts: servers
  vars_files: 
    - vars.yaml
  tasks:
    - name:Display the value of the variable 'http_port'
      debug: 
        msg: "The HTTP port is {{ http_port }}"

ansible-playbook my_playbook.yml -i inventory.ihi -e "http_port=8080"

Facts

Facts in Ansible are automatically generated variables containing information about remote systems. They are collected by Ansible each time it connects to a target host, providing details such as the operating system, IP addresses, available disks, etc.

ansible server1 -i inventory.ini -m setup

Facts can be used in your playbooks to condition the execution of tasks based on the characteristics of the host.

- hosts: servers
  become: yes
  tasks:
    - name: Ensure Apache is installed
      apt: 
        name: apache2
        state: present
      when: ansible_os_family = "Debian"

Roles

Roles in Ansible organize tasks, files, templates, and variables into logical units, thereby facilitating reuse and management.

ansible-galaxy ini role_name

Ansible Vault

Ansible Vault is a tool integrated into Ansible that allows for the encryption of sensitive data files for security. It is particularly useful for managing sensitive information such as passwords or secret keys in your playbooks, roles, or variable files.

# Creating a secret - You will be promoted to enter the vault password
ansible-vault create secret.yml

# Editing a secret
ansible-vault edit secret.yml

# Viewing a secret
ansible-vault view secret.yml

# Decrypting a secret
ansible-vault decrypt secret.yml

# Encrypting a secret
ansible-vault encrypt secret.yml

# Using a playbook containing a secret (Will ask for the password)
ansible-playbook site.yml --ask-vault-pass

# Using a playbook by passing the password as a file
ansible-playbook playbook.yml --vault-password-file /path/to/password_file

Ansible Vault Usage

To use encrypted variables in your playbooks, you must first include the encrypted secrets file. Use the vars_files directive in your playbook to specify the encrypted file.

db_password: supersecretpassword123
api_key: "techaid24" 

- hosts: all
  vars_files:
    - secrets.yml
  tasks:
    - name: Display the API key
      debug: 
      msg: "The API key is {{ api_key }}"

Ansible Galaxy

Ansible Galaxy is a platform where the community shares reusable roles : https://galaxy.ansible.com/ui/

# Install a role for Nginx from Ansible Galaxy
ansible-galaxy install geerlingguy.nging

# Install a role for MySQL from Ansible Galaxy
ansible-galaxy install geerlingguy.mysql

This playbook targets two groups of hosts: web servers for the Nginx role and DB servers for the MySQL role.

- hosts: web_servers
  become: yes
  roles:
    - geerlingguy.nginx


- hosts: db_servers
  become: yes
  roles:
    - geerlingguy.mysql

Errors

Sometimes, you may want to continue the execution of the playbook even if a task fails. You can use ignore_errors.

- hosts: servers
  become: yes
  tasks:
    - name: Task that might fail
      command: /a/command/that/might/fail 
      ignore_errors: yes

You can control the conditions under which a task is considered to have failed or succeeded by using failed_when and changed_when. Here, if the word “ERROR” is present, the task fails.

- hosts: servers
  become: yes
  tasks:
    - name: Execution of a script that always return 0
      command: /my/script.sh
      register: script_result
      failed_when: "'ERROR' in script_result.stdout"
      changed_when: script_result.rc != 0