Speedy Deployments And The Meaning Of Devops

Okay, so here's the project on my mind.  Create and provision a local Fumblina server.  Deploy a simple web app to it.  Time the setup process.  Why?  Because Devops!

The key tools in use are as such...

1. 64-bit Linux Mint
2. Virtual Box 4.3 
3. Ansible 1.5
4. Vagrant 1.7
5. Git 1.9

Technically, this whole arrangement works just as well with a standard Ubuntu desktop distro with Virtualbox 5.  But whatever!  We hit the stopwatch start button and off we go.

The Server Setup

We need a local server.  There's a project called "basemachine" on my Github that would help.  So that gets git cloned over and started up like this...

cote@mymachine ~/PycharmProjects $ git clone https://github.com/pcote/basemachine.git

Cloning into 'basemachine'...

remote: Counting objects: 14, done.

remote: Compressing objects: 100% (3/3), done.

remote: Total 14 (delta 0), reused 0 (delta 0), pack-reused 11

Unpacking objects: 100% (14/14), done.

Checking connectivity... done.

cote@mymachine ~/PycharmProjects $ cd basemachine/

cote@mymachine ~/PycharmProjects/basemachine $ vagrant up

Conveniently, there is a Vagrant box image installed locally so that saves us some time.  But still, it is going to take a few minutes to make and provision this server.  On to other things while this job bakes.

A Skeleton Web Application

While we're busy provisioning, there's a generic web application skeleton in Github to get.  We're also going to need the contents copied into an actual project folder called "DomEditor".  Here it goes!

cote@mymachine ~/PycharmProjects $ git clone https://github.com/pcote/appskeleton.git
Cloning into 'appskeleton'...
remote: Counting objects: 38, done.
remote: Compressing objects: 100% (24/24), done.
remote: Total 38 (delta 6), reused 36 (delta 4), pack-reused 0
Unpacking objects: 100% (38/38), done.
Checking connectivity... done.
cote@mymachine ~/PycharmProjects $ cd appskeleton/
cote@mymachine ~/PycharmProjects/appskeleton $ cp -R * ../DomEditor/
cote@mymachine ~/PycharmProjects/appskeleton $ cd ../DomEditor/
cote@mymachine ~/PycharmProjects/DomEditor $

We switch over to that and get app-specific things setup.  There's a folder in the Ansible role that needs renaming by the way.  It needs to match the name we gave this app.

cotejrp@mymachine ~/PycharmProjects/DomEditor/roles $ mv myapp domeditor

Very good.  So now, we deal with configuration with the deployvarsdev.json file.  

{

    "hostname": "all",

    "domain":"domeditor.com",

    "appname":"domeditor",

    "mysql_root_password":"rootPassword",

    "proxyport":3032

}

Careful for that mysql_root_password by the way.  That variable has to be the same here as it is in basemachine's Vagrantfile.  Yes, the setup is stupid and the root password should be established in one place rather than two.  For the time being, we just accept that the value must match lest the Ansible playbook barf on you later.

Oh yeah.... The /etc/hosts file needs a domain name alias to localhost.  That's going to have to match the domain variable set in our json file.  So this line goes into hosts....

127.0.0.1       domeditor.com

Time to check on the base machine provisioning.  Ding!  It's done.  Time to move forward with application deployment.

Application Deployment

Deployment needs one more thing.  Time to open up provisiondev.sh for a little editing...  

#!/bin/sh

basemachine=/path/to/base/machine

inventory=$basemachine/.vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory

privatekey=$basemachine/.vagrant/machines/default/virtualbox/private_key

ansible-playbook -u vagrant -i $inventory --private-key=$privatekey --extra-vars="@deployvarsdev.json" playbook.yml

See that basemachine variable near the top?  We replace that with the path to wherever we git cloned the basemachine folder to in the first place.  Something like this does the trick nicely.

basemachine=$HOME/PycharmProjects/basemachine/

And there's that.  Time to run this deployment script....

cote@mymachine ~/PycharmProjects/DomEditor $ ./provisiondev.sh 

A couple seconds pass.  Script completes.  Open up this url in a browser...

http://domeditor.com:8080/

And once we see the message "This is an angularjs stub page." in the browser, we know we're done.

Total Time Elapsed: 4 minutes 39 seconds.

Could it be faster?  Maybe.  One of these days, I'll have to figure that one out.

Digression: What Does Devops Mean Anyways?

A conversation with a friend raised the question of exactly how one defines the term "devops".  It depends on who you ask.  I can think of it in terms of management reality, my reality, and wishful thinking.

For a manager, it's about improvement in team dynamics.  Developers are paid to change I.T. systems.  Operations people are paid to keep everything stable.  These job definitions naturally put these two camps at odds.  The idea of devops in this context is to get developers and ops people on the same page to reduce the conflict.

For a solo act like myself, devops is about self-reliance.  There are no operations people in my world.  Naturally, it is my responsibility to set up, modify, and maintain those servers myself.  Devops tools like Ansible and Vagrant just happen to make that business easier for me.

Lastly, there is the wishful thinking vision of devops.  It's that dream of sitting down in a quiet environment to work.  You check out the project from the local Git server.  You do a "vagrant up".  Bang!  There's a virtual version of the same server as what ops is managing in production.  That's what you get to develop against.  It sure would make change change control discussions easier.  One can dream.