This series of lessons lays the foundation for the remainder of the course content. Through a combination of lecture and command line demonstration, Students will gain a broad overview of Ansible. This particular lesson, focuses on Ansible inventories.

Overview
- Invetories
- Modules
- Variables
- Facts
- Plays
- Playbooks
- Configuration files

Inventories

Inventory files may simply consist of a list of hostnames but can be much more robust
It is also possible to define groups of hosts, host or group level variables, and groups of groups withing the inventory
There are a number of variables that may be used within the inventory to control how ansible connects to and interacts with target hosts
Commands to call ansible with ping module:
- ansible innaghiyev1c.mylabserver.com -m ping -k - call ping module on innaghiyev1c.mylabserver.com host. Where -m ping is ping module and -k is key for asking password
- ansible all -m ping -k - call all defined hosts in your inventory list /etc/ansible/hosts/
- ansible -i inv.ini httpd -m ping -k - where -i - inventory file place, httpd hosts group name inside of inv.ini file

Output:

innaghiyev1c.mylabserver.com | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "ping": "pong"
}

Understanding Core Components of Ansible Part 2

Modules
- Modules are essentially tools for particular tasks
- Modules can take (and usually do) take parameters
- They return JSON
- Can run from the command line or within a playbook
- There are a significant number of modules for many kinds of work
- Custom modules can be written
Variables
- Variable names should be letters, numbers and underscores
- Variables should always start with a letter
- Can be scoped by a group, host, or even ini a playbook
- Typically used for configuration values and various parameters
- Variables can also be used to store the return value of executed commands
- Ansible variables may also be dictionaries
- There are a number of predefined variables used by Ansible
Facts
- Facts provide certain information about given target host
- Facts are discovered by Ansible automatically when it reaches out to a host
- Fact gathering may be disabled
- Facts may be cached between playbook executions, but this is not default behavior

