Anton Lindstrom (about, @twitter, @github)

Using the Glesys beta API with Fog

Published:

Currently Glesys is developing an almost finished API for the Cloud-services. Currently only the compute interface is done and beta access for it can be enabled by contacting Glesys support.

The Ruby cloud computing library, Fog now also supports Glesys and as this is being written the next release will include the support into the Ruby gem. This post will show how to use the Glesys services with Fog.

As mentioned, the API is currently in beta and by contacting Glesys access can be enabled for your account. When enabled, an API key must be created. That is done by going to the API tab then "API Keys" and click, "Create new key". The default access for the key is not to allow anything, change this by clicking "None" under "Allowed Hosts" and under "Permissions". If you want to enable the key for all hosts and give them access to all parts, set 0.0.0.0/0 in Allowed Hosts and Allow all in Permissions.

After creating an API key, if the version of Fog is over v0.11.0 then just install the Ruby gem, otherwise pull Fog from Github. Edit the file ~/.fog and make it look like the file below with your login and your API key you just created.

default:
  :glesys_username: 'CLXXXXX'
  :glesys_api_key: 'secret2g3zX72kXq1w31MXRzkRfxLMjXJL9Q6X6X'

To test Fog out, the interactive prompt is a great way to get started. Type fog or if you pulled the source code from git, use ./bin/fog to get a prompt running. It is then possible to start interacting with Glesys. Below are a few examples on commands and how to use them:

As this is a beta, some of the functionality might change but over all this would stay the same. Fog::SSH will be changed as soon as I get the opportunity to make use of xm.ssh(commands), currently the password is not saved in the session and to access the IP we will have to go through the "iplist", this will probably be aliased to from :public_ip_address.

Now, go on and create some servers and provision them with Puppet or Chef to make the process repeatable and choose several compute providers to make your service solid in case of failures. It is not a question of if, it is a question of when a server will fail.