Skip to content

Latest commit

 

History

History
227 lines (127 loc) · 9.36 KB

14.md

File metadata and controls

227 lines (127 loc) · 9.36 KB
Raw
date draft weight title
2016-05-09
false
14
Lab 14 - Ansible
Mon Mon Mon Mon Tue Tue Tue Tue Wed Wed Wed Thur Thur Thur Thur
00 01 02 03 04 05 06 07 08 09 10 11 12 13 alt text

Lab Duration: 40 minutes

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.

Ansible documentation is found here: http://devdocs.io/ansible/

1. Basic Ansible Commands

  1. SSH into the root user on your controller

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

    [root@controller ~]# su centos

    [centos@controller ~]# cd

  3. Ensure ansible is installed. Warning, the first RedHat mirror is down and the system S-L-O-W-L-Y advances to the next mirror. control-c will immediately advance you to the next mirror. We will use ansible to fix this!

    [centos@controller ~]$ sudo yum install ansible

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

    If the above hangs: control-c will advance you to the next mirror and let it run!
    When the install is complete, enter the lower case "y" to say yes to the install

    ansible help

    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.

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

    [centos@controller ~]$ vim hosts

    Enter: i lower case i to enter INSERT mode.

    Enter this content:

    192.168.0.10

    Enter: Escape : wq

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

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

    192.168.0.10 | success >> {                                                                                    |
    "changed": false,                                                                                          |
    "ping": "pong"                                                                                             |
}

    The above text will be GREEN.
    Refer back to the help command and read what each of these flags represent.

  6. 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!

  7. Now lets replace what is in our hosts file with the following content. Type the following command:

    [centos@controller ~]$ vim hosts

    Enter: i lower case i to enter INSERT mode.

    Enter this content:

    [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

    Enter: Escape : wq

  8. Confirm that you did NOT forget to make [openstack] the fist entry in your hosts file!

    cat hosts

  9. Ping all your hosts

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

    The "all" pattern targets all hosts in the inventory -i specifies a certian inventory file (a listing of hosts) "hosts" is the traditional inventory filename. -m specifies a certian module, in this case "ping"

    ping!

  10. 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'

    Read about modules [HERE] (http://docs.ansible.com/ansible/list_of_all_modules.html) Check out the custom Open Stack modules while you are at this link!

  11. Red ink - this command will fail

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

    NOTE: This step may take a moment to complete.
    In the playbook we will implement later in this lab, take notice how we turn this red ink to green.

  12. 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.

  1. 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!

    install sl

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

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

  3. 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.

  1. Clone the ansible-novnc repository

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

    [centos@controller ~]$ cd ansible-novnc

  2. 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

  3. 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

  4. Run the novnc.yml playbook

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

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

    novnc playbook

    playbook output

  6. Let's go use the vnc service! Open the OpenStack Horizon interface (log in as admin / alta3)

  7. Launch an instance or navigate to a launched instance

  8. Click the console tab

  9. Open the console in a separate window

    console link

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

  11. View and interact with the console

    console view

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

    instance view

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