Python 3.6 container image
This container image includes Python 3.6 as a S2I base image for your Python 3.6 applications. Users can choose between RHEL and CentOS 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 or docker.
Note: while the examples in this README are calling
podman, you can replace any such calls by
docker with the same arguments
Python 3.6 available as container is a base platform for building and running various Python 3.6 applications and frameworks. Python is an easy to learn, powerful programming language. It has efficient high-level data structures and a simple but effective approach to object-oriented programming. Python's elegant syntax and dynamic typing, together with its interpreted nature, make it an ideal language for scripting and rapid application development in many areas on most platforms.
For this, we will assume that you are using the
rhscl/python-36-rhel7 image, available via
python:3.6 imagestream tag in Openshift.
Building a simple python-sample-app application
in Openshift can be achieved with the following step:
``` oc new-app python:3.6~https://github.com/sclorg/s2i-python-container.git --context-dir=3.6/test/setup-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-python-container.git --context-dir=3.6/test/setup-test-app/ rhscl/python-36-rhel7 python-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.
Used to run the application from a script file. This should be a path to a script file (defaults to
app.shunless set to null) that will be run to start the application.
Used to run the application from a Python script. This should be a path to a Python file (defaults to
app.pyunless set to null) that will be passed to the Python interpreter to start the application.
Used to run the application with Gunicorn, as documented here. This variable specifies a WSGI callable with the pattern
MODULE_NAMEis the full dotted path of a module, and
VARIABLE_NAMErefers to a WSGI callable inside the specified module. Gunicorn will look for a WSGI callable named
applicationif not specified.
APP_MODULEis not provided, the
runscript will look for a
wsgi.pyfile in your project and use it if it exists.
setup.pyfor installing the application, the
MODULE_NAMEpart can be read from there. For an example, see setup-test-app.
This variable can be used to specify a sub-directory in which the application to be run is contained. The directory pointed to by this variable needs to contain
wsgi.py(for Gunicorn) or
APP_HOMEis not provided, the
runscripts will use the application's root directory.
Path to a valid Python file with a Gunicorn configuration file.
Set this variable to a non-empty value to inhibit the execution of 'manage.py migrate' when the produced image is run. This only affects Django projects. See "Handling Database Migrations" section of Django blogpost on OpenShift blog on suggestions how/when to run DB migrations in OpenShift environment. Most importantly, note that running DB migrations from two or more pods might corrupt your database.
Set this variable to a non-empty value to inhibit the execution of 'manage.py collectstatic' during the build. This only affects Django projects.
Set this to a non-empty value to skip processing of setup.py script if you use
-e .in requirements.txt to trigger its processing or you don't want your application to be installed into site-packages directory.
Set this variable to use Pipenv, the higher-level Python packaging tool, to manage dependencies of the application. This should be used only if your project contains properly formated Pipfile and Pipfile.lock.
Set this variable to a non-empty value to make use of an init wrapper. This is useful for servers that are not capable of reaping zombie processes, such as Django development server or Tornado. This option can be used together with APP_SCRIPT or APP_FILE. It never applies to Gunicorn used through APP_MODULE as Gunicorn reaps zombie processes correctly.
Set this variable to use a custom index URL or mirror to download required packages during build process. This only affects packages listed in requirements.txt. Pipenv ignores this variable.
Set this variable to a non-empty value to have the 'pip' program and related python packages (setuptools and wheel) be upgraded to the most recent version before any Python packages are installed. If not set it will use whatever the default version is included by the platform for the Python version being used.
Set this to change the default setting for the number of workers. By default, this is set to the number of available cores times 2, capped at 12.
Source repository layout
You do not need to change anything in your existing Python project's repository. However, if these files exist they will affect the behavior of the build process:
List of dependencies to be installed with
pip. The format is documented here.
The replacement for requirements.txt, project is currently under active design and development, as documented here. Set
ENABLE_PIPENVenvironment variable to true in order to process this file.
Configures various aspects of the project, including installation of dependencies, as documented here. For most projects, it is sufficient to simply use
DISABLE_SETUP_PY_PROCESSINGenvironment variable to true in order to skip processing of this file.
The container image produced by s2i-python executes your project in one of the following ways, in precedence order:
The Gunicorn WSGI HTTP server is used to serve your application in the case that it is installed. It can be installed by listing it either in the
requirements.txtfile or in the
install_requiressection of the
If a file named
wsgi.pyis present in your repository, it will be used as the entry point to your application. This can be overridden with the environment variable
APP_MODULE. This file is present in Django projects by default.
If you have both Django and Gunicorn in your requirements, your Django project will automatically be served using Gunicorn.
Django development server
If you have Django in your requirements but don't have Gunicorn, then your application will be served using Django's development web server. However, this is not recommended for production environments.
This would be used where you provide a Python code file for running you application. It will be used in the case where you specify a path to a Python script via the
APP_FILEenvironment variable, defaulting to a file named
app.pyif it exists. The script is passed to a regular Python interpreter to launch your application.
Application script file
This is the most general way of executing your application. It will be used in the case where you specify a path to an executable script file via the
APP_SCRIPTenvironment variable, defaulting to a file named
app.shif it exists. The script is executed directly to launch your application.
If you are using Django, hot deploy will work out of the box.
To enable hot deploy while using Gunicorn, make sure you have a Gunicorn
configuration file inside your repository with the
option set to
true. Make sure to specify your config via the
To change your source code in running container, use podman's (or docker's) exec command:
podman exec -it <CONTAINER_ID> /bin/bash
After you enter into the running container, your current directory is set
/opt/app-root/src, where the source code is located.
Dockerfile and other sources are available on https://github.com/sclorg/s2i-python-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