Fast Ansible Save

This repo covers Ansible with LABs: Multipass, Commands, Modules, Playbooks, Tags, Managing Files and Servers, Users, Roles, Handlers, Host Variables, Templates and details.

Project README

Fast-Ansible

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.

Quick Look (HowTo): Scenarios - Hands-on LABs

Table of Contents

Motivation

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).

    • With IaC, tasks is savable, versionable, repetable and testable.
    • With IaC, desired configuration is defined as 'Declerative Way'.

  • 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.

    image (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.)

    image (ref: ibm.github.io)

  • Ansible can be easily integrated with different technologies (e.g. Terraform).

What is Ansible?

  • "Ansible is a software tool that provides simple but powerful automation for cross-platform computer support." (ref: Opensource.com)

How Ansible Works?

  • 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:

    • Inventory File: It contains and groups worker nodes' IP and domain names. Ansible knows and sends commands using these file, typically located at /etc/ansible/hosts.
    • Configuration (.cfg) File: It contains configuration (e.g. inventory file, key_file, remote_user, etc.)
    • Playbook: Playbooks are one of the core features of Ansible and tell Ansible what to execute. It is a file containing a series of tasks to be executed on a remote server. Playbooks are written in YAML format.

  • Other Important Parts:

    • Control Machine / Node: a system where Ansible is installed and configured to connect and execute commands on nodes.
    • Node (Worker node): a server controlled by Ansible.
    • Role: a collection of playbooks and other files that are relevant to a goal such as installing a web server.
    • Play: a full Ansible run. A play can have several playbooks and roles, included from a single playbook that acts as entry point.

    image (ref: kreyman.de)

Creating LAB Environment

Ansible Basic (Ad-Hoc) Commands

  • Commands can be sent to the all worker nodes from control node.

  • Code structure: image

  • 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
  • If you define your inventory file (nano inventory) and group the servers with keywords, you can use 'web_servers' and 'database_servers' in the commands (above).
[web_servers]
172.21.67.249

[database_servers]
172.21.75.98

Ansible Modules

Ansible Playbooks

  • Instead of using Adhoc Commands, playbooks are used to store, manage easily (declerative way)

    image

  • 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>

Inventory File - Targeting Specific Nodes

  • For grouping the nodes (defining with names), we are using inventory file (nano inventory):
[web_servers]
172.21.67.249

[database_servers]
172.21.75.98

Tags

  • With tags, some specific part of the code (playbook's play) could be run.
ansible-playbook --tags ubuntu --ask-become-pass site.yml

image

Managing Files

  • 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.

    image

  • Go to LAB to learn how:

Managing Services

  • It is possible to manage services (create, start, stop, restart, configure service file)
- name: start apache (Ubuntu)
  tags: ubuntu,apache,apache2
  service:
    name: apache2
    state: started
    enabled: yes
  when: ansible_distribution == "Ubuntu"

Adding Users

  • It is possible to manage users (add users, create SSH keys for users, add user as sudoers)
- name: create new user
  user:
    name: newuser111
    groups: root

Roles

  • 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.

    image

  • Go to LAB to learn how:

Host Variables

  • It helps to define variables which are dependent to the hosts.

    image

    image

  • Go to LAB to learn how:

Handlers

  • To trigger/notify other Ansible code, handlers are used.

    image

  • Go to LAB to learn how:

Templates

  • Ansible template module does two things:

    • Replace the Jinja2 interpolation syntax variables present ({{ }}) in the template file with actual values.
    • Copy (scp) the file to the remote server.

  • Jinja2 interpolation syntax variables in the playbook (ref: middlewareinventory):

    image

  • 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"

Debugging

  • For verbosity, use -v, -vv (increase level), -vvv.
ansible all -m shell -a uptime -v
ansible all -m shell -a uptime -vv
ansible all -m shell -a uptime -vvv

Details 

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

Capture Shell Output

  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:

    image

  • Output:

    image

Deleting files & directories

tasks:
- name: rm
  file:
    path: <some path>
    state: absent
    recurse: yes        # optional

References

Open Source Agenda is not affiliated with "Fast Ansible" Project. README Source: omerbsezer/Fast-Ansible
Stars
583
Open Issues
0
Last Commit
1 year ago
Repository
omerbsezer/Fast-Ansible
License
MIT
Tags
Ansible Ansible Playbook Ansible Playbooks Ansible Role Multipass

Open Source Agenda Badge

Open Source Agenda Rating
Submit Review Review Your Favorite Project
Submit Resource Articles, Courses, Videos
Submit Article Submit a post to our blog

From the blog

Dec 11, 2022

How to Choose Which Programming Language to Learn First?

From the blog

Dec 11, 2022

How to Choose Which Programming Language to Learn First?