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
|
1 2 3 4 5 6 7 8 9 10 |
# 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
|
1 2 3 4 |
[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
|
1 2 3 4 5 6 7 |
# '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.
|
1 2 3 4 5 6 7 8 9 |
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.
|
1 2 3 4 5 6 7 8 9 |
- 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.
|
1 2 3 |
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.
|
1 2 3 4 5 6 7 8 9 |
- 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.
|
1 2 3 4 5 6 7 8 9 |
- hosts: servers become: yes tasks: - name: Create a directory apt: path: /my/directory state: directory |
Variables
|
1 2 3 4 |
http_port: 80 max_clients: 200 |
|
1 2 3 4 5 6 7 8 9 |
- hosts: servers vars_files: - vars.yaml tasks: - name:Display the value of the variable 'http_port' debug: msg: "The HTTP port is {{ http_port }}" |
|
1 2 3 |
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.
|
1 2 3 |
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.
|
1 2 3 4 5 6 7 8 9 10 |
- 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.
|
1 2 3 |
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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
# 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.
|
1 2 3 4 |
db_password: supersecretpassword123 api_key: "techaid24" |
|
1 2 3 4 5 6 7 8 9 |
- 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/
|
1 2 3 4 5 6 7 |
# 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.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
- 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.
|
1 2 3 4 5 6 7 8 |
- 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.
|
1 2 3 4 5 6 7 8 9 10 |
- 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 |
Leave a Comment