Codex.org

A while back I started using the RightScale API to automate some tasks related to servers that we have in the cloud. Initially, all the work was done using scripts in various languages, but with Curl calls to the API. Switching over to writing all my tools in Ruby, I realized that the API was lacking when it came to authentication and ease of use.

Being that I am lazy, I did what any good coder would do, and created a class to handle the connections.

Normally, things would end there. But, being that I have started working with Ruby and Gems, I decided that I was going to create a Gem. This was mainly so that as I write new tools, I would not have to add this library manually to all of my apps. Ruby Gems provide a nice mechanism to add code/libraries to a machine for use by various programs.

All this leads to my learning process of how to create a Gem, and add it to the open RubyGems collection. I am going to try and recount all the steps that are needed. Hopefully in an order that will make more sense than the one that I went through to get my first gem added to the public domain.

RightScale provides repositories to use for doing system updates and patches to your machines, but by default, they are only used for installing applications via RightScripts or Chef Scripts. It is up to you to be responsible for patching your servers and ensuring you do not have any vulnerabilities open for the world to exploit. Based on the way that RightScale has setup the repositories, you have to modify where your system is looking in order to install these updates.

To this affect, I wrote a RightScript a while back that can be used to change the default repo that is used to pull updates from. The script has been working great for the past few months, but as more and more updates come out, the delay in booting becomes more and more pronounced. If you are not using dynamic server arrays, this is not an issue. So, it take 20 minutes to boot the server instead of 10. At least the system is patched.

But, if you are using server arrays, and have to handle surges in traffic or load, then the time a server takes to come online is very important. A difference of 10 minutes can be immense. So what can be done to alleviate this problem? We have take to using two various methods to reduce the time that updates take to install on our servers.

RightScale provides an API for automating tasks. However, getting started with them can be a bit confusing. Lets start with the various versions of the API. As of writing this, they are as follows:

• API 1.0 — This API only works with Amazon AWS Cloud
• API 1.5 — Works with most other providers and is NOT compatible with Amazon AWS Cloud
• API 2.0 — This is supposed to be the grand unified API that will work with all supported clouds.

My focus is on how to connect to the RightScale API using Ruby. There are some differences in the API’s and how they make some calls, so they current focus is going to be on version 1.0 with Amazon AWS. While there are rest-client gems you could download, I wanted manual control so I do not include any of these.

Authentication

One of the trickiest parts of using the API is getting the formatting and flags correct. For this example you only need to require two classes based on http. All this was figured out from the documentation.

require 'net/http'
require 'net/https'

I recently started working with RightScale to manage servers in various cloud environments. The servers that I am working with are in the Amazon EC2 cloud, but RightScale provides an interface to manages servers in multiple cloud spaces.

The underlying operating system for the servers that I am managing are running CentOS. While I prefer RedHat, CentOS is fine. I understand the reason for going with both, and when cost is an issue CentOS commonly wins out. The version is CentOS version 5.4.

The problem is that the servers are not getting updates. Based on the RightScale blog, you should be able to choose a RightScale supported frozen image of the CentOS mirrors from any given day, and they will have the most up to date patches to that day. As the servers do not maintain state between reboots, this means you can set the repo for a specific date, and the patches would be consistent for multiple machines no matter when they were booted.