SS17838 Ansible Overview

Ansible Overview
Copyright © 2013 Tech Mahindra. All rights reserved.

Disclaimer
 The source for some of the images and material in this slide pack are Google,
http://docs.ansible.com, https://www.ansible.com/. This material is to be used
for Learning purpose only and for internal consumption
2 Copyright © 2013 Tech Mahindra. All rights reserved.

Objectives
 At the end of this module you will be able to understand:
 Introduction to Configuration Management
 Introduction to Ansible Tool
 Features and Requirements of Ansible
 Basic Terminologies used in Ansible
 Sample Use Cases in Ansible
 Ansible for Network Automation

Ansible Overview
Configuration Management

What is Configuration Management?
 Term applies to both Application/Software Engineers and System
Administrators
 System Administrators can:

 Discover
 Provision
 Perform configuration
 Deployment
 Maintenance
 Other repetitive tasks such as patch management
 Through Simple Codes
 Automation through use of tools ensures consistency, simplicity, uniformity

through one time efforts to write the codes to Configure & Manage
Infrastructure

Why Ansible?
 Example of a typical Use Case
 Need to Manage a User
 Specifically about :
 Existence
 Primary Group that he belongs to
 His Home Directory
 Actions may be to:

 Create/Modify a User profile
 Assign Primary Group and related Policies etc.

Why Ansible?
 Typical Script
 Ansible Way

Why Ansible?
 Simplicity
 Easy to understand and automate
 No specialized skills required
 Tasks are executed in order and no special training is required
 Intuitive
 Powerful
 Can handle infrastructure, network as well as services offered
 Can handle orchestration of the complete lifecycle of application and environment
setup
 Agentless and relies on industry standard communication using SSH

Configuration Management Tools
 Chef
 Puppet
 Ansible
 CFEngine
 Juju
 Rudder
 Salt
 Vagrant
 Bcfg2
 Smartfrof
 Palletops

What is Ansible?
 It is powerful IT automation Opensource Software for System Administrators
 Founded in Feb 2012 and released in 2012
 Supports Red Hat, CentOS, Ubuntu, MAC, Solaris …Support for Windows is
limited
 Ansible Controller Node is supported on Linux variants
 Ansible Inc. that commercially supported Ansible was acquired by Red Hat
 Ansible Tower is an Enterprise Product

Features of Ansible
 Ansible is open source, powerful automation software for configuring, managing

and deploying software applications on the nodes without downtime
 Ansible written in Python and easily extendible

 Python (2.6 or later) needs to be installed on the remote nodes to perform it’s
action.
 It can be used for Network Automation
 There are Five Key Aspects related to Ansible

 Control
 Managed Nodes
 Inventory
 Modules
 Tasks

Features of Ansible
 Ansible categorizes as follows:
 The controlling machine, where Ansible is installed
 Nodes are managed by the controlling machine over SSH.
 The location of nodes are specified by controlling machine through its inventory.
 Ansible is agent-less - No need of any agent installation on remote nodes, no

background daemons or programs are executed for Ansible
 Ansible is scalable and can easily handle few to 100’s of nodes from a single
system over SSH connection
 Multiple commands for a deployment, can be handled by building playbooks

in YAML format

Ansible Terminologies
 Control Node
 Machine where Ansible is installed
 Can run commands and playbooks invoking /usr/bin/ansible or /usr/bin/ansible-
playbook
 Controls Infrastructure & dictates Policies
 Operates repository for configuration data
 Initiates remote commands & ensures state of other machines
 Managed Node
 Network Devices (and/or servers) managed by Ansible
 Controller/master configures these agents/nodes
 Sometimes referred to as “hosts”
 Ansible is not installed on managed nodes

 Inventory
 List of things that you need to automate for e.g. Managed Nodes. Also called
“hostfile”
 Can be static file or dynamic one written to pull a list from external source
 May contain IP Addresses for each managed node
 Represents servers managed using .INI files
 Organizes managed nodes, as well as creating and nesting groups for easier
management
 Machines can be grouped as required
 Modules
 Units of code that ansible executes
 Each Module has a particular use
 There are almost 450 Ansible provided modules that can automate nearly every
part of the environment
 Standard Structure
 Module : directive1=value directive2=value
 For e.g.
 Administers specific type of database
 Manage VLAN interface on specific device
 Tasks
 You can execute a single task once with an ad-hoc command
 Simple small tasks that can be executed without logging in to client
 for e.g.: GetAlive status of server
 Playbooks
 Ordered list of tasks for repeated execution
 Can include variables as well as tasks
 Written in YAML
 Variables
 Allow you to alter how commands, etc. run
 Can be used in many different ways
