Ansible and Vagrant. DevOps acronym decoded

[Pic0o]

Let me start by saying Ive lived the System Admin life for quite some time. The decoding title is in reference to:

Installing, deploying, configuring, and monitoring servers in a rapid deployment manner.

Most important of all, in a non-static and non-fragile manner. TL;DR security - Running services across multiple servers, that can be shut down in the event of intrustion or broken configuration and replaced with a new image with all the required configuration, out the gate on your reployment.

You will be communicating and deploying over SSH sessions, so encrypted communcations are how you 'make the magic happen'.

 

Here are some notes I took from a great presentation by Chris Rossi of AppliedTrust, that also got me running my own deployments. I am also working from the following book: Absible for DevOps by Jeff Geerling.

 

As this is a technical and video game heavy site, Im sure many visitors and members know the struggle of single-thread processes not scaling your gaming hardware. By deploying your server topology with Ansible (Python based) and Vagrant (Ruby syntax) scripting, you get a performance scalable topology, where services can be allocated per Virtual Machine; while also being able to be replaced by a fresh spun VM, in the event of misconfiguration change or security exploit. You also get some botnet-like controls to distribute commands across all or selected servers in your Vagrant configuration.

 

Personally, I have been learning Python to make tools to assist me in log crawling functions, configuration and other data driven projects. I legit feel like Ansible and Vagrant usage has progressed me beyond making bash script, as the state control / config deployment and validation is light-years beyond cobbling my own scripts from scratch. I have been exploring this for less than a week, so please excuse the details thus far. However I will say this knowledge is really addictive, since I am seeing my personal projects materialized in a deliverable, community cooperative platform of Ansible using Vagrant.

 

Borrowing from Chris's presentation, patch deployment and distributing content is the final leg / deliverable of the DevOps process. Considering I am used to living a Windows SysAdmin life with the use of windows cmd and Linux scripting, this point resonates as solid truth in the compliance being the hardest deliverable, while being consistent. Did I mention scaling your network and sever topology? Because that is what you are up to with deploying dynamic servers in a VM environment. Get the most performance per service to VM, with added benefit of essentially real-time monitoring. In the event of a fault, you can also handle the decommission and re-launching of a new, compliant VM in the event of mis-config change / exploit.

[Pic0o]

Relating to performance scaling and security agility response, the topology is ‘Anti-fragle’. Also speaking to the Windows SysAdmin life, this means ‘Not having all your services on one box, that is almost impossible to reproduce on the fly… in the event of a failure or production down’. I don’t nmap much but when I do, seeing a machine running a dozen+ critical services is going to be a bad time. I’m sure many can reflect on terrible ideas, like having an importaint SQL database on a public facing web server. So spin up some secure, scalable servers, that you can count on in a Disaster Recovery level restoration with the speed you need to get things back online ASAP.

 

Circling back to botnet-like controls, say you want to have certain or all machine excute a command, say something like install updates or restart a service. Target your machine(s) by their hosts entry (in the Vagrant file) and have your VM (VirtualBox in my current case) happily accept your commands and return the status of your shell code or the like.

 

So, how do I get something running with Vagrant, Ansible and VirtualBox?

Rundown list:

• YAML is a ‘data serialization’ language used in Vagrantfile scripting. That meaning it is incredibly rational to read and write your configurations.
• Vagrant is a scripting language for configuring and installing your VMs (VirtualBox in my case). This will grab an base image from the internet on 1st run, then work from the local image template. Think of this as the ‘Site Configuration’ for your VM environment. Your configuration file (Vagrantfile) is writen using Ruby-based syntax.

  In my recent deployment test, I was able to launch 3 servers in about 32 lines, of incredibly logical flow-control code. You will add a call to the end of the Vagrantfile to refernce your Ansible .yml configuration file.

• Ansible is is akin to a ‘configuration change & service control’ for your VMs to be deployed. This utilizes YAML for your scripting. Instead of a sloppy bash script that may fail if run more than once (Idempotence is a fancy term for this), you can manage and initialize services state and config changes, with incredibly robust controls and response states. Using your .yml file you can target all or certain hosts as deployed by your Vagrantfile VM hosts named installs.

[Pic0o]

These tools are a step by step Yes to every tool I have been documenting a desire to make. All inherently task driven, service management, configuration + software deployment, and fault-tolerant out the gate. As I mentioned, this makes me feel years beyond, the manual tools I have been scribing into my notebooks.

 

Ending this write up, I will quote some code from Ansible for DevOps, in effort to visualize the post in real-world application.

 

Step 00 - Install your tools. As above detailed we are using:

• Ansible
• Vagrant
• VirtualBox

(Please note these are examples) There are several ways to skin a cat, as people say. I am running OS X to deploy these VMs but we have no need to fight over religious operating system choices. :p

 

Step 01 - On OS X, you will want to install Brew and Python, presuming you have not so before starting with Ansible. (varies on your main OS choice). Then the 3 items from Step 00.

 

Step 02 - Use Vagrant to add a VM. (borrowed from book)

vagrant box add ‘pathto/LinuxVM_YouWantToInstall’

Be sure to make a new folder for this, as you will want to edit the Vagrantfile that is created. You can also make a Vagrantfile from scratch, as quoted below.

 

Step 03 - Hold on, what now? We are going to modify a Vagrantfile to call an Ansible script .yml that will launch services on said VMs.

