This repo covers Ansible with LABs: Multipass, Commands, Modules, Playbooks, Tags, Managing Files and Servers, Users, Roles, Handlers, Host Variables, Templates and details.
MIT License
This repo covers Ansible with HowTo: Hands-on LABs (using Multipass: Ubuntu Lightweight VMs): Ad-Hoc Commands, Modules, Playbooks, Tags, Managing Files and Servers, Users, Roles, Handlers, Host Variables, Templates and many details. Possible usage scenarios are aimed to update over time.
Keywords: Ansible, Multi-PC Configuration.
Why should we use / learn Ansible?
Ansible automates tasks and commands to manage multiple nodes (servers, PCs).
Ansible is a state-of-the-art automation tool. Many companies use it.
Ansible can be used both on-premises and cloud environment.
It is free, open source (https://github.com/ansible/ansible) and has huge community.
Commands, tasks, codes turn into the Infrastructure As Code (IaC).
Agentless: On the worker node, any agent app is not required to run.
Parallel Run: Ansible runs the same task in multiple hosts by default in parallel.
It runs tasks both on Linux and Windows PCs.
It has well-designed documentation (https://docs.ansible.com)
Ansible uses SSH to communicate with other nodes.
Ansible handles many tasks using its modules.
(ref: medium)
Ansible also is used by other important applications (e.g. Open Source Gating CI Tools: Zuul-CI)
Ansible is used for configuration management on the nodes, Terraform is provisioning tool that uses to create/provision Cloud Infrastructure objects/items (e.g. Virtual Private Cloud, Virtual Machines, Subnets, etc.)
(ref: ibm.github.io)
Ansible can be easily integrated with different technologies (e.g. Terraform).
In Ansible, there are two categories of computers: the control node and managed nodes. The control node is a computer that runs Ansible. There must be at least one control node, although a backup control node may also exist. A managed node is any device being managed by the control node.
Ansible works by connecting to nodes (clients, servers, or whatever you're configuring) on a network, and then sending a small program called an Ansible module to that node. Ansible executes these modules over SSH and removes them when finished.(ref: Opensource.com)
The only requirement for this interaction is that your Ansible control node has login access to the managed nodes. SSH keys are the most common way to provide access, but other forms of authentication are also supported. (ref: Opensource.com)
There are files that are for configuration and usage of Ansible:
Other Important Parts:
(ref: kreyman.de)
Commands can be sent to the all worker nodes from control node.
Code structure:
Sample Commands:
# collect information from specific IP
ansible all -m gather_facts --limit 172.26.215.23
# collect information from all hosts
ansible all -m gather_facts
# update all nodes (sudo apt-get update), 'become' for sudo (give all nodes same password with 'passwd')
ansible all -m apt -a update_cache=true --become --ask-become-pass
# install snapd for all ubuntu nodes (sudo apt-get install snapd)
ansible all -m apt -a "name=snapd state=latest" --become --ask-become-pass
# upgrade all nodes (sudo apt-get upgrade)
ansible all -m apt -a upgrade=dist --become --ask-become-pass
# run shell commands
ansible all -m shell -a "cat /proc/meminfo|head -2"
ansible web_servers -m shell -a "cat /proc/meminfo|head -2"
# to learn disk space
ansible all -m command -a "df -h"
ansible all -a "df -h"
# check the status of the httpd service
ansible all -m service -a "name=httpd"
# get the uptime with shell module
ansible all -m shell -a uptime
# create testfile under '/tmp' with mode=0755
ansible all -m file -a "path=/tmp/testfile state=touch mode=0755"
# list all hosts
ansible all --list-hosts
[web_servers]
172.21.67.249
[database_servers]
172.21.75.98
Modules: Small programs that do actual job (one small specific task).
Control node sends these modules to the nodes.
Go to LAB to learn:
Go to LAB to learn:
All Modules in Ansible:
Instead of using Adhoc Commands, playbooks are used to store, manage easily (declerative way)
Playbooks are YAML files that include name, hosts (group name that is defined in inventoryfile), vars (variables that are used in playbooks) and tasks:
---
name: install and configure DB
hosts: testServer
become: yes
vars:
oracle_db_port_value : 1521
tasks:
-name: Install the Oracle DB
yum: <code to install the DB>
-name: Ensure the installed service is enabled and running
service:
name: <your service name>
Playbooks include hostname, user information, and tasks (with modules):
Go to LAB to learn how playbook is created:
[web_servers]
172.21.67.249
[database_servers]
172.21.75.98
ansible-playbook --tags ubuntu --ask-become-pass site.yml
It is possible to transfer file from control node to all workers nodes, to download zip file from internet and to unzip files with playbooks.
Go to LAB to learn how:
- name: start apache (Ubuntu)
tags: ubuntu,apache,apache2
service:
name: apache2
state: started
enabled: yes
when: ansible_distribution == "Ubuntu"
- name: create new user
user:
name: newuser111
groups: root
Roles are defined to simplify, control your Ansible code like sofware code.
Roles are assigned to the group of nodes and roles help to define the task of these nodes.
Go to LAB to learn how:
It helps to define variables which are dependent to the hosts.
Go to LAB to learn how:
To trigger/notify other Ansible code, handlers are used.
Go to LAB to learn how:
Ansible template module does two things:
Jinja2 interpolation syntax variables in the playbook (ref: middlewareinventory):
In Ansible {{ }} is the interpolation syntax whereas in shell script it is ${ }
You can start your playbook like this with the variables at runtime.
ansible-playbook findtest.yaml -e "DIR=/apps/Tomcat FILEEXT=*.log DAYSOLD=30"
ansible all -m shell -a uptime -v
ansible all -m shell -a uptime -vv
ansible all -m shell -a uptime -vvv
ansible-playbook <YAML> -f 10 # Run 10 hosts parallel, default f=5 hosts parallel
ansible-playbook <YAML> -C # Test run
ansible-playbook <YAML> -C -D # Dry run
ansible-playbook <YAML> --user <username> # Log in as username (or -u <username>)
ansible-playbook <YAML> --private-key <key> # Log in using SSH key (usually in ~/.ssh) (or --key-file <key>)
ansible-playbook <YAML> --ssh-extra-args # Pass extra command options to SSH
ansible-playbook <YAML> --vault-id <id> # Use vault identity ID
ansible-playbook <YAML> --vault-password-file <key> # Use vault password file key
ansible-playbook <YAML> --ask-vault-pass # Prompt for a vault password
ansible-playbook <YAML> --become # Escalate privileges
ansible-playbook <YAML> --ask-become-pass # Prompt for a password for become
ansible-playbook <YAML> -l <host> # Run on single host
ansible-playbook <YAML> --list-hosts # Run Infos
ansible-playbook <YAML> --list-tasks # Run Infos
ansible-playbook <YAML> --syntax-check # Syntax Check
ansible-playbook <YAML> --check # Run the playbook but don’t make changes
ansible-playbook <YAML> --diff # Show diffs for what changes are made
tasks:
- name: some shell
register: sh_out
ignore_errors: yes
become_user: root
shell: |
find /
- name: "Print stdout"
debug:
msg: "{{ sh_out.stdout_lines }}"
- name: "Print stderr"
debug:
msg: "{{ sh_out.stderr.split('\n') }}"
Debug output section in the playbook:
Output:
tasks:
- name: rm
file:
path: <some path>
state: absent
recurse: yes # optional