Introduction to Ansible

This tutorial is adapted from the Web Age course Ansible Configuration and Administration.

1.1 Control and Managed Nodes

Control Node – It is a system where Ansible is installed. It is used to execute ansible commands.  One control node can configure many managed nodes.

Managed Node-  It is one of the systems being configured by Ansible. It must be accessible via SSH (secure shell).

1.2 Preparing the Control Node

  • Install Ansible
  • Create an Ansible project directory:

mkdir ansible-control

cd ansible-control

  • Create setup files in directory:

cfg – Ansible Configuration

ini – Holds inventory (list of managed nodes)

  • Ansible commands can now be run from the project directory

1.3 Installing Ansible

  • Ansible runs under Linux/Mac OS
  • Typical installation Instructions (for Ubuntu):

sudo apt update

sudo apt install software-properties-common

sudo add-apt-repository --yes --update ppa:ansible/ansible

sudo apt install ansible

  • Ansible can also be installed with Python’s “pip” utility:

pip3 install ansible

  • Verifying installation:

ansible –version

For more installation information/options see the official documenation here: https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html

 

1.4 Ansible on Windows

On Windows Ansible can be installed:

  • Under CygWin
  • Under the Windows Subsystem for Linux (WSSL)

1.5 ansible.cfg

  • Ansible is configured in the following file which contains many commented out example settings with descriptions of their use:

\etc\ansible\ansible.cfg

  • Placing an ansible.cfg file in the root of your Ansible project allows you to override existing configuration settings

~\ansible-project\ansible.cfg

  • This common setting allows Ansible to get its inventory list from the named file:

[defaults]

inventory = hosts.ini

1.6 hosts.ini

  • Hosts.ini (or just hosts) is a file that Ansible looks at to get a list of the hosts you are planning to manage.
  • A global version of the hosts file exists at the following location:

\etc\ansible\hosts

  • A project-local version of the file, that lists just the hows being managed by the project, is often created in the project root directory.

~\ansible-project\hosts.ini

  • The ansible.cfg is then configured to point Ansible at the local version:

[defaults]

inventory = hosts.ini

1.7 Preparing Managed Nodes

  • The purpose behind Ansible is to connect to and configure servers(hosts) remotely. To do this it needs to be able to connect to the remote server via ssh (secure shell).
  • For each managed node:
    • Test for SSH access to the Managed Node from the Control Node

ssh user-name@{managed-node-id}

(verifies user/password access)

ssh {managed-node-id}

(verifies public/private key access)

  • If needed – copy the control node’s public key to the managed node

 

1.8 Creating Control Node Public/Private Key

  • Ansible uses SSH (secure shell) to access and manage hosts.
  • SSH requires the Ansible control node (the machine where ansible commands will be run) to have a key-pair. The public key of the pair will need to be copied to the host you need to ssh into.
  • The following command is executed to create the key-pair:

ssh-keygen -t rsa

  • The command saves key files into the ~/.ssh directory:

is_rsa   - the private key

Id_rsa.pub   - the public key

 

1.9 Copying Control Node Public Key to Managed Node

  • The public key is copied into the remote host (the one you want to ssh into) using a command like this:

ssh-copy-id vagrant@192.168.60.4

  • During the copy, you will be prompted to provide the password for the user on the remote machine.
  • Once this is done you will be able to:
    • SSH into the remote machine (i.e. ssh vagrant@192.168.60.4 )
    • Use Ansible to connect to and configure the remote machine

 

1.10 The “ansible” Command

  • The ansible command is used to execute ad-hoc commands

ansible [pattern] -m [module] -a "[module options]"

  • Given this as the hosts.ini file:

192.168.60.3

[app]

192.168.60.4

192.168.60.5

  • [pattern] could be

192.168.60.4 – individual host

all – all hosts in the file

app – just the hosts under the ‘app’ group

 

1.11 Other Ad-Hoc Commands

  • Ping the Managed Nodes:

ansible app -m ping -u vagrant

  • Check Memory:

ansible multi -a "free -m"

  • Get Server Details

ansible db -m setup

1.12 Modules and Options

  • The ‘ansible’ command takes as parameters a module and options related to that module
  • When no module is specified it defaults to the ‘command’ module, so the following are equivalent:

ansible all -a "hostname"

ansible all -m command -a "hostname"

  • The -a options for the command module specify the command you wish to execute.

ansible all -a "date" - Executes the 'date' cmd

ansible all -a "pwd"  - Executes the 'pwd' cmd

  • A list of Ansible modules can be found here:

https://docs.ansible.com/ansible/2.9/modules/list_of_all_modules.html

1.13 Modules

  • Ansible modules are used in playbooks and ad-hoc commands.
  • Some module examples include:
    • ping – pings the host
    • yum, apt – install packages via yum or apt
    • user – create and manage users
    • service – start/stop services on a managed node(s)
    • copy – copy files to/from host
    • setup – get host variables/settings
  • For more on how modules work see:

https://docs.ansible.com/ansible/latest/user_guide/modules_intro.html

1.14 Playbooks

Playbooks group the tasks required to install and configure applications into a single executable script.

  • Example:

# playbook01.yml

- hosts: web

  become: 'yes'

  tasks:

    - name: Update the package cache

      apt:

        update_cache: true

    - name: Install the nginx package

      apt:

        name: nginx

        state: present

 

  • The playbook is executed with the ansible-playbook command:

ansible-playbook playbook01.yml

Summary

In this tutorial,  we covered:

  • Control and Managed Nodes
  • Preparing the Control Node
  • Installing Ansible
  • cfg
  • ini
  • Preparing Managed Nodes
  • Public/Private Key Access
  • Ad-Hoc commands
  • Modules
  • Playbooks

Leave a Reply

Your email address will not be published. Required fields are marked *