TruffleRuby on OCI Container Instances

Elegance at Speed


Ruby is one of my favourite programming languages.  I really appreciate how expressive it is, how productive (and how much fun) it makes development.

Unfortunately Ruby has a reputation for being slow compared to other languages such as JavaScript.

While the performance of the default Ruby interpreter has improved, it still hasn't had the engineering investment that goes into V8.

I want to introduce you to an alternative Ruby engine, and a really simple way to deploy Ruby applications in the cloud.

TruffleRuby

TruffleRuby is a high - performance implementation of Ruby, built on top of GraalVM.

GraalVM is a high - performance, polyglot virtual machine.

In benchmark tests, TruffleRuby often delivers superior performance to other Ruby implementations.

You can install TruffleRuby using commonly used Ruby managers such as RVM, chruby && ruby-install, and rbenv.

Once you've installed TruffleRuby, you can use it just like the standard Ruby engine.  Typically I set TruffleRuby as my default runtime.

TruffleRuby is an open-source project.  GraalVM is developed via the open - source project.  GraalVM is available in two flavours:
  • Community Edition (GraalVM CE) - the open - source edition
  • Enterprise Edition - includes premium enhancements not included in the open - source edition
Enterprise Edition requires a subscription for production use.  This is included at no additional cost for workloads running on Oracle Cloud infrastructure (OCI).

OCI Container Instances

Since I like Ruby, it's probably not a surprise that I like to keep things simple.

OCI Container Instances is a simple, serverless, cloud service for running applications in containers.

Essentially you just create an instance, specifying the image you want to use, and the service runs it for you.

So I thought I'd quickly show you how you can use Container Instances to run a simple Sinatra web application in a container, with TruffleRuby as the Ruby runtime.

Hands - On

Pre - Requisites

  • OCI account (paid or trial with credits)
  • VCN with public subnet created (see here for a tutorial if required)

App

The app is about the simplest Sinatra app you can create:

Dockerfile

I'm going to use publicly available GraalVM CE images containing TruffleRuby to build from.

These don't require any license.

I install some dependencies for building native extensions and then the sinatra and thin gems.

Then copy in the app from above:

Then build the image and push it to your repository of choice.

In my case, I have chosen to push it to a private repository in OCI.  Since the plan is to deploy to OCI, this makes sense, but you could push it to any repository you have access to.

In my case the image is oracledeveloper/burton7/truffle:ce

Container Instance

Click on "Container Instances" and then "Create Container Instance".


Just accept the defaults for the moment and click "Next" (make sure your subnet is public).

Select your image and enter your credentials if you're using a private repository.

Then click "Next".

The final screen should look something like this:
Click create.  You should get a screen showing an orange "CI" icon and the message "CREATING":
After a few minutes, the icon should change to green, and the public IP address of the instance will be displayed:
If you then open another tab with the URL http://<public IP>:4567 you should get the traditional "Hello world!" message:

Next steps

You can follow the template to spin up an app that does something more meaningful!

Summary

TruffleRuby is the high - performance implementation of Ruby built on the GraalVM.

OCI Container Instances is a serverless compute service for running containers simply.

Together they enable you to easily run high performance Ruby applications in containers.



Comments

Post a Comment

Popular posts from this blog

Wot no FDK?

Writing Serverless Functions in a New Language Background Fn Project  is an open - source, Docker based, cloud native serverless platform .  You can run it in any environment that supports Docker.  Oracle Functions is based on Fn Project. If you want to have a play with Fn before reading the rest of this post, I recommend the " Quick Start " guide. One of the great strengths of Fn Project is that it is open. When other serverless platforms (that shall remain nameless) restricted you to JavaScript / Node plus maybe a couple of others, Fn offered an FDK for Ruby (for those who prefer elegance and beauty in their code). This was a major factor in me getting involved with the project, and becoming a contributor to the Ruby FDK. In addition to Ruby, Fn offers a number of other FDKs: Go, Java, Python, Node and .NET Core. But beyond that, Fn has always been open to additional language runtimes.  If your code can run in a Docker container, then (in principle) it can run as an Fn fun
Read more

The Case of the Vanishing Dockerfile

If your serverless platform is Oracle Functions or the open source  Fn Project that it is based on, you may have wondered exactly how a function image gets built for one of the standard runtimes. One clue is that if you're watching closely you may see a Dockerfile  a p pear briefly, then vanish during the build process. The Fn CLI will create the Dockerfile for the runtime, build the function and then delete it once the build has completed. You can see the steps of the docker build by running  fn build  or  fn deploy  with the  --verbose  flag specified: $ fn build --verbose [14:57:34] Building image fra.ocir.io/oraseemeatechse/crush157/dummy:0.0.1 FN_REGISTRY: fra.ocir.io/oraseemeatechse/crush157 Current Context: default Sending build context to Docker daemon 14.34kB Step 1/11 : FROM fnproject/fn-java-fdk-build:jdk11-1.0.108 as build-stage ---> e3c33b854f29 Step 2/11 : WORKDIR /function ---> Using cache ---> c0bcff391281
Read more

Honey I Shrunk The Container

Image
(or how I found out about microcontainers and why I think you should use them) Context About 18 months ago I was asked to help an ISV partner who wanted to migrate their product to cloud. At the time they had a very traditional software industry business model - sell the customer a license to run their software, along with a subscription for ongoing support. However they wanted to be able to move to a SaaS model where the customer would consume their software as a service running in the cloud. Their stack consisted of: a Ruby on Rails application Postgres Redis Their initial attempt at creating a SaaS offering had been to run this as a set of VMs on top of IaaS. While the software ran just fine, they soon saw that this approach wasn't going to give them a successful SaaS business. If any part of the application were experiencing high demand, the only way to scale it was to start another instance of the whole application . Since they were packaging the applic
Read more