container/python3
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Blind update from upstream Github - Fedora 31, Python 3.7

Browse source
This commit is contained in:
Lumir Balhar 2020-01-07 08:51:45 +01:00
commit c1cc83f38d
35 changed files with 2266 additions and 176 deletions
Download patch file Download diff file Expand all files Collapse all files

176
README.md
View file

@ -1,29 +1,47 @@
Python Docker image
Python 3.7 container image
===================
This repository contains the source for building various versions of
the Python application as a reproducible Docker image using
[source-to-image](https://github.com/openshift/source-to-image).
This container image includes Python 3.7 as a [S2I](https://github.com/openshift/source-to-image) base image for your Python 3.7 applications.
Users can choose between RHEL and CentOS based builder images.
The resulting image can be run using [Docker](http://docker.io).
The RHEL images are available in the [Red Hat Container Catalog](https://access.redhat.com/containers/),
the CentOS images are available on [Docker Hub](https://hub.docker.com/r/centos/),
and the Fedora images are available in [Fedora Registry](https://registry.fedoraproject.org/).
The resulting image can be run using [podman](https://github.com/containers/libpod) or
[docker](http://docker.io).
Note: while the examples in this README are calling `podman`, you can replace any such calls by `docker` with the same arguments
Description
-----------
Python 3.7 available as container is a base platform for
building and running various Python 3.7 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.
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.
Usage
---------------------
To build a simple [python-sample-app](https://github.com/openshift/s2i-python/tree/master/3.6/test/setup-test-app) application
using standalone [S2I](https://github.com/openshift/source-to-image) and then run the
resulting image with [Docker](http://docker.io) execute:
* **For RHEL based image**
For this, we will assume that you are using the `rhscl/python-37-rhel7 image`, available via `python:3.7` imagestream tag in Openshift.
Building a simple [python-sample-app](https://github.com/sclorg/s2i-python-container/tree/master/3.7/test/setup-test-app) application
in Openshift can be achieved with the following step:
```
$ 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
$ docker run -p 8080:8080 python-sample-app
oc new-app python:3.6~https://github.com/sclorg/s2i-python-container.git --context-dir=3.7/test/setup-test-app/
```
* **For CentOS based image**
The same application can also be built using the standalone [S2I](https://github.com/openshift/source-to-image) 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/ centos/python-36-centos7 python-sample-app
$ docker run -p 8080:8080 python-sample-app
$ s2i build https://github.com/sclorg/s2i-python-container.git --context-dir=3.7/test/setup-test-app/ rhscl/python-37-rhel7 python-sample-app
```
**Accessing the application:**
@ -31,61 +49,6 @@ resulting image with [Docker](http://docker.io) execute:
$ curl 127.0.0.1:8080
```
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](https://github.com/openshift/source-to-image):
* **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](https://github.com/openshift/source-to-image)
test framework with a simple server.
* **`setup-test-app/`**
Simple Gunicorn application used for testing purposes by the [S2I](https://github.com/openshift/source-to-image) test framework.
* **`standalone-test-app/`**
Simple standalone application used for testing purposes by the [S2I](https://github.com/openshift/source-to-image) test framework.
* **run**
Script that runs the [S2I](https://github.com/openshift/source-to-image) test framework.
Environment variables
---------------------
@ -119,7 +82,7 @@ file inside your source code repository.
If using `setup.py` for installing the application, the `MODULE_NAME` part
can be read from there. For an example, see
[setup-test-app](https://github.com/openshift/s2i-python/tree/master/3.6/test/setup-test-app).
[setup-test-app](https://github.com/sclorg/s2i-python-container/tree/master/3.7/test/setup-test-app).
* **APP_HOME**
@ -134,33 +97,62 @@ file inside your source code repository.
Path to a valid Python file with a
[Gunicorn configuration](http://docs.gunicorn.org/en/latest/configure.html#configuration-file) file.
* **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 only affects Django projects. See
"Handling Database Migrations" section of [Django blogpost on OpenShift blog](
https://blog.openshift.com/migrating-django-applications-openshift-3/) 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.
* **DISABLE_COLLECTSTATIC**
Set this variable to a non-empty value to inhibit the execution of
'manage.py collectstatic' during the build. This only affects Django projects.
* **DISABLE_MIGRATE**
* **DISABLE_SETUP_PY_PROCESSING**
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.
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.
* **ENABLE_PIPENV**
Set this variable to use [Pipenv](https://github.com/kennethreitz/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.
* **ENABLE_INIT_WRAPPER**
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.
* **PIP_INDEX_URL**
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.
* **UPGRADE_PIP_TO_LATEST**
Set this variable to a non-empty value to have the 'pip' program 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 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.
* **WEB_CONCURRENCY**
Set this to change the default setting for the number of
[workers](http://docs.gunicorn.org/en/stable/settings.html#workers). By
default, this is set to the number of available cores times 2.
default, this is set to the number of available cores times 2, capped
at 12.
Source repository layout
------------------------
@ -174,18 +166,26 @@ However, if these files exist they will affect the behavior of the build process
[here](https://pip.pypa.io/en/latest/user_guide.html#requirements-files).
* **Pipfile**
The replacement for requirements.txt, project is currently under active
design and development, as documented [here](https://github.com/pypa/pipfile).
Set `ENABLE_PIPENV` environment variable to true in order to process this file.
* **setup.py**
Configures various aspects of the project, including installation of
dependencies, as documented
[here](https://packaging.python.org/en/latest/distributing.html#setup-py).
For most projects, it is sufficient to simply use `requirements.txt`.
For most projects, it is sufficient to simply use `requirements.txt` or
`Pipfile`. Set `DISABLE_SETUP_PY_PROCESSING` environment variable to true
in order to skip processing of this file.
Run strategies
--------------
The Docker image produced by s2i-python executes your project in one of the
The container image produced by s2i-python executes your project in one of the
following ways, in precedence order:
* **Gunicorn**
@ -235,12 +235,20 @@ 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](https://docs.docker.com/reference/commandline/exec/) command:
To change your source code in running container, use podman's (or docker's)
[exec](https://github.com/containers/libpod/blob/master/docs/podman-exec.1.md) command:
```
docker exec -it <CONTAINER_ID> /bin/bash
podman 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.
See also
--------
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 `Dockerfile.rhel7`,
for RHEL8 it's `Dockerfile.rhel8` and the Fedora Dockerfile is called `Dockerfile.fedora`.