LAB MANUAL FOR

FINAL PRESENTATION
Submitted By: Adnan Khurshid
Topic: Ansible manage host & Playbook
Arranged By: Mature Resource Global
Technologies

Cloud Native Computing Boot Camp

 LAB MANUAL FOR FINAL PRESENTATION
Overview: A good automation system allows you to implement Infrastructure as Code
practices. Infrastructure as Code means that you can use a machine-readable automation
language to define and describe the state you want your IT infrastructure to be in. Ideally, this
automation language should also be very easy for humans to read, because then you can
easily understand what the state is and make changes to it. This code is then applied to your
infrastructure to ensure that it is actually in that state. This builds a foundation to help you
follow best practices in DevOps. Developers can define their desired configuration in the
automation language. Operators can review those changes more easily to provide feedback,
and use that automation to producible ensure that systems are in the state expected by the
developers.
Ansible is an open source automation platform. It is a simple automation language
that can perfectly describe an IT application infrastructure in Ansible Playbooks. It is also an
automation engine that runs Ansible Playbooks. Ansible can manage powerful agent-less
automation tasks and can adapt to many different workflows and environments.
Ansible has a number of important strengths:
• Cross platform support: Ansible provides agent-less support for Linux, Windows, UNIX,
and network devices, in physical, virtual, cloud, and container environments.
• Human-readable automation: Ansible Playbooks, written as YAML text files, are easy to
read and help ensure that everyone understands what they will do.
• Perfectdescriptionofapplications: EverychangecanbemadebyAnsiblePlaybooks,and every
aspect of your application environment can be described and documented.
• Easy to manage in version control: Ansible Playbooks and projects are plain text. They
can be treated like source code and placed in your existing version control system.
• Support for dynamic inventories: The list of machines that Ansible manages can be
dynamically updated from external sources in order to capture the correct, current list of all
managed servers all the time, regardless of infrastructure or location.
• Orchestration that integrates easily with other systems: HP SA, Puppet, Jenkins, Red
Hat Satellite, and other systems that exist in your environment can be leveraged and
integrated into your Ansible workflow.

ANSIBLE CONCEPTS AND ARCHITECTURE:

There are two types of machines in the Ansible architecture: control nodes and
managed hosts. Ansible is installed and run from a control node, and this machine also has
copies of your Ansible project files. A control node could be an administrator's laptop, a
system shared by a number of administrators, or a server running Red Hat Ansible Tower.
Managed hosts are listed in an inventory, which also organizes those systems into
groups for easier collective management. The inventory can be defined in a static text file, or
dynamically
determined by scripts that get information from external sources. Instead of writing complex
scripts, Ansible users create high-level plays to ensure a host or group of hosts are in a
particular state. A play performs a series of tasks on the hosts, in the order specified by the
play.These plays are expressed in YAML format in a text file. A file that contains one or
more plays is called a playbook. Each task runs a module, a small piece of code (written in
Python, Power Shell, or some other language), with specific arguments. Each module is
essentially a tool in your toolkit. Ansible ships with hundreds of useful modules that can
perform a wide variety of automation tasks. They can act on system files, install software, or
make API calls.
ANSIBLE INSTALLATION:
Ansible is simple to install. The Ansible software only needs to be installed on the
control node (or nodes) from which Ansible will be run. Hosts that are managed by Ansible
do not need to have Ansible installed. This installation involves relatively few steps and has
minimal requirements. The control node should be a Linux or UNIX system. Microsoft
Windows is not supported as a control node, although Windows systems can be managed
hosts. Python 3 (version 3.5 or later) or Python 2 (version 2.7 or later) needs to be installed on
the control node. Extra Packages for Enterprise Linux (EPEL) is a special interest group (SIG)
from the fedora project that provides a set of additional packages for RHEL (and CentOS, and
others) from the fedora sources for ansible support on controller.

MANAGING ANSIBLE CONFIGURATION FILES:

In configuration file located at /etc/ansible/ansible.cfg, use a text editor to start
editing a new file, ansible.cfg. In that section, add a line which uses the inventory
directive to specify the ./inventory file as the default inventory.

AD HOC COMMANDS WITH ANSIBLE:

An ad-hoc command is a way of executing a single Ansible task quickly, one that you
do not need to save to run again later. They are simple, online operations that can be run
without writing a playbook. For example we want to ping our all target servers,

=> ansible all -m ping “result” this module always returns `pong' on successful contact.
=> ansible all --list-host “result” this module always returns all hosts information.
=> ansible all -m service -a “name=httpd state=started” To start httpd service on all hosts
=> ansible all -m service -a “name=httpd state=restarted” To restart httpd service on all
hosts
=> ansible all -m service -a “name=httpd state=stopped” To stop httpd service on all
hosts
=> ansible all -m setup To check all facts

ANSIBLE PLAYBOOK to copy file on managed host:

TASK 1: Write a playbook to copy file from control host to manage host destination
We can run playbooks in ansible with following commands,
 Ansible-playbook -C filename.yaml
 Ansible-playbook -syntax-check filename.yaml
 Ansible-playbook filename.yaml
---
- name: user prompt for asking run time information
hosts: servera
tasks:
- name: "task"
copy:
src: index.html
dest: /var/www/html
...

TASK 2: To ensure a specific single line of text exists in an existing file, use the lineinfile
module:
---
- name:"task handler"
hosts: servera
tasks:
- name: "task1"
lineinfile:
path: /etc/ssh/sshd_config
line: port 22
notify:
- restart service
handlers:
- name: restart service
service:
name: sshd
state: restarted
…