Ruby - Source-to-Image (<strong>s2i</strong>) | Using Images

Overview
Versions
Images
Build Process
Configuration
Hot Deploying

Overview

OKD provides s2i enabled Ruby images for building and running Ruby applications. The Ruby s2i builder image assembles your application source with any required dependencies to create a new image containing your Ruby application. This resulting image can be run either by OKD or by Docker.

Versions

Currently, OKD provides versions 2.0, 2.2, and 2.3 of Ruby.

Images

These images come in two flavors, depending on your needs:

RHEL 7
CentOS 7

RHEL 7 Based Images

The RHEL 7 images are available through the Red Hat registry:

$ docker pull registry.access.redhat.com/openshift3/ruby-20-rhel7
$ docker pull registry.access.redhat.com/rhscl/ruby-22-rhel7
$ docker pull registry.access.redhat.com/rhscl/ruby-23-rhel7

CentOS 7 Based Images

These images are available on Docker Hub:

$ docker pull openshift/ruby-20-centos7
$ docker pull openshift/ruby-22-centos7
$ docker pull centos/ruby-23-centos7

To use these images, you can either access them directly from these image registries or push them into your OKD Docker registry. Additionally, you can create an image stream that points to the image, either in your Docker registry or at the external location. Your OKD resources can then reference the ImageStream. You can find example image stream definitions for all the provided OKD images.

Build Process

s2i produces ready-to-run images by injecting source code into a container and letting the container prepare that source code for execution. It performs the following steps:

Starts a container from the builder image.
Downloads the application source.
Streams the scripts and application sources into the builder image container.
Runs the assemble script (from the builder image).
Saves the final image.

See s2i Build Process for a detailed overview of the build process.

Configuration

The Ruby image supports a number of environment variables which can be set to control the configuration and behavior of the Ruby runtime.

To set these environment variables as part of your image, you can place them into a .s2i/environment file inside your source code repository, or define them in the environment section of the build configuration’s sourceStrategy definition.

You can also set environment variables to be used with an existing image when creating new applications, or by updating environment variables for existing objects such as deployment configurations.

Environment variables that control build behavior must be set as part of the s2i build configuration or in the .s2i/environment file to make them available to the build steps.

Table 1. Ruby Environment Variables
Variable name	Description
`RACK_ENV`	This variable specifies the environment within which the Ruby application is deployed; for example, `production`, `development`, or `test`. Each level has different behavior in terms of logging verbosity, error pages, and ruby gem installation. The application assets are only compiled if `RACK_ENV` is set to `production`; the default value is `production`.
`RAILS_ENV`	This variable specifies the environment within which the Ruby on Rails application is deployed; for example, `production`, `development`, or `test`. Each level has different behavior in terms of logging verbosity, error pages, and ruby gem installation. The application assets are only compiled if `RAILS_ENV` is set to `production`. This variable is set to `${RACK_ENV}` by default.
`DISABLE_ASSET_COMPILATION`	When set to `true`, this variable disables the process of asset compilation. Asset compilation only happens when the application runs in a production environment. Therefore, you can use this variable when assets have already been compiled.
`PUMA_MIN_THREADS`, `PUMA_MAX_THREADS`	This variable indicates the minimum and maximum number of threads that will be available in Puma's thread pool.
`PUMA_WORKERS`	This variable indicates the number of worker processes to be launched in Puma’s clustered mode (when Puma runs more than two processes). If not explicitly set, the default behavior sets `PUMA_WORKERS` to a value that is appropriate for the memory available to the container and the number of cores on the host.
`RUBYGEM_MIRROR`	Set this variable to use a custom RubyGems mirror URL to download required gem packages during the build process. Note: This environment variable is only available for Ruby 2.2+ images.

Hot Deploying

Hot deployment allows you to quickly make and deploy changes to your application without having to generate a new s2i build. The method for enabling hot deployment in this image differs based on the application type.

Ruby on Rails Applications

For Ruby on Rails application, run the built Rails application with the RAILS_ENV=development environment variable passed to the running pod. For an existing deployment configuration, you can use the oc set env command:

$ oc set env dc/rails-app RAILS_ENV=development

Other Types of Ruby Applications (Sinatra, Padrino, etc.)

For other types of Ruby applications, your application must be built with a gem that can reload the server every time a change to the source code is made inside the running container. Those gems are:

In order to be able to run your application in development mode, you must modify the s2i run script so that the web server is launched by the chosen gem, which checks for changes in the source code.

After you build your application image with your version of the s2i run script, run the image with the RACK_ENV=development environment variable. For example, see the oc new-app command. You can use the oc set env command to update environment variables of existing objects.

You should only use this option while developing or debugging; it is not recommended to turn this on in your production environment.

To change your source code in a running pod, use the oc rsh command to enter the container:

$ oc rsh <pod_id>

After you enter into the running container, your current directory is set to /opt/app-root/src, where the source code is located.