# -*- mode: ruby -*-
# vi: set ft=ruby :

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.ssh.insert_key = false
  config.vm.provider :virtualbox do |vb|
    vb.customize ["modifyvm", :id, "--memory", "256"]
  end

  # Application server 1.
  config.vm.define "app1" do |app|
    app.vm.hostname = "orc-app1.dev"
    app.vm.box = "geerlingguy/centos7"
    app.vm.network :private_network, ip: "192.168.60.4"
  end

  # Application server 2.
  config.vm.define "app2" do |app|
    app.vm.hostname = "orc-app2.dev"
    app.vm.box = "geerlingguy/centos7"
    app.vm.network :private_network, ip: "192.168.60.5"
  end

  # Database Server.
  config.vm.define "db" do |db|
    db.vm.hostname = "orc-db.dev"
    db.vm.box = "geerlingguy/centos7"
    db.vm.network :private_network, ip: "192.168.60.6"
  end
end

[Pic0o]

Step 04 - Launch these servers. To do so, run this in your terminal:

vagrant up

Running this a second time, I got the following output (remeber that slick checking to avoid breaking already deployed items).

$ vagrant up

Bringing machine 'app1' up with 'virtualbox' provider...

Bringing machine 'app2' up with 'virtualbox' provider...

Bringing machine 'db' up with 'virtualbox' provider...

==> app1: Checking if box 'geerlingguy/centos7' is up to date...

==> app1: VirtualBox VM is already running.

==> app2: Checking if box 'geerlingguy/centos7' is up to date...

==> app2: VirtualBox VM is already running.

==> db: Checking if box 'geerlingguy/centos7' is up to date...

==> db: VirtualBox VM is already running.

Step 05 - Ansible to configure these 3 VMs. So add them to a hosts (inventory file). Find this @ /etc/ansible/hosts and modify accordingly to work with the above Vagrant example.

# this is your hosts file for ansible
# remote PC dev test
[example]
192.168.138.36

# Application servers
[app] # grouping name
192.168.60.4
192.168.60.5

# Database server
[db]
192.168.60.6

# Group 'multi' for all server call
[multi:children]
app
db

# set up your ssh on all 3 servers
[multi:vars]
ansible_ssh_user=vagrant
ansible_ssh_private_key_file=~/.vagrant.d/insecure_private_key
# NOTE this sequence will vary on your SSH deployment method. Example from Jeff Greeling's book.

Step 06 - Get hostnames from your VMs via ansible.

In a terminal window, type:

ansible multi -a “hostname”

I got an error of

[WARNING]: provided hosts list is empty, only localhost is available

.

To resolve this on my OS X install and define the environment variable, I typed:

export ANSIBLE_HOSTS=/etc/ansible/hosts

Step 07 - Enjoy your output.

192.168.60.6 | SUCCESS | rc=0 >>

orc-db.dev

 

192.168.60.4 | SUCCESS | rc=0 >>

orc-app1.dev

 

192.168.60.5 | SUCCESS | rc=0 >>

orc-app2.dev

Radical, we are done with this guide. So far we spawned 3 VMs and had them deploy SSH for processing commands, then give us a result showing their active host name. Your imagination is the limit but now you have a starting point. Enjoy and thanks for reading!

Edited May 8, 2016 by Pic0o

[Pic0o]

Wait a minute... I said something about a playbook.

 

Indeed. Make a new file called playbook.yml or the like. Syntax as below, because at some point you will want to run more than one command on multiple machines.

Keying off the above example - Remember this is in YAML:

---
- hosts: multi
  become: no
  tasks:
  - name: Show me the hostnames because I am not typing the cmd every time.
    command: hostname

To call this after having saved the file, type into a shell prompt:

ansible-playbook playbook.yml

Results as follows:

$ ansible-playbook playbook.yml

PLAY [multi] *******************************************************************

TASK [setup] *******************************************************************
ok: [192.168.60.4]
ok: [192.168.60.5]
ok: [192.168.60.6]

TASK [Show me the hostnames because I am not typing the cmd every time.] *******
changed: [192.168.60.5]
changed: [192.168.60.4]
changed: [192.168.60.6]

PLAY RECAP *********************************************************************
192.168.60.4               : ok=2    changed=1    unreachable=0    failed=0   
192.168.60.5               : ok=2    changed=1    unreachable=0    failed=0   
192.168.60.6               : ok=2    changed=1    unreachable=0    failed=0   

Please notice the output of the command does not output, however you notice it did execute properly. Chain some admin functions into your playbook and go from there. Perhaps you want to export the result to a fileserver share. Back to work for me. :bunny:

 

To stop your VMs, type:

vagrant halt

[JeT]

This is a nice handy combination I've seen in a lot of educational seminars, workshops, etc. as well.

 

Had a conference in LV back in Nov where this enabled everyone to quickly be on the same page to begin coding and executing examples without spending some 1hr pre-workshop getting people's environments all settled up.

 

The Couchbase team also did a vagrant, VB combo during their 1 day workshop I attended when they hosted in Philly few months back.

 

Also been looking at the popular rise of Docker over VMs like virtualbox, etc. It's more a container that can translate to your current OS, vs an entire VM where you need to be concerned with driver compatibilities and blah blah. This also makes for a speedier and more lightweight package. Can be pros and cons, like with anything, though.

 

Some infos: http://devops.com/2014/11/24/docker-vs-vms/