Chapter 2. Source-to-Image (S2I)
2.1. Overview
This topic group includes information on the different S2I (Source-to-Image) supported images available for OpenShift users.
2.2. Node.js
2.2.1. Overview
OpenShift provides S2I enabled Node.js images for building and running Node.js applications. The Node.js S2I builder image assembles your application source with any required dependencies to create a new image containing your Node.js application. This resulting image can be run either by OpenShift or by Docker.
2.2.2. Versions
Currently, OpenShift provides version 0.10 of Node.js.
2.2.3. Images
This image comes in two flavors, depending on your needs:
- RHEL 7
- CentOS 7
RHEL 7 Based Image
The RHEL 7 image is available through Red Hat’s subscription registry via:
$ docker pull registry.access.redhat.com/openshift3/nodejs-010-rhel7
CentOS 7 Based Image
This image is available on DockerHub. To download it:
$ docker pull openshift/nodejs-010-centos7
To use these images, you can either access them directly from these image registries, or push them into your OpenShift 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 OpenShift resources can then reference the ImageStream. You can find example ImageStream definitions for all the provided OpenShift images.
2.2.4. Configuration
The Node.js image does not offer any environment variable based configuration settings.
2.3. Ruby
2.3.1. Overview
OpenShift 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 or by Docker.
2.3.2. Versions
Currently, OpenShift provides version 2.0 of Ruby.
2.3.3. Images
This image comes in two flavors, depending on your needs:
- RHEL 7
- CentOS 7
RHEL 7 Based Image
The RHEL 7 image is available through Red Hat’s subscription registry via:
$ docker pull registry.access.redhat.com/openshift3/ruby-20-rhel7
CentOS 7 Based Image
This image is available on DockerHub. To download it:
$ docker pull openshift/ruby-20-centos7
To use these images, you can either access them directly from these image registries, or push them into your OpenShift 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 OpenShift resources can then reference the ImageStream. You can find example ImageStream definitions for all the provided OpenShift images.
2.3.4. 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, you can place them into a .sti/environment file inside your source code repository, or define them in the environment section of the BuildConfig Source Strategy definition.
| Variable name | Description |
|---|---|
|
|
This variable specifies the environment within which the Ruby application is deployed; for example, |
|
|
This variable specifies the environment within which the Ruby on Rails application is deployed; for example, |
|
| The presence of 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. |
2.4. Perl
2.4.1. Overview
OpenShift provides S2I enabled Perl images for building and running Perl applications. The Perl S2I builder image assembles your application source with any required dependencies to create a new image containing your Perl application. This resulting image can be run either by OpenShift or by Docker.
2.4.2. Versions
Currently, OpenShift supports version 5.16 of Perl.
2.4.3. Images
This image comes in two flavors, depending on your needs:
- RHEL 7
- CentOS 7
RHEL 7 Based Image
The RHEL 7 image is available through Red Hat’s subscription registry via:
$ docker pull registry.access.redhat.com/openshift3/perl-516-rhel7
CentOS 7 Based Image
This image is available on DockerHub. To download it:
$ docker pull openshift/perl-516-centos7
To use these images, you can either access them directly from these image registries, or push them into your OpenShift 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 OpenShift resources can then reference the ImageStream. You can find example image stream definitions for all the provided OpenShift images.
2.4.4. Configuration
The Perl image supports a number of environment variables which can be set to control the configuration and behavior of the Perl runtime.
To set these environment variables, you can place them into .sti/environment file inside your source code repository, or define them in the environment section of the BuildConfig Source Strategy definition.
| Variable name | Description |
|---|---|
|
| This variable installs all the cpan modules and runs their tests. By default, the testing of the modules is turned off. |
|
| This variable specifies a mirror URL which cpanminus uses to install dependencies. By default, this URL is not specified. |
2.5. PHP
2.5.1. Overview
OpenShift provides S2I enabled PHP images for building and running PHP applications. The PHP S2I builder image assembles your application source with any required dependencies to create a new image containing your PHP application. This resulting image can be run either by OpenShift or by Docker.
2.5.2. Versions
Currently, OpenShift provides version 5.5 of PHP.
2.5.3. Images
This image comes in two flavors, depending on your needs:
- RHEL 7
- CentOS 7
RHEL 7 Based Image
The RHEL 7 image is available through Red Hat’s subscription registry via:
$ docker pull registry.access.redhat.com/openshift3/php-55-rhel7
CentOS 7 Based Image
This image is available on DockerHub. To download it:
$ docker pull openshift/php-55-centos7
To use these images, you can either access them directly from these image registries, or push them into your OpenShift 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 OpenShift resources can then reference the ImageStream. You can find example ImageStream definitions for all the provided OpenShift images.
2.5.4. Configuration
The PHP image supports a number of environment variables which can be set to control the configuration and behavior of the PHP runtime.
To set these environment variables, you can place them into .sti/environment file inside your source code repository, or define them in the environment section of the BuildConfig Source Strategy definition.
The following environment variables set their equivalent property value in the php.ini file:
| Variable name | Description | Default |
|---|---|---|
|
| Informs PHP of the errors, warnings, and notices for which you would like it to take action. | E_ALL & ~E_NOTICE |
|
| Controls if and where PHP outputs errors, notices, and warnings. | ON |
|
| Causes any display errors that occur during PHP’s startup sequence to be handled separately from display errors. | OFF |
|
|
Stores the last error/warning message in | OFF |
|
| Links errors to documentation that is related to the error. | ON |
|
| Path for PHP source files. | |
|
| Location for session data files. | /tmp/sessions |
The following environment variable sets its equivalent property value in the opcache.ini file:
| Variable name | Description | Default |
|---|---|---|
|
| The OPcache shared memory storage size. | 16M |
You can also override the entire directory used to load the PHP configuration by setting:
| Variable name | Description |
|---|---|
|
| Sets the path to the php.ini file. |
|
| Path to scan for additional ini configuration files |
2.5.4.1. Apache Configuration
If the DocumentRoot of the application is nested in the source directory /opt/openshift/src, you can provide your own .htaccess file to override the default Apache behavior and specify how application requests should be handled. The .htaccess file must be located at the root of the application source.
2.5.5. Logs
This image logs primarily to standard out and as such the logs can be viewed via the oc logs command. Access logs are stored in /tmp/access_log which can be viewed using oc exec to access the container.
2.6. Python
2.6.1. Overview
OpenShift provides S2I enabled Python images for building and running Python applications. The Python S2I builder image assembles your application source with any required dependencies to create a new image containing your Python application. This resulting image can be run either by OpenShift or by Docker.
2.6.2. Versions
Currently, OpenShift provides version 3.3 of Python.
2.6.3. Images
This image comes in two flavors, depending on your needs:
- RHEL 7
- CentOS 7
RHEL 7 Based Image
The RHEL 7 image is available through Red Hat’s subscription registry via:
$ docker pull registry.access.redhat.com/openshift3/python-33-rhel7
CentOS 7 Based Image
This image is available on DockerHub. To download it:
$ docker pull openshift/python-33-centos7
To use these images, you can either access them directly from these image registries, or push them into your OpenShift 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 OpenShift resources can then reference the ImageStream. You can find example ImageStream definitions for all the provided OpenShift images.
2.6.4. Configuration
The Python image supports a number of environment variables which can be set to control the configuration and behavior of the Python runtime.
To set these environment variables, you can place them into a .sti/environment file inside your source code repository, or define them in the environment section of the BuildConfig Source Strategy definition.
| Variable name | Description |
|---|---|
|
| This variable specifies the file name passed to the python interpreter which is responsible for launching the application. This variable is set to app.py by default. |
|
|
This variable specifies the WSGI callable. It follows the pattern |
|
| This variable indicates the path to a valid Python file with a gunicorn configuration. |
|
|
Set it to a nonempty value to inhibit the execution of |
|
|
Set it to a nonempty value to inhibit the execution of |
