Ruby

Overview

OpenShift Container Platform 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 OpenShift Container Platform or by a container runtime.

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.

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.