README cleanup/editing

This commit is contained in:
geemus 2010-12-13 14:32:25 -08:00
parent 2ed751c563
commit f7631ddca5
1 changed files with 18 additions and 25 deletions

View File

@ -1,20 +1,16 @@
http://geemus.s3.amazonaws.com/fog.png
fog is the Ruby cloud computing library.
The quick and dirty, top to bottom:
fog is the Ruby cloud computing library, top to bottom:
* Collections provide a simplified interface, making clouds easier to work with and switch between.
* Requests allow power users to get the most out of the features of each individual cloud.
* Mocks make testing and integrating a breeze.
Put them together and you get a great cloud computing experience, but we are getting ahead of ourselves...
== Getting Started
sudo gem install fog
Now just type 'fog' to trying stuff out, confident that fog should let you know what you need to do. Here is an example of wading through server creation for Amazon Elastic Compute Cloud:
Now type 'fog' to try stuff, confident that fog will let you know what to do. Here is an example of wading through server creation for Amazon Elastic Compute Cloud:
>> server = AWS.servers.create
ArgumentError: image_id is required for this operation
@ -27,19 +23,19 @@ Now just type 'fog' to trying stuff out, confident that fog should let you know
== Collections
A high level interface to each cloud is provided through collections, such as images and servers.
You can see a list of available collections by calling #collections on the connection object. You can try it out using the `fog` command:
A high level interface to each cloud is provided through collections, such as `images` and `servers`.
You can see a list of available collections by calling `collections` on the connection object. You can try it out using the `fog` command:
>> server = AWS.collections
>> AWS.collections
[:addresses, :directories, :files, :flavors, :images, :key_pairs, :security_groups, :servers, :snapshots, :volumes]
Some of these collections are available across multiple providers. For example, all compute providers have +flavors+, +images+ and +servers+, and storage providers have +directory+ and +file+.
Some collections are available across multiple providers. For example, compute providers have +flavors+, +images+ and +servers+, and storage providers have +directory+ and +file+.
Collections share most of the basic CRUD type operations, such as:
Collections share basic CRUD type operations, such as:
* +all+ - fetch every object of that type from the provider.
* +create+ - initialize a new record locally and then persists it with the provider.
* +get+ - fetch a single object by its identity from the provider.
* +new+ - initialize a new record locally, but do not persist it to the provider.
* +create+ - initialize a new record locally and a remote resource with the provider.
* +get+ - fetch a single object by it's identity from the provider.
* +new+ - initialize a new record locally, but create a remote resource with the provider.
As an example, we'll try initializing and persisting a Rackspace Cloud server:
@ -64,36 +60,33 @@ As an example, we'll try initializing and persisting a Rackspace Cloud server:
== Models
Many of the collection methods return individual objects, which also provide some common methods:
Many of the collection methods return individual objects, which also provide common methods:
* +destroy+ - will destroy the persisted object from the provider
* +save+ - persist the object to the provider
* +wait_for+ - takes a block and waits for either the block to return true for the object or for a timeout (defaults to 10 minutes)
== Mocks
As you might imagine, testing code using Fog could be feasibly slow and expensive to constantly be turning and and shutting down instances. Fortunately, fog includes support for mocking itself out.
Mocking provides an in memory representation of the state of cloud resources as you make requests.
Mocked calls to mimic the behavior of each provider while eliminating the cost and time needed to actually use cloud resources.
Enabling mocking easy to use, before you run any other commands run:
As you might imagine, testing code using Fog can be slow and expensive, constantly turning on and and shutting down instances.
Mocking allows skipping this overhead by providing an in memory representation resources as you make requests.
Enabling mocking easy to use, before you run other commands, simply run:
Fog.mock!
Then you can run other commands just like you always would.
Some mocks are not implemented just yet, but fog will raise an error to let you know and contributions are always welcome!
Then proceed as usual, if you run into unimplemented mocks fog will raise an error and as always contributions are welcome!
== Requests
Requests allow you to dive deeper when the models just can't cut it.
You can see a list of available requests by calling #requests on the connection object.
For instance, ec2 provides methods related to reserved instances that don't have any models (yet).
Here is how you can lookup your reserved instances:
For instance, ec2 provides methods related to reserved instances that don't have any models (yet). Here is how you can lookup your reserved instances:
$ fog
>> AWS[:ec2].describe_reserved_instances
#<Excon::Response [...]>
It will return an {excon}[http://github.com/geemus/excon] response, which has #headers and #body. Both return nice hashes.
It will return an {excon}[http://github.com/geemus/excon] response, which has `body`, `headers` and `status`. Both return nice hashes.
== Go forth and conquer