14.md

+++ date = "2015-09-30" draft = false weight = 14 title = "Lab 14 - Ansible" +++

Lab Objective

The objective of this lab is to introduce you to the basics of ansible. You will learn the syntax and mechanisms for one-off commands, inventories to reach multiple hosts, and playbooks to accomplish complex and multi-part tasks.

An appropriate ssh environment amiable to ansible has been setup for you inside this lab environment. This is usually a non-trivial amount of work which involves setting up passwordless sudoers and distributing public keys.

The final portion of this lab will focus on using ansible to fix a specific OpenStack configuration issue.

1. Basic Ansible Commands

0. SSH to your controller and log in as root

1. De-elevate your privileges to the normal user centos

   [root@controller ~]# su centos

2. Ensure ansible is installed

   [centos@controller ~]$ sudo yum install ansible

   [centos@controller ~]$ ansible -h | less

   

   It's always useful to check out the help file. Take a second and look for some key words which should be familiar from the lecture.

3. Create a simple hosts file with the following content:

   192.168.0.10
   

4. Use the ping ansible module to test connectivity to the controller

   [centos@controller ~]$ ansible all -i hosts -m ping

   Refer back to the help command and read what each of these flags represent.

5. Gather Facts about controller with ansible

   [centos@controller ~]$ ansible all -i hosts -m setup | less

   Skim through these facts and look for interesting values. How many processor cores does this node have? Which Linux kernel? Which release of CentOS is it running? All of these variables are available to your playbooks, these can be very useful for eliminating many repetitive information gathering tasks in your environments!

6. Add our other openstack nodes to the hosts file:

   [openstack]
   controller ansible_ssh_host=192.168.0.10
   neutron    ansible_ssh_host=192.168.0.11
   compute1   ansible_ssh_host=192.168.0.12
   compute2   ansible_ssh_host=192.168.0.13
   

7. Ping all your hosts

   [centos@controller ~]$ ansible all -i hosts -m ping

   

8. Try different host-patterns and modules

   [centos@controller ~]$ ansible openstack -i hosts -m command -a 'hostname'

   [centos@controller ~]$ ansible controller -i hosts -m command -a 'whoami'

   [centos@controller ~]$ ansible openstack -i hosts -m command -a '/usr/sbin/ip addr'

9. Red ink - this command will fail

   [centos@controller ~]$ ansible openstack -i hosts -m yum -a 'name=htop state=installed'

   Read the help in order to find the argument to run this command with sudo, turn this red ink to green

10. Gather some information about our compute nodes

    [centos@controller ~]$ ansible compute1 -i hosts -m setup | grep vcpus

    [centos@controller ~]$ ansible compute2 -i hosts -m setup | grep vcpus

At this point you now know how to run ansible one-off commands. These can be very useful for making changes and gathering information from your systems quickly and efficiently from a central location. Next we will use an ansible playbook to accomplish an ordered list of tasks.

2. Ansible Playbooks

Ansible playbooks are an efficient way to organize a list of ordered tasks. These tasks are grouped into a play which specify which hosts will be configured. In this section we will make a simple playbook that installs a new program to our controller.

0. Download the sl.yml playbook, inspect it, and run it

   [centos@controller ~]$ curl https://alta3.com/labs/files/sl.yml

   [centos@controller ~]$ curl https://alta3.com/labs/files/sl.yml > sl.yml

   [centos@controller ~]$ less sl.yml

   [centos@controller ~]$ ansible-playbook -i hosts sl.yml

   Note that we did not need to enumerate the host-pattern in this command! My fingers feel less tired already!

   

1. Run it again and see how the PLAY RECAP is different

   [centos@controller ~]$ ansible-playbook -i hosts sl.yml

2. Use the new application (don't forget to read the man page!)

   [centos@controller ~]$ sl

   [centos@controller ~]$ man sl

3. Fix Nova VNC Service

First we will see what is broken. There is a configuration issue with Nova VNC Proxy service. This service allows a user to view and interact with an instance console from the web browser, a super useful feature! In order to configure this service correctly the controller and the compute nodes need to know the external ip address of the controller in order to correctly direct the browser to the vnc proxy resource. Because your lab environment was stood up just for you, your external ip address is not predictable. As a result this service is incorrectly configured and pointing to an incorrect public ip address.

In this section we will read and run a playbook that fixes this issue.

0. Clone the ansible-novnc repository

   [centos@controller ~]$ git clone https://github.com/bryfry/ansible-novnc.git

   [centos@controller ~]$ cd ansible-novnc

1. Read the novnc.yml and confguration template file

   [centos@controller ansible-novnc]$ less novnc.yml

   [centos@controller ansible-novnc]$ less files/nova-controller.conf.j2

   [centos@controller ansible-novnc]$ less files/nova-compute.conf.j2

2. We actually care about the vnc related parameters, let's filter on that

   [centos@controller ansible-novnc]$ grep vnc files/nova-controller.conf.j2

   [centos@controller ansible-novnc]$ grep vnc files/nova-compute.conf.j2

3. Run the novnc.yml playbook

   [centos@controller ~]$ ansible-playbook -i hosts novnc.yml

4. Match up each PLAY and TASK with the corresponding portion of the playbook below

   

5. Let's go use the vnc service! Open the OpenStack Horizon interface

6. Launch an instance or navigate to a launched instance

7. Click the console tab

8. Open the console in a separate window

   

9. Accept the privacy exception, we're using a self signed certificate

10. View and interact with the console

    

11. Refresh the page the console tab page, it should also work now

    

This is only a very small subset of the use cases for ansible. Like any tool you can customize and utilize it to fit your environments needs. Especially reccomended is to use ansible in combination with a revision control system (like git). This allows for a succinct and manageable orchestration of your environments throughout time. The sky is definitely the limit!

Next Lab