It has been a while since I’ve posted a full project, so here it goes. Enjoy. This time we have our first guest appearance in a super awesome software developer, cycling, and beer snob buddy @jrrickard, who I am doing a number of projects with these days & showcasing some of them in a booth at our employers internal Science Fair (It’s going to be rad. And there will be pliny.) How did I get so far off track already…
I have been doing a lot with VMware vCloud Application Director lately, and while I think it is a really interesting product that strokes all of my ex-sysadmin nerdy tendancies in all the right ways, I think it has a really bright future as it’s a _really_ powerful tool that almost no one knows about (yet). So, I thought to myself, what’s something totally silly I can do with it while still showing off it’s real world potential? (if you haven’t picked up on it yet, that’s kind of my thing…) That’s when I decided:
I should start a blog on cyclocross.
— josh gray (@jasper9) April 15, 2014
@jasper9 ok, hang on! Blog on cyclocross on the way.
— The Owen Bot (@TheOwenBot) April 15, 2014
About ten minutes later, I have this:
So what’s going on here? Step by Step:
1) I tweet a specific phrase like “I should start a blog on cyclocross” .
2) @jrrickard wrote some slick python that talks to Twitter over the REST API, finds that phrase, and sends a specially formatted call over a REST API to vCO  [note that is supposed to be a superscript… not sure how to do that and link to a lower section in this blog yet..]
3) The vCO workflow(s) talk to AppD over a REST API, processes the parameters, finds the application blueprint in AppD, and schedules the deployment. (There is some new fancy secret sauce another co-worker is developing that I may post about at a later time. In short it is a collection of workflows that finds and executes exactly what you want in AppD based on the human readable name instead of the ID… which is a pain in the rear to find.. seriously…)
4) The AppD blueprint that gets deployed is based on a canned blueprint found at the VMware Solution Exchange here  with only a minor addition at the end. It deploys a CentOS VM from a template, and installs Apache, MySQL and WordPress in order with all dependencies resolved. AppD configures each one and starts all services.
5) Based on the original tweet that started this whole mess, an AppD service I created from scratch and added to the blueprint (a) pulls a CLI for WordPress from Git, (b) uses that cli to write a few posts to the blog on the topic I tweeted, and lastly (c) goes to flickr (over another REST API) and pulls a bunch of images on the topic to adds them to the posts.
[FUTURE] 6) We didn’t add it in yet for a number of reasons, but plan to complete the loop and notify back with a tweet saying “Here’s your blog link!”.
 So why make the REST call to vCO instead of AppD directly?
Good question! Doing it this way can be considered best practice because it can give you greater flexibility in processing all the data and lets you monitor the process and better trap erros. This way you are not relying on the 3rd party system entirely but can work around it and integrate better.
 VMware Solution Exchange?
Yes! It’s great! You can browse all of these canned & demo solutions like Websphere, Oracle, JasperReports, SharePoint, Jenkins, and Liferay to see how one could (or should) use AppD to automate deployments.
 Want to see the workflows and blueprints?
Maybe when I get some time to clean it all up. It’s kind of…messy right now.
@jrrickard / Jeremy Rickard for the help with the python script running the twitter bot.
@MarcoCaronna for the AppD/vCO zen master skills simplifying the REST API