• Playbooks
• Files
• Inventories (group_vars, host_vars)
• Command Line
• Discovered Variables (facts)
• Ansible Tower
Ansible Architecture
The Ansible Automation
engine consists of:
1. Inventories
2. API’s
3. Modules
4. Plugin
There are a few more

components in Ansible
Architecture
1. Networking
2. Hosts
3. Playbook
4. CMDB
5. Cloud

Ansible Architecture : contd.
 Modules
 Connects to nodes, pushes out “Ansible” modules, executes them over SSH and
removes them when finished
 Library of modules can reside on any machine
 Plugins:
 Pieces of code that Add to the core functionality

Ansible Architecture : contd.
 Inventories:
 Represents which machines it manages using a very simple INI file
 An inventory file looks like
[webservers]
www1.example.com
www2.example.com
[dbservers]
Db0.example.ccom
Db1.example.com
 After hosts are listed, variables can be assigned to them in simple text
files (in sub directory called group_vars or host_vars
 Dynamic inventory can be used to pull your inventory from data

sources such as EC2, Rackspace etc.

Ansible Architecture : contd
 Playbooks
 Orchestrate groups of infrastructure topology with detailed control
 This is where automation steps in
 Simple playbook
 ---
- hosts: webservers
serial: 5 # update 5 machines at a time
roles:
- common
- webapp
- hosts: content_servers
roles:
- common
- content

Ansible Architecture : contd
 APIs
 Ansible modules can be written in any language that returns JSON
 Inventory can plugin to any datasource by writing a program that speaks to the
datasource and returns JSON
 APIs can be written in python for extending Ansible connection types, callbacks
etc.

How Ansible works?
• Ansible works by configuring client

Host machines from a computer
with Ansible components installed
and configured in Ansible
Management node.
• It communicates over
SSH channels to retrieve
information from remote machines,
issue commands, and copy files etc
• Configuration files are in

the YAML data serialization format.
• Host Inventory contains the IP

addresses of all Hosts.
• Ansible can interact with clients

through either command line tools
Ansible has a default inventory file used to
define which servers it will be managing. or through its configuration scripts
Ex. /etc/ansible/hosts. called Playbooks.

Provisioning with Ansible
 Ansible is Push Based , in
few cases Pull based as
well.
 Ansible takes advantage

of a hosts inventory file.
It contains a list of
machine addresses
arranged by groups
 Here we have 2 groups:
database servers and web
servers. The inventory file
would simple list the IP
addresses and/or host
names for each one.

Orchestration with Ansible
 Complex Orchestration – Simple solutions

 Today’s IT brings complex deployments and complex challenges.
 Need to deal with clustered applications, multiple datacenters, public, private and
hybrid clouds and applications with complex dependencies.
 Here Ansible will help which can orchestrate complex tasks simply.
 Ex. Complex IT orchestrations example like OpenStack.

Configuration Management with Ansible
 Ansible is the simplest solution for

configuration management.
 Ansible configurations are simple

data descriptions of infrastructure
 With password or SSH key

Ansible can manage systems
without any agent software
installation

Continuous Delivery with Ansible
 Rolling updates and zero downtime
Ansible provides
 true multi-tier,
 multi-step orchestration.
 Fine grained control over operations
 Batchwise updates to servers while
working with load balancers, monitoring
systems etc.
 Call your Play
 Playbooks can be created as
per need
 Playbooks can
 select hosts, assign tasks
or roles
 Identify the order in which
playbooks/tasks are executed

Security and Compliance with Ansible
 Ansible allows you to simply define systems for security.
 Ansible’s Playbook syntax allows to define secure any part of our system,
 Like
• setting firewall rules,
• locking down users and groups,
• applying custom security policies

Automated Deployment with Ansible

Ansible deployment

Ansible Overview
Installation

Basics of Installation
 Enable ‘Extras’ and ‘Optional’ yum repos
 Ansible by default manages machines over SSH protocol
 It needs to be installed on only one machine (controller )
 It executes modules by running them on clients/managed nodes as required
 No running software/commands are left on the clients/managed nodes
 Any upgrade to Ansible needs to be run only on one machine
 Single controller can manage huge no of managed nodes remotely

Pre-requisites for installation
 Controller Machine
 Python 2.6 or above or Python 3.5 or above needs to be installed
 Any flavor of Unix such as Red Hat, Cent OS, Ubuntu etc.
 Windows is not supported on control machine
 Managed Nodes
 Python 2.6 or above or Python 3.5 or above needs to be installed
 Communication using ssh

Installation Procedure
 Installation on Control Machine using dnf or yum
 On RHEL or CentOS
 $ sudo yum install ansible
 RPMS for RHEL 7 are available in Ansible Engine repository
 To enable the Ansible Engine repository

 $ sudo subscription-manager repos --enable rhel-7-server-ansible-2.6-rpms
 To install from the source clone git ansible repository

 $ git clone https://github.com/ansible/ansible.git --recursive
 $ cd ./ansible
 Using Bash
 $ source ./hacking/env-setup

Ansible Overview
Network Automation

Ansible for Network Automation
 Network Modules do not run on managed nodes
 Network Devices cannot work with python while Ansible is designed using
python
 Network Modules execute on control node, where ansible or ansible-playbook

run
 Network Modules use control node to create Backup Files
 Can support multiple communication protocols as they run on control node
 Communication protocol XML over SSH or CLI over SSH depends on

platform or purpose of the module
 Communication Protocol is set with ansible_connection variable

Ansible for Network Automation
 Persistent Network connection is used over local from Ansible 2.6 onwards
 In case of persistent connection, host and credentials are defined only once
 Network Platform is considered as a set of network devices with common

operating system, managed by a collection of modules
 Modules for a specific network platform share a prefix, For e.g.

 Arista: eos_
 Cisco : ios_, iossxr_, nxos_
 Juniper : junos_
 VyOS: vyos_
 All modules with same network platform share certain requirements

Privilege Escalation
 Few network Platforms allow certain functions/commands to be executed by
a user with certain privileges
 for e.g. super user in unix (sudo)
 “enable” mode in network devices
 Ansible provides support for privilege escalation for network devices that
support it
 Ansible Parameter used for privilege escalation if network platform that

supports privilege escalation
 Become: yes with become_method: enable
 For network devices use

 Connnection: network_cli or connection: httpapi with become and
become_method as above

Privilege Escalation : contd.
 When using network_cli to connect ansible to network devices, a group_vars
file:
 Ansible_connection: network_cli
 Ansible_network_os: ios
 Ansible_become: yes
 Ansible_become_method: enable
 Earlier versions of ansible (2.5 or earlier), some network platforms support

privilege escalation but not network_cli or httpapi connections
 For this use case code will look like:
 Ansible_connection: local
 Ansible_network_os: eos
# provider settings
authorize: yes
auth_pass: “{{ secret_auth_pass”}}
port: 80
transport: eapi
use_ssl: no

Ansible Overview
Ansible Language & Getting Started

Ansible Language Basics
 Playbooks contain Plays, Plays contain tasks, Tasks call modules
 Tasks run Sequentially
 Handlers are triggered by tasks and are run once , at the end of plays
 Static Inventory for e.g.

---
[web]
web-1.example.com
Web-2 example.com
[db]
db-a.example.com
db-b.example.com

Advanced Playbook Capabilities
 Ansible has many different ways to alter how Playbooks run
 With_items, failed_when, changed_when, until etc.
 Refer to http://docs.ansible.com/ansible/playbooks_special_topics.html
 Ansible Roles are a special kind of playbook

 Fully self contained with tasks, variables, configuration templates as well as
supporting files
 Refer to http://docs.ansible.com/ansible/playbooks_roles.html
 Ansible Galaxy has been created to contain user created Ansible Roles

How to Use Ansible?
 You can directly automate by running the module from command line
 Adhoc: ansible <inventory>-m
 Run an Ansible Playbook from command line

 Playbooks:ansible-playbook
 Use Automation Framework provided by Ansible Tower

 It is an Enterprise product supported by Red Hat Linux.

Ad-Hoc Commands
 Two methods
 Directly run commands from command line
 Run module from the command line

 For e.g.

Running Playbooks
 Used in case of repetitive and complex tasks
 Playbooks are run against selected inventories from command line
 Each Task within playbook is run sequentially

Running Playbooks
 Output at the end after same playbook is run again

Additional Features/Utilities
 Check mode
 Allows you to check the execution of the tasks/playbooks before they are executed
in the actual environment
 Dry Run for the commands/playbooks
 Validates playbooks/commands before they are run on target systems
 There is no change in state of the machines after the command/playbook is
executed
 Ansible Tower
 Red hat Enterprise Product
 Offers ease and support to use of Ansible
 Easy Access and view to playbooks and state of the systems post execution
 Ansible Galaxy
 Contains many user defined and vendor provided roles
 Easy to Adapt/modify
 Easy to execute

Ansible Overview
Ansible Playbooks

Ansible playbooks
 Playbooks are sequence of tasks you want to execute on your devices
maintained in your inventory file in groups
 They are expressed in YAML
 Each playbook can have a play and each play can have one or more tasks

Playbook in Ansible

Ex of Playbook
 Tasks
Let's create a simple play which will check and install http packages on the
remote host. Here, this play will run the [task] named "Install Apache httpd"
on [all] hosts listed in the hosts inventory file.
---
## PLAYBOOK TO INSTALL AND CONFIGURE APACHE HTTP ON
CENTOS
- host: all
tasks:
- name: Install Apache httpd
yum: pkg=httpd state=installed

Run the playbook
 Run the playbook. you should see the following sample output as shown
below:
# ansible-playbook main.yml

Run Playbook

Who uses Ansible

Configuration management cycle

Prerequisite for Ansible
 Ansible Tower has the following setup requirements:
http://docs.ansible.com/ansible-
tower/2.2.2/html/installandreference/requirements_refguide.html
 Ansible installation information

http://docs.ansible.com/intro_installation.html
 Ansible Documentation
http://docs.ansible.com/
 Pre-requsite to start Ansible Learning –

 Linux platform.
 Configuration Management of Linux OS
 Basic Linux Adminstration
 Programming Knowledge to write modules.
 With Ansible, basic YAML knowledge

Summary
 You can now understand:
 Need for Configuration Management
 Ansible Tool Architecture
 Features and Requirements for Ansible
 Basic Terminologies used in Ansible
 Sample Use Cases in Ansible


Ansible Commands


SS17838 Ansible Overview

Uploaded by

Copyright:

Available Formats

SS17838 Ansible Overview

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SS17838 Ansible Overview

Uploaded by

Copyright:

Available Formats

Ansible Overview

Copyright © 2013 Tech Mahindra. All rights reserved.

2 Copyright © 2013 Tech Mahindra. All rights reserved.

3 Copyright © 2013 Tech Mahindra. All rights reserved.

Copyright © 2013 Tech Mahindra. All rights reserved.

 System Administrators can:

 Automation through use of tools ensures consistency, simplicity, uniformity

5 Copyright © 2013 Tech Mahindra. All rights reserved.

 Actions may be to:

6 Copyright © 2013 Tech Mahindra. All rights reserved.

7 Copyright © 2013 Tech Mahindra. All rights reserved.

8 Copyright © 2013 Tech Mahindra. All rights reserved.

9 Copyright © 2013 Tech Mahindra. All rights reserved.

 Founded in Feb 2012 and released in 2012

 Ansible Controller Node is supported on Linux variants

 Ansible Tower is an Enterprise Product

10 Copyright © 2013 Tech Mahindra. All rights reserved.

 Ansible is open source, powerful automation software for configuring, managing

 Ansible written in Python and easily extendible

 It can be used for Network Automation

 There are Five Key Aspects related to Ansible

11 Copyright © 2013 Tech Mahindra. All rights reserved.

 Ansible is agent-less - No need of any agent installation on remote nodes, no

 Multiple commands for a deployment, can be handled by building playbooks

12 Copyright © 2013 Tech Mahindra. All rights reserved.

13 Copyright © 2013 Tech Mahindra. All rights reserved.

There are a few more

16 Copyright © 2013 Tech Mahindra. All rights reserved.

17 Copyright © 2013 Tech Mahindra. All rights reserved.

 Dynamic inventory can be used to pull your inventory from data

18 Copyright © 2013 Tech Mahindra. All rights reserved.

19 Copyright © 2013 Tech Mahindra. All rights reserved.

20 Copyright © 2013 Tech Mahindra. All rights reserved.

• Ansible works by configuring client

• Configuration files are in

• Host Inventory contains the IP

• Ansible can interact with clients

21 Copyright © 2013 Tech Mahindra. All rights reserved.

 Ansible takes advantage

22 Copyright © 2013 Tech Mahindra. All rights reserved.

 Complex Orchestration – Simple solutions

 Ex. Complex IT orchestrations example like OpenStack.

23 Copyright © 2013 Tech Mahindra. All rights reserved.

 Ansible is the simplest solution for

 Ansible configurations are simple

 With password or SSH key

24 Copyright © 2013 Tech Mahindra. All rights reserved.

25 Copyright © 2013 Tech Mahindra. All rights reserved.

26 Copyright © 2013 Tech Mahindra. All rights reserved.

27 Copyright © 2013 Tech Mahindra. All rights reserved.

28 Copyright © 2013 Tech Mahindra. All rights reserved.

Copyright © 2013 Tech Mahindra. All rights reserved.

 Ansible by default manages machines over SSH protocol

 It needs to be installed on only one machine (controller )

 It executes modules by running them on clients/managed nodes as required

 No running software/commands are left on the clients/managed nodes

 Any upgrade to Ansible needs to be run only on one machine

 Single controller can manage huge no of managed nodes remotely

30 Copyright © 2013 Tech Mahindra. All rights reserved.

31 Copyright © 2013 Tech Mahindra. All rights reserved.