Big thanks to Aaron Delp (@aarondelp) and Brian Gracely (@bgracely) for inviting me to be a guest on The Cloudcast episode #149. We discussed my time at Cloud Foundry Summit and what it means to enterprises out there. If you are bored with virtualization, you should listen and maybe start seeing the light... i know i did.
A Summary from the show (taken from thecloudcast.net)
Cloud Foundry Summit 2014 - A Review and Perspective
I've lived in a world of VMs for the past few years and since I started learning Ruby on Rails last year, I've seen a whole new light. You hear all the time that software is eating the world but it's starting to really settle in for me. This is where PaaS and Docker start to shine. As applications become less monolithic, the need for VMs diminish. PaaS and Docker are a new frontier.
To put it in perspective, check out this slide below from the opening keynote. Software is disrupting every industry and one of the things that Andrew Clay Shafer (@littleidea) said at the end of his final keynote on Wednesday was "If you aren't creating a software company, then someone else is...and you will lose".
NOTE: This final part has not been 100% verified. The deployment of this Cloud Foundry manifest requires the following infrastructure: 72 vCPUs, 200GB of RAM, and 1 TB of storage. Of course, my home lab doesn't support this so I kept getting timeout errors during the deployment. My problem is that my vCenter server can't keep up with the deployment speed. My vCenter Server Virtual Appliance is only configured with 8GB of RAM but it needs something much beefier to be able to handle the amount of requests. I believe this is the case because my vSphere Web Client would lose connection for a few minutes and when the deployment stopped, the Web Client started responding again. If you do test out this manifest below, please confirm it by mentioning it in the comments below. I will hope to test this in a real lab environment soon.
From Zero to Cloud Foundry on vSphere: Part 1 - How to install MicroBOSH
It seems that the teams over at Cloud Foundry give us too much credit. I spent days trying to get Cloud Foundry up and running because of minor snags and glitches. In addition, the documentation to make this all work doesn't exist in a single place, it's all outdated, or isn't descriptive enough. Hopefully this spoon feeding series tutorial will help get you there.
This tutorial will go over the steps it takes to deploy Cloud Foundry on vSphere. Here are the proper steps:
Over the past week, I started learning Chef. There are a few different configuration management toolsets out there such as Puppet, SaltStack, and Ansible. But Puppet and Chef have majority amount of market share and use Ruby as its code base so it made sense for me to start there. There's no point in starting a project unless you have a goal to accomplish so after I read more about Chef cookbooks, recipes, attributes, etc it seemed like making a JumpSquares cookbook would be a good place to start.
Skip the blah blah and see the code at chef-jumpsquares or read on for the complete back story.
The setup of Chef is simple and only takes about an hour or two to complete. After the server is up and a node has been added, that's where the fun begins. I began my involvement with looking around for cookbooks that use the same components that are needed in the JumpSquares appliance model. Cookbooks such as postgres for database, rvm for ruby, and nginx for web/application servers were already available and made my job starting out much easier.
Chef Cookbook and Recipe for Thin + Nginx with Rails
For simplicity, I deploy thin + nginx for most of my rails applications. Thin is lighter weight than Passenger and the combo makes it more favorable than running Apache. I began learning Chef and saw nothing for thin existed so I attempted to make a cookbook.
If you don't want to read any more about this, then jump over to the code on github chef-thin_nginx.
This cookbook will install thin as a gem and complete a configuration. While 'nginx' will be installed from package and installed as a normal service.
To make the 'thin' installation from gem work properly, 'rvm' is required. rvm has a shell interface that is used to install the service from the gem. I previously tried to install thin from source and it wouldn't work correctly because 'rake' tasks are necessary gems that aren't loaded into the internal 'chef' gemset. In addition, I tried to install the thin gem to chef's internal gemset, but I received lots of errors when it came to postgresql gems. That is why rvm is necessary. rvmwill install version 1.6.1 of thin unless you change the parameters. This was tested with 1.6.1 so it will work.
I had a problem where my vCAC environment could no longer talk to my vCO APIs. I constantly have to turn off vCAC and bring it back up because of resource constraints in my home lab. For some reason I just thought the services weren't coming up and I realized no amount of reboots were going to fix it.
The error was:
You cannot perform that action because the system cannot connect to the provider at https://vcac-appliance.kendrickcoleman.c0m:8281/vco/api/.
Automating vCloud Director Organization VDCs with Ruby
I filed this under rails projects, but it's really just some ruby code...
I set a goal for myself to become familiar with the vCloud Director APIs using REST. Mainly to see how long it would take me to automate my first task and prove to myself I can do it. Well, I'm pleased to say that it's alot easier than I thought. I had a new vCloud Director instance installed on Monday, and by Wednesday morning I was just finishing up my code. So within 2 days I was doing some automation tasks and it really wasn't that hard. It gave me a chance to work directly with the API using the rest-client and nokogiri gems. A total of 200+ lines of ruby code all together
1st: NewOrg.rb This will create a new Organization based on the parameters specified in the XML. Relies on the new_org.xml.
2nd. NewOrgVDCandServices.rb (not completely working) This will create a new Organization VDC based on parameters specified at the beginning of the Script. It also uses 3 XML files for the POST input parameters. After the Organization vDC is created, then deploy a vShield Edge Gateway appliance to the newly created OrgVDC. Wait 120 seconds after deployment, then configure 2 new services are created on the Gateway appliance:
A default firewall rule to allow all internal traffic to pass to anything external
A SNAT rule to allow internal traffic to speak on a NATed address externally.