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-openstack in your
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
domain_name. If you specify both
username will be ignored.
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.
- 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