Pull changes from upstream and rebase for: rebuild for latest f30

root/help.1

@@ -0,0 +1,250 @@
+.TH Ruby 2.5 container image
+.PP
+This container image includes Ruby 2.5 as a S2I
+\[la]https://github.com/openshift/source-to-image\[ra] base image for your Ruby 2.5 applications.
+Users can choose between RHEL and CentOS based builder images.
+The RHEL image is available in the Red Hat Container Catalog
+\[la]https://access.redhat.com/containers/#/registry.access.redhat.com/rhscl/ruby-25-rhel7\[ra]
+as registry.access.redhat.com/rhscl/ruby\-25\-rhel7.
+The CentOS image is then available on Docker Hub
+\[la]https://hub.docker.com/r/centos/ruby-25-centos7/\[ra]
+as centos/ruby\-25\-centos7.
+The resulting image can be run using Docker
+\[la]http://docker.io\[ra]\&.
+
+.SH Description
+.PP
+Ruby 2.5 available as container is a base platform for
+building and running various Ruby 2.5 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.
+
+.PP
+This container image includes an npm utility, so users can use it to install JavaScript
+modules for their web applications. There is no guarantee for any specific npm or nodejs
+version, that is included in the image; those versions can be changed anytime and
+the nodejs itself is included just to make the npm work.
+
+.SH Usage
+.PP
+To build a simple ruby\-sample\-app
+\[la]https://github.com/sclorg/s2i-ruby-container/tree/master/2.5/test/puma-test-app\[ra] application
+using standalone S2I
+\[la]https://github.com/openshift/source-to-image\[ra] and then run the
+resulting image with Docker
+\[la]http://docker.io\[ra] execute:
+.IP \(bu 2
+
+.PP
+\fBFor RHEL based image\fP
+.PP
+.RS
+
+.nf
+$ s2i build https://github.com/sclorg/s2i\-ruby\-container.git \-\-context\-dir=2.5/test/puma\-test\-app/ rhscl/ruby\-25\-rhel7 ruby\-sample\-app
+$ docker run \-p 8080:8080 ruby\-sample\-app
+
+.fi
+.RE
+.IP \(bu 2
+
+.PP
+\fBFor CentOS based image\fP
+.PP
+.RS
+
+.nf
+$ s2i build https://github.com/sclorg/s2i\-ruby\-container.git \-\-context\-dir=2.5/test/puma\-test\-app/ centos/ruby\-25\-centos7 ruby\-sample\-app
+$ docker run \-p 8080:8080 ruby\-sample\-app
+
+.fi
+.RE
+
+.PP
+\fBAccessing the application:\fP
+
+.PP
+.RS
+
+.nf
+$ curl 127.0.0.1:8080
+
+.fi
+.RE
+
+.SH Environment variables
+.PP
+To set these environment variables, you can place them as a key value pair into a \fB\fC\&.sti/environment\fR
+file inside your source code repository.
+.IP \(bu 2
+
+.PP
+\fBRACK\_ENV\fP
+.PP
+This variable specifies the environment where the Ruby application will be deployed (unless overwritten) \- \fB\fCproduction\fR, \fB\fCdevelopment\fR, \fB\fCtest\fR\&.
+Each level has different behaviors in terms of logging verbosity, error pages, ruby gem installation, etc.
+
+.PP
+\fBNote\fP: Application assets will be compiled only if the \fB\fCRACK\_ENV\fR is set to \fB\fCproduction\fR
+.IP \(bu 2
+
+.PP
+\fBDISABLE\_ASSET\_COMPILATION\fP
+.PP
+This variable set to \fB\fCtrue\fR indicates that the asset compilation process will be skipped. Since this only takes place
+when the application is run in the \fB\fCproduction\fR environment, it should only be used when assets are already compiled.
+.IP \(bu 2
+
+.PP
+\fBPUMA\_MIN\_THREADS\fP, \fBPUMA\_MAX\_THREADS\fP
+.PP
+These variables indicate the minimum and maximum threads that will be available in Puma
+\[la]https://github.com/puma/puma\[ra]\&'s thread pool.
+.IP \(bu 2
+
+.PP
+\fBPUMA\_WORKERS\fP
+.PP
+This variable indicate the number of worker processes that will be launched. See documentation on Puma's clustered mode
+\[la]https://github.com/puma/puma#clustered-mode\[ra]\&.
+.IP \(bu 2
+
+.PP
+\fBRUBYGEM\_MIRROR\fP
+.PP
+Set this variable to use a custom RubyGems mirror URL to download required gem packages during build process.
+
+.SH Hot deploy
+.PP
+In order to dynamically pick up changes made in your application source code, you need to make following steps:
+.IP \(bu 2
+
+.PP
+\fBFor Ruby on Rails applications\fP
+.PP
+Run the built Rails image with the \fB\fCRAILS\_ENV=development\fR environment variable passed to the Docker
+\[la]http://docker.io\[ra] \fB\fC\-e\fR run flag:
+
+.PP
+.RS
+
+.nf
+$ docker run \-e RAILS\_ENV=development \-p 8080:8080 rails\-app
+
+.fi
+.RE
+.IP \(bu 2
+
+.PP
+\fBFor other types of Ruby applications (Sinatra, Padrino, etc.)\fP
+.PP
+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:
+.IP \(bu 2
+Shotgun
+\[la]https://github.com/rtomayko/shotgun\[ra]
+.IP \(bu 2
+Rerun
+\[la]https://github.com/alexch/rerun\[ra]
+.IP \(bu 2
+Rack\-livereload
+\[la]https://github.com/johnbintz/rack-livereload\[ra]
+
+.PP
+Please note that in order to be able to run your application in development mode, you need to modify the S2I run script
+\[la]https://github.com/openshift/source-to-image#anatomy-of-a-builder-image\[ra], so the web server is launched by the chosen gem, which checks for changes in the source code.
+
+.PP
+After you built your application image with your version of S2I run script
+\[la]https://github.com/openshift/source-to-image#anatomy-of-a-builder-image\[ra], run the image with the RACK\_ENV=development environment variable passed to the Docker
+\[la]http://docker.io\[ra] \-e run flag:
+
+.PP
+.RS
+
+.nf
+$ docker run \-e RACK\_ENV=development \-p 8080:8080 sinatra\-app
+
+.fi
+.RE
+
+.PP
+To change your source code in running container, use Docker's exec
+\[la]http://docker.io\[ra] command:
+
+.PP
+.RS
+
+.nf
+docker exec \-it <CONTAINER\_ID> /bin/bash
+
+.fi
+.RE
+
+.PP
+After you Docker exec
+\[la]http://docker.io\[ra] into the running container, your current
+directory is set to \fB\fC/opt/app\-root/src\fR, where the source code is located.
+
+.SH Performance tuning
+.PP
+You can tune the number of threads per worker using the
+\fB\fCPUMA\_MIN\_THREADS\fR and \fB\fCPUMA\_MAX\_THREADS\fR 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
+\[la]https://github.com/puma/puma\[ra]\&'s documentation. This is determined using
+the cgroup cpusets
+\[la]https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt\[ra]
+subsystem. You can specify the cores that the container is allowed to use by passing
+the \fB\fC\-\-cpuset\-cpus\fR parameter to the Docker
+\[la]http://docker.io\[ra] run command:
+
+.PP
+.RS
+
+.nf
+$ docker run \-e PUMA\_MAX\_THREADS=32 \-\-cpuset\-cpus='0\-2,3,5' \-p 8080:8080 sinatra\-app
+
+.fi
+.RE
+
+.PP
+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:
+
+.PP
+.RS
+
+.nf
+50 + 15 * WORKERS + 0.125 * WORKERS * PUMA\_MAX\_THREADS
+
+.fi
+.RE
+
+.PP
+You can specify a memory limit using the \fB\fC\-\-memory\fR flag:
+
+.PP
+.RS
+
+.nf
+$ docker run \-e PUMA\_MAX\_THREADS=32 \-\-memory=300m \-p 8080:8080 sinatra\-app
+
+.fi
+.RE
+
+.PP
+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 \fB\fCPUMA\_WORKERS\fR\&.
+
+.SH See also
+.PP
+Dockerfile and other sources are available on 
+\[la]https://github.com/sclorg/s2i-ruby-container\[ra]\&.
+In that repository you also can find another versions of Python environment Dockerfiles.
+Dockerfile for CentOS is called Dockerfile, Dockerfile for RHEL is called Dockerfile.rhel7.

root/opt/app-root/.gemrc

@@ -0,0 +1,9 @@
+---
+install: --no-document
+update: --no-document
+:benchmark: false
+:update_sources: true
+:bulk_threshold: 1000
+:backtrace: true
+:sources:
+- https://rubygems.org/

root/opt/app-root/etc/puma.cfg

@@ -0,0 +1,50 @@
+def get_max_memory()
+    return ENV['MEMORY_LIMIT_IN_BYTES'].to_i if ENV.has_key? 'MEMORY_LIMIT_IN_BYTES'
+
+    # Assume unlimited memory. 0.size is the number of bytes a Ruby
+    # Fixnum class can hold. One bit is used for sign and one is used
+    # by Ruby to determine whether it's a number or pointer to an object.
+    # That's why we subtract two bits. This expresion should therefore be
+    # the largest signed Fixnum possible.
+    (2 ** (8*0.size - 2) - 1)
+end
+
+def get_memory_per_worker()
+    bytes = ENV.fetch('MEMORY_BYTES_PER_WORKER', '0').to_i
+    if bytes == 0
+        # Comment describing rationale for choosing default of 256MiB/worker is below.
+        bytes = 256 * (2**20)
+    end
+    bytes
+end
+
+def get_min_threads()
+    ENV.fetch('PUMA_MIN_THREADS', '0').to_i
+end
+
+def get_max_threads()
+    ENV.fetch('PUMA_MAX_THREADS', '16').to_i
+end
+
+# Determine the maximum number of workers that are allowed by the available
+# memory.  Puma documentation recommends the maximum number of workers to be
+# set to the number of cores.
+# Unless we're specifically tuned otherwise, allow one worker process per 256MiB
+# memory, to a maximum of 1 worker / core.  Hopefully that'll be a reasonable
+# starting point for average apps; if not, it's all tunable.  The simple
+# OpenShift ruby/rails sample app currently requires approx. 60MiB +
+# 70MiB/worker before taking its first request, so hopefully a default of
+# 256MiB/worker will give other simple apps reasonable default headroom.
+def get_workers()
+    return ENV['PUMA_WORKERS'].to_i if ENV.has_key? 'PUMA_WORKERS'
+
+    cores = ENV.fetch('NUMBER_OF_CORES', '1').to_i
+    max_workers = get_max_memory() / get_memory_per_worker()
+
+    [cores, max_workers].min
+end
+
+environment ENV['RACK_ENV'] || ENV['RAILS_ENV'] || 'production'
+threads     get_min_threads(), get_max_threads()
+workers     get_workers()
+bind        'tcp://0.0.0.0:8080'

root/opt/app-root/etc/scl_enable

@@ -0,0 +1,6 @@
+# IMPORTANT: Do not add more content to this file unless you know what you are
+#            doing. This file is sourced everytime the shell session is opened.
+#
+# This will make scl collection binaries work out of box.
+unset BASH_ENV PROMPT_COMMAND ENV
+source scl_source enable rh-ruby25 $NODEJS_SCL