Using IBM Bluemix Object Storage in Ruby Projects
How it works
You’ve probably heard about the announcement of Bluemix Object Storage—this technical overview explains why and how to use it for your Ruby project.
When writing scalable or distributed applications, developers often face the necessity of sharing rarely changing binary data between app instances. In case of one application instance, the data, such as user-uploaded images, is usually stored on the hard drive.
Traditional databases do not handle this type of data quite well, so cloud storage services like IBM Object Storage for Bluemix can be used instead. They make operating large amounts of unstructured data almost as easy as reading/writing a local file. Among IBM Object Storage analogs are Amazon S3, Azure Blob Storage, and Google Cloud Storage.
Using Bluemix Object Storage saves you from implementing a file synchronization solution from scratch or setting up NFS that does not provide very impressive performance as well as may cause lots of technical troubles for heavy workloads.
Bluemix Object Storage gives 5 GB of free storage. For further pricing details, see the Bluemix Catalog.
How to use it
Ruby (on Rails) applications typically use one of the available gems that provide file uploading capabilities. Most popular are Paperclip and CarrierWave. Both of them support fog
storage, which in its turn supports Object Storage among other cloud storage services.
When searching for how to use Bluemix Object Storage with Ruby, I found a couple of Stack Overflow questions. None of the suggested solutions worked for me, so I decided to dig into the problem myself. Here’s what I’ve figured out.
To use Bluemix Object Storage with CarrierWave or Paperclip, set the storage option to :fog
. Fog is a Ruby cloud services library, and it provides a common interface for many cloud provider services, including Object Storage. Make sure you have fog
and fog-openstack
in your Gemfile
.
For using Bluemix with Paperclip, check out the paperclip_test.rb configuration. (Important lines are 21-37.) With CarrierWave, use carrierwave_test.rb. (Important lines are 8-19.)
The auth_url
value from the Object Storage page does not work, and you need to append /v3/auth/tokens
to it. The result should look like the following: https://lon-identity.open.softlayer.com/v3/auth/tokens
. I couldn’t get it working with v2.0 URLs though the auth server claimed to support it; but v3 worked just fine. Let us know if you sorted it out.
If you do not specify user_id
, you should provide username
with domain_name
. If you specify both username
and user_id
, then username
will be ignored.
The fog_directory
value should match to an existing container. (You have to create one before uploading any files, and it is not created automatically.) Unlike containers, directories within the container are created upon file uploading as needed. Bluemix Object Storage does not have size limits for uploading files. Internally, it handles large files as a set of smaller ones.
Note that currently you have to use the version of the fog-openstack
gem from master
. The Bluemix Object Storage authentication fixes will be included in fog-openstack
versions above 0.1.1.
A code sample
If you want an example of a working CarrierWave uploader or Paperclip model for Bluemix Object Storage, clone https://gist.github.com/1306e41989a398dc14b7.git, specify your Object Storage credentials in the credentials.yml
file, and create the test_uploads
container in the Bluemix console. Make sure you run bundle install
before executing test scripts. Use ruby carrierwave_test.rb
for CarrierWave and ruby paperclip_test.rb
for Paperclip.
The results of running ruby carrierwave_test.rb
and ruby paperclip_test.rb
are on the screenshots.
Further reading
- Getting Started with IBM Bluemix: Deploying a Sample Ruby/Sinatra App
- Continuous Integration and Continuous Delivery in IBM Bluemix
- Building Java Apps with IBM Bluemix and DB2