innaghiyev1c.mylabserver.com | SUCCESS => {
    "ansible_facts": {
        "ansible_all_ipv4_addresses": [
            "172.31.37.72"
        ],
        "ansible_all_ipv6_addresses": [
            "2a05:d01c:2c7:d802:4db1:18cc:f13f:a1cf",
            "fe80::9e:19ff:fe1e:7376"
        ],
        "ansible_apparmor": {
            "status": "enabled"
        },
        "ansible_architecture": "x86_64",
        "ansible_bios_date": "10/16/2017",
        "ansible_bios_version": "1.0",

Plays and playbooks
- The goal of a play is to map a group of hosts to some well-defined roles
- A play may use one or more modules to achieve a desired end state on a group of hosts
- A playbook is a series of plays
- A playbook may deploy new web servers, install a new application to existing application servers, and run SQL against some database servers to support the new application
Configuration Files
- Several possible locations (in order processed):
  - ANSIBLE_CONFIG (an environment variable)
  - ansible.cfg (in the current directory)
  - .ansible.cfg (in the home directory)
  - /etc/ansible/ansible.cfg (master configuration)
- Configuration can also be set in environment variables
- Some commonly used settings:
  - ansible_managed
  - forks
  - Inventory

A Brief Tour of the Ansible Configuration File

The Ansible master configuration file is reviewed on a live system in this demonstration. Key configuration values are discussed as well as how to modify those values.

Let's see some default values of ansible.cfg file located by /etc/ansible/ansible.cfg directory

[defaults]

# some basic default values...

#inventory      = /etc/ansible/hosts
#library        = /usr/share/my_modules/
#module_utils   = /usr/share/my_module_utils/
#remote_tmp     = ~/.ansible/tmp
#local_tmp      = ~/.ansible/tmp
#plugin_filters_cfg = /etc/ansible/plugin_filters.yml
#forks          = 5
#poll_interval  = 15
#sudo_user      = root
#ask_sudo_pass = True
#ask_pass      = True
#transport      = smart
#remote_port    = 22
#module_lang    = C
#module_set_locale = False

Another handy block is following

[privilege_escalation]
#become=True
#become_method=sudo
#become_user=root
#become_ask_pass=False

LAB Getting Started with Ansible

The very first step to harnessing the power of Ansible is configuring your environment. This activity goes over installing Ansible on a control node and configuring two managed servers for use with Ansible. We will also create a simple inventory and run an Ansible command to verify our configuration is correct.

Additional Information and Resources

Your CIO has greenlit a proof of concept for Ansible in your environment. You are to set up an Ansible control node in a test environment and verify basic functionality. You have three demo hosts, one to be the control node (control1), and two to serve as managed nodes (node1 and node2). You must complete the following steps:

Install Ansible on the control node.
Configure the ansible user on the control node for ssh shared key access to managed nodes. Note: do not use a passphrase for the key pair.
Create a simple Ansible inventory on the control node in /home/ansible/inventory containing node1 and node2.
Configure sudo access for Ansible on node1 and node2 so that Ansible may use sudo for any command with no password prompt.
Verify each managed node can be accessed by Ansible from the control node using the ping module. Redirect the output of a successful command to /home/ansible/output.

Important Notes:

The user ansible is already present on all servers for your convenience.
The ansible user has the same password as the cloud_user.
/etc/hosts entries are present on control1 for the managed nodes.

Install Ansible on the control node.

To install Ansible on the control node, run ansible.

yum install ansible

If package not found run

yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

Configure the `ansible` user on the control node for ssh shared key access to managed nodes. Do not use a passphrase for the key pair.

To create a keypair for the ansible user on the control host, run the following:
- sudo su - ansible
- ssh-keygen (accept all defaults: press enter for each prompt)
Copy the public key to both node1 and node2.
As the ansible user on the control host:
- ssh-copy-id node1 (accept the host key if prompted, authenticate as ansible user)
- ssh-copy-id node2 (accept the host key if prompted, authenticate as ansible user)

Create a simple Ansible inventory on the control node in `/home/ansible/inventory` containing `node1` and `node2`.

On the control host:
- sudo su - ansible (if not already ansible user)
- touch /home/ansible/inventory
- echo "node1" >> /home/ansible/inventory
- echo "node2" >> /home/ansible/inventory

Configure sudo access for Ansible on `node1` and `node2` such that Ansible may use sudo for any command with no password prompt.

Log in to node1 as cloud_user and edit the sudoers file to contain appropriate access for the ansible user:
- ssh cloud_user@node1
- sudo visudo
- Add the following line to the file and save:

ansible    ALL=(ALL)       NOPASSWD: ALL

Repeate these steps for node2.

Verify each managed node is able to be accessed by Ansible from the control node using the `ping` module. Redirect the output of a successful command to `/home/ansible/output`.

To verify each node, run the following as the ansible user from the control host:
- ansible -i /home/ansible/inventory node1 -m ping
- ansible -i /home/ansible/inventory node2 -m ping
To redirect output of a successful command to /home/ansible/output:
- ansible -i /home/ansible/inventory node1 -m ping > /home/ansible/output

Run Ad-Hoc Ansible Commands

Learn how to use ad-hoc ansible commands for simple system managment. This lecture covers one of the key objectives for Red Hat exam 407.

Overview:
- What is an ad-hoc command in Ansible?
- Use cases for ad-hoc commands
- Ad-hoc vs Playbook
- Ansible command syntax
- Common modules
What is an ad-hoc command in Ansible
- You can run ansible either ad-hoc or as a playbook
- Both methods have the same capabilities
- Ad-hoc commands are effectively one-liners
Use cases for Ad-hoc
- Operational commands
  - Checking log contents
  - Daemon control
  - Process management
- Informational commands
  - Check installed software
  - Check system properties
  - Gather system performance information
- Research
  - Work with unfamiliar modules on test systems
  - Practice for playbook engineering

Ad-hoc vs Playbook

Common Modules

Demonstration: Ansible Ad-Hoc Commands Part 1

Let's use yum as an example of ad-hoc command
- ansible myserver.example.com -i inv.ini -m yum -b -a "name=elinks state=latest" - install elinks with latest version
  - -i - key for inventory host file
  - -m yum - use yum module
  - -b - become (by default become root). Can be changed in /etc/ansible/ansible.cfg file
  - -a "name=elinks state=latest" - arguments. For yum module we're using name and state
- ansible myserver.example.com -i inv.ini -m yum -b -a "name=elinks state=absent" - state absent will uninstall elinks

Demonstration: Ansible Ad-Hoc Commands Part 2

Let's work with a file module
- ansible myserver.example.com -i inv.ini -m file -a "name=/home/user/newfile state=touch"
  - -m file - using file module
  - -a "name=/home/user/newfile state=touch" - arguments name - for declaring path of file and state what to do with it.
- ansible myserver.example.com -i inv.ini -m file -a "name=/home/user/newfile" - get properties of the file
- ansible myserver.example.com -i inv.ini -m file -a "name=/home/user/newfile mode=0400" - set a mode of the file to 0400
- ansible myserver.example.com -i inv.ini -m file -b -a "name=/home/user/newfile owner=root" - we are changing file owner to root and using -b key for become.
- ansible myserver.example.com -i inv.ini -m user -b -a "name=sam" - create user sam
  - -m user - using user module
  - -a "name=sam" - as argument we indicate user name
- ansible myserver.example.com -i inv.ini -m user -b -a "name=sam append=yes groups=wheel" - add user to a wheel group.
  - append=yes - for appending group, otherwise it will wipe out previous groups
  - groups=wheel - define which group needs to be added

LAB Ad-Hoc Ansible Commands

One of the keys to success with Ansible is being able to run ad-hoc commands. The value of ad-hoc commands is underscored by the fact that it is an objective of the Red Hat Certified Ansible Specialist exam. This exercise guides students through crafting many ad-hoc commands which will not only build experience with the concept but also broaden the students' exposure to various Ansible command modules.

Additional Information and Resources

Some consultants have been employed to perform audits on a number of systems in your company's environment. You must create the user accounts noted in /home/ansible/userlist.txt and set up the provided public keys for their accounts. The security team has built a jump host for the consultants to access production systems and provided the full key-pair to you so you may set up and test the connection. All hosts in dbsystems will need the provided public key installed so the consultants may use key-pair authentication to access the systems. Also, you must ensure the auditd service is enabled and running on all systems.

To summarize, you must do the following:

Create the user accounts noted in /home/ansible/userlist.txt.
Copy the authorized_keys file for each user to the correct location so the new accounts can log in with ssh key authentication.
Ensure auditd is enabled and running on all systems.

Important notes:

For your convenience, Ansible is already on the control node. If you connect to the server by clicking on the Public IP address in your browser, make sure to change to the ansible user with the su - ansible command.
The user ansible is present on all servers with appropriate shared keys for access to managed servers from the control node. Make sure to use this user to complete the commands.
The ansible user has the same password as cloud_user.
The default Ansible inventory has been configured for you with the appropriate hosts and groups.
/etc/hosts entries are present on control1 for the managed servers.

Learning Objectives

Create the User Accounts Noted in `/home/ansible/userlist.txt`

ansible dbsystems -b -m user -a "name=consultant"
ansible dbsystems -b -m user -a "name=supervisor"

Place Key Files in the Correct Location, `/home/$USER/.ssh/authorized_keys`, on Hosts in `dbsystems`

ansible dbsystems -b -m file -a "path=/home/consultant/.ssh state=directory owner=consultant group=consultant mode=0755"
ansible dbsystems -b -m copy -a "src=/home/ansible/keys/consultant/authorized_keys dest=/home/consultant/.ssh/authorized_keys mode=0600 owner=consultant group=consultant"
ansible dbsystems -b -m file -a "path=/home/supervisor/.ssh state=directory owner=supervisor group=supervisor mode=0755"
ansible dbsystems -b -m copy -a "src=/home/ansible/keys/supervisor/authorized_keys dest=/home/supervisor/.ssh/authorized_keys mode=0600 owner=supervisor group=supervisor"

Ensure `auditd` Is Enabled and Running on All Hosts

ansible all -b -m service -a "name=auditd state=started enabled=yes"

Inventory Management

Inventory Essentials and Inventory Variables

In Ansible, inventories are crucially important as they serve as the foundation for ansible automation. This lecture extends on the basic inventory concpets already covered such as file format and location. Students will be introduced to the concept of static and dynamic inventories and learn about how inventories and variables work together.

Overview

Use both static and dynamic inventories to define groups of hosts:
- What is the inventory
- File formats
- Statis vs. Dynamic
- Variables and inventories
Utilize an existing dynamic inventory script:
- On dynamic inventories
- Some popular options

What is an Inventory

An inventory is a list of hosts that Ansible manages
Inventory location may be specified as follows:
- Default: /etc/ansible/hosts
- Specified by CLI: ansible -i
- Can be set in ansible.cfg
The inventory file may contain hosts, patterns, groups, and variables
You may specofy the inventory as a directory containing a series of inventory files (both static and dynamic)
The inventory may be specified in YAML or INI format
Can be static or dynamic

File Formats

Static vs. Dynamic

Variables and Inventories

Demo: Variables and Inventories

Being able to work with inventories and variables is an essential skill for any user of Ansible. This command line demonstration will show students the best practices for using variables within inventories.

Inside of inventory directory we have following structure:

[cloud_user@innaghiyev2c inventory]$ ls -l
total 4
drwxrwxr-x. 2 cloud_user cloud_user  23 Feb 28 05:18 group_vars
drwxrwxr-x. 2 cloud_user cloud_user  25 Feb 27 10:53 host_vars
-rw-rw-r--. 1 cloud_user cloud_user 127 Feb 27 10:41 inventory

Where:

inventory - stores our hosts

[cloud_user@innaghiyev2c inventory]$ cat inventory
innaghiyev1c ansible_host=innaghiyev1c.mylabserver.com

[labservers]
innaghiyev3c.mylabserver.com
innaghiyev1c.mylabserver.com

group_vars - contains group name of our hosts' group. labservers - name of group, which contains variables

[cloud_user@innaghiyev2c inventory]$ ls -l group_vars/
total 4
-rw-rw-r--. 1 cloud_user cloud_user 50 Feb 28 05:18 labservers
[cloud_user@innaghiyev2c inventory]$ cat group_vars/labservers
logs : /var/log/messages
secure : /var/log/secure

host_vars - contains hostname with stored variable inside. innaghiyev1c - name of the host, which contains variables

[cloud_user@innaghiyev2c inventory]$ ls host_vars/
innaghiyev1c
[cloud_user@innaghiyev2c inventory]$ cat host_vars/innaghiyev1c
opt_dir : /opt

Demo: Using YAML in Inventories

Inventories may be specified in INI or YAML format. This demonstration goes over how to use YAML to create an inventory. Students will benefit from a refresher on YAML syntax as well as review key details on Ansible inventories.

This is how YAML inventory file looks like:

all:
  hosts:
    innaghiyev1c.mylabserver.com:
  children:
    production:
      hosts:
        innaghiyev1c.mylabserver.com:
        innaghiyev3c.mylabserver.com:
    labservers:
      hosts:
        innaghiyev[1:3]c.mylabserver.com:

Dynamic Inventories

Being able to use dynamic inventories in essential skill for any Ansible specialist. This lecture goes over the details of how dynamic inventories in Ansible work.

Some Popular Options:

Demo: Dynamic Inventories

chmod +x script.py - script for dynamic inventory must be executable. Output of your script must be in JSON format
ansible all -i script.py -m ping - usage of dynamic inventory is the same as a static one

LAB Working with Ansible Inventories

Additional Information and Resources

Your company has decided the backup software license is frivolous and unnecessary. As a consequence, the license was not renewed. Your supervisor has created a simple script and an Ansible playbook to create an archive of select files, depending on pre-defined Ansible host groups, as a stop-gap measure. You will create the inventory file to complete the backup strategy.

You must do the following:

Create the inventory file in /home/ansible/inventory.
Configure the host group media to contain media1 and media2.
Define the following variables for media with their accompanying values:
- media_content should be set to /var/media/content/.
- media_index should be set to /opt/media/mediaIndex.
Configure the host group webservers to contain the hosts web1 and web2.
Define the following variables for webservers with their accompanying values:
- httpd_webroot should be set to /var/www/
- httpd_config should be set to /etc/httpd/
Define the variable script_files specifically for web1. The value of script_files should be set to /usr/local/scripts.
You can run /home/ansible/scripts/backup.sh to test your inventory. If you have correctly configured the inventory, it should not error.
Do not edit anything in /home/ansible/scripts/.

Important notes:

For your convenience, Ansible has been installed on the control node.
The user ansible has already been created on all servers with appropriate shared keys for access to managed servers from the control node.
The ansible user has the same password as cloud_user.
/etc/hosts entries have been made on control1 for the managed servers.
Do not edit anything in /home/ansible/scripts/.

Learning Objectives

Create the `inventory` File in `/home/ansible/`

touch /home/ansible/inventory

Configure the Host Group `media` to Contain `media1` and `media2`

echo "[media]" >> /home/ansible/inventory
echo "media1" >> /home/ansible/inventory
echo "media2" >> /home/ansible/inventory

Define Variables for `media` with Their Accompanying Values

mkdir /home/ansible/group_vars
touch /home/ansible/group_vars/media
echo "media_content: /var/media/content/" >> /home/ansible/group_vars/media
echo "media_index: /opt/media/mediaIndex" >> /home/ansible/group_vars/media

Configure the Host Group `webservers` to Contain the Hosts `web1` and `web2`

echo "[webservers]" >> /home/ansible/inventory
echo "web1" >> /home/ansible/inventory
echo "web2" >> /home/ansible/inventory

Define Variables for `webservers` with Their Accompanying Values

touch /home/ansible/group_vars/webservers
echo "httpd_webroot: /var/www/" >> /home/ansible/group_vars/webservers
echo "httpd_config: /etc/httpd/" >> /home/ansible/group_vars/webservers

Define the Variable `script_files` Specifically for `web1`, Setting Its Value to `/usr/local/scripts`

mkdir /home/ansible/host_vars
touch /home/ansible/host_vars/web1
echo "script_files: /usr/local/scripts" >> /home/ansible/host_vars/web1

Create Ansible Plays and Playbooks

Introduction to Playbooks and Common Modules

This less provides an overview of the section and reviews some of the common modules that will continue showing up as the playbook discussion occurs.

Overview:

Know how to work with commonly used Ansible modules
Create playbooks to configure systems to a specified state
Use variables to retrieve the results of running commands
Use conditionals to control play execution
Configure error handling
Selectively run specified tasks in playbooks using tags

Know how to work with Commonly Used Ansible Modules

Core modules to be familiar with:
- Working with files: copy, archive, unarchive, get_url
- user, group
- ping
- service
- yum
Lineinfile module
htpasswd
Shell and command modules
Script module
Debug module
https://docs.ansible.com/ansible/latest/modules/modules_by_category.html

Create Playbooks to Configure Systems to a Specified State

Basic Playbook Syntax Demonstration

Let's write some simple playbook.

--- #to mention that this is a cookbook
- hosts: labservers #define hosts group
  become: yes #become means sudo, by default is root user 
  tasks: #what to do on defined hosts
    - name: install apache #task name, can be anything
      yum: #what module to call
        name: httpd #package name
        state: latest #state of that package, version, absent etc.
    - name: start and enable httpd #task name
      service: #module name
        name: httpd #service name
        state: started #what is desired state of that service 
        enabled: yes #enable service, equal to systemctl enable httpd
    - name: create index.html #name of task 
      file: #module name 
        path: /var/www/html/index.html #path of file to change
        state: touch #what to do with that file, in our case - touch
    - name: add a linex to index.html #task name
      lineinfile: #module name
        path: /var/www/html/index.html #path to the file
        line: "Hello World" #check line, if not exist add it

ansible-playbook playbook.yml - instead of ansible - ad-hoc run, we're running ansible-playbook to execute playbook file.
ansible-playbook playbook.yml --limit innaghiyev1c.mylabserver.com - set limits on playbook run and execute it only on limited host.

README.md

EX407-Ansible-Automation

Understanding Core Components of Ansible

Understanding Core Components of Ansible Part 1

Inventories

Understanding Core Components of Ansible Part 2

A Brief Tour of the Ansible Configuration File

LAB Getting Started with Ansible

Additional Information and Resources

Install Ansible on the control node.

Configure the ansible user on the control node for ssh shared key access to managed nodes. Do not use a passphrase for the key pair.

Create a simple Ansible inventory on the control node in /home/ansible/inventory containing node1 and node2.

Configure sudo access for Ansible on node1 and node2 such that Ansible may use sudo for any command with no password prompt.

Verify each managed node is able to be accessed by Ansible from the control node using the ping module. Redirect the output of a successful command to /home/ansible/output.

Run Ad-Hoc Ansible Commands

Run Ad-Hoc Ansible Commands

Ad-hoc vs Playbook

Common Modules

Demonstration: Ansible Ad-Hoc Commands Part 1

Demonstration: Ansible Ad-Hoc Commands Part 2

LAB Ad-Hoc Ansible Commands

Additional Information and Resources

Learning Objectives

Create the User Accounts Noted in /home/ansible/userlist.txt

Place Key Files in the Correct Location, /home/$USER/.ssh/authorized_keys, on Hosts in dbsystems

Ensure auditd Is Enabled and Running on All Hosts

Inventory Management

Inventory Essentials and Inventory Variables

Overview

What is an Inventory

File Formats

Static vs. Dynamic

Variables and Inventories

Demo: Variables and Inventories

Demo: Using YAML in Inventories

Dynamic Inventories

Demo: Dynamic Inventories

LAB Working with Ansible Inventories

Additional Information and Resources

Learning Objectives

Create the inventory File in /home/ansible/

Configure the Host Group media to Contain media1 and media2

Define Variables for media with Their Accompanying Values

Configure the Host Group webservers to Contain the Hosts web1 and web2

Define Variables for webservers with Their Accompanying Values

Define the Variable script_files Specifically for web1, Setting Its Value to /usr/local/scripts

Create Ansible Plays and Playbooks

Introduction to Playbooks and Common Modules

Overview:

Know how to work with Commonly Used Ansible Modules

Create Playbooks to Configure Systems to a Specified State

Basic Playbook Syntax Demonstration

Configure the `ansible` user on the control node for ssh shared key access to managed nodes. Do not use a passphrase for the key pair.

Create a simple Ansible inventory on the control node in `/home/ansible/inventory` containing `node1` and `node2`.

Configure sudo access for Ansible on `node1` and `node2` such that Ansible may use sudo for any command with no password prompt.

Verify each managed node is able to be accessed by Ansible from the control node using the `ping` module. Redirect the output of a successful command to `/home/ansible/output`.

Create the User Accounts Noted in `/home/ansible/userlist.txt`

Place Key Files in the Correct Location, `/home/$USER/.ssh/authorized_keys`, on Hosts in `dbsystems`

Ensure `auditd` Is Enabled and Running on All Hosts

Create the `inventory` File in `/home/ansible/`

Configure the Host Group `media` to Contain `media1` and `media2`

Define Variables for `media` with Their Accompanying Values

Configure the Host Group `webservers` to Contain the Hosts `web1` and `web2`

Define Variables for `webservers` with Their Accompanying Values

Define the Variable `script_files` Specifically for `web1`, Setting Its Value to `/usr/local/scripts`