Public | Automated Build

Last pushed: a year ago
Short Description
FFI Support for Python 3.5
Full Description

Python Docker image

This repository contains the source for building various versions of
the Python application as a reproducible Docker image using
Users can choose between RHEL and CentOS based builder images.
The resulting image can be run using Docker.


To build a simple python-sample-app application
using standalone S2I and then run the
resulting image with Docker execute:

  • For RHEL based image

     $ s2i build --context-dir=3.5/test/setup-test-app/ rhscl/python-35-rhel7 python-sample-app
     $ docker run -p 8080:8080 python-sample-app
  • For CentOS based image

     $ s2i build --context-dir=3.5/test/setup-test-app/ centos/python-35-centos7 python-sample-app
     $ docker run -p 8080:8080 python-sample-app

Accessing the application:

$ curl

Repository organization

  • <python-version>

    • Dockerfile

      CentOS based Dockerfile.

    • Dockerfile.rhel7

      RHEL based Dockerfile. In order to perform build or test actions on this
      Dockerfile you need to run the action on a properly subscribed RHEL machine.

    • s2i/bin/

      This folder contains scripts that are run by S2I:

      • assemble

        Used to install the sources into the location where the application
        will be run and prepare the application for deployment (eg. installing
        dependencies, etc.)

      • run

        This script is responsible for running the application by using the
        application web server.

      • usage*

        This script prints the usage of this image.

    • contrib/

      This folder contains a file with commonly used modules.

    • test/

      This folder contains a S2I
      test framework with a simple server.

      • setup-test-app/

        Simple Gunicorn application used for testing purposes by the S2I test framework.

      • standalone-test-app/

        Simple standalone application used for testing purposes by the S2I test framework.

      • run

        Script that runs the S2I test framework.

Environment variables

To set these environment variables, you can place them as a key value pair into a .s2i/environment
file inside your source code repository.


    Used to run the application from a Python script.
    This should be a path to a Python file (defaults to that will be
    passed to the Python interpreter to start the application.


    Used to run the application with Gunicorn, as documented
    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
    file in your project and use it if it exists.

    If using for installing the application, the MODULE_NAME part
    can be read from there. For an example, see


    Path to a valid Python file with a
    Gunicorn configuration file.


    Set this variable to a non-empty value to inhibit the execution of
    ' collectstatic' during the build. This only affects Django projects.


    Set this variable to a non-empty value to inhibit the execution of ' migrate'
    when the produced image is run. This only affects Django projects.


    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.


    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.

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:

  • requirements.txt

    List of dependencies to be installed with pip. The format is documented


    Configures various aspects of the project, including installation of
    dependencies, as documented
    For most projects, it is sufficient to simply use requirements.txt.

Run strategies

The Docker image produced by s2i-python executes your project in one of the
following ways, in precedence order:

  • Gunicorn

    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.txt
    file or in the install_requires section of the file.

    If a file named is 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.

  • Python script

    This is the most general way of executing your application. It will be used
    in the case where you specify a path to a Python script via the APP_FILE environment
    variable, defaulting to a file named if it exists. The script is
    passed to a regular Python interpreter to launch your application.

Hot deploy

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 APP_CONFIG
environment variable.

To change your source code in running container, use Docker's
exec command:

docker exec -it <CONTAINER_ID> /bin/bash

After you enter into the running container, your current directory is set
to /opt/app-root/src, where the source code is located.

Docker Pull Command