Using Red Hat Software Collections Container Images
THIS DOCUMENT IS OBSOLETE
See Using Red Hat Software Collections 3 Container Images or Using Red Hat Software Collections 2 Container Images instead
As a part of the Red Hat Software Collections offering, Red Hat provides a number of container images, which are based on the corresponding Software Collections. These include application, daemon, and database images. The provided images are detailed in tables Container Images Based on Red Hat Software Collections 2.3, Container Images Based on Red Hat Software Collections 2.2, and Container Images Based on Red Hat Software Collections 2.0.
You can use these images in a containerized environment to build, deploy, and run your applications.
For more information on containers and container images, see the Core Concepts of the OpenShift Enterprise 3.0 Architecture, which discusses core concepts and methods related to delivering containerized applications.
For more information on Software Collections, see the Red Hat Software Collections documentation.
Note that running Red Hat Software Collections container images is supported only on Red Hat Enterprise Linux 7 Server and Red Hat Enterprise Linux Atomic Host. You cannot run the images on Red Hat Enterprise Linux 7 Workstation or Red Hat Enterprise Linux 6 or earlier.
When using SELinux for controlling processes within a container, make sure that any content that is volume mounted into the container is readable, and potentially writable, depending on the use case. For more information, see Using Volumes With the docker Container Can Cause Problems With SELinux .
Using Red Hat Software Collections Container Images
There are two basic approaches that you can take to use the container images shipped with Red Hat Software Collections: using base images or using Source-to-Image.
Using Base Images
To use container images provided by Red Hat as base images in your own Dockerfile, add the following line to it:
FROM registry.access.redhat.com/rhscl/python-35-rhel7
Working with Dockerfiles is covered in the document Red Hat Enterprise Linux Atomic Host 7 Getting Started with Containers. Detailed information on Dockerfiles can be found in the Dockerfile reference document.
Using Source-to-Image (S2I)
Source-to-Image (S2I) is a framework and a tool that allows you to write images which use the application source code as an input and produce a new image that runs the assembled application as an output. The main advantage of using the S2I tool for building reproducible container images is the ease of use for developers.
To use the S2I tool on your system, subscribe to Red Hat Software Collections and run the following command to install the source-to-image package:
# yum install source-to-image
Use the RHSM channel: rhel-server-rhscl-7-rpms. Note that the source-to-image package requires the docker package from the Red Hat Enterprise Linux Extras channel.
Alternatively, you can use the RHN channel rhel-x86_64-server-7-rhscl-1 but note that the RHN channel is accessible only through Red Hat Satellite instances.
For details about subscribing to Red Hat Software Collections, see Getting Access to Red Hat Software Collections.
More information about the S2I tool is available at GitHub.
Note that, similarly to Red Hat Software Collections container images, using the S2I tool is supported only on Red Hat Enterprise Linux 7 Server. You cannot run the tool on Red Hat Enterprise Linux 7 Workstation.
Build Process
The build process consists of the following three fundamental elements, which are combined into a final container image:
- The source code of your application -- written in a programming language or framework
- Builder image -- container image provided by Red Hat that supports building images using the S2I tool
- S2I scripts that are part of the builder image
During the build process, S2I creates a tar file that contains the source code and scripts, then streams that file into the builder image.
For more information on the Source-to-Image framework, see S2I Requirements.
Example: building a Python application from Git using S2I
This example shows how to build:
- A new container image from the
python-35-rhel7builder image that is available in the Red Hat Container Registry, and - A test application available from a public Git repository in the GitHub sti-python repository, in the
3.5/test/setup-test-app/directory.
-
Install the S2I tool from the Red Hat Software Collections repository:
# yum install source-to-image -
Pull the builder image:
# docker pull registry.access.redhat.com/rhscl/python-35-rhel7 -
Build the test application from the GitHub sti-python repository, underneath the
3.5/test/setup-test-app/directory:# s2i build https://github.com/openshift/sti-python.git --context-dir=3.5/test/setup-test-app/ rhscl/python-35-rhel7 python-35-rhel7-appThis produces a new application image
python-35-rhel7-app. -
Run the resulting
python-35-rhel7-appimage:# docker run -d -p 8080:8080 --name example-app python-35-rhel7-app -
Fetch a document from
http://localhost:8080/:$ wget http://localhost:8080/The example document is returned.
-
Stop the container:
# docker stop example-app
Container Images Based on Red Hat Software Collections 2.3
| Component | Description |
|---|---|
| Application Images | |
rhscl/perl-524-rhel7 |
Perl 5.24 platform for building and running applications |
rhscl/php-56-rhel7 |
PHP 5.6 platform for building and running applications |
rhscl/php-70-rhel7 |
PHP 7.0 platform for building and running applications |
rhscl/python-35-rhel7 |
Python 3.5 platform for building and running applications |
rhscl/ruby-23-rhel7 |
Ruby 2.3 platform for building and running applications |
rhscl/thermostat-16-agent-rhel7 |
Thermostat 1.6 agent suitable for monitoring Java applications in other containers |
rhscl/thermostat-16-storage-rhel7 |
Thermostat 1.6 storage, a web endpoint for storing and retrieving data |
| Database Images | |
rhscl/mysql-57-rhel7 |
MySQL 5.7 SQL database server |
rhscl/mongodb-32-rhel7 |
MongoDB 3.2 NoSQL database server |
rhscl/redis-32-rhel7 |
Redis 3.2 key-value store |
All images are based on components from Red Hat Software Collections. The images are available for Red Hat Enterprise Linux 7 through the Red Hat Container Registry.
For detailed information about components provided by Red Hat Software Collections 2.3, refer to the Red Hat Software Collections 2.3 Release Notes.
Additionally, two Red Hat Developer Toolset container images are available:
-
The
rhscl/devtoolset-6-toolchain-rhel7image, which contains the following Red Hat Developer Toolset components:- devtoolset-6-gcc
- devtoolset-6-gcc-c++
- devtoolset-6-gcc-fortran
- devtoolset-6-gdb
-
The
rhscl/devtoolset-6-perftools-rhel7image, which contains:- devtoolset-6-oprofile
- devtoolset-6-systemtap
- devtoolset-6-valgrind
- devtoolset-6-dyninst
- devtoolset-6-elfutils
For more information about the Red Hat Developer Toolset 6.0 components, see the Red Hat Developer Toolset 6.0 User Guide.
Container Images Based on Red Hat Software Collections 2.2
| Component | Description |
|---|---|
| Application Images | |
rhscl/nodejs-4-rhel7 |
Node.js 4 platform for building and running applications |
rhscl/python-27-rhel7 |
Python 2.7 platform for building and running applications |
rhscl/ror-42-rhel7 |
Ruby on Rails 4.2 platform for building and running applications |
rhscl/thermostat-1-agent-rhel7 |
Thermostat 1.4 agent suitable for monitoring Java applications in other containers |
| Daemon Images | |
rhscl/httpd-24-rhel7 |
Apache HTTP 2.4 Server |
rhscl/nginx-18-rhel7 |
nginx 1.8 server and a reverse proxy server |
rhscl/varnish-4-rhel7 |
Varnish Cache 4.0 HTTP reverse proxy |
| Database Images | |
rhscl/mariadb-101-rhel7 |
MariaDB 10.1 SQL database server |
rhscl/postgresql-95-rhel7 |
PostgreSQL 9.5 SQL database server |
All images are based on components from Red Hat Software Collections. The images are available for Red Hat Enterprise Linux 7 through the Red Hat Container Registry.
For detailed information about components provided by Red Hat Software Collections 2.2, refer to the Red Hat Software Collections 2.2 Release Notes.
Additionally, two Red Hat Developer Toolset container images are available:
-
The
rhscl/devtoolset-4-toolchain-rhel7image, which contains the following Red Hat Developer Toolset components:- devtoolset-4-gcc
- devtoolset-4-gcc-c++
- devtoolset-4-gcc-fortran
- devtoolset-4-gdb
-
The
rhscl/devtoolset-4-perftools-rhel7image, which contains:- devtoolset-4-oprofile
- devtoolset-4-systemtap
- devtoolset-4-valgrind
- devtoolset-4-dyninst
- devtoolset-4-elfutils
For more information about the Red Hat Developer Toolset 4.1 components, see the Red Hat Developer Toolset 4.1 User Guide.
Container Images Based on Red Hat Software Collections 2.0
| Component | Description |
|---|---|
| Application Images | |
rhscl/python-34-rhel7 |
Python 3.4 platform for building and running applications |
rhscl/perl-520-rhel7 |
Perl 5.20 platform for building and running applications |
rhscl/ruby-22-rhel7 |
Ruby 2.2 platform for building and running applications |
rhscl/ror-41-rhel7 |
Ruby on Rails 4.1 platform for building and running applications |
rhscl/passenger-40-rhel7 |
Phusion Passenger 4.0 web server and application server |
| Daemon Images | |
rhscl/nginx-16-rhel7 |
nginx 1.6 server and a reverse proxy server |
| Database Images | |
rhscl/mysql-56-rhel7 |
MySQL 5.6 SQL database server |
rhscl/mariadb-100-rhel7 |
MariaDB 10.0 SQL database server |
rhscl/postgresql-94-rhel7 |
PostgreSQL 9.4 SQL database server |
rhscl/mongodb-26-rhel7 |
MongoDB 2.6 NoSQL database server |
All images are based on components from Red Hat Software Collections. The images are available for Red Hat Enterprise Linux 7 through the Red Hat Container Registry.
For detailed information about components provided by Red Hat Software Collections 2.0, refer to the Red Hat Software Collections 2.0 Release Notes.
Application Images
Node.js
Description
The rhscl/nodejs-4-rhel7 image provides a Node.js 4 platform for building and running applications.
Access
To pull the rhscl/nodejs-4-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/nodejs-4-rhel7
Configuration
No further configuration is required.
Perl
Description
The rhscl/perl-524-rhel7 image provides a Perl 5.24 platform for building and running applications, the rhscl/perl-520-rhel7 image provides a Perl 5.20 platform. Apache httpd 2.4 with mod_perl for deploying Perl web applications is preinstalled. The images also supports deploying Perl Web Server Gateway Interface (PSGI) applications.
Access
To pull the rhscl/perl-524-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/perl-524-rhel7
To pull the rhscl/perl-520-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/perl-520-rhel7
Configuration
To set environment variables, you can place them as a key-value pair into a .sti/environment file inside your source code repository.
| Variable Name | Description | Default |
|---|---|---|
ENABLE_CPAN_TEST |
Allows the installation of all specified cpan packages and the running of their tests | false |
CPAN_MIRROR |
Specifies a mirror URL which will used by cpanminus to install dependencies | URL is not specified by default |
PSGI_FILE |
Specifies relative path to the PSGI application file; Use empty value to disable the PSGI autoconfiguration | Single *.psgi file in the top-level directory, if it exists |
PSGI_URI_PATH |
Specifies URI path that is handled by the PSGI application | / |
To install additional Perl modules from the Comprehensive Perl Archive Network (CPAN), create a cpanfile in the root directory of your application sources. The file must conform to the cpanfile format as defined in Module-CPANFile CPAN distribution. For detailed information about the cpanfile format, refer to the cpanfile documentation.
To modify the Apache httpd behavior, drop the .htaccess file in the application sources tree where appropriate. For details about .htaccess, see the Apache HTTP Server Tutorial.
PHP
Description
The rhscl/php-70-rhel7 image provides a PHP 7.0 platform for building and running applications and is based on therh-php70 Software Collection. The rhscl/php-56-rhel7 image provides a PHP 5.6 platform for building and running applications and is based on the updated rh-php56 Software Collection shipped in Red Hat Software Collections 2.3.
Access
To pull the rhscl/php-70-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/php-70-rhel7
To pull the rhscl/php-56-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/php-56-rhel7
Configuration
To set environment variables, place them as a key-value pair into a .sti/environment file inside your source code repository.
The following environment variables set their equivalent property value in the php.ini file:
| Variable Name | Description | Default |
|---|---|---|
ERROR_REPORTING |
Informs PHP of which errors, warnings and notices you would like it to take action for | E_ALL & ~E_NOTICE |
DISPLAY_ERRORS |
Controls whether or not and where PHP will output errors, notices and warnings | ON |
DISPLAY_STARTUP_ERRORS |
Cause display errors which occur during PHP's startup sequence to be handled separately from display errors | OFF |
TRACK_ERRORS |
Store the last error/warning message in $php_errormsg (boolean) |
OFF |
HTML_ERRORS |
Link errors to documentation related to the error | ON |
INCLUDE_PATH |
Path for PHP source files | .:/opt/app-root/src:/opt/rh/php56/root/usr/share/pear |
SESSION_PATH |
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 |
|---|---|---|
OPCACHE_MEMORY_CONSUMPTION |
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 |
|---|---|
PHPRC |
Sets the path to the php.ini file |
PHP_INI_SCAN_DIR |
Path to scan for additional ini configuration files |
In case the DocumentRoot of the application is nested within the source directory /opt/app-root/src, users can provide their own .htaccess file. This allows the overriding of Apache's behavior and specifies how application requests should be handled. The .htaccess file needs to be located at the root of the application source. For details about .htaccess, see the Apache HTTP Server Tutorial.
Python
Description
The rhscl/python-35-rhel7 image provides a Python 3.5 platform for building and running applications and is based on the updated rh-python35 Software Collection shipped in Red Hat Software Collections 2.3. The rhscl/python-34-rhel7 includes a Python 3.4 platform, and the rhscl/python-27-rhel7 image provides a Python 2.7 platform.
Access
To pull the rhscl/python-35-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/python-35-rhel7
To pull the rhscl/python-34-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/python-34-rhel7
To pull the rhscl/python-27-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/python-27-rhel7
Configuration
To set environment variables, you can place them as a key-value pair into a .sti/environment file inside your source code repository.
| Variable Name | Description |
|---|---|
APP_FILE |
Used to run the application from a Python script. This should be a path to a Python file (defaults to app.py) that will be passed to the Python interpreter to start the application. |
APP_MODULE |
Used to run the application with Gunicorn, as documented here. This variable specifies a WSGI callable with the pattern MODULE_NAME:VARIABLE_NAME, where MODULE_NAME is the full dotted path of a module, and VARIABLE_NAME refers to a WSGI callable inside the specified module. Gunicorn will look for a WSGI callable named application if not specified. If APP_MODULE is not provided, the run script will look for a wsgi.py file in your project and use it if it exists. If using setup.py for installing the application, the MODULE_NAME part can be read from there. For an example, see setup-test-app. |
APP_CONFIG |
Path to a valid Python file with a Gunicorn configuration file. |
DISABLE_COLLECTSTATIC |
Set this variable to a non-empty value to inhibit the execution of manage.py collectstatic during the build. This affects only Django projects. |
DISABLE_MIGRATE |
Set this variable to a non-empty value to inhibit the execution of manage.py migrate when the produced image is run. This affects only Django projects. |
Ruby
Description
The rhscl/ruby-23-rhel7 image provides a Ruby 2.3 platform for building and running applications and is based on the updated rh-ruby23 Software Collection shipped in Red Hat Software Collections 2.3. Node.js 4 is preinstalled for assets compilation. The rhscl/ruby-22-rhel7 image provides a Ruby 2.2 platform; Node.js 0.10 is preinstalled for assets compilation.
Access
To pull the rhscl/ruby-23-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/ruby-23-rhel7
To pull the rhscl/ruby-22-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/ruby-22-rhel7
Configuration
To set environment variables, you can place them as a key-value pair into a .sti/environment file inside your source code repository.
| Variable Name | Description |
|---|---|
RACK_ENV |
This variable specifies the environment where the Ruby application will be deployed (unless overwritten) - production, development, test. Each level has different behaviors in terms of logging verbosity, error pages, Ruby gem installation, and other. Note that application assets will be compiled only if the RACK_ENV is set to production. |
DISABLE_ASSET_COMPILATION |
This variable indicates that the asset compilation process will be skipped. Because this only takes place when the application is run in the production environment, it should be used only when assets are already compiled. |
PUMA_MIN_THREADS, PUMA_MAX_THREADS |
These variables indicate the minimum and maximum threads that will be available in Puma's thread pool. |
PUMA_WORKERS |
This variable indicates the number of worker processes that will be launched. See documentation on Puma's clustered mode. |
RUBYGEM_MIRROR |
Set this variable to use a custom RubyGems mirror URL to download required gem packages during the build process. |
For S2I scripts to work, you need to include the puma or rack gem in the application's Gemfile.
Ruby on Rails
Description
The rhscl/ror-42-rhel7 provides a Ruby on Rails 4.2 platform for building and running applications. It contains Ruby 2.3, Ruby on Rails 4.2, and Node.js 4 preinstalled.
The rhscl/ror-41-rhel7 provides a Ruby on Rails 4.1 platform and it contains Ruby 2.2, Ruby on Rails 4.1, and Node.js 0.10 preinstalled.
Access
To pull the rhscl/ror-42-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/ror-42-rhel7
To pull the rhscl/ror-41-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/ror-41-rhel7
Configuration
No further configuration is required. The rhscl/ror-42-rhel7 image contains and enables the rh-ruby23, rh-ror42, and rh-nodejs4 Software Collections. The rhscl/ror-41-rhel7 image contains and enables the rh-ruby22, rh-ror41, and nodejs010 Software Collections. For automatic S2I builds, use the Ruby container.
Phusion Passenger
Description
The rhscl/passenger-40-rhel7 image provides a Phusion Passenger 4.0 application server configured with Apache httpd web server. It also provides a Ruby 2.2 platform for building and running applications. Node.js 0.10 is preinstalled for assets compilation.
Access
To pull the rhscl/passenger-40-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/passenger-40-rhel7
Configuration
No further configuration is required; this image contains and enables the rh-ruby22, rh-ror41, nodejs010, rh-passenger40, and httpd24 Software Collections. It is especially designed to support automatic S2I builds.
Thermostat Agent
Description
The rhscl/thermostat-16-agent-rhel7 image provides a thermostat agent suitable for monitoring Java applications in other containers and is based on the rh-thermostat16 Software Collection shipped in Red Hat Software Collections 2.3. The rhscl/thermostat-1-agent-rhel7 image is based on the thermostat1 Software Collection shipped in Red Hat Software Collections 2.2.
Access
To pull the rhscl/thermostat-16-agent-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/thermostat-16-agent-rhel7
To pull the rhscl/thermostat-1-agent-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/thermostat-1-agent-rhel7
Usage
If you want to set only the mandatory environment variables, connect to Thermostat storage exposed through http://example.com/thermostat/storage and other containers running Java applications, which expose their Hotspot performance data to /docker/tmp, execute the following command:
docker run -d --privileged --pid host --net host \
-e THERMOSTAT_AGENT_USERNAME=user -e THERMOSTAT_AGENT_PASSWORD=password \
-e THERMOSTAT_CMDC_PORT=12000 -e THERMOSTAT_CMDC_ADDR=192.168.0.1 \
-e THERMOSTAT_DB_URL=http://example.com/thermostat/storage \
--name thermostat1-agent
-v /docker/tmp:/tmp rhscl/thermostat-1-agent-rhel7
Change the image name if you are using the rhscl/thermostat-16-agent-rhel7 image.
Usage for Running Java Applications being Monitored in Separate Containers
In order for Java applications to be properly monitored by the super-privileged Agent Docker image, containers with Java applications need to:
- Expose
/tmp/hsperfdata_*to host's/docker/tmp(using -v/docker/tmp:/tmp) - Mount the volume exposed by the Thermostat agent image. This is necessary so that the Thermostat built-in JVM agent for profiling Java apps will be available to the container running the Java application.
- Share the host's network stack. This is needed so that JMX connections work cross-container.
- Share the host's PID space. This is necessary since
hsperfdata_*is closely tied to the PIDs being created for Java applications.
If you want to run a Java application using the image hello-world-webapp and you want this application to get monitored by an instance of the thermostat1-agent image, the application needs to get started using Docker:
docker run -d --pid host \
--net host \
--volumes-from=thermostat1-agent \
--name hello-world \
-v /docker/tmp:/tmp hello-world-webapp
Change the image name if you are using the rhscl/thermostat-16-agent-rhel7 image.
Configuration
The image recognizes the following environment variables that you can set during initialization by passing -e VAR=VALUE to the docker run command:
| Variable Name | Description |
|---|---|
THERMOSTAT_AGENT_USERNAME |
User name for the Thermostat agent to use connecting to storage |
THERMOSTAT_AGENT_PASSWORD |
Password for connecting to storage |
THERMOSTAT_CMDC_PORT |
The port to bind the command channel to |
THERMOSTAT_CMDC_ADDR |
The address to bind the command channel to |
THERMOSTAT_DB_URL |
The URL for Thermostat storage |
Thermostat Storage
Description
The rhscl/thermostat-16-storage-rhel7 contains a Thermostat 1.6 storage, which provides a web endpoint for storing and retrieving data. This image is based on the rh-thermostat16 Software Collection shipped in Red Hat Software Collections 2.3.
Access
To pull the rhscl/thermostat-16-storage-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/thermostat-16-storage-rhel7
Usage
To run Thermostat storage connected to some other MongoDB backend (for example, provided by another container), you need to provide the MongoDB URL, mongo user name and password, and the agent and client user name and passwords. Run the following command:
docker run -d \
-e MONGO_URL=mongodb://172.17.0.1:27017 \
-e MONGO_USERNAME=mongouser \
-e MONGO_PASSWORD=mongopass \
-e THERMOSTAT_AGENT_USERNAME=agentuser \
-e THERMOSTAT_AGENT_PASSWORD=agentpass \
-e THERMOSTAT_CLIENT_USERNAME=clientuser \
-e THERMOSTAT_CLIENT_PASSWORD=clientpass \
--name thermostat16-storage \
rhscl/thermostat-16-storage-rhel7
This will run a container with the HTTP layer connected to the MongoDB URL using the provided mongo user name and password. The container can be accessed at http://ip-address:port/thermostat/storage with the appropriate client or agent credentials that you specified with the environment variables. The port number is 8999 by default but can be specified using the THERMOSTAT_DB_PORT environment variable and exposing the port with the -p option. To find the IP address, run the following command:
docker inspect --format '{{ .NetworkSettings.IPAddress }}' thermostat16-storage
Configuration
The rhscl/thermostat-16-storage-rhel7 image recognizes the following environment variables that you can set during initialization by passing -e VAR=VALUE to the docker run command:
| Variable Name | Description |
|---|---|
THERMOSTAT_AGENT_USERNAME |
User name for Thermostat agents to connect to storage |
THERMOSTAT_AGENT_PASSWORD |
Password for agents connecting to storage |
THERMOSTAT_CLIENT_USERNAME |
User name for Thermostat clients to connect to storage |
THERMOSTAT_CLIENT_PASSWORD |
Password for clients connecting to storage |
THERMOSTAT_DB_PORT |
The port for Thermostat storage to listen on |
MONGO_USERNAME |
User name for the MongoDB backing storage |
MONGO_PASSWORD |
Password for the MongoDB backing storage |
MONGO_URL |
MongoDB URL to connect to |
Daemon Images
Apache HTTP Server
Description
The rhscl/httpd-24-rhel7 image provides an Apache HTTP 2.4 Server. The image can be used as a base image for other applications based on Apache HTTP web server.
Access
To pull the rhscl/httpd-24-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/httpd-24-rhel7
The rhscl/httpd-24-rhel7 image supports using the S2I tool.
Configuration
The Apache HTTP Server container image supports the following configuration variable, which can be set by using the -e option with the docker run command:
| Variable Name | Description |
|---|---|
HTTPD_LOG_TO_VOLUME |
By default, httpd logs into standard output, so the logs are accessible by using the docker logs command. When HTTPD_LOG_TO_VOLUME is set, httpd logs into /var/log/httpd24, which can be mounted to host system using the Docker volumes. |
nginx
Description
The rhscl/nginx-18-rhel7 image provides an nginx 1.8 server and a reverse proxy server; the image can be used as a base image for other applications based on nginx 1.8 web server.
Access
To pull the rhscl/nginx-18-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/nginx-18-rhel7
Configuration
The nginx container image supports the following configuration variable, which can be set by using the -e option with the docker run command:
| Variable Name | Description |
|---|---|
NGINX_LOG_TO_VOLUME |
By default, nginx logs into standard output, so the logs are accessible by using the docker logs command. When NGINX_LOG_TO_VOLUME is set, nginx logs into /var/log/nginx18, which can be mounted to host system using the Docker volumes. |
The rhscl/nginx-18-rhel7 image supports using the S2I tool.
Varnish Cache
Description
The rhscl/varnish-4-rhel7 image provides Varnish Cache 4.0, an HTTP reverse proxy.
Access
To pull the rhscl/varnish-4-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/varnish-4-rhel7
Configuration
No further configuration is required.
The rhscl/varnish-4-rhel7 image supports using the S2I tool. Note that the default.vcl configuration file in the directory accessed by S2I needs to be in the VCL format.
Database Images
MySQL
Description
The rhscl/mysql-56-rhel7 image provides a MySQL 5.6 SQL database server. The rhscl/mysql-57-rhel7 image provides a MySQL 5.7 SQL database server.
Access and Usage
To pull the rhscl/mysql-56-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/mysql-56-rhel7
To pull the rhscl/mysql-57-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/mysql-57-rhel7
To set only the mandatory environment variables and not store the database in a host directory, execute the following command:
docker run -d --name mysql_database -e MYSQL_USER=user -e MYSQL_PASSWORD=pass -e MYSQL_DATABASE=db -p 3306:3306 rhscl/mysql-56-rhel7
Change the image name if you are using the rhscl/mysql-57-rhel7 image,
This will create a container named mysql_database running MySQL with database db and user with credentials user:pass. Port 3306 will be exposed and mapped to the host. If you want your database to be persistent across container executions, also add a -v /host/db/path:/var/lib/mysql/data:Z argument. The directory /host/db/path will be the MySQL data directory.
If the database directory is not initialized, the entrypoint script will first run mysql_install_db and set up necessary database users and passwords. After the database is initialized, or if it was already present, mysqld is executed and will run as PID 1. You can stop the detached container by running the docker stop mysql_database command.
Configuration
The image recognizes the following environment variables that you can set during initialization by passing -e VAR=VALUE to the docker run command:
| Variable Name | Description |
|---|---|
MYSQL_USER |
User name for MySQL account to be created |
MYSQL_PASSWORD |
Password for the user account |
MYSQL_DATABASE |
Database name |
MYSQL_ROOT_PASSWORD |
Password for the root user (optional) |
Note: The root user has no password set by default, only allowing local connections. You can set it by setting the MYSQL_ROOT_PASSWORD environment variable when initializing your container. This will allow you to login to the root account remotely. Local connections will still not require a password.
The following environment variables influence the MySQL configuration file and are all optional:
| Variable name | Description | Default |
|---|---|---|
MYSQL_LOWER_CASE_TABLE_NAMES |
Sets how the table names are stored and compared | 0 |
MYSQL_MAX_CONNECTIONS |
The maximum permitted number of simultaneous client connections | 151 |
MYSQL_MAX_ALLOWED_PACKET |
The maximum size of one packet or any generated/intermediate string | 200M |
MYSQL_FT_MIN_WORD_LEN |
The minimum length of the word to be included in a FULLTEXT index | 4 |
MYSQL_FT_MAX_WORD_LEN |
The maximum length of the word to be included in a FULLTEXT index | 20 |
MYSQL_AIO |
Controls the innodb_use_native_aio setting value in case the native AIO is broken. See http://help.directadmin.com/item.php?id=529 |
1 |
MYSQL_TABLE_OPEN_CACHE |
The number of open tables for all threads | 400 |
MYSQL_KEY_BUFFER_SIZE |
The size of the buffer used for index blocks | 32M (or 10% of available memory) |
MYSQL_SORT_BUFFER_SIZE |
The size of the buffer used for sorting | 256K |
MYSQL_READ_BUFFER_SIZE |
The size of the buffer used for a sequential scan | 8M (or 5% of available memory) |
MYSQL_INNODB_BUFFER_POOL_SIZE |
The size of the buffer pool where InnoDB caches table and index data | 32M (or 50% of available memory) |
MYSQL_INNODB_LOG_FILE_SIZE |
The size of each log file in a log group | 8M (or 15% of available available) |
MYSQL_INNODB_LOG_BUFFER_SIZE |
The size of the buffer that InnoDB uses to write to the log files on disk | 8M (or 15% of available memory) |
MYSQL_DEFAULTS_FILE |
Point to an alternative configuration file | /etc/my.cnf |
MYSQL_BINLOG_FORMAT |
Set sets the binlog format, supported values are row and statement |
statement |
MYSQL_LOG_QUERIES_ENABLED |
To enable query logging, set this variable to 1 |
0 |
You can also set the following mount point by passing the -v /host:/container:Z flag to Docker:
| Volume Mount Point | Description |
|---|---|
/var/lib/mysql/data |
MySQL data directory |
Note: When mounting a directory from the host into the container, ensure that the mounted directory has the appropriate permissions and that the owner and group of the directory matches the user UID or name which is running inside the container, which is 27 by default.
MariaDB
Description
The rhscl/mariadb-101-rhel7 image provides a MariaDB 10.1 SQL database server; the rhscl/mariadb-100-rhel7 image provides a MariaDB 10.0 SQL database server.
Access
To pull the rhscl/mariadb-101-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/mariadb-101-rhel7
To pull the rhscl/mariadb-100-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/mariadb-100-rhel7
Usage and Configuration
The usage and configuration is the same as for the MySQL image. For details, see the MySQL section. Note that the name of the daemon is mysqld and all environment variables have the same names as in MySQL.
See also How to Extend the rhscl/mariadb-101-rhel7 Container Image .
PostgreSQL
Description
The rhscl/postgresql-95-rhel7 image provides a PostgreSQL 9.5 SQL database server; the rhscl/postgresql-94-rhel7 image provides a PostgreSQL 9.4 SQL database server.
Access and Usage
To pull the rhscl/postgresql-95-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/postgresql-95-rhel7
To pull the rhscl/postgresql-94-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/postgresql-94-rhel7
To set only the mandatory environment variables and not store the database in a host directory, execute the following command:
docker run -d --name postgresql_database -e POSTGRESQL_USER=user -e POSTGRESQL_PASSWORD=pass -e POSTGRESQL_DATABASE=db -p 5432:5432 rshcl/postgresql-94-rhel7
This will create a container named postgresql_database running PostgreSQL with database db and user with credentials user:pass. Port 5432 will be exposed and mapped to the host. If you want your database to be persistent across container executions, also add a -v /host/db/path:/var/lib/pgsql/data argument. This will be the PostgreSQL database cluster directory.
If the database cluster directory is not initialized, the entrypoint script will first run initdb and set up necessary database users and passwords. After the database is initialized, or if it was already present, postgres is executed and will run as PID 1. You can stop the detached container by running the docker stop postgresql_database command.
Configuration
The image recognizes the following environment variables that you can set during initialization by passing -e VAR=VALUE to the docker run command:
| Variable Name | Description |
|---|---|
POSTGRESQL_USER |
User name for PostgreSQL account to be created |
POSTGRESQL_PASSWORD |
Password for the user account |
POSTGRESQL_DATABASE |
Database name |
POSTGRESQL_ADMIN_PASSWORD |
Password for the postgres admin account (optional) |
Note: The postgres administrator account has no password set by default, only allowing local connections. You can set it by setting the POSTGRESQL_ADMIN_PASSWORD environment variable when initializing your container. This will allow you to login to the postgres account remotely. Local connections will still not require a password.
The following environment variables influence the PostgreSQL configuration file and are both optional:
| Variable Name | Description | Default |
|---|---|---|
POSTGRESQL_MAX_CONNECTIONS |
The maximum number of client connections allowed. This also sets the maximum number of prepared transactions. | 100 |
POSTGRESQL_SHARED_BUFFERS |
Sets how much memory is dedicated to PostgreSQL to use for caching data | 32M |
You can also set the following mount point by passing the -v /host:/container flag to Docker:
| Volume Mount Point | Description |
|---|---|
/var/lib/pgsql/data |
PostgreSQL database cluster directory |
Note: When mounting a directory from the host into the container, ensure that the mounted directory has the appropriate permissions and that the owner and group of the directory matches the user UID or name which is running inside the container.
MongoDB
Description
The rhscl/mongodb-32-rhel7 image provides a MongoDB 3.2 NoSQL database server and is based on the updated rh-mongodb32 Software Collection shipped in Red Hat Software Collections 2.3. The rhscl/mongodb-26-rhel7 image provides a MongoDB 2.6 NoSQL database server.
Access and Usage
To pull the rhscl/mongodb-32-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/mongodb-32-rhel7
To pull the rhscl/mongodb-26-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/mongodb-26-rhel7
To set only the mandatory environment variables and store the database in the /home/user/database directory on the host file system, execute the following command:
docker run -d -e MONGODB_USER=<user> -e MONGODB_PASSWORD=<password> -e MONGODB_DATABASE=<database> -e MONGODB_ADMIN_PASSWORD=<admin_password> -v /home/user/database:/var/lib/mongodb/data rhscl/mongodb-26-rhel7
Change the image name when appropriate.
If you are initializing the database and it is the first time you are using the specified shared volume, the database will be created with two users: admin and MONGODB_USER. After that, the MongoDB daemon will be started. If you are re-attaching the volume to another container, the creation of the database user and admin user will be skipped and only the MongoDB daemon will be started.
Configuration
The image recognizes the following environment variables that you can set during initialization by passing -e VAR=VALUE to the docker run command:
| Variable Name | Description |
|---|---|
MONGODB_USER |
User name for MONGODB account to be created |
MONGODB_PASSWORD |
Password for the user account |
MONGODB_DATABASE |
Database name |
MONGODB_ADMIN_PASSWORD |
Password for the admin user |
Note: The administrator user name is set to admin and you have to to specify the password by setting the MONGODB_ADMIN_PASSWORD environment variable. This process is done upon database initialization.
The following environment variables influence the MongoDB configuration file and are all optional:
| Variable Name | Description | Default |
|---|---|---|
MONGODB_NOPREALLOC |
Disable data file preallocation | true |
MONGODB_SMALLFILES |
Set MongoDB to use a smaller default data file size | true |
MONGODB_QUIET |
Runs MongoDB in a quiet mode that attempts to limit the amount of output | true |
Note: In the rhscl/mongodb-32-rhel7 image, the MONGODB_NOPREALLOC and MONGODB_SMALLFILES options are not effective.
You can also set the following mount point by passing the -v /host:/container flag to Docker:
| Volume Mount Point | Description |
|---|---|
/var/lib/mongodb/data |
MongoDB data directory |
Note: When mounting a directory from the host into the container, ensure that the mounted directory has the appropriate permissions and that the owner and group of the directory matches the user UID or name which is running inside the container.
Custom configuration file
It is possible to use a custom configuration file for the mongod server. Providing a custom configuration file supersedes the environment variable values of an individual configuration.
A custom configuration file used in a container has to be mounted into /etc/mongod.conf. For example, to use a configuration file stored in the /home/user directory, use the following option for the docker run command: -v /home/user/mongod.conf:/etc/mongod.conf:Z.
Note: The custom configuration file does not affect the name of a replica set. The replica set name has to be set in the MONGODB_REPLICA_NAME environment variable.
Redis
Description
The rhscl/redis-32-rhel7 image provides Redis 3.2, an advanced key-value store. The image is based on the rh-redis32 Software Collection shipped in Red Hat Software Collections 2.3.
Access
To pull the rhscl/redis-32-rhel7 image, run the following command as root:
docker pull registry.access.redhat.com/rhscl/redis-32-rhel7
Configuration
The following environment variable influences the Redis configuration file and is optional:
| Variable Name | Description |
|---|---|
REDIS_PASSWORD |
Password for the server access |
You can also set the following mount point by passing the -v /host:/container flag to Docker:
| Volume Mount Point | Description |
|---|---|
/var/lib/redis/data |
Redis data directory |
Note: When mounting a directory from the host into the container, ensure that the mounted directory has the appropriate permissions and that the owner and group of the directory matches the user UID or name that is running inside the container. The default UID for this container is 1001.
Comments