Ruby 2.3 container image
This container image includes Ruby 2.3 as a S2I base image for your Ruby 2.3 applications. Users can choose between RHEL, CentOS and Fedora based builder images. The RHEL images are available in the Red Hat Container Catalog, the CentOS images are available on Docker Hub, and the Fedora images are available in Fedora Registry. The resulting image can be run using podman.
Note: while the examples in this README are calling
podman, you can replace any such calls by
docker with the same arguments
Ruby 2.3 available as container is a base platform for building and running various Ruby 2.3 applications and frameworks. Ruby is the interpreted scripting language for quick and easy object-oriented programming. It has many features to process text files and to do system management tasks (as in Perl). It is simple, straight-forward, and extensible.
For this, we will assume that you are using the
rhscl/ruby-23-rhel7 image, available via
ruby:2.3 imagestream tag in Openshift.
Building a simple ruby-sample-app application
in Openshift can be achieved with the following step:
``` oc new-app ruby:2.3~https://github.com/sclorg/s2i-ruby-container.git --context-dir=2.3/test/puma-test-app/ ```
The same application can also be built using the standalone S2I application on systems that have it available:
``` $ s2i build https://github.com/sclorg/s2i-ruby-container.git --context-dir=2.3/test/puma-test-app/ rhscl/ruby-23-rhel7 ruby-sample-app ```
Accessing the application:
$ curl 127.0.0.1:8080
To set these environment variables, you can place them as a key value pair into a
file inside your source code repository.
This variable specifies the environment where the Ruby application will be deployed (unless overwritten) -
test. Each level has different behaviors in terms of logging verbosity, error pages, ruby gem installation, etc.
Note: Application assets will be compiled only if the
RACK_ENVis set to
This variable set to
trueindicates that the asset compilation process will be skipped. Since this only takes place when the application is run in the
productionenvironment, it should only be used when assets are already compiled.
These variables indicate the minimum and maximum threads that will be available in Puma's thread pool.
This variable indicate the number of worker processes that will be launched. See documentation on Puma's clustered mode.
Set this variable to use a custom RubyGems mirror URL to download required gem packages during build process.
In order to dynamically pick up changes made in your application source code, you need to make following steps:
For Ruby on Rails applications
Run the built Rails image with the
RAILS_ENV=developmentenvironment variable passed to the podman
$ podman run -e RAILS_ENV=development -p 8080:8080 rails-app
For other types of Ruby applications (Sinatra, Padrino, etc.)
Your application needs to be built with one of gems that reloads the server every time changes in source code are done inside the running container. Those gems are:
Please note that in order to be able to run your application in development mode, you need to modify the S2I run script, so the web server is launched by the chosen gem, which checks for changes in the source code.
$ podman run -e RACK_ENV=development -p 8080:8080 sinatra-app
To change your source code in running container, use Podman's exec command:
podman exec -it <CONTAINER_ID> /bin/bash
After you podman exec into the running container, your current
directory is set to
/opt/app-root/src, where the source code is located.
You can tune the number of threads per worker using the
PUMA_MAX_THREADS environment variables.
Additionally, the number of worker processes is determined by the number of CPU
cores that the container has available, as recommended by
Puma's documentation. This is determined using
the cgroup cpusets
subsystem. You can specify the cores that the container is allowed to use by passing
--cpuset-cpus parameter to the podman run command:
$ podman run -e PUMA_MAX_THREADS=32 --cpuset-cpus='0-2,3,5' -p 8080:8080 sinatra-app
The number of workers is also limited by the memory limit that is enforced using cgroups. The builder image assumes that you will need 50 MiB as a base and another 15 MiB for every worker process plus 128 KiB for each thread. Note that each worker has its own threads, so the total memory required for the whole container is computed using the following formula:
50 + 15 * WORKERS + 0.125 * WORKERS * PUMA_MAX_THREADS
You can specify a memory limit using the
$ podman run -e PUMA_MAX_THREADS=32 --memory=300m -p 8080:8080 sinatra-app
If memory is more limiting then the number of available cores, the number of
workers is scaled down accordingly to fit the above formula. The number of
workers can also be set explicitly by setting
Dockerfile and other sources are available on https://github.com/sclorg/s2i-ruby-container.
In that repository you also can find another versions of Python environment Dockerfiles.
Dockerfile for CentOS is called
Dockerfile, Dockerfile for RHEL7 is called
for RHEL8 it's
Dockerfile.rhel8 and the Fedora Dockerfile is called Dockerfile.fedora.